Git uses the canonical process

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).

1 2 3) 4 5

# 获取主干最新代码 $ 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.

1 2 3

$ 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.

Present-tense Summary under Characters

* More information about commit (under characters).
* More information about commit (under 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.

1 2	$ 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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

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.

• Pick: Normal Check

• Reword: Select, and modify the submission information;

• Edit: Checked, rebase will be paused, allowing you to modify this commit (see here)

• Squash: checked, the current commit is merged with the previous commit

• Fixup: Same as squash, but does not save commit information for the current commit

• EXEC: Execute other shell commands

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.

1 2 3 4

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.

1 2 3 4 5 6 7

# 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.

1 2 3 4

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.

1 2 3 4 5 6 7

# 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.

1 2	$ 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.

Git uses the canonical process