blocks|key|3363003|text|使用git-svn创建本地分支绝对是可能的。只要您只是为自己使用本地分支，而不是尝试使用git在上游svn分支之间进行合并，就应该没问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363004|我有一个"master“分支，用于跟踪svn服务器。这是我执行dcommit操作的唯一分支。如果我正在做一些工作，我会创建一个主题分支，然后继续工作。当我想提交它时，我会执行以下操作：|3363005|3363006|将所有内容提交到主题分支|ordered-list-item|3363007|git+svn+rebase+(解决您的工作和svn之间的任何冲突)|3363008|git签出主|3363009|git+svn+rebase+(这使得下一步是快进合并，请参阅下面的Aaron注释)|3363010|<代码>H19git+merge+topic_branch|3363011|resolve任何合并冲突(此时应该没有任何冲突)<代码>H212<代码>H113git+svn+dcommit<代码>H214<代码>G215|3363012|3363013|我还有另一种情况，我需要维护一些本地更改(用于调试)，这些更改永远不应该推送到svn。为此，我有上面的master分支，但也有一个名为"+work“的分支，我通常在这里工作。主题分支是工作的分支。当我想在那里提交工作时，我签出master，并使用cherry-pick从我想要提交到svn的工作分支中选择提交。这是因为我希望避免提交三个本地更改提交。然后，我从主分支进行数据提交，并重新设置所有内容的基址。|3363014|首先运行git+svn+dcommit+-n是值得的，以确保您将要提交的正是您想要提交的内容。与git不同，在svn中重写历史记录很难！|offset|length|style|CODE|3363015|我觉得一定有更好的方法来合并主题分支上的更改，同时跳过那些本地更改提交，而不是使用樱桃挑选，所以如果有人有任何想法，他们将是受欢迎的。|3363016|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|4|I|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|17|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|18|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|19|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1B|8|@]|9|@]|A|$]]|$1|P|3|Q|5|G|7|1C|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1F|8|@$W|1G|X|1H|Y|Z]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1I|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|13|$]]

Creating local branches is definitely possible with git-svn. As long as you're just using local branches for yourself, and not trying to use git to merge between upstream svn branches, you should be fine.

I have a "master" branch that I use to track the svn server. This is the only branch that I dcommit from. If I'm doing some work, I create a topic branch and work away on it. When I want to commit it, I do the following:

