任何人都可以帮助避免git合并问题。 我想合并我的分支让我说my_branch到另一个分支让我们说另一个分支。因为another_branch是基础分支。所以要添加my_branch中完成的工作，首先我要合并my_branch。为此，我正在执行这些步骤。
git checkout another_branch
git pull anothr_branch
我在another_branch中更新了最新的更改后，切换到my_branch
git checkout my_branch
git merge anothr_branch
在完成所有这些之前，我正在提交并暂存我的更改以在本地保存它。所以毫无疑问会失去我的任何改变。
但我没有看到another_branch的所有更改。所以我称之为覆盖。
可能是什么原因？
答案 0 :(得分：1)
您可能想要做的是使用rebase。在源分支上提交后，rebase会在目标分支中放置提交。
所以在本地，如果我在我的功能分支上，我将使用git rebase master - 这会将我在功能分支上的提交放在master的最新提交之上。
对于远程分支，我通常使用git pull --rebase来保存您的更改，从服务器提取更改，将更改置于服务器的最新更改之上。
我遇到的最佳视觉指导方式是this one by Atlassian。
您可以在以下资源中找到有关rebase的更多信息：
答案 1 :(得分：1)
这是我们在多开发人员，多团队环境中使用的日常例程，该环境非常简单且运行良好。
假设您有一个 dev 分支，用于存储产品的当前开发版本。存储当前生产版本的主分支。每个开发人员都有自己的分支来实现正在实施的功能或错误修复。
每天早上，所有开发者都会做以下事情：
结帐 dev 。
拉。
结帐 dev的工作分支
重新定位到 dev
全天，上述情况可能会重演。开发人员将合并请求发送给指定为 dev 分支的维护者的其他开发人员。
开发者：
提交更改。
按
开发维护者：
从开发人员签出分支以合并
拉。
Checout dev 。
从开发人员的分支合并到合并
推
答案 2 :(得分：0)
在您将冲突标记为已解决的文件标记之前，Git不会覆盖。（即使它们确实不是）。
Git不会尝试合并聪明。合并时，如果它可以干净地合并，它会这样做。如果不能，它将暂停合并过程并标记您应手动解决的冲突。解决完文件冲突后，应使用命令git add <file>...将其标记为已解析（与用于跟踪文件的命令相同）。
Git标记了这样的冲突：
<<<<<<< HEAD:index.html
< div id="footer" > contact : email.support@kozbara.com</div>
=======
<div id="footer" >
please contact us at support@kozbara.com</div>
>>>>>>> anotherBranch:index.html
上部（====之前的部分）位于文件index.html的HEAD处。下半部分来自同一文件中名为 anotherBranch 的分支。
也许您想从git tutorial中阅读this part。
答案 3 :(得分：0)
我解决了以下分支布局的问题：
功能A -从开发分支而来，对所有文件进行了大量更改。很久没有处理了。
开发-当前版本，错误修复以及需要发布的其他新功能。最近正在研究。
我希望Develop的所有新功能都可以在featureA上使用。 所以我做到了：
在featureA分支上：
git rebase develop
（这会将整个功能分支移到developer分支的顶部，并保留所有提交）->并非如此。它用开发覆盖了一切。
然后： 在开发分支上：
git rebase featureA
（这将整个开发分支移到了featureA的顶部），并且成功了！ 但是，存在冲突是有道理的，因为对文件和文件进行了编辑，但这是我想要的，因为我现在可以选择。
error: could not apply fa39187... something to add to patch A
因此，我将解决冲突（选择我想要的更改...有时会从featureA和同一文件中的development中选取一些内容），然后提交并推送，然后继续进行基础调整，直到使用下一个提交冲突为止< / p>
git rebase --continue
这将表示不再存在问题，我应该改用
git rebase --skip
我这样做，然后又发生另一个冲突，依此类推。 因此，基本上尝试以其他方式重新设置基础使我能够看到所有代码更改，并一步一步解决了我想做的冲突。