合并到git后git-svn dcommit危险吗？

Question

我尝试 git-svn 的动机是轻松的合并和分支。 然后我注意到 man git-svn(1) 说：

不建议在您计划的分支上运行 git-merge 或 git-pull d 提交自。 Subversion 不代表任何合并 合理或有用的时尚； 因此使用 Subversion 的用户看不到任何 您所做的合并。 此外，如果你从 git 合并或拉取 分支是 SVN 分支的镜像，dcommit 可以提交到 错误的分支。

这是否意味着我无法从 svn/trunk （或分支）创建本地分支，破解，合并回 svn/trunk，然后 dcommit？ 我知道 svn 用户会看到 svn pre 1.5.x 中合并的混乱情况，但是还有其他缺点吗？ 最后一句话也让我担心。 人们经常做这些事情吗？

Answer 1

实际上，我在 git merge 上使用 --no-ff 选项找到了更好的方法。
我以前使用的所有这些挤压技术都不再需要了。

我的新工作流程现在如下：

• 我有一个“主”分支，这是我提交的唯一分支，它克隆 SVN 存储库（-s 假设您有标准 SVN 布局在存储库 trunk/、branches/ 和 tags/ 中）：

  git svn clone [-s] ; 
    

• 我在本地分支“work”上工作（-b 创建分支“work”）

  git checkout -b work 
    

• 本地提交到“work”分支（- s 签署您的提交消息）。 在接下来的内容中，我假设您进行了 3 次本地提交

  <前><代码>...
  (工作)$> git commit -s -m“消息1”
  ...
  (工作)$> git commit -s -m“消息2”
  ...
  (工作)$> git commit -s -m “消息 3”

现在您想要提交到 SVN 服务器

• [最终] 存储您不希望看到在 SVN 服务器上提交的修改（通常您在主文件中注释了一些代码）文件只是因为您想加速编译并专注于给定的功能）

  <前><代码>（工作）$> git 存储

• 使用 SVN 存储库对 master 分支进行变基（以从 SVN 服务器更新）

  <前><代码>（工作）$> git 结账大师
  （大师）$> git svn 变基

• 返回工作分支并使用 master 进行 rebase

  <前><代码>(主)$> git 结账工作
  (工作)$> git 变基大师

• 确保一切正常，例如：

  <前><代码>（工作）$> git log --graph --oneline --decorate

• 现在是时候使用这个美妙的 --no-ff< 将“work”分支的所有三个提交合并到“master”中/code> 选项

  <前><代码>（工作）$> git 结账大师
（大师）$> git merge --no-ff 工作


• 您可以注意到状态日志：

  <前><代码>(主)$> git log --graph --oneline --decorate
  * 56a779b（工作，主控）合并分支“工作”
  |\
  | * af6f7ae 消息 3
  | * 8750643 消息 2
  | * 08464ae 消息 1
  |/
  * 21e20fa (git-svn) 最后一次 svn 提交

• 现在您可能想要编辑（修改）您的 SVN 人员的最后一次提交（否则他们只会看到带有消息“合并分支'工作'”的单次提交

  <前><代码>(主)$> git commit --修改

• 最终在SVN服务器上提交

  <前><代码>(主)$> git svn dcommit

• 返回工作并最终恢复您隐藏的文件：

  <前><代码>(主)$> git 结账工作
  (工作)$> git stash 流行

Answer 2

使用 git-svn 绝对可以创建本地分支。 只要您只是自己使用本地分支，而不是尝试使用 git 在上游 svn 分支之间进行合并，就应该没问题。

我有一个“master”分支，用来跟踪 svn 服务器。 这是我提交的唯一分支。 如果我正在做一些工作，我会创建一个主题分支并继续努力。 当我想提交时，我会执行以下操作：

1. 将所有内容提交到主题分支
2. git svn rebase （解决您的工作和 svn 之间的任何冲突）
3. git checkout master
4. git svn rebase （这使得下一步是快进合并，请参阅下面 Aaron 的评论）
5. git merge topic_branch
6. 解决任何合并冲突 （此时不应该有任何冲突）
7. git svn dcommit

