Hiển thị các bài đăng có nhãn Git. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn Git. Hiển thị tất cả bài đăng

Thứ Ba, 16 tháng 3, 2021

Git Cheat Sheet

 ## 1. install git

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

sudo apt-get update
sudo apt-get install git

- set up global user information:
git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com"

- set up specific user for each project:
git config user.name "Your Name"
git config user.email "youremail@domain.com"

## 2. Config file mode
File config in a project: `.git/config`
Don't check file mode in global: `git config --global core.filemode false`
Don't check file mode in specific project:`cd project_name && git config core.filemode false`

Check after change: `git config core.filemode`

## 3. Command to specify your preferences
git config --global core.editor your_editor_choice
EX: `git config --global core.editor nano`

## 4. Where is gitconfig
The global Git configuration file is stored
at $HOME/.gitconfig on all platforms.
git config --global --edit

## 5. Increase performance of git
git prune
--------Enable the filesystem cache
`git config core.fscache true` or

git gc(https://git-scm.com/docs/git-gc)
git clean

git config --global core.preloadindex true
git config --global core.fscache true
git config --global gc.auto 256

## 6. Clone new project
git clone https://github.com/libgit2/libgit2
git clone git@git_server_IP_address:johnsproject

## 7. create new branch
Make format branch name clearly: feature/<date>_<feature-name>

git checkout develop
git checkout -b feature/20170605_check_connection
git push origin feature/20170605_check_connection

## 8. GET ONE COMMIT FROM ANOTHER BRANCH
git cherry-pick 62ecb3
https://ariejan.net/2010/06/10/cherry-picking-specific-commits-from-another-branch/

## 9. Show list branches
git branch
git branch -a | grep -v 'remotes'
git branch onflict

Delete local branch: git branch -D <branch_name>
Delete remote branch: git branch -dr <branch_name>

## 10. Show current git info
- Show file changes: `git status`
- git show

- you can show commit_id by this command: `git log`
- git log -2

## 11. Fetch data
git fetch
git fetch --all

## 12. Pull data
git pull
$git pull origin master

***Pull data with develop to refesh commit already appear in branch develop***

$git pull --rebase origin develop
$git push -f origin feature/201807_output_announce

## 13. Get list remote branches
git remote -v

## 14. Reset or Revert to HEAD version
git reset HEAD --hard
git reset --hard HEAD~n

## 15. Checkout new branch or switch local branch
- switch local branch: git checkout <branch_name>
- create new branch: git checkout -b qa/201705_new_branch origin/qa/201705_original_branch

## 16. Git commit with message
$git commit -a -m "<message>"
$git commit --allow-empty -m "<message>"

- commit with ignore check validation before commit:
git commit -m "update code" --no-verify

## 17. Push data to server
- git push origin master
- Force all thing in local branch to remote branch:
`git push -f origin feature/20200202_force_all_data`

## 18. Show diff status between remote and local branch
$ git diff

------------git: diff between file in local repo and origin
$ git fetch origin master
$ git diff origin/master -- [local-path]

$ git diff master:<path-or-file-name>

------------Show overwrite file, change files with git diff
git diff origin/develop --name-only --diff-filter=acdrtuxb -- ./frontend/touch/common

## 19. Add new file
$ git add keydir/john.pub
$ git add Documentation/\*.txt
$ git add git-*.sh

Add all file: $git add .

## 20. Undo git add
git reset <file>
git reset
git reset HEAD --hard

git rm <path>
git rm --cached <path>
git reset HEAD <path>

Examples:

git add file1
git stage file2
git reset HEAD -- file2
git reset HEAD -- file1
git reset HEAD myfile.txt
git reset HEAD *.bmp
------will "un-add" everything you've added from your current directory recursively

git rm --cached . -r
git reset *

## 21. Submodule
git submodule sync
git submodule update --init --recursive

-----setup submodule
git submodule foreach git reset --hard HEAD
git submodule foreach git status
git submodule update --init --recursive
git submodule foreach git reset --hard HEAD

## 22. Merge branch
git checkout -b qa/201705_test origin/qa/201705_test
git merge origin/feature/201705_feature_1
git push origin qa/201705_test

## 23. Revert n commit
you can show commit_id by this command: `git log`
-
git reset --hard HEAD~n
OR
git revert (commit_id)
- git push -f origin feature/<branch_name>

## 24. Delete a commit
$git rebase -i
https://stackoverflow.com/questions/1338728/delete-commits-from-a-branch-in-git
https://www.clock.co.uk/insight/deleting-a-git-commit

## 25. Merge commit bằng rebase - Rebasing
Step 1: merge n commit
$ git rebase -i HEAD~n
==> when editor open, keep first commit as current,
for another commit change text "pick" to "f"
and then save.

Step 2: push commit after merge( with force -f)
git push -f origin feature/<...>

If you want to UNDO a git rebase
⇒ git rebase --abort
https://git-scm.com/docs/git-rebase/1.8.2.2

## 26. Fix Conflict File In Git
Replace file with file get from remote branch:
`git checkout --theirs Path/file.dll`

> $ git add Path/file.dll
> $ git commit -m "Resolved merge conflict"

## 27. Rename a branch
- a) Rename your local branch.
If you are on the branch you want to rename: `git branch -m new-name`
If you are on a different branch: `git branch -m old-name new-name`

