After use, the tree can be very clear, to some extent easy to track, but
push --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:
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 any
git push, so their
origin/masterAll remain unchanged.
Jerry’s repo is as follows
Tom’s repo is as follows. Note
T1And the above figure
J1, respectively, are two different commit
At this time Tom first submitted his commit to the remote repo, then he native
origin/masterThe pointer advances, and
masterThe 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 he
git fetchAfter a while, the remote repo, that is, tom submitted before
T1To 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 to
git 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, namely
git rebase. Jerry’s submission
J1At this time, it has not been submitted to the remote repo, that is, a commit that is completely private to him, so it is used
J1The history of has no problem at all. after rewriting, it is as follows
pay attention to
J1Be rewritten to
git pushAfter that, the local repo
And remote repo
Unusual ease, a straight line, no.
So, in no use
-fOn the premise of, want to keep the tree clean and tidy, the method is: in
git pushBefore, first
git fetch origin master git rebase origin/master git push
Reading is highly recommended.