如何使git分支与master保持同步

275

在git努力工作的当下，我无法为以下问题提供最佳解决方案。

有两个分支，一个称为master，一个称为mobiledevicesupport。我想将mobiledevicesupport保持为连续分支，只要mobiledevicesupport稳定，它将与master分支合并/同步。这样既可以将移动设备支持中的更改合并到主设备中，也可以将主设备中的所有更改都并入移动设备支持中，以便可以继续处理分支并改进或修改功能。这需要与中央存储库和多个开发人员一起使用。

请举一个其他人使用的类似工作流程的示例，或者只是告诉我这个想法是否愚蠢，我应该考虑其他选择。目前，工作流程听起来不错，但我只是不知道如何使git这样工作。

谢谢，所有帮助，不胜感激。

更新1：如果我要将master合并到mobiledevicesupport中，并且将mobiledevice支持合并到master中，我是否会在两个分支之间获得复制的提交。还是git足够聪明，可以算出我已将最新的更改从分支A拉到分支B并将合并提交C添加到分支B。而且我已将最新的更改从分支B拉到分支A并将合并提交D添加到分支一个？

我打算发布一张图片，但我对此没有足够的声誉，所以我想下面的插图很有用。连续运行的两个分支通常会双向合并。我不确定的关键是git如何播放提交内容，并在合并时用另一个分支的提交内容填充任一分支，还是保持干净。我以前使用过rebase，但似乎结束了分支并将所有提交放入master，否则我做错了。感谢你目前的帮助。

master
A--B--C-----H--I--J--M--N
       \   /    \
mobile  \ /      \
D--E--F--G--------K--L

git

— 以西结先生
source

1

如果您像我一样，正在寻找如何使用GitHub 客户端执行此操作：help.github.com/articles/merging-branches

— cregox

1

这个问题挽救了我几个世纪的生命。感谢您抽出宝贵的时间来设置@Mr先生这个好问题。EZEKIEL

— DJphy '16

如果您正在使用叉子，则必须遵循help.github.com/articles/syncing-a-fork

— koppor

416

是的，只是做

git checkout master
git pull
git checkout mobiledevicesupport
git merge master

使移动设备支持与主机保持同步

然后，当您准备将mobiledevicesupport放入主服务器中时，请首先像上面那样在主服务器中合并，然后...

git checkout master
git merge mobiledevicesupport
git push origin master

就是这样。

这里的假设是，mobilexxx是一个主题分支，其工作尚未准备好进入您的主分支。因此，只有在移动设备支持良好的情况下，才能合并到主设备中

— 概念47
source

这对我来说听起来很合理，我想我不确定这样做会使提交历史变得多么脏，我将以我认为将要发生的情况为例来更新我的问题。

— EZEKIEL先生13年

1

您将有很多“合并提交”，实质上是git试图解决分支之间的差异。如果您担心这一点，并且您是唯一使用分支的人，请执行“ git rebase master”而不是“ git merge master”，并且不要在远程分支上进行提交。如果您这样做，将会发现自己对原始设备/移动设备支持进行了大量的强制推送（git push --force），因为您将（可能）始终发送与历史记录不匹配的提交历史记录远程分支有。此处有更多详细信息git-scm.com/book/en/Git-Branching-Rebasing

— concept47

我相信这是正确的答案，听起来完全像我想要的。我在上面添加了一个插图，以使其更加清楚，但是如果您说的是正确的，那么这应该可以准确地解决我的要求。谢谢。

— 以西结先生13年

2

阅读以下内容以了解为什么这不是特别好的建议：kentnguyen.com/development/visualized-git-practices-for-team/…。那是由Git维护者写的，所以可以公平地说他知道他在谈论这个特定主题。

— Dan Moulding

2

这使提交历史变得混乱，请参阅我的答案通过重新设置基准。

— Gob00st

43

每当您要将更改从master转移到工作分支时，请执行git rebase <remote>/master。如果有任何冲突。解决它们。

工作分支准备就绪后，请重新设置基础，然后执行git push <remote> HEAD:master。这将更新远程（中央存储库）上的master分支。

— 欣快83
source

3

这样做而不是接受答案的优点/缺点是什么？

— 汉普斯·阿赫格伦2015年

33

Sane，直到您花了5个小时在地狱中

— 扎根

21

仅当您的分支位于专用存储库上时，才如此。切勿使已经推向上游的东西变基。这就是为什么：git-scm.com/book/en/v2/…–

— Kleag

3

变基是对历史的重写，其问题在于更改了基于变基的提交的SHA，因此您不能依赖（eg）的输出git branch --contains <commit>。

— jnns

13

concept47的方法是正确的方法，但是我建议与--no-ff选项合并，以使提交历史记录清晰明了。

git checkout develop
git pull --rebase
git checkout NewFeatureBranch
git merge --no-ff master

— 理想的
source

9

是的，我同意您的方法。要将移动设备支持合并到主设备，可以使用

git checkout master
git pull origin master //Get all latest commits of master branch
git merge mobiledevicesupport

同样，您也可以在移动设备支持中合并母版。

问：交叉合并是否存在问题。

答：这取决于上次同步时在mobile *分支和master分支中所做的提交。举个例子：上次同步后，这些分支发生以下提交

Master branch: A -> B -> C [where A,B,C are commits]
Mobile branch: D -> E

现在，假设提交B对文件a.txt进行了一些更改，并且提交D也对a.txt进行了一些更改。让我们看一下现在合并的每个操作的影响，

git checkout master //Switches to master branch
git pull // Get the commits you don't have. May be your fellow workers have made them.
git merge mobiledevicesupport // It will try to add D and E in master branch.

现在，有两种合并方式

快进合并
真正合并（需要人工）

Git将首先尝试使FF合并，如果它发现git无法解决任何冲突。合并失败，并要求您合并。在这种情况下，将发生一个新的提交，负责解决a.txt中的冲突。

因此，底线是交叉合并不是问题，最终您必须这样做，这就是同步的含义。在生产中进行任何操作之前，请确保在合并分支时弄脏了手。

— sachinjain024
source

1

那么像这样的交叉合并不是问题吗？

— EZEKIEL先生13年

交叉合并是我们所说的同步，除非在两个分支中的提交都不会引起任何冲突，否则这不是问题。请查看我更新的答案。

— sachinjain024

3

通过git merge接受的答案将完成工作，但会留下混乱的提交历史记录，正确的方法应通过以下步骤进行“变基”（假设您想在PR进行最后的推送之前，将特征分支保留在Develop中，然后再执行sycn ）。

1 git fetch从功能分支（确保您正在使用的功能分支是最新的）

2 git rebase origin/develop

3如果发生任何冲突，请一一解决

git rebase --continue解决所有冲突后使用4

5 git push --force

— 哥布
source

1

这既难以阅读，也难以理解。请更新您的答案并使用适当的代码标记，以将您的注释与命令分开。

— not2qubit

2

您正在朝正确的方向思考。持续将master与mobiledevicesupport合并，并在mobiledevice支持稳定后将mobiledevicesupport与master合并。每个开发人员都将拥有自己的分支机构，并且可以根据自己的角色在主站或移动设备支持上进行合并。

— 费萨尔
source