- b) Delete the old-name remote branch and push the new-name local branch.
Note: keep “:”, don’t remove it.

git push origin :old-name new-name

- c) Reset the upstream branch for the new-name local branch.
Switch to the branch and then: `git push origin -u new-name`

## 28. Revert a file
git checkout HEAD filename
Or
git checkout [commit-ref] -- [filename]
git checkout [commit-ref] [filename]

git checkout HEAD~5 -- foo.bar or git checkout 048ee28 -- foo.bar
$ git add filename
$ git commit -m 'restoring filename from first commit.'

Example:
git checkout 3db97069620dce547f0a30d5d66196ccc347b6b8 frontend/v3.1/abc.zip
git add frontend/v3.1/abc.zip
git commit -m 'revert abc v3.1'
git push origin feature/201803_revert

## 29. Revert a deleted file
If the deletion has not been committed,
the command below will restore the deleted file in the working tree.
$ git checkout -- <file>

You can get a list of all the deleted files
in the working tree using the command below.
$ git ls-files --deleted


If the deletion has been committed,
find the commit where it happened, then recover the file from this commit.
$ git rev-list -n 1 HEAD -- <file>
$ git checkout <commit>^ -- <file>

In case you are looking for the path of the file to recover,
the following command will display a summary of all deleted files.
$ git log --diff-filter=D --summary

## 30. How to change your commit messages in Git
https://gist.github.com/nepsilon/156387acf9e1e72d48fa35c4fabef0b4
Not pushed + most recent commit: `git commit --amend`
This will open your $EDITOR and let you change the message.
Continue with your usual git push origin master.

Already pushed + most recent commit: `git commit --amend`
`git push origin master --force`

We edit the message like just above.
But need to --force the push to update the remote history.

⚠️ But! Force pushing your commit after changing
it will very likely prevent others to sync with the repo,
if they already pulled a copy. You should first check with them.

Not pushed + old commit: `git rebase -i HEAD~X`
# X is the number of commits to go back
# Move to the line of your commit, change pick into edit,
# then change your commit message: git commit --amend
# Finish the rebase with: git rebase --continue

Rebase opened your history and let you pick what to change.
With edit you tell you want to change the message.
Git moves you to a new branch to let you --amend the message.
git rebase --continue puts you back in your previous branch
with the message changed.

Already pushed + old commit:

Edit your message with the same 3 steps process as above
(rebase -i, commit --amend, rebase --continue).
Then force push the commit: `git push origin master --force`
⚠️ But! Remember re-pushing your commit after changing
it will very likely prevent others to sync with the repo,
if they already pulled a copy. You should first check with them.

## 31. Delete a file

Use git rm: `git rm file1.txt git commit -m "remove file1.txt"`
But if you want to remove the file only from the Git repository
and not remove it from the filesystem, use:
git rm --cached file1.txt
git commit -m "remove file1.txt
And to push changes to remote repo
git push origin branch_name

## 32. How to remove local (untracked) files from the current Git working tree?

As per the Git Documentation git clean
Step 1 is to show what will be deleted by using the -n option: `git clean -n`

Clean Step - beware: this will delete files: `git clean -f`

To remove directories, run `git clean -f -d` or `git clean -fd`

To remove ignored files, run `git clean -f -X` or `git clean -fX`

To remove ignored and non-ignored files, run `git clean -f -x` or `git clean -fx`

