问合并到git后的git-svn dcommit会有危险吗？

EN

实际上，我发现了一种更好的方法，在git merge上使用--no-ff选项。我以前使用的所有这些壁球技术都不再需要了。

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

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

git svn clone -s

• 我在本地分支" work“上工作(-b创建分支"work")

git checkout -b work

• commit本地进入"work“分支(使用-s对提交消息进行签名)。在续集中，我假设您进行了3次本地提交

..。(工作)$> git commit -s -m "msg 1“...(工作)$> git commit -s -m "msg 2“...(工作)$> git commit -s -m "msg 3"

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

SVN

• 最终会将您不希望看到的修改保存在服务器上(通常，您在主文件中注释了一些代码，仅仅是因为您想要加速编译并专注于给定的特性)。

(工作)$> git stash

• 使用SVN存储库重新设置主分支的基础(从SVN服务器进行更新)

(工作)$> git签出主程序(主程序)$> git svn rebase

• 返回工作分支并使用主程序重新建立基本程序

(主)$> git签出工作(工作)$> git rebase master

• Ensure使用以下命令一切都很好，例如：

(工作)主git日志--$> --oneline --decorate

• Now现在是时候使用这个出色的--no-ff选项将“工作”分支中的所有三个提交合并到“$>”中了

$> git checkout master ($>)$> git merge --no-ff work

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

(主) svn git日志--图形--oneline -装饰* 56a779b (工作，主)合并分支‘工作’|\ |* af6f7ae消息3|* 8750643消息2|* 08464ae消息1 |/ * 21e20fa (git- SVN ) $>提交

• 现在，您可能想要编辑(amend)您的SVN伙伴的最后一次提交(否则他们只会看到一次提交，并显示消息“合并分支‘工作’”)

(主) SVN服务器上的$> git提交--amend

• Finally提交

(master)$> git svn dcommit

• 继续工作，并最终恢复您隐藏的文件：

($>) git签出工作(工作)$> git stash pop

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

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

1. 将所有内容提交到主题分支
2. git svn rebase (解决您的工作和svn之间的任何冲突)
3. git签出主
4. git svn rebase (这使得下一步是快进合并，请参阅下面的Aaron注释)

<代码>H19git merge topic_branch

1. resolve任何合并冲突(此时应该没有任何冲突)<代码>H212<代码>H113git svn dcommit<代码>H214<代码>G215

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

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

我觉得一定有更好的方法来合并主题分支上的更改，同时跳过那些本地更改提交，而不是使用樱桃挑选，所以如果有人有任何想法，他们将是受欢迎的。

简单的解决方案:合并后删除'work‘分支

简短回答：你可以随心所欲地使用git (参见下面的简单工作流程)，包括merge。只要确保遵循每个“git merge work ”和“git branch -d work”来删除临时工作分支即可。

背景解释：合并/dcommit问题是，当你“git svn dcommit”一个分支时，该分支的合并历史记录是“扁平的”：git忘记了所有进入该分支的合并操作:只保留文件内容，但这些内容(部分)来自特定的其他分支的事实丢失了。请参阅：Why does git svn dcommit lose the history of merge commits for local branches?

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

但这是整个问题所在。如果你在“工作”分支合并到“主分支”之后删除它，那么你的git仓库是100%干净的，看起来和你的svn仓库一模一样。

当然，我首先将远程存储库克隆到本地git存储库(这可能需要一些时间)：

$> git svn clone <svn-repository-url> <local-directory>

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

$> git checkout master
$> git svn rebase

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

$> git checkout -b work

当然，您可以为您的工作创建任意多的分支，并根据您的喜好在它们之间进行合并和重新建立基础(只需在完成后删除它们-如下所述)。在我的正常工作中，我经常做以下事情：

$> git commit -am '-- finished a little piece of work'

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

$> git log

并复制svn储存库中的最后提交的sha-1散列(如git-svn-id所指示的)。然后我会打电话给

$> git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb

只需粘贴我们上次svn提交的sha-1散列，而不是我的。你可能想要阅读'git help rebase‘的文档来了解详细信息。简而言之:这个命令首先打开一个呈现你的提交的编辑器-对于你想用之前的提交来压缩的所有提交，只需将'pick‘改为' squash’即可。当然，第一行应该保留为“选择”。通过这种方式，您可以将许多小提交压缩为一个或多个有意义的单元。保存并退出编辑器。您将看到另一个编辑器要求您重写提交日志消息。

简而言之:在我完成“代码破解”之后，我推敲我的“工作”分支，直到它看起来是我想要向其他程序员展示它的方式(或者当我浏览历史记录时，我想要在几周内看到工作)。

为了将更改推送到svn存储库，我执行以下操作：

$> git checkout master
$> git svn rebase

现在我们回到了旧的'master‘分支，同时更新了svn存储库中发生的所有更改(您的新更改隐藏在'work’分支中)。

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

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

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

注意2:确保在合并和dcommit之间使用'git branch -d work‘删除你的分支:如果你试图在dcommit之后删除分支，你会得到一个错误信息:当你执行'git svn dcommit’时，git忘记你的分支已经和'master‘合并了。你必须使用不做安全检查的'git branch -D work‘来删除它。

现在，我立即创建了一个新的'work‘分支，以避免意外地攻击'master’分支：

$> git checkout -b work
$> git branch            # show my branches:
  master
* work

将你的‘工作’与svn上的更改集成在一起：当'git svn rebase‘显示当我在我的’工作‘分支上工作时，其他人更改了svn存储库时，我会这么做：

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

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

存在更强大的解决方案：目前的工作流程过于简单:它只在每一轮的“更新/破解/提交”中使用git的功能-但长期项目历史与svn存储库一样线性。如果您只是想在遗留的svn项目中开始使用git合并，那么这是可以的。

当您更熟悉git合并时，请随意探索其他工作流程:如果您知道自己在做什么，则可以将git合并与svn合并(Using git-svn (or similar) just to help out with svn merge?)混合在一起。