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

# Get skeleton Latest code $ git checkout master$ git pull# create a new development branch myfeature$ git checkout-b myfeature

Step two: Commit the Branch commit

After the branch is modified, you can commit the commit.

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

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.

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

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

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.

Pick 07c5abd introduce OpenPGP and teach basic Usagepick de9b1eb Fix postchecker::P ost#urlspick 3e7ee36 Hey Kids, stop all The Highlightingpick 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 to previous commit#  f, fixup = like "Squash", but discard this commits ' s log message#  x, exec = Run command (the rest of the line) using shell## these Lin ES can be re-ordered; They is executed from the top to bottom.## if you remove a line here This COMMIT'll be lost.## However, if you remove every Thing, the rebase is being aborted.## Note that empty commits is 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: check, and modify the submission information; edit: Check, rebase will pause, allow you to modify this commit (see here) Squash: SELECT, Merges the current commit with the previous commit fixup: Same as squash, but does not save the 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.

Pick 07c5abd introduce OpenPGP and teach basic usages De9b1eb Fix postchecker::P ost#urlss 3e7ee36 Hey Kids, stop all the H Ighlightingpick 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.

# This is a combination of 3 commits.# the first commit ' s message is:introduce OpenPGP and teach basic usage# the 2nd commit message:fix Postchecker::P ost#urls# This was the 3rd commit Message:hey Kids, stop all the highlighting

If you change the squash command in the third row to the fixup command.

Pick 07c5abd introduce OpenPGP and teach basic usages De9b1eb Fix postchecker::P ost#urlsf 3e7ee36 Hey Kids, stop all the H Ighlightingpick 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.

# This is a combination of 3 commits.# the first commit ' s message is:introduce OpenPGP and teach basic usage# the 2nd commit message:fix Postchecker::P ost#urls# This was 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.

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

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

