重用一个合并的开发分支/使用git重新合并到一个未更改的稳定分支

Question

两个程序员A和B正在使用github托管的repo开发一个项目:

分支机构存在.

程序员A基于最新的master创建devBranchA

master$ git checkout -b devBranchA

程序员B根据最新的master创建devBranchB

master$ git checkout -b devBranchB

他们决定尽可能将稳定的变化合并到主人.

商定的工作流程是:

[在devBranch上]

git commit -m 'Stuff to make branch stable enough to merge'

git checkout master

git pull origin master 

git merge devBranch [fix merge conflicts if any]

git checkout devBranch

git commit -m 'New cool stuff'

但是,如果自上次合并后没有要提交的提交,则无法将devbranch合并回master(除非创建了新的dev分支,而不是重新使用旧的分支)

在这种情况下,当程序员B将他的工作合并到主分支时,它将不是当前的预期主服务器,而是合并之前的主服务器状态.

如果没有临时提交,有没有办法自动强制主分支在合并时将自己更新到dev分支的头部？

使用git和集中式github存储库时,预期的多用户工作流程是什么？我觉得好像我没有使用git,因为它是打算使用的.

Answer 1

查看git fetch;git rebase origin/master或git pull --rebase，两者都遵循主存储库中提交的顺序，因为它会变基，将本地提交粘在顶部。无论如何，您并不关心本地分支上本地提交的顺序，因为只有您拥有它们。尝试一下，但要小心使用，例如在变基之前复制一个分支，直到您习惯为止。

一般来说，您谈论的是 git 工作流程，我发现您应该熟悉两个通用工作流程。请注意，我正在谈论如何最大限度地减少冲突的个人经验：

• 变基优先工作流程（为了最干净的提交历史记录，通常将冲突的负担推给未提交的代码）
• 合并工作流程（有时当有很多可能发生冲突的更改时更简单，我通常仅将其用作后备）

示例初始工作流程

git checkout master // For the sake of argument, let's say the latest commit in your local master is from august 1st or something old like that.
git branch temp_branch // copy of the master
git checkout temp_branch
git add changedFiles;git commit changedFiles; // A change from november 2nd.

git log // Now your dev branch has a new commit on top of an otherwise old branch.

git log origin/master // You get a listing of the commits from the origin repository, the master branch.  

一般来说，我使用 origin/master 进行开发阶段，git 标签代表实时发布的提交。

现在这就是问题发生的地方，也是工作流程选择发挥作用的地方：假设有一个提交来自 master 中的另一个开发存储库，例如 10 月 15 日的提交。也许它是由另一个开发人员提交的，也许是您自己提交的。

您的选择：合并或变基。

合并

引入额外的提交，尊重您的本地（未推送）分支开发历史而不是规范（原始/主）历史，导致其他分支和其他分支发生更多冲突的可能性。本质上，您是在说“我的提交顺序将与主分支提交顺序混合”，而不是重新排序提交历史记录。

git merge origin/master // merge commit introduced
... // Resolve any conflicts, and finalize the merge commit.
git checkout master;git rebase temp_branch // Move the changes to master.
git push origin/master // Pushing changes, including merge commit, to origin/master

最后，提交历史记录将类似于：August-October-November-MergeCommit

变基

没有额外的提交，尊重规范存储库（原始/主）中已经存在的提交而不是本地提交，发生的冲突通常会发生在开发人员尚未提交的提交上（因此没有其他人可以解释）。

git rebase origin/master // 
... // Resolve any conflicts...
git rebase --continue or git rebase --abort
... // Resolve any conflicts...
git checkout master;git rebase temp_branch // Get the branch changes without a merge commit into master.
git push // Push all changes to the canonical repository.

注意：如果您最终不得不执行两个以上的冲突解决方案，那么现在是git rebase --abort进行合并的好时机。

尝试一下这个过程，看看它对你是否有意义！在你真正获得适合 git 开发的策略之前，需要进行一些实验，我想是因为一旦你实现去中心化，就会有更多的方法。