从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

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

git rebase master test  

git checkout master
git merge test

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

git push
git checkout test

其他回答

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

git checkout master
git pull

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

git rebase master test  

git checkout master
git merge test

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

git push
git checkout test

这是一个非常实用的问题,但上面的所有答案都不实用。

Like

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

这种方法有两个问题:

这是不安全的,因为我们不知道测试分支和主分支之间是否存在冲突。它会将所有测试提交“压缩”到master上的一个合并提交中;也就是说,在主分支上,我们看不到测试分支的所有更改日志。

因此,当我们怀疑会发生冲突时,我们可以执行以下git操作:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

在提交之前测试合并,通过--no ff避免快速提交,

如果遇到冲突,我们可以运行gitstatus来检查冲突的详细信息并尝试解决

git status

一旦我们解决了冲突,或者如果没有冲突,我们就承诺并推动它们

git commit -m 'merge test branch'
git push

但这种方式将丢失记录在测试分支中的更改历史,并且会使主分支很难让其他开发人员了解项目的历史。

因此,最好的方法是我们必须使用rebase而不是merge(假设此时我们已经解决了分支冲突)。

以下是一个简单的示例,有关高级操作,请参阅http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

是的,当你完成了上层时,所有测试分支的提交都将被移动到Master分支的头上。重新定基的主要好处是可以获得线性的、更清晰的项目历史。

唯一需要避免的是:永远不要在公共分支上使用rebase,就像master分支一样。

切勿执行以下操作:

git checkout master
git rebase -i test

的详细信息https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

附录:

如果您不确定重新定基操作,请参阅:https://git-scm.com/book/en/v2/Git-Branching-Rebasing

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

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

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

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

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

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

重新基准和合并都不应覆盖任何人的更改(除非您在解决冲突时选择这样做)。

开发时的通常方法是

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

当你准备好合并回master时,

git checkout master
git log ..test # if you're curious
git merge test
git push

如果您担心在合并过程中出现问题,gitmerge--abort就在您身边。

使用推拉合并是愚蠢的。我也不确定你为什么要把测试推向原点。