21

We are a team working with git, we have a central repository (single origin) we use to push and pull from (and capistrano use it to deploy the branch master)

we make commits and deploy regularly (10~20 deploys a day), that means we have a lot of merge commit and git blame become a nightmare

I've read that to have a simpler history we can use git pull --rebase to avoid this. Is it a good idea to do always do this on the master branch?

if it is I'd like to suggest to set it in config with : 

git config branch.master.rebase true

Is there any issue with this?

4

4 回答 4

25

完全没有问题。事实上，这是首选。

99% 的情况下最好重新设置更改。如果没有，开发人员可以随时中止重新设置并手动合并更改。

另一种选择（合并拉动）会导致大量的小侧提交和合并，这些提交和合并没有任何意义。

一般来说，我不经常看到合并本地更改的意义。这意味着开发人员开始使用的确切版本有一些特别之处，并且以某种方式重新定位到不同的版本会导致信息丢失（也许“我在 Bob 的功能之前开始了这个，我想传达一下，以防它没有和鲍勃打得好，我会受到指责”或其他什么……）。实际上很少有这种情况，并且干净的直线提交历史更容易遵循。

于 2014-01-09T18:02:32.830 回答
4

默认情况下进行 pull rebase 是可以的（不一定是“好主意”，也不一定是“坏主意”）。你只需要记住它实际上会改变你的工作。如果您进行了一系列提交，这些提交都取决于Bob 更改之前的仓库中的内容1，那么您的 rebase（在 Bob 的更改之上）可能会迫使您修复所有这些提交，而这可能更容易仅修复最终的合并提交。

我更喜欢手动执行此操作：运行git fetch，然后git rebase或git merge视情况而定，一旦完成获取，我就会发现。

git pull --rebase但是（和/或设置）有一个优势branch.master.rebase true，因为“使用变基拉动”非常聪明，并且可以处理遥控器也完成变基的某些情况。

1这里的“Bob”代表任何做出一些改变（并击败你push）导致你自己的改变“消化不良”的人。

于 2013-10-03T09:21:59.263 回答
2

根据我的经验，pull.rebase 总是很好。如果您不想出现合并冲突，您可以在本地分支中工作，如果您想使用最新代码，您总是希望在推送当前工作之前进行任何未提交的更改。

合并到一个分支中git pull几乎总是毫无意义的，如果合并是有意义的分支应该是不同的（并且合并显式）。

另请参阅http://stevenharman.net/git-pull-with-automatic-rebase。

于 2013-10-03T09:59:06.787 回答
-4

您永远不应该对其他存储库中存在的任何修订进行变基，并且可能有基于它的其他工作，因为该工作也需要变基。

如果你推送一个分支然后重新设置它，你将不得不使用-f选项来下一次推送。因此，如果您从不使用该选项，您将永远不会遇到问题，并且可以自由地变基。但是，如果您使用 推送-f，可能会推送到功能分支，那么当其他人可能也在该分支上工作或与他们协调 rebase 时，请注意不要变基。

因此，对于您自己的开发工作，无论如何，rebase（和 rebase -i 以及合并和拆分更改等以使它们更合乎逻辑）。但是如果不止一个人在一个特性上工作，变基将需要协调，这可能不再值得，并且变基已发布的开发分支基本上是禁止的。

于 2013-10-03T08:38:32.017 回答