从master创建一个新分支,我们称之为test。

有几个开发人员要么提交到master,要么创建其他分支,然后合并到master。

假设测试工作需要几天的时间,您希望通过master内部的提交不断更新测试。

我会从测试中提取原始主机。

问题1:这是正确的方法吗?其他开发人员可以像我一样轻松地处理相同的文件。


我的测试工作已经完成,我已经准备好将其合并回master。以下是我可以想到的两种方法:

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

git checkout test
git pull origin master
git checkout master
git merge test

我没有使用--rebase,因为根据我的理解,rebase将从master获取更改,并将我的更改叠加在上面,因此它可能会覆盖其他人所做的更改。

问题2:这两种方法中哪一种是正确的?有什么不同?

所有这一切的目标是让我的测试分支随着master中发生的事情而更新,然后我可以将它们合并到master中,希望尽可能保持时间线的线性。


当前回答

git checkout master
git pull origin master
# Merge branch test into master
git merge test

合并后,如果文件发生了更改,则在合并时将出现“解决冲突”错误

因此,您需要首先解决所有冲突,然后再次提交所有更改,然后推送

git push origin master

这是更好的做法,谁在测试分支中做了更改,因为他知道自己做了什么更改。

其他回答

我该怎么做

git checkout master
git pull origin master
git merge test
git push origin master

如果我有一个来自远程分支的本地分支,那么我不愿意将除此分支之外的其他分支与远程分支合并。此外,我不会推送我的更改,除非我对我想要推送的内容感到满意,而且我也不会推送任何内容,这些内容只针对我和我的本地存储库。在你的描述中,这个测试似乎只针对你?所以没有理由发表它。

git总是努力尊重你和其他人的改变,所以会——重新基准。我觉得我不能恰当地解释它,所以看看Git的书《Rebasing or Git ready》:介绍一下Rebasing。这是一个很酷的功能

我将按照开发和功能分支回答,

如果您在功能分支上,需要使用develop进行更新,请使用以下命令:

git checkout develop
git pull
git checkout feature/xyz
git merge develop

现在,您的feature/xyz已通过开发分支更新,您可以将更改推送到远程feature/xz。

本文来自GitLab:只需遵循说明:

@在很多情况下,金克鲁奇的答案应该是有效的。可能会出现的一个问题是,您可能在另一台机器上,需要从测试中获取最新信息。所以,我建议先进行拉力测试。修订如下:

git checkout test
git pull
git checkout master
git pull origin master
git merge test
git push origin master

您必须签出分支才能进行拉取,因为拉取意味着合并到主分支中,您需要一个工作树来合并。

git checkout master
git pull

无需先退房;rebase用两个参数做了正确的事情

git rebase master test  

git checkout master
git merge test

默认情况下,git push推送存在于此处和远程上的所有分支

git push
git checkout test