相关疑难解决方法(0)

我和其他开发人员一起在一个项目上使用Git几个月了.我有几年的SVN经验,所以我想我给这段关系带来了很多包袱.

我听说Git非常适合分支和合并,到目前为止,我只是没有看到它.当然,分支很简单,但是当我尝试合并时,一切都变得很糟糕.现在,我已经习惯了SVN,但在我看来,我只是将一个低于标准的版本系统换成了另一个.

我的搭档告诉我,我的问题源于我不顾一切地合并,并且我应该在很多情况下使用rebase而不是合并.例如,这是他所规定的工作流程:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature

基本上,创建一个功能分支,始终从主分支到分支,并从分支合并回主分支.需要注意的重要一点是,分支始终保持在本地.

这是我开始的工作流程

clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish …

假设我是回购的维护者,并且我想从贡献者那里获取更改,那么有一些可能的工作流程:

1. 我cherry-pick每个都从远程提交(按顺序).在这种情况下,git将提交记录为与远程分支无关.
2. 我merge是分支,拉入所有更改,并添加新的"冲突"提交(如果需要).
3. 我merge各自从远程分支单独提交(再次按顺序),允许为每个提交记录冲突,而不是将所有冲突组合为一个.
4. 为了完整性,你可以做一个rebase(与cherry-pick选项相同？),但我的理解是,这可能会导致贡献者的混淆.也许这消除了选项1.

在情况2和3中,git记录了提交的分支历史记录,与1不同.

使用任何一种方法cherry-pick或merge描述的方法之间有什么优点和缺点？我的理解是方法2是常态,但我觉得用单个"冲突"合并解决大型提交并不是最干净的解决方案.