Git合并后的git-svn提交是否危险?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (23)

我尝试使用git-svn的动机是毫不费力的合并和分支。然后我注意到man git-svn(1)说:

运行git-merge或git-pull不建议在您计划从中提交的分支上。Subversion不代表任何合理或有用的合并方式; 因此使用Subversion的用户无法看到您所做的任何合并。此外,如果您从SVN分支的镜像git分支合并或拉出,dcommit可能会提交到错误的分支。

这是否意味着我不能从svn / trunk(或分支)创建本地分支,破解,合并回svn / trunk,然后dcommit?我明白,svn用户会看到svn pre 1.5.x中合并的那个混乱一直存在,但是还有其他什么缺点吗?最后一句话也让我担心。人们经常做这些事情吗?

提问于
用户回答回答于

实际上,我发现--no-ff在git merge上有更好的选择。我之前使用的所有这种压扁技术不再需要。

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

  • 我有一个“主”分支,是我从dcommit唯一分支机构和克隆SVN库(-s假设你已经在库中的标准SVN布局trunk/branches/tags/): git svn clone [-s] <svn-url>
  • 我在本地分公司工作(-b创建分支“工作”) git checkout -b work
  • 在本地提交到“工作”分支(-s签署您的提交消息)。在续集中,我假设你做了3次本地提交 ... (work)$> git commit -s -m "msg 1" ... (work)$> git commit -s -m "msg 2" ... (work)$> git commit -s -m "msg 3"

现在你想提交到SVN服务器上

  • [最终]隐藏您不希望在SVN服务器上看到提交的修改(通常您在主文件中注释了一些代码,仅仅是因为您想加快编译并专注于给定的功能) (work)$> git stash
  • 使用SVN存储库重新分配master分支(从SVN服务器更新) (work)$> git checkout master (master)$> git svn rebase
  • 返回工作分支并与主人重新绑定 (master)$> git checkout work (work)$> git rebase master
  • 确保一切正常使用,例如: (work)$> git log --graph --oneline --decorate
  • 现在是时候使用这个美妙的--no-ff选项将“work”分支中的所有三个提交合并到“master”中 (work)$> git checkout master (master)$> git merge --no-ff work
  • 您可以注意到日志的状态: (master)$> 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
  • 现在你可能想编辑(amend)你的SVN花花公子的最后一次提交(否则它们只会看到一条提交信息“合并分支工作”的消息) (master)$> git commit --amend
  • 最后在SVN服务器上提交 (master)$> git svn dcommit
  • 回去工作,并最终恢复你的隐藏文件: (master)$> git checkout work (work)$> git stash pop
用户回答回答于

使用git-svn创建本地分支是绝对可能的。只要你只为自己使用本地分支,而不是尝试使用git合并上游svn分支,你应该没问题。

我有一个“主”分支,我用它来跟踪svn服务器。这是我承诺的唯一分支。如果我正在做一些工作,我会创建一个主题分支并开始工作。当我想提交它时,我执行以下操作:

  1. 把所有东西都交给主题分支
  2. git svn rebase (解决你的工作与svn之间的任何冲突)
  3. git checkout master
  4. git svn rebase (这会让下一步快速合并)
  5. git合并topic_branch
  6. 解决任何合并冲突(这里不应该有任何)
  7. git svn dcommit

我还有另外一种情况,我需要维持一些本地的变化(用于调试),而这些变化绝不应该推到svn上。为此,我有上面的主分支,但也有一个叫做“工作”的分支,我通常在这里工作。主题分支分支下班。当我想在那里提交工作时,我签出master并使用cherry-pick从我想提交给svn的工作分支中选择提交。这是因为我想避免提交三个本地更改提交。然后,我从主分支处提交并重新设置所有内容。

git svn dcommit -n首先要确保你准备提交你准备提交的内容,这是值得的。与git不同,svn中的重写历史很难!

我觉得必须有一种更好的方式来合并主题分支上的变化,而跳过本地更改提交而不是使用樱桃选择,所以如果有人有任何想法,他们将受到欢迎。

扫码关注云+社区