两位程序员，A＆amp; B，正在开发一个带有github托管仓库的项目：
分支机构存在。
程序员A基于最新的主人
创建devBranchAmaster$ git checkout -b devBranchA
程序员B根据最新的主程序
创建devBranchBmaster$ 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，因为它是打算使用的。
答案 0 :(得分：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标记代表实时发布的提交。
现在问题出现了，工作流程的选择发挥作用：让我们说有一个提交来自另一个dev存储库，例如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
没有额外的提交，荣誉在本地提交中已经存在于规范存储库（origin / master）中，发生的冲突通常会发生在开发人员尚未提交的提交中（因此没有其他人可以解释）。
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中开发的策略之前，需要进行一些实验，我想因为一旦你分散了，就会有更多的方法。
答案 1 :(得分：0)
您可以在Tchalvak＆＃34; his answer＆＃34;中找到git rebase vs git merge所提到的两个工作流程的另一个例子。
如＆＃34; What is the right git workflow with shared feature branches?＆＃34;中所述，我更喜欢避免＆＃34;反向合并＆＃34; （从master到devBranch），并且宁愿在devBranch之上重新master，前提是：
devBranch定期合并为主人