你有两个选择:

第一个是合并，但是这为合并创建了一个额外的提交。

检查每个分支:

git checkout b1

然后合并:

git merge origin/master

然后推:

git push origin b1

或者，你可以做一个rebase:

git fetch
git rebase origin/master

对于这个问题有两种选择。

1） Git 变基

2）去合并

只有与上述两者不同的合并情况下，将有额外的历史提交

1) git结帐分支(b1,b2,b3)

2) git rebase origin/master(如果冲突可以通过git rebase -continue在本地解决)

3）去推

或者，git合并选项是类似的方式

1) git checkout“your_branch”(b1,b2,b3)

2）转到合并母版

3）去推

你基本上有两个选择:

You merge. That is actually quite simple, and a perfectly local operation: git checkout b1 git merge master # repeat for b2 and b3 This leaves the history exactly as it happened: You forked from master, you made changes to all branches, and finally you incorporated the changes from master into all three branches. git can handle this situation really well, it is designed for merges happening in all directions, at the same time. You can trust it be able to get all threads together correctly. It simply does not care whether branch b1 merges master, or master merges b1, the merge commit looks all the same to git. The only difference is, which branch ends up pointing to this merge commit. You rebase. People with an SVN, or similar background find this more intuitive. The commands are analogue to the merge case: git checkout b1 git rebase master # repeat for b2 and b3 People like this approach because it retains a linear history in all branches. However, this linear history is a lie, and you should be aware that it is. Consider this commit graph: A --- B --- C --- D <-- master \ \-- E --- F --- G <-- b1 The merge results in the true history: A --- B --- C --- D <-- master \ \ \-- E --- F --- G +-- H <-- b1 The rebase, however, gives you this history: A --- B --- C --- D <-- master \ \-- E' --- F' --- G' <-- b1 The point is, that the commits E', F', and G' never truly existed, and have likely never been tested. They may not even compile. It is actually quite easy to create nonsensical commits via a rebase, especially when the changes in master are important to the development in b1. The consequence of this may be, that you can't distinguish which of the three commits E, F, and G actually introduced a regression, diminishing the value of git bisect. I am not saying that you shouldn't use git rebase. It has its uses. But whenever you do use it, you need to be aware of the fact that you are lying about history. And you should at least compile test the new commits.

令人惊讶的是，我最常用的方法没有被提及。这在基于Trunk的开发风格中是很常见的，其中main不断更新，并且从它的分支中工作。

假设main已经有了更新的代码，并且你在分支b1中。如果不是这种情况，您将需要git fetch。

因此，要用main中所做的更改更新b1，只需使用

git pull origin main

当您或其他人到达其他分支并想要更新时，也必须在其他分支中进行相同的操作。

有两种方法

您希望将主分支合并到您的分支中 - git checkout master - git拉 - git checkout your-feature-branch - git merge master //解决冲突并提交 - git push

2:如果你想在main的基础上重新调整你的改变。

 git checkout master #Switch to main branch
 git pull #Take latest
 git checkout your-feature-branch #Switch to story branch
 git pull --ff-only # Ensure branch is up to date
 git rebase -i origin master #Interactively rebase your commits on top of master. So your changes are on top of latest commits in main.
 git rebase --continue #Resolve conflicts and rebase --continue to continue with next commits
 git push -f origin your-feature-branch # As you have rewritten the commit history, you have to **force push** the commits

你有两个选择:

第一个是合并，但是这为合并创建了一个额外的提交。

检查每个分支:

git checkout b1

然后合并:

git merge origin/master

然后推:

git push origin b1

或者，你可以做一个rebase:

git fetch
git rebase origin/master