Note the case difference on the X for the two latter commands.
If clean.requireForce is set to "true" (the default) in your configuration,
one needs to specify -fotherwise nothing will actually happen.
Again see the git-clean docs for more information.
If needed to remove untracked files from particular subdirectory, git clean -f {dir_path}
And combined way to delete untracked dir/files and ignored files.
git clean -fxd {dir_path}
after this you will have modified files only in git status.
Example: $git clean -fd frontend/
## 33. Fix error “fatal: missing object in git”

rm -rf objects/c65d9adb7d5151df89aac3d52a2e018066dafc65
find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full
rm .git/index
git reset HEAD --hard
rm .git/HEAD
echo 'ref: refs/heads/master' > .git/HEAD
git status
git reset HEAD --hard
Git pull origin master
fatal: missing object c65d9adb7d5151df89aac3d52a2e018066dafc65 for refs/heads/feature/201804_sheep
$ git reset HEAD c65d9adb7d5151df89aac3d52a2e018066dafc65
$ git fsck

## 34. Git – Revert File to Previous Commit
Git – Revert Changes to File

Revert (reset) changes to a file if they haven’t been committed yet:
`$ git checkout -- <file>`

Revert (reset) a single file to a specific revision:
`$ git checkout <commit_hash> -- <file>`

## 35. How to view a file at a specific commit in git

$ git show REVISION:/path/to/file
You can also save a copy by

$ git show REVISION:/path/to/file >file.copy
Ex: git show HEAD~4:src/main.c

To show only commits of an individual file, run this command:
`$ git log -- <file>`

Run the below command to show commits of the particular file with diffs for each change:
`$ git log -p -- <file>`

Show the entire history of a file (including history beyond renames):
`$ git log --follow -p -- <file>`

https://www.thegeekstuff.com/2014/04/git-log/

$ git log --pretty=format:"Commit Hash: %H, Author: %aN, Date: %aD"

## 36. overwrite a branch in Git with master
git checkout dev_branch
git reset --hard master
git push -f origin dev_branch

## 37. Change default branch of a repository
https://stackoverflow.com/questions/51274430/change-from-master-to-a-new-default-branch-git

## 38. Git stash
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

// use -u when you want to save new file
git stash save "save 2" -u

--------Get list file changes have save

git stash list -p
// See detail of a specific changes:
git stash show stash@{index}
// Apply a stash:
git stash apply stash@{index}
OR
git stash pop index
--------Remove stash
Apply a stash and then delete it:
git stash apply stash@{index}
git stash drop stash@{index}
OR
git stash pop stash@{index}
Delete all stash:

git stash clear

Thứ Năm, 28 tháng 7, 2016

Git va SVN

Rất nhiều nhà phát triển đã từng nghe về cái gọi là version control, nhưng họ có thể không biết đầy đủ về chúng là cái gì và lợi ích của chúng trong quản lý dự án của họ như nào. Trong bài viết này chúng ta đi tìm hiểu lợi ích công việc với version control và sự khác nhau giữa GIT và SVN, những cái version control được dùng nhiều nhất hiện nay.Phương án đơn giản nhất để giải thích Version control là sử dụng các kho dự án file cùng nhau với lịch sử của các mã nguồn của bạn trong cùng một vị trí. Điều này làm cho những nhà phát triển dự án theo dõi mỗi sự thay đổi tạo ra với mã nguồn, những ai làm thay đổi và lý do thay đổi.
Những file đó bình thường sẽ nằm trên một vài server từ máy tính của những nhà phát triển, sau đó họ đẩy những file của họ lên khi hoàn thành việc gõ xong mã nguồn.
Nó cũng cho phép bạn đánh dấu mã nguồn của bạn vào thời điểm đó, tạo dễ dàng quay trời lại thời điểm đó nếu những tính năng mới đó làm đổ vỡ mã nguồn của bạn. Version control có thể cũng có lợi cho nhà phát triển độc lập(một mình) trên dự án của họ và nó cần thiết cho đội những nhà phát triển làm việc trên cùng một dự án.

 TẠI SAO PHẢI SƯ DỤNG VERSION CONTROL?