我还有另一个我需要维护一些本地更改（用于调试）的情况，这些更改永远不应该推送到 svn。 为此，我有上面的 master 分支，还有一个名为“work”的分支，我通常在其中工作。 主题分支是从工作中分支出来的。 当我想在那里提交工作时，我会签出 master 并使用cherry-pick 从工作分支中选择我想要提交到 svn 的提交。 这是因为我想避免提交三个本地更改提交。 然后，我从主分支提交并重新设置所有内容。

首先运行 git svn dcommit -n 是值得的，以确保您将要准确地提交您想要提交的内容。 与 git 不同，在 svn 中重写历史非常困难！

我觉得一定有一种比使用cherry-pick更好的方法来合并主题分支上的更改，同时跳过那些本地更改提交，所以如果有人有任何想法，他们将受到欢迎。

Answer 3

简单的解决方案：合并后删除“工作”分支

简短回答：您可以根据需要使用 git （参见下面的简单工作流程），包括合并。 只需确保在每个“git merge work”后面加上“gitbranch -d work”即可删除临时工作分支。

背景说明：
合并/dcommit 问题是，每当您“git svn dcommit”一个分支时，该分支的合并历史记录就会“扁平化”：git 会忘记进入该分支的所有合并操作：仅保留文件内容，但事实是该内容（部分）来自特定的其他分支已丢失。 请参阅： 为什么git svn dcommit 会丢失本地分支合并提交的历史记录吗？

（注意：git-svn 对此无能为力：svn 根本不理解更强大的 git merges。因此，在svn 存储库此合并信息无法以任何方式表示。）

但这就是整个问题。 如果您在将“工作”分支合并到“主分支”后将其删除，那么您的 git 存储库就是 100% 干净的，并且看起来与您的 svn 存储库完全相同。

我的工作流程：
当然，我首先将远程 svn 存储库克隆到本地 git 存储库（这可能需要一些时间）：

gt; git svn clone <svn-repository-url> <local-directory>

然后所有工作都发生在“本地目录”内。 每当我需要从服务器获取更新（例如“svn update”）时，我都会这样做：

gt; git checkout master
gt; git svn rebase

我在一个单独的分支“work”中完成所有开发工作，该分支的创建方式如下：

gt; git checkout -b work

当然，您可以为您的应用程序创建尽可能多的分支按照你喜欢的方式工作，并按照你喜欢的方式在它们之间合并和变基（使用完它们后只需删除它们 --- 如下所述）。 在我的正常工作中，我非常频繁地提交：

gt; git commit -am '-- finished a little piece of work'

下一步（git rebase -i）是可选的——它只是在将历史记录归档到 svn 之前清理历史记录：一旦我达到了一个稳定的里程碑，我想与其他人分享，我重写了这个“工作”分支的历史记录并清理了提交消息（其他开发人员不需要看到我在此过程中犯的所有小步骤和错误——只需要结果）。 为此，我

gt; git log

复制了 svn 存储库中最后一次提交的 sha-1 哈希值（如 git-svn-id 所示）。 然后我调用

gt; git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb

Just Paste 我们最后一次 svn 提交的 sha-1 哈希值而不是我的。 您可能需要阅读“git help rebase”文档以了解详细信息。 简而言之：此命令首先打开一个编辑器，显示您的提交 ---- 只需将您想要与以前的提交一起压缩的所有提交的“pick”更改为“squash”即可。 当然，第一行应该保留为“pick”。 通过这种方式，您可以将许多小提交压缩为一个或多个有意义的单元。
保存并退出编辑器。 您将看到另一个编辑器要求您重写提交日志消息。

简而言之：在完成“代码黑客”后，我会调整我的“工作”分支，直到它看起来像我想要向其他程序员展示的那样（或者我想要在几周后浏览历史记录时看到的工作） 。

