In team development, it is important to follow a logical and clear git usage process.
Otherwise, everyone commits a bunch of messy commits, and the project will quickly become difficult to reconcile and maintain.
The following is a Thoughtbot git usage specification process. I've learned a lot from it, and I recommend that you use Git as well.
First step: Create a new branch
First, each time you develop a new feature, you should create a separate branch (refer to the GIT Branch management policy).
?
123456 |
# 获取主干最新代码 $ git checkout master $ git pull # 新建一个开发分支myfeature $ git checkout -b myfeature |
Step two: Commit the Branch commit
After the branch is modified, you can commit the commit.
?
123 |
$ git add --all $ git status $ git commit --verbose |
The all parameter of the git add command, which means that all changes are saved (including new, modified, and deleted). Starting with Git 2.0, all is the default parameter for git add, so you can also use git Add. Replace.
Git status command to view the files that have changed.
The verbose parameter of the git commit command lists the results of the diff.
Step Three: Compose submission information
When committing a commit, you must give a complete summary of the submission, and here is a template.
?
123456 |
Present-tense summary under 50 characters * More information about commit (under 72 characters). * More information about commit (under 72 characters). http: //project.management-system.com/ticket/123 |
The first line is a feed of no more than 50 words, and then an empty line, ROM lists the reasons for the change, major changes, and issues to be aware of. Finally, provide the corresponding URL (such as Bug ticket).
Fourth step: synchronizing with the backbone
During the development of the branch, you should always keep in sync with the trunk.
?
12 |
$ git fetch origin $ git rebase origin/master |
Fifth Step: Merge Commit
After the branch development is complete, it is possible to have a bunch of commits, but when merging into the trunk, it is often desirable to have only one (or up to two or three) commits, which is not only clear, but also manageable.
So how can you merge multiple commits? This will use the git rebase command.
?
1 |
$ git rebase -i origin/master |
The I parameter of the git rebase command represents the interaction (interactive), when Git opens an interactive interface for next steps.
The following example of Tute Costa is used to explain how to merge commits.
?
12345678910111213141516171819202122 |
pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post
#urls
pick 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend
# Rebase 8db7e8b..fa20af3 onto 8db7e8b
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit‘s log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
|
The interactive interface above lists the latest 4 commits for the current branch (the more recent). Each commit is preceded by an action command, which defaults to pick, which indicates that the row commit is selected for rebase operation.
4 commits the following is a bunch of comments that list the commands you can use.
?
123456 |
pick:正常选中 reword:选中,并且修改提交信息; edit:选中,rebase时会暂停,允许你修改这个commit(参考这里) squash:选中,会将当前commit与上一个commit合并 fixup:与squash相同,但不会保存当前commit的提交信息 exec:执行其他shell命令 |
Among the 6 commands above, squash and fixup can be used to merge commits. Change the verb in front of the commit that needs to be merged to squash (or s) first.
?
1234 |
pick 07c5abd Introduce OpenPGP and teach basic usage s de9b1eb Fix PostChecker::Post #urls s 3e7ee36 Hey kids, stop all the highlighting pick fa20af3 git interactive rebase, squash, amend |
With this change, the current branch will only have two commits left after execution. The commit of the second and third rows is merged into the commit of the first row. The submission information will also contain the three commit submissions.
?
123456789 |
# This is a combination of 3 commits. # The first commit‘s message is: Introduce OpenPGP and teach basic usage # This is the 2nd commit message: Fix PostChecker::Post #urls # This is the 3rd commit message: Hey kids, stop all the highlighting |
If you change the squash command in the third row to the fixup command.
?
1234 |
pick 07c5abd Introduce OpenPGP and teach basic usage s de9b1eb Fix PostChecker::Post #urls f 3e7ee36 Hey kids, stop all the highlighting pick fa20af3 git interactive rebase, squash, amend |
The result is the same, two commits are generated, and a commit of the second and third rows is merged into the commit of the first row. However, in the new submission, the commit information for the third row of commits will be commented out.
?
123456789 |
# This is a combination of 3 commits. # The first commit‘s message is: Introduce OpenPGP and teach basic usage # This is the 2nd commit message: Fix PostChecker::Post #urls # This is the 3rd commit message: # Hey kids, stop all the highlighting |
The squash and fixup commands can also be used as command-line arguments to automatically merge commits.
?
12 |
$ git commit --fixup $ git rebase -i --autosquash |
Please refer to this article for this usage, it is not explained here.
Sixth step: push to remote repository
Once the commit is merged, you can push the current branch to the remote repository.
?
1 |
$ git push --force origin myfeature |
The git push command has to add the Force parameter, because after rebase, the branch history changes, and the remote branch is not necessarily compatible, it is possible to push (see here).
Seventh step: Issue Pull request
After committing to the remote repository, you can issue a pull request to the master branch and then request someone else to code review, confirming that it can be merged into master.
Original address: Http://www.jointforce.com/jfperiodical/article/954?f=jf_tg_bky
Git uses the canonical process