用了以后, 树可以非常清晰, 某种程度上便于追踪, 但是 push --force 就多多了,
不用呢, 合并没有远程仓库被修改的麻烦, 可是追踪又不清晰...
怎样取舍? 团队里一般怎么取舍?
滿天的星座2017-04-25 09:04:57
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 branchesmaster, origin/master, origin/master
Jerry’s machine also has two branchesmaster, 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
git fetch, then git rebase.
git fetch origin master
git rebase origin/master
git push
巴扎黑2017-04-25 09:04:57
Unless you are the only one using it, anyone who uses push --force should die.
PHPz2017-04-25 09:04:57
Binding (tracking) of local branches and remote branches, plus rebase strategy:
[branch "master"]
remote = origin
merge = refs/heads/master
rebase = true
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!
我想大声告诉你2017-04-25 09:04:57
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!
阿神2017-04-25 09:04:57
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.
PHP中文网2017-04-25 09:04:57
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.
漂亮男人2017-04-25 09:04:57
There is no need to push -f. If the branch is lagging behind, use pull --rebase
伊谢尔伦2017-04-25 09:04:57
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).
PHP中文网2017-04-25 09:04:57
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
習慣沉默2017-04-25 09:04:57
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.