从分叉存储库中提取 GIT，但两者都有进步

我有一个git存储库，有一个分支说V1。
我已经推进了它的提交，比如 c1.1->c1.2->c1.3，但随后我通过名称 V2 从 c1.2 分叉，因为我需要维护与 c1.2 分开的分支。
我添加了很多/很多提交，比如 c2.1->c2.2->c2.3。
与此同时，V1 升级到 c1.3->c1.4->c1.5。
现在，我想在 V1 分支中添加在 V2 分支中所做的更改，但不影响在 V1 中所做的更改。

我想我可以通过从 c2 提交创建 V1.2 分支然后做 git pull origin V2 --rebase

我的问题如下。

上述命令是否会成功运行而不会篡改来自 V1 和 V2 的任何提交。
如果我在两个版本中更改了相同的文件但代码的不同部分怎么办？
如果我在两个版本中更改了相同的文件和相同的代码怎么办？
如果同一文件同时发生上述两个事件怎么办？
以上3点会不会有冲突？如果是，如何解决？如果没有，那为什么？
提交消息会发生什么情况

我不想深入了解 git。简单的外行答案预期，但技术细节也欢迎。

此外，当我尝试从 V2 分支执行 git diff V1 时，我可以看到 V1 和 V2 之间的差异，很少添加和删除。
然后从 V1 我做了 git pull origin V2，再次做了 git diff V2，我可以再次看到相同的差异，但几乎没有更多差异。
我怀疑这是正确的行为，因为不应该有区别或只有额外的区别。？

在 git 中执行此操作的两种基本方法是：

将 V2 合并到 V1 中：
```
git checkout V1
git merge V2
```
V1 之上重定 V2 的基数：
```
git checkout V2
git rebase V1
```

如果 git 检测到任何在两端修改的文件，其中两端的差异不完全相同，它将在提交任何内容之前停止，并让您检查所述文件的内容。

这就是所谓的冲突，您可以找到一些关于选择要保留的每个修改块的版本指南。

起点是：如果发生这样的事情，请运行命令git mergetool。
git将在 3 窗格模式下打开默认的比较工具，您可以在其中比较文件的两个版本(左和右)，并构建要保留在中间的版本。

关于 git 合并工具中显示的内容的一些解释：

假设您的历史记录如下所示：

*--*--X--*--*--*--A <- branch V1

Y--Z--B <- branch V2

如果将V2合并到V1：
```
git checkout V1
git merge V2
```
并得到冲突，
当你打开git mergetool：
- 左窗格(LOCAL)将是文件的V1版本
- 右窗格(REMOTE)将是V2的文件版本
- 中间窗格(BASE)将是：XX
  的文件版本是最近的提交，它是V1和V2的祖先
如果将V2变基到V1：
```
git checkout V2
git rebase V1
```
Git 变基的快速提醒：
git 查找在V2上而不是在V1上的提交(在我们的图中，这些提交将是Y、Z和B)，并在V1之上"重播"Y，然后Z在最后一次提交之上，然后B在最后一次提交之上。
git 变基期间的冲突：
重播Y时，或重播Z时，或重播B时，可能会发生冲突。
在每一步中，"基本提交"将是重放提交的父级：
- 如果在重播Y时发生冲突，则基本提交将被X
- 如果在重放Z时发生冲突，则基本提交将被Y
- 如果在重播B时发生冲突，则基本提交将被Z
Git 合并工具中显示的内容：
当您打开git mergetool时：
- 左窗格(LOCAL)将是V1的文件版本
- 右窗格(REMOTE)将replayed commit的文件版本，这取决于触发冲突的步骤
- 中间窗格(BASE)将是文件的base commit版本，这取决于触发冲突的步骤

你的 qsn 集的响应，

提交永远不会被篡改。每个提交都存储在合并时结转的版本中。
如果不发生相同的行冲突，文件将自动合并，没有冲突
然后会有冲突，您必须手动解决此冲突并提交这些文件。

对于下面的其他问题，解释应该会有所帮助。

git Rebase是正确的行为，它通过为原始分支中的每个提交创建全新的提交来重写项目历史记录。如果您在同一文件中有类似的提交，这有助于清理混乱的历史记录。一件事是您无法跟踪更改何时合并到功能中。

Git checkout v2
Git rebase -i V1

这有助于交互式变基，您可以在其中相应地更改提交。

相关内容

最新更新

热门标签：