<ol>
<li>Commit everything to the topic branch</li>
<li>git svn rebase (resolve any conflicts between your work and svn)</li>
<li>git checkout master</li>
<li>git svn rebase (this makes the next step a fast-forward merge, see Aaron's comments below)</li>
<li>git merge topic_branch</li>
<li>resolve any merge conflicts (there shouldn't be any at this point)</li>
<li>git svn dcommit</li>
</ol>

I also have another situation where I need to maintain some local changes (for debugging) that should never be pushed up to svn. For that, I have the above master branch but also a branch called "work" where I normally do work. Topic branches are branched off work. When I want to commit work there, I checkout master and use cherry-pick to pick the commits from the work branch that I want to commit to svn. This is because I want to avoid committing the three local change commits. Then, I dcommit from the master branch and rebase everything.

It is worthwhile running <code>git svn dcommit -n</code> first to make sure that you are about to commit exactly what you intend to commit. Unlike git, rewriting history in svn is hard!

I feel that there must be a better way to merge the change on a topic branch while skipping those local change commits than using cherry-pick, so if anybody has any ideas they would be welcome.

blocks|key|3150182|text|在git中合并svn分支的安全方法是使用git+merge+--squash。这将创建一次提交并停止，让您添加一条消息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150183|假设您有一个主题svn分支，称为svn-branch。|3150184|git+svn+fetch
git+checkout+remotes/trunk+-b+big-merge
git+merge+--squash+svn-branch|code-block|syntax|javascript|3150185|此时，svn-branch中的所有更改都被压缩到索引中等待的一个提交中|3150186|git+commit|3150187|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

A safe way to merge svn branches in git is to use git merge --squash. This will create a single commit and stop for you to add a message.

Let's say you have a topic svn branch, called svn-branch.

<pre><code>git svn fetch
git checkout remotes/trunk -b big-merge
git merge --squash svn-branch
</code></pre>

at this point you have all the changes from the svn-branch squashed into one commit waiting in the index

<pre><code>git commit
</code></pre>

blocks|key|3363135|text|将本地git分支重新设置为主git分支，然后执行dcommit，这样看起来就像您按顺序完成了所有这些提交，这样svn用户就可以像他们习惯的那样线性地看到它。假设您有一个名为topic的本地分支，您可以这样做|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363136|git+rebase+master+topic|code-block|syntax|javascript|3363137|然后，它将在准备进行dcommit的主分支上播放您的提交|3363138|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Rebase the local git branch onto the master git branch then dcommit and that way it looks like you did all those commits in sequence so svn people can see it linearly as they are accustomed to. So assuming you have a local branch called topic you could do

<pre><code>git rebase master topic
</code></pre>

which will then play your commits over the master branch ready for you to dcommit

blocks|key|3363238|text|实际上，我发现了一种更好的方法，在git+merge上使用--no-ff选项。我以前使用的所有这些壁球技术都不再需要了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3363239|我的新工作流程现在如下所示：|3363240|3363241|我有一个“主”分支，它是我提交数据并克隆SVN存储库的唯一分支(-s假设您在存储库trunk/、branches/和tags/中有一个标准的SVN布局)：|unordered-list-item|3363242|3363243|git+svn+clone+-s+|3363244|我在本地分支"+work“上工作(-b创建分支"work")|3363245|3363246|git+checkout+-b+work|3363247|commit本地进入"work“分支(使用-s对提交消息进行签名)。在续集中，我假设您进行了3次本地提交|3363248|3363249|..。(工作)$>+git+commit+-s+-m+"msg+1“...(工作)$>+git+commit+-s+-m+"msg+2“...(工作)$>+git+commit+-s+-m+"msg+3"|3363250|现在您想要提交到SVN服务器|3363251|SVN+|3363252|最终会将您不希望看到的修改保存在服务器上(通常，您在主文件中注释了一些代码，仅仅是因为您想要加速编译并专注于给定的特性)。|3363253|3363254|(工作)$>+git+stash|3363255|使用SVN存储库重新设置主分支的基础(从SVN服务器进行更新)|3363256|3363257|(工作)$>+git签出主程序(主程序)$>+git+svn+rebase+|3363258|返回工作分支并使用主程序重新建立基本程序|3363259|3363260|(主)$>+git签出工作(工作)$>+git+rebase+master|3363261|Ensure使用以下命令一切都很好，例如：|3363262|3363263|(工作)主git日志--$>+--oneline+--decorate|3363264|Now现在是时候使用这个出色的--no-ff选项将“工作”分支中的所有三个提交合并到“$>”中了|3363265|3363266|$>+git+checkout+master+($>)$>+git+merge+--no-ff+work|3363267|您可以注意到日志的状态：|3363268|3363269|(主)+svn+git日志--图形--oneline+-装饰*+56a779b+(工作，主)合并分支‘工作’%7C\+%7C*+af6f7ae消息3%7C*+8750643消息2%7C*+08464ae消息1+%7C/+*+21e20fa+(git-+SVN+)+$>提交|3363270|现在，您可能想要编辑(amend)您的SVN伙伴的最后一次提交(否则他们只会看到一次提交，并显示消息“合并分支‘工作’”)|3363271|3363272|(主)+SVN服务器上的$>+git提交--amend|3363273|Finally提交|3363274|3363275|(master)$>+git+svn+dcommit|3363276|继续工作，并最终恢复您隐藏的文件：|3363277|3363278|($>)+git签出工作(工作)$>+git+stash+pop|3363279|entityMap^0|T|7|0|0|0|W|2|15|6|1C|9|1M|5|0|0|0|H|2|0|0|0|L|2|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|F|7|0|0|0|0|0|0|B|5|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2D|8|@$9|2E|A|2F|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|2G|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|2H|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|2I|8|@$9|2J|A|2K|B|C]|$9|2L|A|2M|B|C]|$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]]|D|@]|E|$]]|$1|L|3|-4|5|6|7|2R|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|2S|8|@]|D|@]|E|$]]|$1|O|3|P|5|K|7|2T|8|@$9|2U|A|2V|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|2W|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|2X|8|@]|D|@]|E|$]]|$1|T|3|U|5|K|7|2Y|8|@$9|2Z|A|30|B|C]]|D|@]|E|$]]|$1|V|3|-4|5|6|7|31|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|32|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|33|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|34|8|@]|D|@]|E|$]]|$1|12|3|13|5|K|7|35|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|36|8|@]|D|@]|E|$]]|$1|15|3|16|5|6|7|37|8|@]|D|@]|E|$]]|$1|17|3|18|5|K|7|38|8|@]|D|@]|E|$]]|$1|19|3|-4|5|6|7|39|8|@]|D|@]|E|$]]|$1|1A|3|1B|5|6|7|3A|8|@]|D|@]|E|$]]|$1|1C|3|1D|5|K|7|3B|8|@]|D|@]|E|$]]|$1|1E|3|-4|5|6|7|3C|8|@]|D|@]|E|$]]|$1|1F|3|1G|5|6|7|3D|8|@]|D|@]|E|$]]|$1|1H|3|1I|5|K|7|3E|8|@]|D|@]|E|$]]|$1|1J|3|-4|5|6|7|3F|8|@]|D|@]|E|$]]|$1|1K|3|1L|5|6|7|3G|8|@]|D|@]|E|$]]|$1|1M|3|1N|5|K|7|3H|8|@$9|3I|A|3J|B|C]]|D|@]|E|$]]|$1|1O|3|-4|5|6|7|3K|8|@]|D|@]|E|$]]|$1|1P|3|1Q|5|6|7|3L|8|@]|D|@]|E|$]]|$1|1R|3|1S|5|K|7|3M|8|@]|D|@]|E|$]]|$1|1T|3|-4|5|6|7|3N|8|@]|D|@]|E|$]]|$1|1U|3|1V|5|6|7|3O|8|@]|D|@]|E|$]]|$1|1W|3|1X|5|K|7|3P|8|@$9|3Q|A|3R|B|C]]|D|@]|E|$]]|$1|1Y|3|-4|5|6|7|3S|8|@]|D|@]|E|$]]|$1|1Z|3|20|5|6|7|3T|8|@]|D|@]|E|$]]|$1|21|3|22|5|K|7|3U|8|@]|D|@]|E|$]]|$1|23|3|-4|5|6|7|3V|8|@]|D|@]|E|$]]|$1|24|3|25|5|6|7|3W|8|@]|D|@]|E|$]]|$1|26|3|27|5|K|7|3X|8|@]|D|@]|E|$]]|$1|28|3|-4|5|6|7|3Y|8|@]|D|@]|E|$]]|$1|29|3|2A|5|6|7|3Z|8|@]|D|@]|E|$]]|$1|2B|3|-4|5|6|7|40|8|@]|D|@]|E|$]]]|2C|$]]