Version control là cần thiết khi làm việc cho đội phát triển, nếu bạn đang làm với đội phát triển và không có version control, chắc chắn bất kì một ai đó sẽ dừng công việc bởi không biết ai làm cái gì và đọc điều đó ở đâu.
Nếu bạn không có version control, phương án duy nhất bạn có thể làm việc là chia sẻ mã nguồn của bạn trên các nơi lưu trữ có thể và bạn có thể truy cập tất cả file mã nguồn đó để thấy những thay đổi đó. Nhưng mọi thứ đều làm công việc đi sai hướng, đầu tiên là không có từ hai nhà phát triển làm việc trên cùng một file ở cùng một thời điểm. Nếu hơn hai nhà phát triển làm việc trên nó, người cuối cùng lưu lại sẽ vượt quyền thay đổi những mã nguồn của người khác. Sử dụng version control giúp cho nhiều nhà phát triển làm việc trên một file ở cùng một thời điểm, khi họ đã hoàn thành những thay đổi mã nguồn, họ có thể commit chúng trở lại kho mã nguồn. Khi bạn đã commit file quay trở lại kho, nó sẽ trộn lẫn những thay đổi đó trong version control.
Vấn đề thứ hai đó là không có lịch sử mã nguồn vì vậy nếu bạn tạo ra một tính năng mới và demo nó với khách hàng và họ quyết định họ không muốn nó nữa, bạn sẽ phải đi tới mã nguồn và xóa đi những thứ mà bạn đã làm. Nếu bạn đã sử dụng version control bạn có thể sẽ lấy lại mã nguồn trước khi phát triển những tính năng mới đó.
Vấn đề thứ ba cho việc bạn không thể sử dụng thiếu version control đó là tính năng “trách nhiệm”. Version control sẽ ghi lại ai đã viết ra các phần mã nguồn, điều đó có nghĩa là với nhũng phần mã nguồn mà bạn không biết tại sao nó ở đây, bạn sử dụng version control để kiểm tra mã nguồn để nói với bạn, nhà phát triển nào viết điều đó vì vậy bạn có thể hỏi nhà phát triển đó giải thích lý do tại sao họ làm điều này.
Tagging là một tính năng quan trọng bạn cần có để nâng cao khi làm việc với versioncontrol.Khi bạn hoàn thành với một phần công việc và sẵn cho việc triển khai mã nguồn, bạn sau đó tag phiên bản mã nguồn đó. Điều đó là cần thiết cho việc tạo ra các nhánh mã nguồn khác nhau ở thời điểm tạo đó. Sau đó bạn có thể triển khai mã nguồn với những tag đó, cho phép bạn trích xuất ra mã nguồn đó mà bạn có trên máy chủ. Lợi ích của điều này nếu có vấn đề với phiên bản phát hành hiện tại đó, bạn có thể dễ dàng quay trở lại thời điểm tạo ra tag đó.

LỰA CHỌN VERSION CONTROL

Bây giờ bạn đã hiểu những lợi ích của việc sử dụng version control, nhưng giờ bạn sẽ lựa chọn cái nào để dùng?
Có nhiều kiểu phiên bản version control, ở đây chúng ta sẽ xem xét hai version control hay dùng và phổ biết nhất hiện nay là Git và SVN. Bạn có thể thấy chúng khá giống nhau, nhưng phương án làm việc của hai cái đó là khác nhau hoàn toàn. Không có cái nào là tốt hơn cái nào, nó tùy thuộc vào việc bạn sẽ học nó và phục vụ cho công việc của bạn, cũng như cái gì bạn muốn sử dụng nó.

SVN

SVN or Subversion là một trong những version control được sử dụng phổ biến hiện nay, nó dễ hiểu và rất rõ trong các luồng công việc. Hiện tại kho plugin WordPress sử dụng SVN.
Nó làm việc với một máy chủ trung tâm kho mã nguồn, những kho đó là được chia vào 3 key chính đó là Trunk, Branches(nhánh), tags. Mỗi cái đều có vai trò quan trọng của riêng chúng.
Trunk
Cái này là nơi lưu trữ mã nguồn gốc, nó sẽ không được commit các phần mã nguồn vào trong đó, nó giống như khu vực trung tâm nơi bất cứ ai làm việc trên dự án sẽ lấy các cập nhật tại đây. Khi bạn làm việc với một tính năng mới bạn sẽ branches (nhánh) mã nguồn từ trunk, khi bạn gõ mã hoàn thành tính năng mới đó, sau đó bạn sẽ merge tất cả những thay đổi đó vào trunk.
Branches
Như giải thích ở trên branch(nhánh) là sử dụng khi bạn tạo ra một tính năng mới, vì vậy bạn branch mã nguồn từ trunk. Điều này nghĩa là bạn có thể lấy ra bản sao chép trunk và đặt điều này vào trong một folder mới bện trong khu vực branch. Bây giờ bạn có thể làm việc trong đó với việc tạo ra tính năng mới của bạn, sau khi hoàn thanh bạn sẽ merge những thay đổi đó vào trong trunk.
Lợi ích của điều này giúp cho bạn phát triển tính năng mới mà bạn có thể commits vào trong branche(nhánh) và bạn có thể không làm đổ vỡ trunk cho một ai đó khác làm việc trên cùng dự án., nó giữ cho trunk ổn định nhất có thể.
 Tags
