Git rebase is frequently used in team development to keep trees tidy, okay?

  git, question

After use, the tree can be very clear, to some extent easy to track, butpush --forceThere will be more.
No, the merger does not have the trouble of modifying the remote warehouse, but the tracking is not clear. …

How to choose? What is the general choice in the team?

git rebaseIt is a rewrite of commit history. When the commit history you want to rewrite has not been submitted to the remote repo, that is,Before sharing with othersCommit history is your private property, so you can rewrite it any way you want.

Once submitted to the remote, if history is rewritten again, it will certainly be different from the history of others.git pushAt the same time, git will compare the commit history. If there is no agreement, the commit action will be rejected. The only way is to take it with you.-fParameter, forcing commit, git will overwrite the remote repo with the history of the committer to complete the code submission. Although the code has been submitted, it may result in the loss of other people’s work, so use the-fParameters should be carefully measured.

The problem encountered by the landlord is caused by rewriting the public commit history.To solve this problem, we must standardize the submission process.

For example, chestnuts in the right process:

Let’s assume that there are two developers: Tom and jerry in the landlord’s team. They use a remote repo together and clone each to their own machine. To simplify the description, let’s assume that there is only one branch:master.

At this time, tom’s repo has two branch.
Jerry’s machine also has two branch

As shown in the following figure

Tom and jerry respectively develop their own new feature, and new commits are submitted to their own private commit history, so their master pointers move forward and point to different commits. And because they don’t have anygit fetchAndgit push, so theirorigin/masterAll remain unchanged.

Jerry’s repo is as follows

Tom’s repo is as follows. NoteT1And the above figureJ1, respectively, are two different commit

At this time Tom first submitted his commit to the remote repo, then he nativeorigin/masterThe pointer advances, andmasterThe pointer remains the same as follows

The remote repo is as follows

Now jerry also wants to submit his commit to the remote repo and run it.git push, there is no unexpected failure, so hegit fetchAfter a while, the remote repo, that is, tom submitted beforeT1To pull into his native repo, as follows

There is a bifurcation in the commit history. If you want to include the content submitted by tom in your work, one way is togit merge, it will automatically generate a commit, including tom’s submission and jerry’s submission, thus merging the two forked COMMITs again. However, this auto-generated commit will have two parent. It is inconvenient to compare the two when reviewing the code.

Jerry decided to adopt another method to ensure the linearity of the commit history, namelygit rebase. Jerry’s submissionJ1At this time, it has not been submitted to the remote repo, that is, a commit that is completely private to him, so it is usedgit rebaserewriteJ1The history of has no problem at all. after rewriting, it is as follows

pay attention toJ1Be rewritten toT1Behind, becameJ1`

git pushAfter that, the local repo

And remote repo

Unusual ease, a straight line, no.-f

So, in no use-fOn the premise of, want to keep the tree clean and tidy, the method is: ingit pushBefore, firstgit fetchAgaingit rebase.

git fetch origin master
 git rebase origin/master
 git push

Reading is highly recommended.