"Todo" Git's Fast Forward & git command learning

Git's fast-forward has been introduced in previous articles, but the introduction is not fine:

Http://www.cnblogs.com/charlesblc/p/5953066.html

The fast-forward method is that when the condition permits, git directly points the head pointer to the header of the merge branch and completes the merge. is a "fast forward", but if you delete a branch, the branch information is lost.
Because Commitsquash is not created in this process to compress some unnecessary commits, for example, when your feature write a messy commit in development, we don't want to bring these historical commits when we merge.
The merge is then done using--squash, where the file is the same as the merge, but does not move the head and does not commit. An additional commit is required to "summarize" and complete the final merge. --no-ff refers to forcibly closing the fast-forward mode.

Have this article in detail review (Link)

Typically, when merging branches, GIT uses patterns when possible, Fast forward but in this mode, the branch information is discarded after the branch is deleted.

If you want to force the mode to be disabled, Fast forward git will generate a new commit at merge, so you can see the branching information from the branch history.

--no-ffthe way of actual combat git merge :

First, you still create and switch dev branches:

$ git checkout-new branch ' Dev '

Modify the Readme.txt file and submit a new commit:

-M "Add merge"6224937 1 file changed, 1 insertion (+)

Now, we switch back to master :

' Master '

To prepare the merge dev branch, note --no-ff The parameter, which indicates disabled Fast forward :

$ git merge--no-ff-m "merge with No-ff"' recursive '|    1 + 1 file changed, 1 insertion (+)

Because this merge will create a new commit, add the -m arguments and write the commit description.

After merging, let's take a git log look at the branching history:

$ git log--graph--pretty=oneline--abbrev-Commit*   7825a50 merge with no-ff|| * 6224937 Add Merge|/*   59bc1cb conflict fixed ...

As you can see, no pattern is used Fast forward , and the merge is like this:

With regard to the default fast-forward, the above citation is not detailed. Basically, there is no information that is merged from other branches, only the actual information of each commit is visible. If the other branches are missing, the information for the branch merge is lost.

I tried it myself. The default is a fast-forward case. As follows:

$ git checkout-b testffswitched to aNewBranch ' TESTFF '$ vi readme$ git add readme$ git commit readmetest ff# Please enter the commit message foryour changes. Lines starting# with‘#‘Would be ignored, and an empty message aborts the commit.# Explicit paths specified without-I. Or-o; Assuming--Only paths...# on branch testff# changes to be committed:#Newfile:readme#
...". Git/commit_editmsg" [converted] 8L, 282C WRITTEN[TESTFF 5a036ee] Test ff1 file changed, 1 insertion (+) Create mode100644Readme$ git checkout -b newtestffswitched to a  new branch ' NEWTESTFF '$ git merge testff alreadyup-t o date.$ git diff testff newtestff$ git checkout masterswitched to branch' Master 'Your Branch is up-to-date with ' Origin/master '. $ git pull$ git checkout-b newffswitched to aNewBranch ' NEWFF '$ git checkout newffalready on' NEWFF '$ git merge testffupdating 30a974d. 5a036eefast-Forward Readme| 1 + 1 file changed, 1 insertion (+) Create mode100644Readme$ git log --graph--pretty=oneline--abbrev-commit* 5a036ee test ff * 30a974d Merge branch ' xxx 'into master|\  ...

Focus on two points:

1. the first place to be yellow, in the TEST-FF version checkout-b, found that git two branch completely no difference.

The git checkout-b dev command is equivalent to
To create a branch:GITBRANcH dev slitting branch : git checkout Dev

And this creation is based on the current head.

So there is no difference between the newly created branch and the TEST-FF.

2. after using the default merge, use git log--graph--pretty=oneline--abbrev-commit to see:

* 5a036ee Test ff

There is no information about the original TEST-FF branch at all.

Another, git log command with the following parameters is very useful,--graph--pretty=oneline--abbrev-commit

It looks much better than the original output.

Branching policy

In the actual development, we should follow several basic principles of branch Management:

First, the master branch should be very stable, that is, only to release the new version, usually do not work on it;

So where do you work? The work is on the dev branch, that dev is, the branch is unstable, to some point, such as the release of 1.0, then the dev branch to merge master , in the master Branch Release 1.0 version;

You and your friends each work on the dev branch, everyone has their own branch, and occasionally merge on the dev branch.

So, the branch of teamwork looks like this:

Summary

The GIT branch is very powerful and should be fully applied in team development.

Merging branches, plus --no-ff parameters can be combined with normal mode, the merged history has branches, you can see that there has been a merger, and the fast forward merger will not be seen to have been merged.

Some git commands:

git checkout-b dev// Create local branch based on local branch // remote Branch  -- D dev Delete remote branch git push origin:branch-name Colon followed by no spaces

Here are a few more things to review:

Http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

Http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html

Http://www.ruanyifeng.com/blog/2015/08/git-use-process.html

Http://www.ruanyifeng.com/blog/2014/06/git_remote.html

"Todo" Git's Fast Forward & git command learning