执行Git合并所需的步骤数

我需要一些关于将我的开发分支合并到主分支的建议。 还请注意，我使用的是Git扩展，所以尽可能避免使用太多的命令行行话

假设我在dev分支上进行了3次提交（我目前仍将其签出，mst分支在我分支后有1次提交）

dev:    1 ---> 2 ---> 3
       /
      /
mst: 0 --- X

现在我想将我的dev分支合并到mst分支中，但实际上我只想合并提交1和2

我的理解是，我需要签出mst（对于任何正在进行的工作，事先隐藏或进行临时提交），并将mst与提交2合并

dev:    1 ---> 2 ---> 3
       /        \
      /          \
mst: 0 --- X ---- 4

现在，commit 3已不同步，因此下一步要做的是重新同步dev分支。 为此，我需要签出dev，并将dev与mst合并，或将dev重新设置到mst

即

或

与其他开发人员不一致的主要问题是，合并可能会成为一个巨大的时间浪费，因为

您需要“保存”当前工作，然后签出mst，然后返回签出dev（我们使用的是VB6，因此我们还需要关闭并重新打开VB6以重新加载文件，因为可能存在合并冲突，VB6无法识别外部修改的文件）

双重合并过程（一个用于更新mst，另一个用于重新同步dev）

另外，我也遇到了一些关于隐藏的可靠性问题（有时隐藏弹出会阻止我弹出），这就是为什么我建议我的开发伙伴只做一个临时提交（在提交3之后），然后在最后进行混合重置

我们是一家小公司，所以尽快把事情解决是一个优先事项（但我们不能把所有事情都推出去，因为有些事情会被拖延）。

---

实际上需要这么多步骤，还是有更快的方法？

您使用的工具是什么？我使用Mac client for github：

使用这个优秀的工具，分支、合并、分支之间的切换对我来说只需要30秒的操作。当然，你需要相当高的抽象级别，但对于今天的使用，这正是我所需要的

它也有一个windows变体，但我没有使用过，也不知道是否存在任何限制：

---

主要有三个级别的源代码管理工具：

1） VSS风格的阻止签出：这是历史上的做法。。如果您有一个或多个开发人员不同时处理相同的文件，这可能对您有用

2） SVN风格的非阻塞签出：所有开发人员都在一个中央回购协议上工作，但他们可能同时在同一个文件上工作。如果存在冲突，则需要在提交前解决这些冲突（提交前更新/解决）

3） Git风格的分布式SCM：当开发人员使用本地repo进行独立开发的时间更长时，这会带来最大的价值。一旦他们对结果感到满意，他们可能会决定将其变更发布到母公司回购协议中。主要用于开源开发

---

您需要选择适合您的开发风格的最佳模型。对于大多数拥有紧密合作团队的商业组织来说，SVN模型工作得相当好。如果您有更复杂的开发团队，Git可能会帮助您处理它。

Git需要在合并操作期间使用工作目录和索引，因为您需要它们来解决出现的任何合并冲突

如果在执行合并时需要将工作目录保持在脏状态，则可以使用主本地存储库作为源创建克隆存储库。然后在克隆中进行所有合并，并将更改恢复到主存储库中

您可以使用Git扩展进行克隆，也可以使用以下命令：

cd C:\Users\Basewq\Code
git clone MyProject MyProjectForMerging

然后，当您希望在不中断工作目录的情况下进行合并时，请将MyProject中的更改拉入MyProjectForMerging，进行合并，然后将提交的内容取回MyProject（警告：不要将更改推入MyProject，始终取/拉）。同样，您可以使用Git扩展，也可以使用命令行：

cd C:\Users\Basewq\Code\MyProjectForMerging
git checkout mst
git pull
git merge dev

要将更改带回主存储库，请执行以下操作：

cd ..\MyProject
git fetch ..\MyProjectForMerging

---

现在，提交将位于MyProject存储库中，随时可以推回原始位置或任何位置。如果需要，您也可以从MyProjectForMerging推送到任何其他远程设备。

Git需要在合并操作期间使用工作目录和索引，因为您需要它们来解决出现的任何合并冲突

如果在进行合并时需要将工作目录保持在脏状态，那么可以告诉Git临时使用另一个工作目录和索引。但是，这需要命令行，可能会造成混乱

目标是创建一个临时索引文件和一个临时工作目录。将Git指向它们，进行合并，然后恢复正常索引和工作目录

:: Create a temporary working directory, but use my normal repository

mkdir C:\Temp\MyProject
set GIT_DIR=C:\Users\Basewq\Code\MyProject  -- (path to my normal repo)
set GIT_INDEX_FILE=C:\Temp\index
set GIT_WORK_TREE=C:\Temp\MyProject

:: Now do the merge in C:\Temp\MyProject

git checkout mst
git merge dev

:: Now put everything back

set GIT_DIR=
set GIT_INDEX_FILE=
set GIT_WORK_TREE=
del C:\Temp\index
rd /q /s C:\Temp\MyProject

---

使用分支

正如注释中所建议的，最简单的方法是在第二次提交后创建一个新分支（如中所示，就在开始处理提交3的更改之前）

如果你这样做，不管你做什么进一步的工作，你都会有一个干净的合并点

您的工作流程似乎受到以前集中式vcs经验的影响。仅仅因为在你的授权回复上有一个分支“master”（mst）或“develop”（dev），并不意味着你必须把它们称为相同的分支，或者需要一对一的通信

我觉得在git中，创建短期分支（无论名称如何）通常更容易，然后在推送到公共或授权回购时简单地合并适当的分支

我用的是G

cd ..\MyProject
git fetch ..\MyProjectForMerging

:: Create a temporary working directory, but use my normal repository

mkdir C:\Temp\MyProject
set GIT_DIR=C:\Users\Basewq\Code\MyProject  -- (path to my normal repo)
set GIT_INDEX_FILE=C:\Temp\index
set GIT_WORK_TREE=C:\Temp\MyProject

:: Now do the merge in C:\Temp\MyProject

git checkout mst
git merge dev

:: Now put everything back

set GIT_DIR=
set GIT_INDEX_FILE=
set GIT_WORK_TREE=
del C:\Temp\index
rd /q /s C:\Temp\MyProject