Tag là phương án tạo mã nguồn của bạn vào một thời điểm nào đó, nó giống như branch làm với mã nguồn của bạn. Chúng sẽ làm điều đó với một bản sao chép từ mã nguồn trunk và đặt nó vào bên trong một folder mới với thư mục tag. Sự khác nhau đó là tag sẽ không bao giờ sử dụng cho phát triển mã nguồn, chúng là phưong án dễ dàng cho việc lấy lại mã nguồn của bạn.
 Thời điểm khi sử dụng tag là cho việc triển khai mã nguồn, khi bạn hoàn thành những mã nguồn mới, mereg vào trong trunk, test đầy đủ và sẵn sàng cho việc phát hành, khi đó bạn sử dụng tag. Bạn sẽ tạo tag trên trunk và đánh dấu tính năng mới đó, bạn có thể nắm giữ tag và triển khai nó tới máy chủ của bạn. Lợi ích làm điều này là nếu bản phát hành mới đổ vỡ, bạn có thể lấy lại mã nguồn quay trở lại thời điểm tag trước đó.

GIT 

Thời điểm này GIT là một version control phổ biến và hay dùng nhất, bởi sự phổ biết của website Github. Giống như trước đây đã đề cập GIT và SVN là khá giống nhau nhưng luồng công việc là có chút ít khác nhau. SVN là chỉ có một kho trung tâm, nhưng GIT có đa kho, tức là một kho trung tâm những mỗi nhà phát triển có những kho riêng của họ.
Lợi ích cho việc chia nhỏ đó vào trong nhiều kho mã nguồn đó là sự hỏng hóc ở một chỗ nào đó. Với SVN nếu kho trung tâm là bị hỏng hoặc mã nguồn bị đổ vỡ sau khi phát triển, thì không một nhà phát triển nào khác sử dụng cho việc commit mã nguồn của họ cho đến khi kho được sủa chữa lại. Với GIT thì mỗi nhà phát triển đều có một kho riêng của họ, nó không phải là kho chính nếu kho chính bị đổ vỡ, họ có thể tiếp tục commit mã nguồn trên kho cá nhân , cho đến khi kho chính là được sửa và sau đó họ có thể đẩy mã nguồn của họ vào trong kho chính đó.
 Một lợi ích khác là kho cá nhân đó là commit nhanh, không mất băng thông mạng cần cho việc commit mã nguồn vào trong source control, những nhà phát triển có thể làm việc độc lập cho đến khi sẵn đẩy mã nguồn tới kho chính.
Luồng công việc mà bạn sử dụng khi phát triển với việc dùng GIT như sau:
 Khi làm việc trên dự án bạn sẽ sao chép bản sao mã nguồn từ kho chính, có nghĩa rằng bạn có thể tạo ra một bản sao mã nguồn ở thời điểm đó. Điều này tạo ra một kho GIT cục bộ trên máy tính cá nhân của bạn, nơi bạn có thể tiếp tục công việc cho việc phát triểnt tính năng mới. Bạn có thể sử dụng kho cục bộ đó như sử dụng nó như sử dụng SVN đó là tạo branche mới , tags mới và tiếp tục commit mã nguồn lên kho cục bộ trong khi phát triển.
 Khi tính năng mới của bạn hoàn thành và bạn sẵn merge những thay đổi đó vào trong kho chính bạn cần đẩy những thay đổi đó lên từ kho cục bộ của bạn tới kho chính. Đây chỉ là phần ít sử dụng nhất trong GIT và nó tương tự như commit trong SVN, nhưng bạn sẽ không thường sử dụng commit và sử dụng commit trong GIT nhanh chóng.

Học lập trình web căn bản với PHP

Bài 1: Các kiến thức căn bản Part 1:  https://jimmyvan88.blogspot.com/2012/05/can-ban-lap-trinh-web-voi-php-bai-1-cac.html Part 2:  https://...