Actually, I found an even better way with the <code>--no-ff</code> option on git merge.
All this squash technic I used before is no longer required. 

My new workflow is now as follows: 

<ul>
<li>I have a "master" branch that is the only branch that I dcommit from and that clone the SVN repository (<code>-s</code> assume you have a standard SVN layout in the repository <code>trunk/</code>, <code>branches/</code>, and <code>tags/</code>):

<pre><code>git svn clone [-s] &lt;svn-url&gt;
</code></pre></li>
<li>I work on a local branch "work" (<code>-b</code> creates the branch "work")

<pre><code>git checkout -b work
</code></pre></li>
<li>commit locally into the "work" branch (<code>-s</code> to sign-off your commit message). In the sequel, I assume you made 3 local commits

<pre><code>...
(work)$&gt; git commit -s -m "msg 1"
...
(work)$&gt; git commit -s -m "msg 2"
...
(work)$&gt; git commit -s -m "msg 3"
</code></pre></li>
</ul>

<h2>Now you want to commit onto the SVN server</h2>

<ul>
<li>[Eventually] stash the modifications you don't want to see committed on the SVN server (often you commented some code in the main file just because you want to accelerate the compilation and focus on a given feature)

<pre><code>(work)$&gt; git stash
</code></pre></li>
<li>rebase the master branch with the SVN repository (to update from the SVN server)

<pre><code>(work)$&gt; git checkout master
(master)$&gt; git svn rebase
</code></pre></li>
<li>go back to the work branch and rebase with master

<pre><code>(master)$&gt; git checkout work
(work)$&gt; git rebase master
</code></pre></li>
<li>Ensure everything is fine using, for instance: 

<pre><code>(work)$&gt; git log --graph --oneline --decorate
</code></pre></li>
<li>Now it's time to merge all three commits from the "work" branch into "master" using this wonderful <code>--no-ff</code> option

