问题标签 [git-merge]

所以我只是为我们的一个文件打了补丁，我看到了一些不应该存在的代码（加上这个流氓代码导致的网页错误）。该代码是几个月前在补丁中添加的，然后在大约一个月前被该提交的还原删除。所以它真的不应该在那里。

我尝试了几种方法来追踪它的来源：

1. git blame：奇怪的是，向我展示了添加代码的原始提交的提交标记和消息，就好像还原从未发生过一样。
2. git log -- 文件名：显示了我预期会出现的所有提交，包括还原，但之后没有任何内容表明它应该重新出现。
3. 手动检查补丁（二等分）：代码在还原后直接重新出现在提交中，但是当我检查该补丁时，它的日志完全不同，并且没有还原。

最后的观察让我得出结论，有问题的补丁是一个拙劣的合并，但提交消息没有提到合并，我们的团队通常保留 git 生成的合并消息。

看起来是这样吗？在解决冲突期间做出错误的选择是否重新引入了代码？如果是这样，有没有更快的方法来找到这种东西？例如，git blame 说代码来自我原来的补丁。但是有没有办法让它直接告诉我它在恢复后在补丁 X 中重新引入？如果 git 不知道在合并期间受到影响，它如何跟踪每段代码的来源？它是否能够告诉我有人在合并冲突期间弄乱了那段代码？我认为合并本身应该出现在指责中。

一个新的分支 frommaster被创建，我们称之为test。

有几个开发人员要么提交master或创建其他分支，然后合并到master.

假设工作test需要几天时间，并且您希望不断test更新内部的提交master。

我会git pull origin master从test.

问题1：这是正确的方法吗？顺便说一句，其他开发人员可以轻松地处理与我工作过的文件相同的文件。

我的工作test已经完成，我准备将其合并回master. 以下是我能想到的两种方式：

A：

乙：

我没有使用--rebase，因为根据我的理解，rebase 会从中获取更改master并将我的更改堆叠在此之上，因此它可能会覆盖其他人所做的更改。

问题2：这两种方法哪一种是正确的？那里有什么区别？

所有这一切的目标是让我的test分支更新发生的事情，master然后我可以将它们合并回来，master希望尽可能保持时间线的线性。

我在分支上mybranch1。mybranch2从中分叉mybranch1并在 中进行了更改mybranch2。

然后，在 on 时mybranch1，我已经完成了git merge --no-commit mybranch2 它表明合并时存在冲突。

现在我想丢弃所有内容（merge命令），以便mybranch1恢复到以前的状态。我不知道我该怎么做。

我的团队正在 git 中开发一个共享主题分支，我将其称为“topic1”。我正在对由 topic1 构成的分支上的一些代码进行重构，我将其称为“重构”。我一直在定期将 topic1 合并到重构中，以便我可以及时了解更改，但没有将重构合并回 topic1，因为重构仍在进行中。

还有另一个主题分支，我称之为“topic2”，它是最近从 master 创建的。我想做的只是将我对“重构”所做的更改合并到一个由 topic2 构成的新分支，我将其称为“topic2_refactor”。（即提交中的更改只能通过重构访问，但不能通过 topic1 访问。）

我知道如何看到这些变化：

所以我想做的是这样的——但这种语法不正确：

然后这个：

或这个：

（以上似乎导致了不必要的合并冲突，因为 master 上发生了一些更改，后来又合并回了重构分支。）

我希望有一种干净的方法来做到这一点，并避免不必要的合并冲突，这些冲突后来在“重构”分支的历史中得到解决。这可能使用 git rebase、git filter-branch 等吗？

我有一个 git 分支（例如主线），我想合并到另一个开发分支。还是我？

为了决定我是否真的想合并这个分支，我想看看合并将做什么的某种预览。最好能够查看正在应用的提交列表。

到目前为止，我能想到的最好的方法是merge --no-ff --no-commit, 然后diff HEAD.

我跑了一个git pull以冲突告终的。我解决了冲突，现在一切都很好（我也使用了 mergetool）。

当我提交已解析的文件时，git commit file.php -m "message"出现错误：

我之前遇到过同样的问题，并且-a在提交中使用效果很好。我认为这不是完美的方式，因为我不想提交所有更改。我想用单独的注释单独提交文件。我怎样才能做到这一点？为什么git不允许用户在合并后单独提交文件？我找不到这个问题的满意答案。

我正在与多个“共同祖先”可用的场景进行合并，因此 Git 运行“git merge recursive”策略。

因此，它运行合并以创建一个新的祖先，该祖先又将用作我正在处理的贡献者的 CA。

好的，问题如下，有一个冲突的文件，其中“祖先”来自 Git 内部执行的“递归合并”，所以，当我尝试使用 KDiff3 修复与 git mergetool 的冲突时，我看到以下内容：

这是正常的吗？我的例子有点“太简单了”（文件中只有一行，所以不是真的），但是......有这个共同的祖先会有帮助吗？

谢谢！！

我正在将一个修补程序分支合并到 master 中。当我做一个简单git merge hotfix-2.09的合并快进但我'merge branch "hotfix-2.09"'在日志中得到一个提交。修补程序 01 - 08 没有这样做。我在这个合并中做错了什么，还是我的主人的状态发生了一些变化？

编辑我想这不是真正的快进，而是像它一样。

I am curious about some best practices.

There is a git repo that I would like to include as a submodule in my project. I would also like to contribute to this repo and offer pull requests. I have forked the repo and would like to add my fork as the submodule to my project.

I have made a new slim branch in my fork that removes some stuff from the original repo master branch: e.g. example files, demos, etc. I would specifically like to use this slim branch for the submodule to keep the extra stuff out.

I have successfully done this branching and submodule strategy. However I am now wondering about pull requests and contributions to the project.

Ideally I would like to edit the submodule as part of my project, and push commits to the submodules slim branch. I would then like to merge the changes in slim branch back into master so that I can do a pull request.

However I do not want my initial delete commit on the slim branch to be merged back into master. What are some ways I can contribute back to the project with out messing in some of my delete commits?

我正在尝试使用 git 的子树合并策略，其中我要合并的子目录嵌套得相当深——目前有四层深。

我按照此处的说明将模块存储库添加为远程，运行 git read-tree 以将远程代码放入本地存储库的子目录中，然后提交这些更改。

当我尝试将远程更改并合并到我的主项目的主分支时，我的问题就出现了。上面页面的第 5 步建议使用 -s 子树开关进行 git pull。当我的子目录为一层、两层或三层而不是四层时，这对我来说是正确的。

这是合并到 2 层深的子目录的结果。您可以看到sites/all/ 中的README 文件已正确更新。在我的远程仓库中，自述文件位于根目录中。

这里的子目录有 3 层深：sites/all/modules/。这也可以正常工作，拉取更改并更新文件。

但现在我的代码位于 4 层深的子目录中：sites/all/modules/my_module/。Git 似乎从 REMOTE_REPO 中提取了更改，但它不会更新文件，而是告诉我它已经是最新的。

如果我立即再次运行它，它不会拉取更改或更新文件。

此时查看 git 日志将显示来自远程 repo 和合并的更改，但我结帐中的文件尚未更新。

这是一个错误，还是我做错了什么？

更新： Chris Johnsen 提供了以下选项，但会引发错误：