为了将更改推送到 svn 存储库，我这样做：

gt; git checkout master
gt; git svn rebase

现在我们回到了旧的“master”分支，更新了 svn 存储库中同时发生的所有更改（您的新更改隐藏在“work”中）分支）。

如果存在可能与您的新“工作”更改发生冲突的更改，您必须在本地解决它们，然后才能推送新工作（请参阅下面的详细信息）。 然后，我们可以将更改推送到 svn：

gt; git checkout master
gt; git merge work        # (1) merge your 'work' into 'master'
gt; git branch -d work    # (2) remove the work branch immediately after merging
gt; git svn dcommit       # (3) push your changes to the svn repository

注意 1：命令 'gitbranch -d work' 非常安全：它只允许您删除不再需要的分支（因为它们已经合并到您当前的分支中） ）。 如果您在将工作与“master”分支合并之前错误地执行了此命令，您会收到一条错误消息。

注意 2：确保在合并和 dcommit 之间使用 'gitbranch -d work' 删除分支：如果您尝试在 dcommit 后删除分支，您会收到一条错误消息：当您执行 'git svn dcommit'，git 忘记了你的分支已经与 'master' 合并了。 您必须使用“git Branch -D work”删除它，这不会进行安全检查。

现在，我立即创建一个新的“工作”分支，以避免意外侵入“主”分支：

gt; git checkout -b work
gt; git branch            # show my branches:
  master
* work

将您的“工作”与 svn 上的更改集成：
当“git svn rebase”显示其他人在我处理“工作”分支时更改了 svn 存储库时，我会执行以下操作：

gt; git checkout master
gt; git svn rebase              # 'svn pull' changes
gt; git checkout work           # go to my work
gt; git checkout -b integration # make a copy of the branch
gt; git merge master            # integrate my changes with theirs
gt; ... check/fix/debug ...
gt; ... rewrite history with rebase -i if needed

gt; git checkout master         # try again to push my changes
gt; git svn rebase              # hopefully no further changes to merge
gt; git merge integration       # (1) merge your work with theirs
gt; git branch -d work          # (2) remove branches that are merged
gt; git branch -d integration   # (2) remove branches that are merged
gt; git svn dcommit             # (3) push your changes to the svn repository

存在更强大的解决方案：
所提出的工作流程很简单：它仅在每一轮“更新/黑客/dcommit”中使用 git 的功能——但使长期项目历史记录与 svn 存储库一样线性。 如果您只想在遗留 svn 项目中的小第一步中开始使用 git merges，这是可以的。

当您更加熟悉 git 合并时，请随意探索其他工作流程：如果您知道自己在做什么，您可以将 git 合并与 svn 合并混合使用（使用 git-svn （或类似的）只是为了帮助 svn 合并？)

Answer 4

Greg Hewgill 上面的答案并不安全！ 如果两个“git svn rebase”之间的主干上出现任何新的提交，则合并将不会快进。

可以通过在 git-merge 中使用“--ff-only”标志来确保这一点，但我通常不在分支中运行“git svn rebase”，只在其上运行“git rebase master”（假设它只是本地的）分支）。 然后“git merge thebranch”保证快进。

Answer 5

在 git 中合并 svn 分支的一个安全方法是使用 git merge --squash。 这将创建一个提交并停止供您添加消息。

假设您有一个主题 svn 分支，称为 svn-branch。

git svn fetch
git checkout remotes/trunk -b big-merge
git merge --squash svn-branch

此时，您已将 svn 分支中的所有更改压缩为一个提交，并在索引中等待

git commit

Answer 6

将本地 git 分支重新设置到主 git 分支上，然后进行 dcommit，这样看起来就像您按顺序完成了所有这些提交，以便 svn 人们可以按照他们习惯的方式线性地看到它。 因此，假设您有一个名为 topic 的本地分支，您可以这样做

git rebase master topic

，然后它将在 master 分支上播放您的提交，准备好进行 dcommit