<pre><code>(work)$&gt; git checkout master
(master)$&gt; git merge --no-ff work
</code></pre></li>
<li>You can notice the status of the logs: 

<pre><code>(master)$&gt; git log --graph --oneline --decorate
* 56a779b (work, master) Merge branch 'work'
|\ 
| * af6f7ae msg 3
| * 8750643 msg 2
| * 08464ae msg 1
|/ 
* 21e20fa (git-svn) last svn commit
</code></pre></li>
<li>Now you probably want to edit (<code>amend</code>) the last commit for your SVN dudes (otherwise they will only see a single commit with the message "Merge branch 'work'"

<pre><code>(master)$&gt; git commit --amend
</code></pre></li>
<li>Finally commit on the SVN server

<pre><code>(master)$&gt; git svn dcommit
</code></pre></li>
<li>Go back to work and eventually recover your stashed files:

<pre><code>(master)$&gt; git checkout work
(work)$&gt; git stash pop
</code></pre></li>
</ul>

blocks|key|360685|text|Greg+Hewgill在上面回答是不安全的！如果在两个"git+svn+rebase“之间的主干上出现任何新的提交，合并将不会快进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360686|可以通过对git-merge使用"--ff-+only“标志来确保这一点，但我通常不会在分支中运行"git+svn+rebase”，只在分支上运行"git+rebase+master“(假设它只是一个本地分支)。然后，"git+merge+thebranch“就被保证是快进的。|360687|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Greg Hewgill answer on top is not safe! If any new commits appeared on trunk between the two "git svn rebase", the merge will not be fast forward.

It can be ensured by using "--ff-only" flag to the git-merge, but I usually do not run "git svn rebase" in the branch, only "git rebase master" on it (assuming it is only a local branch). Then afterwards a "git merge thebranch" is guaranteed to be fast forward.

blocks|key|3363328|text|简单的解决方案:合并后删除'work‘分支|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3363329|简短回答：你可以随心所欲地使用git+(参见下面的简单工作流程)，包括merge。只要确保遵循每个“git+merge+work+”和“git+branch+-d+work”来删除临时工作分支即可。|3363330|背景解释：合并/dcommit问题是，当你“git+svn+dcommit”一个分支时，该分支的合并历史记录是“扁平的”：git忘记了所有进入该分支的合并操作:只保留文件内容，但这些内容(部分)来自特定的其他分支的事实丢失了。请参阅：Why+does+git+svn+dcommit+lose+the+history+of+merge+commits+for+local+branches?|3363331|(注意:+git-svn对此无能为力:+svn根本无法理解更强大的git合并。因此，在svn存储库中，此合并信息不能以任何方式表示。)|3363332|但这是整个问题所在。如果你在“工作”分支合并到“主分支”之后删除它，那么你的git仓库是100%25干净的，看起来和你的svn仓库一模一样。|3363333|当然，我首先将远程存储库克隆到本地git存储库(这可能需要一些时间)：|3363334|$>+git+svn+clone+<svn-repository-url>+<local-directory>|code-block|syntax|javascript|3363335|然后所有的工作都发生在“本地目录”中。每当我需要从服务器获取更新时(比如'svn+update')，我都会这样做：|3363336|$>+git+checkout+master
$>+git+svn+rebase|3363337|我的所有开发工作都是在一个单独的分支“work”中完成的，它的创建方式如下：|3363338|$>+git+checkout+-b+work|3363339|当然，您可以为您的工作创建任意多的分支，并根据您的喜好在它们之间进行合并和重新建立基础(只需在完成后删除它们-如下所述)。在我的正常工作中，我经常做以下事情：|3363340|$>+git+commit+-am+'--+finished+a+little+piece+of+work'|3363341|下一步(git+rebase+-i)是可选的-它只是在将其归档到svn之前清理历史:一旦我到达一个稳定的英里石，我想与其他人分享，我重写这个‘工作’分支的历史并清理提交消息(其他开发人员不需要看到我在此过程中所犯的所有小步骤和错误-只是结果)。为此，我做了|3363342|$>+git+log|3363343|并复制svn储存库中的最后提交的sha-1散列(如git-svn-id所指示的)。然后我会打电话给|3363344|$>+git+rebase+-i+74e4068360e34b2ccf0c5869703af458cde0cdcb|3363345|只需粘贴我们上次svn提交的sha-1散列，而不是我的。你可能想要阅读'git+help+rebase‘的文档来了解详细信息。简而言之:这个命令首先打开一个呈现你的提交的编辑器-对于你想用之前的提交来压缩的所有提交，只需将'pick‘改为'+squash’即可。当然，第一行应该保留为“选择”。通过这种方式，您可以将许多小提交压缩为一个或多个有意义的单元。保存并退出编辑器。您将看到另一个编辑器要求您重写提交日志消息。|3363346|简而言之:在我完成“代码破解”之后，我推敲我的“工作”分支，直到它看起来是我想要向其他程序员展示它的方式(或者当我浏览历史记录时，我想要在几周内看到工作)。|3363347|为了将更改推送到svn存储库，我执行以下操作：|3363348|$>+git+checkout+master
$>+git+svn+rebase|3363349|现在我们回到了旧的'master‘分支，同时更新了svn存储库中发生的所有更改(您的新更改隐藏在'work’分支中)。|3363350|如果有一些更改可能与您的新“工作”更改发生冲突，您必须在本地解决它们，然后才能推送您的新工作(请参阅下面的详细信息)。然后，我们可以将更改推送到svn：|3363351|$>+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|3363352|注意1：'git+branch+-d+work‘命令是非常安全的:它只允许你删除不再需要的分支(因为它们已经合并到你当前的分支中)。如果您在将工作与'master‘分支合并之前错误地执行了此命令，则会收到一条错误消息。|3363353|注意2:确保在合并和dcommit之间使用'git+branch+-d+work‘删除你的分支:如果你试图在dcommit之后删除分支，你会得到一个错误信息:当你执行'git+svn+dcommit’时，git忘记你的分支已经和'master‘合并了。你必须使用不做安全检查的'git+branch+-D+work‘来删除它。|3363354|现在，我立即创建了一个新的'work‘分支，以避免意外地攻击'master’分支：|3363355|$>+git+checkout+-b+work
$>+git+branch++++++++++++#+show+my+branches:
++master
*+work|3363356|将你的‘工作’与svn上的更改集成在一起：当'git+svn+rebase‘显示当我在我的’工作‘分支上工作时，其他人更改了svn存储库时，我会这么做：|3363357|$>+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|3363358|存在更强大的解决方案：目前的工作流程过于简单:它只在每一轮的“更新/破解/提交”中使用git的功能-但长期项目历史与svn存储库一样线性。如果您只是想在遗留的svn项目中开始使用git合并，那么这是可以的。|3363359|当您更熟悉git合并时，请随意探索其他工作流程:如果您知道自己在做什么，则可以将git合并与svn合并(Using+git-svn+(or+similar)+just+to+help+out+with+svn+merge?)混合在一起。|3363360|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/425766/why-does-git-svn-dcommit-lose-the-history-of-merge-commits-for-local-branches|1|https://stackoverflow.com/questions/2945842/using-git-svn-or-similar-just-to-help-out-with-svn-merge^0|0|A|0|0|5|1E|F|1W|I|0|0|5|39|26|0|0|0|0|9|Q|0|0|0|1L|0|0|0|12|0|0|0|27|0|0|0|3K|0|0|0|1D|0|0|0|5T|0|0|26|0|0|N|0|0|0|1N|0|0|24|0|0|0|31|0|0|4J|0|0|15|0|0|0|L|0|0|0|B|0|1G|1N|1|0^^$0|@$1|2|3|4|5|6|7|2I|8|@$9|2J|A|2K|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|2L|8|@$9|2M|A|2N|B|C]|$9|2O|A|2P|B|C]|$9|2Q|A|2R|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|2S|8|@$9|2T|A|2U|B|C]]|D|@$9|2V|A|2W|1|2X]]|E|$]]|$1|J|3|K|5|6|7|2Y|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|2Z|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|30|8|@$9|31|A|32|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|R|7|33|8|@]|D|@]|E|$S|T]]|$1|U|3|V|5|6|7|34|8|@$9|35|A|36|B|C]]|D|@]|E|$]]|$1|W|3|X|5|R|7|37|8|@]|D|@]|E|$S|T]]|$1|Y|3|Z|5|6|7|38|8|@$9|39|A|3A|B|C]]|D|@]|E|$]]|$1|10|3|11|5|R|7|3B|8|@]|D|@]|E|$S|T]]|$1|12|3|13|5|6|7|3C|8|@$9|3D|A|3E|B|C]]|D|@]|E|$]]|$1|14|3|15|5|R|7|3F|8|@]|D|@]|E|$S|T]]|$1|16|3|17|5|6|7|3G|8|@$9|3H|A|3I|B|C]]|D|@]|E|$]]|$1|18|3|19|5|R|7|3J|8|@]|D|@]|E|$S|T]]|$1|1A|3|1B|5|6|7|3K|8|@$9|3L|A|3M|B|C]]|D|@]|E|$]]|$1|1C|3|1D|5|R|7|3N|8|@]|D|@]|E|$S|T]]|$1|1E|3|1F|5|6|7|3O|8|@$9|3P|A|3Q|B|C]]|D|@]|E|$]]|$1|1G|3|1H|5|6|7|3R|8|@$9|3S|A|3T|B|C]]|D|@]|E|$]]|$1|1I|3|1J|5|6|7|3U|8|@$9|3V|A|3W|B|C]]|D|@]|E|$]]|$1|1K|3|1L|5|R|7|3X|8|@]|D|@]|E|$S|T]]|$1|1M|3|1N|5|6|7|3Y|8|@$9|3Z|A|40|B|C]]|D|@]|E|$]]|$1|1O|3|1P|5|6|7|41|8|@$9|42|A|43|B|C]]|D|@]|E|$]]|$1|1Q|3|1R|5|R|7|44|8|@]|D|@]|E|$S|T]]|$1|1S|3|1T|5|6|7|45|8|@$9|46|A|47|B|C]]|D|@]|E|$]]|$1|1U|3|1V|5|6|7|48|8|@$9|49|A|4A|B|C]]|D|@]|E|$]]|$1|1W|3|1X|5|6|7|4B|8|@$9|4C|A|4D|B|C]]|D|@]|E|$]]|$1|1Y|3|1Z|5|R|7|4E|8|@]|D|@]|E|$S|T]]|$1|20|3|21|5|6|7|4F|8|@$9|4G|A|4H|B|C]]|D|@]|E|$]]|$1|22|3|23|5|R|7|4I|8|@]|D|@]|E|$S|T]]|$1|24|3|25|5|6|7|4J|8|@$9|4K|A|4L|B|C]]|D|@]|E|$]]|$1|26|3|27|5|6|7|4M|8|@]|D|@$9|4N|A|4O|1|4P]]|E|$]]|$1|28|3|-4|5|6|7|4Q|8|@]|D|@]|E|$]]]|29|$2A|$5|2B|2C|2D|E|$2E|2F]]|2G|$5|2B|2C|2D|E|$2E|2H]]]]

