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

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

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

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

是的，只要做:

git checkout master
git pull
git checkout mobiledevicesupport
git merge master

保持移动设备支持与主同步。

然后，当你准备好把mobiledevicsupport放到master中，首先，像上面那样合并在master中，然后:

git checkout master
git merge mobiledevicesupport
git push origin master

就是这样。

这里假设mobilexxx是一个主题分支，其中的工作还没有准备好进入您的主分支。所以只有在mobiledevicessupportionenabled好的时候才合并到master。

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

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

同样，你也可以在mobiledevicesupport中合并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中的冲突。

所以底线是交叉合并不是一个问题，最终你必须这样做，这就是同步的意思。在生产环境中做任何事情之前，请确保您在合并分支时弄脏了手脚。

当你想要把master的更改放到你的工作分支中时，执行git rebase <remote>/master。如果有任何冲突。解决这些冲突。

当你的工作分支准备好了，重新设置base，然后执行git push <remote> HEAD:master。这将在远程(中央回购)上更新主分支。

你想的方向是对的。不断合并master和mobiledevicesupport，并在mobiledevicesupport稳定时合并master。每个开发人员都有自己的分支，可以根据自己的角色与主设备或移动设备支持进行合并。