寻找理想的git-svn工作流程

Question

我正在工作的公司正在与SVN合作，但我想开始使用git来利用光分支和存储功能（免责声明，我对git很新颖）。我已经开始使用git-svn了，我正在试图找出理想的git-svn工作流程，我正在尝试做什么（以及如果我正在尝试做什么需要调整的建议）。

我已阅读git svn workflow - feature branches and merge和其他一些帖子，但仍不清楚我应该如何处理它。

我如何计划工作： 我打算让我的主分支从开发中清除，只用于合并/ rebase/dcommit。

我想将每个新功能/错误分解为单独的git分支，以便它们可以独立工作。也就是说，我可以在一个功能上工作几个小时，然后放在一边，开始下一个问题。当我在SVN中的时候，当我在一个文件中有两个不同的功能/错误时，这是​​一个问题，因为当它提交时，我会记得它有两个变化，并暂时取出我现在不想提交的内容 - 痛苦。 而现在我可能想要工作的一些功能在一段时间内不会被添加到主要的回购中。

当一个功能准备好在主仓库中共享/测试之后，我会将/ rebase合并到我的主分支，然后dcommit到svn-repo。我只想为每个dcommit提供一条SVN提交消息 - 我希望更频繁地提交更具体的评论，然后向团队的其他成员发送消息并提交给svn。我为此假设我将使用git合并--squash或git rebase - 交互。

我所设想的基本混帐流程是这样的：

1. //它开始...
   git svn clone <repo>

2. //
   git checkout -b feature 1
   //工作承诺，工作承诺

3. //
   git checkout -b bug-123
   //工作承诺，工作承诺
   //错误-123完成 - 准备发回

4. //一回到主步骤5
   git checkout master

5. //得到什么变化的其他开发者做了
   git svn rebase

6. //
   git checkout bug-123

7. // rebase分支，所以我有更少的小变化。不知道这里..
   git rebase master || git svn rebase
   //假设我做了FF重订，所以我提交只是插件当前的回购
   //我不知道我是否重订主或svn的或没有关系没关系。

8. //需要让我变回主欢送
   git checkout master

9. //添加我的变化，掌握
   git rebase bug-123 (--interactive?) || git merge --squash bug-123
   //我添加一个新的提交信息吗？

10. //把我变回了球队
    git dcommit

所以有几个问题：

1. 我应该如何得到变成我想要的分支承诺 - 通过重新分配主人或svn分支

2. 我如何获取更改回到主分支 - rebase或合并 - 记住，我只需要一次提交每个提交 - 除非这会使事情复杂化 - 我真的希望保持我的git提交与SVN提交分离，因为我可能会启动一些东西 - 它是一半工作，并想提交它，所以我可以尝试别的 - 但我不想承诺这些破碎的步骤。

3. dmitmit直接从工作分支（例如bug-123）有意义吗？

4. 我如何从bug-123变回现在的功能-1？我假设我会通过SVN回购 - 这意味着我添加的更改将在我为回购添加功能-1时进行重新组合，但也许不会。

Answer 1

我不是专家，但这些都是我的经验（related answer）。

1. 我觉得没关系。重要的是，您将来自SVN的最新变化重新分配到您要提交的分支中。
2. 让其他分支通过SVN接收更改。如果你想从一系列git提交中提交一个SVN，首先将它们压缩在一起。
3. 我认为这也没有关系。您将重新设置来自SVN的最新更改，并且需要在您的Git提交前线性地获取它们。如果你在master中执行git svn rebase，然后将master重新转换为一个特性分支，或者反过来也是一样的。之后，您可能希望删除该分支，因为它已完成其工作（按SVN限制，不允许再次合并）。
4. 始终让更改流入其他分支并通过SVN重新分配进行回购。

只要尝试一下，并尝试为您和您的团队获得最简单/实用的工作流程。尽量让分支短暂（SVN无论如何都不会理解它们），并且记住提交必须始终在日志顶部线性化，然后再提交回去。