Simple solution: Remove 'work' branch after merging

Short answer: You can use git however you like (see below for a simple workflow), including merge. Just make sure follow each 'git merge work' with 'git branch -d work' to delete the temporary work branch.

Background explanation: 
The merge/dcommit problem is that whenever you 'git svn dcommit' a branch, the merge history of that branch is 'flattened': git forgets about all merge operations that went into this branch: Just the file contents is preserved, but the fact that this content (partially) came from a specific other branch is lost. See: <a href="https://stackoverflow.com/questions/425766/why-does-git-svn-dcommit-lose-the-history-of-merge-commits-for-local-branches">Why does git svn dcommit lose the history of merge commits for local branches?</a> 

(Note: There is not much that git-svn could do about it: svn simply doesn't understand the much more powerful git merges. So, inside the svn repository this merge information cannot be represented in any way.)

But this is the whole problem. If you delete the 'work' branch after it has been merged into the 'master branch' then your git repository is 100% clean and looks exactly like your svn repository.

My workflow:
Of course, I first cloned the remote svn repository into a local git repository (this may take some time):

<pre><code>$&gt; git svn clone &lt;svn-repository-url&gt; &lt;local-directory&gt;
</code></pre>

All work then happens inside the "local-directory". Whenever I need to get updates from the server (like 'svn update'), I do:

<pre><code>$&gt; git checkout master
$&gt; git svn rebase
</code></pre>

I do all my development work in a separate branch 'work' that is created like this:

<pre><code>$&gt; git checkout -b work
</code></pre>

Of course, you can create as many branches for your work as you like and merge and rebase between them as you like (just delete them when you are done with them --- as discussed below). In my normal work, I commit very frequently:

<pre><code>$&gt; git commit -am '-- finished a little piece of work'
</code></pre>

The next step (git rebase -i) is optional --- it's just cleaning up the history before archiving it on svn: Once I reached a stable mile stone that I want to share with others, I rewrite the history of this 'work' branch and clean up the commit messages (other developers don't need to see all the little steps and mistakes that I made on the way --- just the result). For this, I do 

