目前git正在做我的头,我不能提出以下最好的解决方案。

There are two branches, one called master and one called mobiledevicesupport. I want to keep mobiledevicesupport as a continuous branch that will be merged/synced with the master branch whenever mobiledevicesupport is stable. This would merge changes from mobiledevicesupport into master but also bring all the changes from master into mobiledevicesupport so that branch can continue to be worked on and the features improved or amended. This needs to work with a central repository and multiple developers.

请举一个其他人使用的类似工作流程的例子,或者只是告诉我这个想法是否愚蠢,我应该考虑其他选择。目前,工作流程似乎很健全,但我只是不知道如何使git以这种方式工作。

谢谢,非常感谢所有的帮助。

更新1: 如果我将master合并到mobiledevicesupt中,并将mobiledevicesupport合并到master中,我是否会在两个分支之间复制提交?或者git是否足够聪明,可以计算出我已经将最新的更改从分支A拉到分支B,并将合并提交C添加到分支B。我已经将最新的更改从分支B拉到分支A,并将合并提交D添加到分支A?

I was going to post an image but I don't have enough reputation for it, so I guess the following illustration will have to do. Two branches continuously running with merges going both directions often. The key thing I am not sure about is how git will play out the commits and will it fill either branch with the commits from the other branch on merges or will it stay clean. I have used rebase before but it seems to end the branch and put all the commits into the master, or I did it wrong. Thanks for the help so far.

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

当前回答

通过git合并可以完成工作,但会留下一个混乱的提交历史,正确的方法应该是通过以下步骤“rebase”(假设你想在做PR前的最后推送之前保持你的功能分支与开发同步)。

从你的特性分支中获取1个git(确保你正在使用的特性分支是最新更新的)

2 git rebase origin/develop

如有冲突,应逐一解决

4使用git rebase—在所有冲突处理完毕后继续

5个git推——力

其他回答

通过git合并可以完成工作,但会留下一个混乱的提交历史,正确的方法应该是通过以下步骤“rebase”(假设你想在做PR前的最后推送之前保持你的功能分支与开发同步)。

从你的特性分支中获取1个git(确保你正在使用的特性分支是最新更新的)

2 git rebase origin/develop

如有冲突,应逐一解决

4使用git rebase—在所有冲突处理完毕后继续

5个git推——力

是的,我同意你的方法。要合并移动设备支持到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中的冲突。

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

是的,只要做:

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。

using yourBranch = mobiledevicesupport;

让你的分支和master保持同步包括两个重要的细节:

根据master更新云中的yourBranch版本 根据master更新你PC上的yourBranch版本

如何:

假设你的分支在master后面

创建一个合并请求从master到你的分支(例如via GitLab web UI) 接受/解决从master到你分支的合并请求。 通过GitLab web UI)

现在你的分支中有来自master的变化 这已经在远程(云中)将主更改加载到你的分支,但还没有在本地

更新你的分支的旧版本 你的电脑)

确保您现在正在与您的分支进行本地交互 Git获取将检查更改 git状态会告诉你本地存储库的状态(你本地的分支库)——例如master后5次提交 Git pull会从云端(从“远程”)下载新的更新版本,其中添加了来自master的更改-现在你将在本地存储库(在你的机器上)与master同步。

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

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