刚开始使用Git，想要从右脚开始。我做了一些研究（例如Git workflow and rebase vs merge questions，"git pull" or "git merge" between master and development branches），建议的工作流程似乎是：
- 仅限一次：将中央回购克隆到个人仓库
- 创建一个开发分支
-Do承诺开发分支
- 如果master确实已经更新，那么经常拉上主分支（从中央仓库获取更改）并在更新的主分支上重新开发分支
- 在开发分支合并主设备和开发分支上完成开发功能后（再次拉动主设备）
我对此有几个问题：
如果由于更新后的主分支与您的开发分支（来自编辑同一文件的开发人员）之间的合并冲突导致rebase失败，您是应该中止并切换到合并吗？
为什么在功能完成时进行合并而不是再次进行重新定位？
每次完成功能开发或修复错误时，我都应该推送吗？
答案 0 :(得分：0)
当你在rebase期间遇到冲突时，你可以简单地解决它并继续变基。相反，中止和合并将无济于事，无论如何你仍然会遇到冲突。
当您完成功能时，无论是否在master之上重新设置功能/开发分支，您都希望合并。 rebase预先产生的差异在于它让你有机会以（希望）更清晰的方式重写，构造，塑造和呈现你的历史，而不仅仅是做一个导致合并提交的合并（也称为“非快进“合并”。
然而，有些人喜欢创建合并提交，只是为了显示分支发生的位置。您甚至可以在使用“非快进”标记（即git merge --no-ff）后强制进行合并提交。
完成功能或错误修复后是否推送取决于项目，以及您希望如何与其他人共享代码，如果您要共享它。