<pre><code>$&gt; git log
</code></pre>

and copy the sha-1 hash of the last commit that is live in the svn repository (as indicated by a git-svn-id). Then I call 

<pre><code>$&gt; git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb
</code></pre>

Just paste sha-1 hash of our last svn commit instead of mine. You may want to read the documentation with 'git help rebase' for the details. In short: this command first opens an editor presenting your commits ---- just change 'pick' to 'squash' for all those commits that you want to squash with previous commits. Of course, the first line should stay as a 'pick'. In this way, you can condense your many little commits into one or more meaningful units.
Save and exit the editor. You will get another editor asking you to rewrite the commit log messages.

In short: After I finish 'code hacking', I massage my 'work' branch until it looks how I want to present it to the other programmers (or how I want to see the work in a few weeks time when I browse history).

In order to push the changes to the svn repository, I do:

<pre><code>$&gt; git checkout master
$&gt; git svn rebase
</code></pre>

Now we are back at the old 'master' branch updated with all changes that happened in the mean time in the svn repository (your new changes are hidden in the 'work' branch). 

If there are changes that may clash with your new 'work' changes, you have to resolve them locally before you may push your new work (see details further below). Then, we can push our changes to svn:

<pre><code>$&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
</code></pre>

Note 1: The command 'git branch -d work' is quite safe: It only allows you to delete branches that you don't need anymore (because they are already merged into your current branch). If you execute this command by mistake before merging your work with the 'master' branch, you get an error message. 

