现在我有一个develop分支，我使用feature-keyboard作为新版本创建了一个新分支git checkout -b feature-keyboard develop。现在我需要对两个分支进行更改。我现在正在做的是我这样做：git checkout -b feature-ui-changes develop然后添加一些更改提交它们。然后是git checkout develop和git merge --no-ff feature-ui-changes。但是，如果我执行相同的首次结帐feature-keyboard，然后将更改合并到feature-ui-changes。它说冲突。而且这是假设的。但是，在对应用程序进行一些更改后，如何更新develop和feature-keyboard分支的更改？
答案 0 :(得分：1)
您可以在一个分支上执行更改，然后提交它们。然后切换到另一个分支并挑选您的更改：
git cherry-pick <commit-hash>
答案 1 :(得分：1)
如果你发现自己需要＆＃34;双重提交＆＃34;两个分支之间的大量更改，那么这表明您的流程可能存在问题。也许代码过早地分支了。
Git有一个很好的工作流程来创建一个＆＃34;主题＆＃34;你在哪里开发一些东西，同时跟上那个主题上游的变化。也就是说，您可以使用git rebase重写分支历史记录，并将更改迁移到较新版本的上游。
这可以节省您进行双重提交的痛苦，并且还可以防止您分配每个上游提交的两个副本。
$ git checkout -b topic
# ... hack, commit, hack, commit, ...
$ git checkout master
# ... pull, hack, commit, pull, ...
现在master上有各种新内容未反映在topic中：您所做的更改，以及可能从其他回购中获取的上游更改。您希望返回topic上的工作，但在新master上的工作基于。 变基的含义是：
$ git checkout topic
$ git rebase master
Git将找出当前分支topic和master之间的祖先点。它将从那一点开始进行topic更改，并在当前master之上挑选它们。然后，生成的选择将作为topic分支安装。从而，topic分支被重写：它被该分支的全新版本替换。 （当然，你可能必须解决冲突。）
如果您有两个或更多这样的主题，您可以单独处理它们：在返回时对其中的每个主题进行rebase，使其与主更改保持同步。
重新定位后的好处是，在topic重新定义之后，它包含上游分支（例如master）作为后缀：它具有{{1}中的所有提交加上一些新的提交。那时，你可以这样做：
master现在git checkout master
git reset --hard topic # fast-forward master to the topic
发生了所有master次更改：事实上，topic和master指向同一个提交对象：它们是相同的。我们可以安全地执行此操作，因为topic由于最近的rebase而没有master中的任何提交。因此，我们不会丢弃topic中的任何内容：它只是向前跳。
如果master确实有一些新的提交，你也可以进行＆＃34;其他方式的反对＆＃34;：
master # on master
git rebase topic # same as git reset --hard topic if master has no new commits!
上的新更改将重绕，然后会引入master更改，并重新播放（樱桃挑选）新更改。它是将topic变为topic的镜像：master并不关心哪个分支是主干，哪个是主题。
但是，如果这些新的rebase提交是公开的，那么您通过对master更改进行重新定位来编写公开历史记录。如果topic以外的所有新master提交都是您自己的未发布的（您在本地创建并且未经过topic - 将它们转到另一个仓库，则可以免除此操作），或者你有一些其他理由重写git push历史，即使它已被发表。