从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
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就在您身边。

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

其他回答

这里已经有很多好答案了。我只是在添加我所做的步骤。

git fetch -p
git checkout master
git rebase origin/master
git checkout test
git rebase master

解释

gitfetch-p将检索自上次获取以来所做的任何更改,-p将修剪您的分支,删除所有过时的分支。

git checkout master签出master分支

gitrebaseorigin/master更新master分支。在这里做一次拉动会得到同样的结果。

gitcheckout测试签出您所做更改的分支

gitrebasemaster使用master上的更改更新测试分支。这将合并所有更改的文件,如果在任何提交上存在冲突,则必须解决它们,然后执行git rebase--continue或git rebase--abort

我总是在执行git合并功能分支时遇到合并冲突。这似乎对我有用:

git checkout -b feature-branch

进行一系列代码更改。。。

git merge -s ours master 

git checkout master

git merge feature-branch

or

git checkout -b feature-branch

进行一系列代码更改。。。

git checkout master

git merge -X theirs feature-branch
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。这是一个很酷的功能

我将首先使要合并的分支尽可能干净。运行测试,确保状态符合您的要求。通过git squash清理新提交。

除了克朗彻国王的回答,我建议使用

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

您可能在另一个分支中进行了多次提交,而在主分支中应该只有一次提交。为了尽可能保持提交历史记录的干净,您可能希望将测试分支中的所有提交压缩到主分支中的一个提交中(另请参阅:Git:压缩还是不压缩?)。然后,您还可以将提交消息重写为非常有表达力的内容。易于阅读和理解的内容,无需深究代码。

编辑:你可能对

在git中,merge-squick和rebase之间有什么区别?合并与再贴现如何重新估价拉取请求

因此,在GitHub上,我最终为一个功能分支mybranch执行了以下操作:

从原点获取最新信息

$ git checkout master
$ git pull origin master

查找合并基哈希:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

现在确保只有第一个是pick,其余的是s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

接下来选择一个非常好的提交消息并推送到GitHub。然后提出拉动请求。

合并拉取请求后,您可以在本地删除它:

$ git branch -d mybranch

和GitHub上

$ git push origin :mybranch