Question

我需要一些关于将我的开发分支合并到主分支的建议。另请注意，我正在使用Git Extensions，因此尽可能避免使用过多的命令行术语。

假设我已经在 dev 分支上做了3次提交（目前我还检查了它， mst 分支在我分支之后有1次提交关闭。

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

现在我想将 dev 分支合并到 mst 分支中，但实际上我只想合并提交1＆amp; 2。

我的理解是，我需要检查 mst （为任何正在进行的工作预先存储或临时提交）并将 mst 与提交2合并。

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

现在，提交3 不同步所以接下来要做的是重新同步 dev 分支。要做到这一点，我需要检查 dev 并将 dev 与 mst 合并或将 dev 转换为 MST

即

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

或

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

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

您需要“保存”当前的工作，然后结帐 mst 然后返回结帐 dev （我们正在使用VB6，所以我们还需要关闭重新打开VB6以重新加载文件，因为潜在的合并冲突，VB6无法识别外部修改的文件）
双重合并流程（一个到更新 mst ，另一个到重新同步 开发）< / LI>
另外，我对stash有一些可靠性问题（有时stash pop会阻止我弹出），这就是为什么我建议我的开发人员只进行临时提交（提交3之后），然后进行混合重置最后。

我们是一家小公司，所以尽可能快地解决问题是一个优先事项（但我们不能推出一切，因为有些事情会被阻止）。实际需要这么多步骤，还是有更快的方法？

Answer 1

您使用的工具是什么？我使用Mac客户端github：

http://mac.github.com/。

使用这个出色的工具，分支，合并，分支之间的更改对我来说只需30秒。但是你当然是在一个相当高的抽象级别上工作，但对于今天使用它来说就是我所需要的。

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

http://windows.github.com/

主要有3个级别的源管理工具：

1）VSS样式阻止签出：这是历史性的方法。如果你有一个开发人员或开发人员同时不在同一个文件上工作，这可能适合你。

2）SVN样式非阻塞检出：所有开发人员都在中央仓库上工作，但他们可能同时在同一个文件上工作。如果存在冲突，那么在提交之前需要解决这些冲突（在提交之前更新/解析）

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

您需要选择适合您的开发风格的最佳模型。对于拥有密切合作团队的大多数商业组织而言，SVN模型运作良好。如果你有更复杂的开发团队，Git可以帮助你处理它。

Answer 2

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

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

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

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

然后，当你想在不中断工作目录的情况下进行合并时，将更改从MyProject拉到MyProjectForMerging，进行合并，然后将提交提取回MyProject（警告：不要将更改推送到MyProject，总是获取/拉）。同样，您可以使用Git Extensions，也可以使用命令行：

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

并将更改重新带回主存储库：

cd ..\MyProject
git fetch ..\MyProjectForMerging

现在提交将在MyProject存储库中，准备好被推回原点或任何地方。如果需要，您也可以从MyProjectForMerging推送到任何其他遥控器。

Answer 3

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

Answer 4

使用分支

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

如果你这样做，无论你做了多少工作，你都会有一个干净的合并点。

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

我觉得在git中，创建短命分支（无论名称是什么）通常更容易，然后在推送到公众或授权回购时简单地合并相应的分支。

执行Git合并所需的步骤数

4 个答案: