git rebase is a rewrite of commit history. When the commit history you want to rewrite has not been submitted to the remote repo, that is to say, before it has been shared with others, the commit history is private to you, so you can rewrite it however you want.
Once it is submitted to the remote, if you rewrite the history, it will definitely be different from other people’s history. git push的时候，git会比较commit history，如果不一致，commit动作会被拒绝，唯一的办法就是带上-f参数，强制要求commit，这时git会以committer的history覆写远程repo，从而完成代码的提交。虽然代码提交上去了，但是这样可能会造成别人工作成果的丢失，所以使用-fBe careful with parameters.
The problem the poster encountered was caused by rewriting the public commit history. To solve this problem, we need to standardize the submission process.
Give me an example of the correct process:
Suppose there are two developers in the poster's team: Tom and Jerry. They jointly use a remote repo and clone it to their own machines. To simplify the description, it is assumed that there is only one branch: master.
At this time, the repo of tom machine has two branches master, origin/master, origin/master
Jerry’s machine also has two branches master, origin/master, origin/master
As shown in the picture below
Tom and Jerry each develop their own new features, and new commits are constantly submitted to their respective private commit histories, so their master pointers continue to move forward, pointing to different commits. And since none of them git fetch和git push，所以他们的origin/master remain unchanged.
jerry’s repo is as follows
tom’s repo is as follows. Note T1和上图的J1 that they are two different commits
At this time, Tom first submits his commit to the remote repo, then his local origin/master pointer will advance and be consistent with the origin/master指针则会前进，和masterpointer, as follows
The remote repo is as follows
Now Jerry also wants to submit his commit to the remote repo. Run git push，毫无意外的失败了，所以他git fetch了一下，把远程repo，也就是之前tom提交的T1 to pull it into his local repo, as follows
The commit history has bifurcated. If you want to include the content that Tom previously submitted into your own work, there is a way to git merge. It will automatically generate a commit, including both Tom's submission and Jerry's submission, so Just merge the two forked commits back together. However, this automatically generated commit will have two parents. When reviewing the code, it must be compared twice, which is very inconvenient.
In order to ensure the linearity of the commit history, Jerry decided to use another method, that is, git rebase。jerry的提交J1这时还没有被提交到远程repo上去，也就是他完全私有的一个commit，所以使用git rebase改写J1’s history has no problem at all. After rewriting, it is as follows
AttentionJ1被改写到T1后面了，变成了J1`
git pushAfter, native repo
And remote repo
Exceptionally easy, a straight line, nothing-f
So, if you want to keep the tree clean without using -f的前提下，想维持树的整洁，方法就是：在git push之前，先git fetch，再git rebase, the method is: before
, first git fetch, then git rebase.
git fetch origin master
git rebase origin/master
git push
In this way, rebase will be automatically applied when updating the code (pull) instead of generating a merge commit, unless there are other situations, such as conflicts caused by a three-party merger that require intervention. Most of the time it is very smart. As long as the team has good habits, it can maintain a very clean and beautiful tree shape.
In fact, there are many ways to make the tree structure more beautiful and clear, but it first depends on what kind of Git Model the team uses, and you can just prescribe the right medicine. There is no way to sum it up here.
Also, the person above is right, use it with caution push -f!
This should be a git workflow problem. Our team has been using rebase to ensure the cleanliness of commit information, but we will not use push -fsuch an operation.
Regarding git workflow, it’s a matter of opinion. You can read the following articles and find one that suits your team. But the most important thing is to ensure that everyone in the team is familiar with git to prevent mistakes. Stupid mistake.
Construct a clean Git history thread
A successful Git branching model that is widely circulated
Github workflow
If you use github for teamwork, make good use of pull requests, it can solve push -fthis stupid problem!
Everyone should rebase their modifications to the latest code of the server before submitting. There will be no problems if you follow this rule. If you need force push, it means you are doing it the other way around. Rebase the server code to your local branch before force push is required. This is a wrong usage.
It is recommended to refer to the chapter about rebase in Pro Git http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94% AF%E7%9A%84%E8%A1%8D%E5%90%88
Risk of regeneration
Well, the wonderful derivation is not perfect. You have to follow one rule to use it:
Once the submission object in the branch is published to the public warehouse, never rebase the branch.
If you follow this golden rule, nothing can go wrong. Otherwise, the people will hate you, and your friends and family will laugh at you and spurn you.
As far as I am concerned. If you need to use push -f after rebase, it must mean that the rebase operation is inappropriate. Unless you intend to modify the commit history.
The answers above are all correct. Personally, unless you are the only one working on a certain branch, you will have no problem rebasing. However, if you rebase on a branch like master or develop, it is estimated that there will be no problem in the team. Everyone wants to shoot you to death, especially teammates who are not familiar with git. It is very normal to be at a loss.
There is only one situation for pushing -f after rebase, that is, the subject has obsessive-compulsive disorder like me, and is afraid of computer downtime and system crashes (a tragic history of blood and tears), so after completing a feature commit, he quickly pushes to the remote On the branch that only belongs to you, in order to get the new features of develop, you rebase develop on your own branch and perform the push operation repeatedly. I personally think there is no problem. After all, you only affect yourself (and you know this is right).
Personally, I think it is really unreasonable to use rebase when you are working as a team on a certain branch. And it's easy to go wrong. Use with caution push --force
Git rebase is generally used when developing alone to keep the submission record clean. Once uploaded to github, you should not use git rebase, otherwise you will be scolded to death.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
git rebaseis a rewrite of commit history. When the commit history you want to rewrite has not been submitted to the remote repo, that is to say, before it has been shared with others, the commit history is private to you, so you can rewrite it however you want.Once it is submitted to the remote, if you rewrite the history, it will definitely be different from other people’s history.
git push的时候，git会比较commit history，如果不一致，commit动作会被拒绝，唯一的办法就是带上-f参数，强制要求commit，这时git会以committer的history覆写远程repo，从而完成代码的提交。虽然代码提交上去了，但是这样可能会造成别人工作成果的丢失，所以使用-fBe careful with parameters.The problem the poster encountered was caused by rewriting the public commit history. To solve this problem, we need to standardize the submission process.
Give me an example of the correct process:
Suppose there are two developers in the poster's team: Tom and Jerry. They jointly use a remote repo and clone it to their own machines. To simplify the description, it is assumed that there is only one branch:
master.At this time, the repo of tom machine has two branches
master,origin/master,origin/masterJerry’s machine also has two branches
master,origin/master,origin/masterAs shown in the picture below
Tom and Jerry each develop their own new features, and new commits are constantly submitted to their respective private commit histories, so their master pointers continue to move forward, pointing to different commits. And since none of them
git fetch和git push，所以他们的origin/masterremain unchanged.jerry’s repo is as follows
tom’s repo is as follows. Note
T1和上图的J1that they are two different commitsAt this time, Tom first submits his commit to the remote repo, then his local
origin/masterpointer will advance and be consistent with theorigin/master指针则会前进，和masterpointer, as followsThe remote repo is as follows
Now Jerry also wants to submit his commit to the remote repo. Run
git push，毫无意外的失败了，所以他git fetch了一下，把远程repo，也就是之前tom提交的T1to pull it into his local repo, as followsThe commit history has bifurcated. If you want to include the content that Tom previously submitted into your own work, there is a way to
git merge. It will automatically generate a commit, including both Tom's submission and Jerry's submission, so Just merge the two forked commits back together. However, this automatically generated commit will have two parents. When reviewing the code, it must be compared twice, which is very inconvenient.In order to ensure the linearity of the commit history, Jerry decided to use another method, that is,
git rebase。jerry的提交J1这时还没有被提交到远程repo上去，也就是他完全私有的一个commit，所以使用git rebase改写J1’s history has no problem at all. After rewriting, it is as followsAttention
J1被改写到T1后面了，变成了J1`git pushAfter, native repoAnd remote repo
Exceptionally easy, a straight line, nothing
-fSo, if you want to keep the tree clean without using
, first-f的前提下，想维持树的整洁，方法就是：在git push之前，先git fetch，再git rebase, the method is: beforegit fetch, thengit rebase.
Highly recommended reading-
a successful git branching model-
Git-branch-branch rebase
🎜Unless you are the only one using it, anyone who uses
push --forceshould die.Binding (tracking) of local branches and remote branches, plus rebase strategy:
In this way, rebase will be automatically applied when updating the code (
pull) instead of generating a merge commit, unless there are other situations, such as conflicts caused by a three-party merger that require intervention. Most of the time it is very smart. As long as the team has good habits, it can maintain a very clean and beautiful tree shape.In fact, there are many ways to make the tree structure more beautiful and clear, but it first depends on what kind of Git Model the team uses, and you can just prescribe the right medicine. There is no way to sum it up here.
Also, the person above is right, use it with caution
push -f!This should be a git workflow problem. Our team has been using rebase to ensure the cleanliness of commit information, but we will not use
push -fsuch an operation.Regarding git workflow, it’s a matter of opinion. You can read the following articles and find one that suits your team. But the most important thing is to ensure that everyone in the team is familiar with git to prevent mistakes. Stupid mistake.
If you use github for teamwork, make good use of pull requests, it can solve
push -fthis stupid problem!Everyone should rebase their modifications to the latest code of the server before submitting. There will be no problems if you follow this rule. If you need force push, it means you are doing it the other way around. Rebase the server code to your local branch before force push is required. This is a wrong usage.
It is recommended to refer to the chapter about rebase in Pro Git http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94% AF%E7%9A%84%E8%A1%8D%E5%90%88
As far as I am concerned. If you need to use
push -fafter rebase, it must mean that the rebase operation is inappropriate. Unless you intend to modify the commit history.There is no need to push -f. If the branch is lagging behind, use pull --rebase
The answers above are all correct. Personally, unless you are the only one working on a certain branch, you will have no problem rebasing. However, if you rebase on a branch like master or develop, it is estimated that there will be no problem in the team. Everyone wants to shoot you to death, especially teammates who are not familiar with git. It is very normal to be at a loss.
There is only one situation for pushing -f after rebase, that is, the subject has obsessive-compulsive disorder like me, and is afraid of computer downtime and system crashes (a tragic history of blood and tears), so after completing a feature commit, he quickly pushes to the remote On the branch that only belongs to you, in order to get the new features of develop, you rebase develop on your own branch and perform the push operation repeatedly. I personally think there is no problem. After all, you only affect yourself (and you know this is right).
Personally, I think it is really unreasonable to use rebase when you are working as a team on a certain branch. And it's easy to go wrong. Use with caution push --force
Git rebase is generally used when developing alone to keep the submission record clean. Once uploaded to github, you should not use git rebase, otherwise you will be scolded to death.