Note 2: Make sure to delete your branch with 'git branch -d work' between merging and dcommit: If you try to delete the branch after dcommit, you get an error message: When you do 'git svn dcommit', git forgets that your branch has been merged with 'master'. You have to remove it with 'git branch -D work' which doesn't do the safety check.

Now, I immediately create a new 'work' branch to avoid accidentally hacking on the 'master' branch:

<pre><code>$&gt; git checkout -b work
$&gt; git branch # show my branches:
 master
* work
</code></pre>

Integrating your 'work' with changes on svn:
Here is what I do when 'git svn rebase' reveals that others changed the svn repository while I was working on my 'work' branch:

<pre><code>$&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
</code></pre>

More powerful solutions exist:
The presented workflow is simplistic: It uses the powers of git only within each round of 'update/hack/dcommit' --- but leaves the long-term project history just as linear as the svn repository. This is ok if you just want to start using git merges in small first steps in a legacy svn project. 

When you become more familiar with git merging, feel free to explore other workflows: If you know what you are doing, you can mix git merges with svn merges (<a href="https://stackoverflow.com/questions/2945842/using-git-svn-or-similar-just-to-help-out-with-svn-merge">Using git-svn (or similar) just to help out with svn merge?</a>)

My motivation for trying out git-svn is the effortless merging and branching. Then I noticed that man git-svn(1) says: 

<blockquote>
 Running git-merge or git-pull is NOT recommended on a branch you plan
 to dcommit from. Subversion does not represent merges in any
 reasonable or useful fashion; so users using Subversion cannot see any
 merges you've made. Furthermore, if you merge or pull from a git
 branch that is a mirror of an SVN branch, dcommit may commit to the
 wrong branch.
</blockquote>

Does this mean I cannot create a local branch from svn/trunk (or a branch), hack away, merge back into svn/trunk, then dcommit? I understand that svn users will see the same mess that merges in svn pre 1.5.x have always been, but are there any other drawbacks? That last sentence worries me, too. Do people routinely do these kinds of things?

Is git-svn dcommit after merging in git dangerous?

服务器

我尝试git-svn的动机是毫不费力的合并和分支。然后我注意到man git-svn(1)说：不建议在计划从中执行dcommit的分支上运行git- 或git-pull。Subversion不以任何合理或有用的方式表示合并；因此使用Subversion的用户看不到您所做的任何合并。此外，如果合并或拉出的git分支是SV...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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