我们是一个团队使用Git的工作,我们有一个中央存储库(单源),我们用它来push和pull从(和Capistrano的使用它来部署分支主)
我们定期提交和部署(每天10到20次部署),这意味着我们有很多合并提交并git blame成为一场噩梦
我已经读过这个有一个更简单的历史,我们可以用它git pull --rebase来避免这种情况.总是在主分支上做这个是个好主意吗？
如果它是我想建议在配置中使用:
git config branch.master.rebase true
这有什么问题吗？
Mic*_*ele 25
没问题.事实上,这是首选.
99%的时候最好重新定义更改.如果没有,开发人员可以随时中止rebase并手动合并他们的更改.
替代方案(合并拉动)导致大量的小方提交和合并,这些都没有任何意义.
总的来说,我并不经常看到合并局部变化的重点.这意味着开发人员开始的确切修订有一些特殊之处,并且以某种方式重新定位到不同的版本会导致信息丢失(可能是"我在Bob的功能之前启动了这个,我希望在没有它的情况下进行通信"和Bob一起玩得很好,我被指责为"或某事......".实际情况并非如此,干净的直线提交历史记录更容易理解.
| 归档时间： |
|
| 查看次数： |
4822 次 |
| 最近记录： |