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

Question

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

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

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

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

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

我设想的基本git流程是这样的：

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

2. //
   git checkout -b feature 1
   //工作提交，工作提交

3. //
   git checkout -b bug-123
   //工作提交，工作提交
   // bug-123完成 - 准备发回

4. //回到主人的第5步 git checkout master

5. //得到其他开发者所做的任何改变 git svn rebase

6. //
   git checkout bug-123

7. // rebase分支，所以我的更改次数更少。这里不确定..
   git rebase master || git svn rebase
   //假设我正在做一个FF rebase，所以我的提交只是当前回购的插件 //我不知道我是否会改变主人或者svn回购或者无关紧要。

8. //需要将我的更改恢复为主人才能发送 git checkout master

9. //将我的更改添加到主人 git rebase bug-123 (--interactive?) || git merge --squash bug-123
   //我在这里添加新的提交消息吗？

10. //将我的更改推回给团队 git dcommit

所以有几个问题：

1. 如何通过重新设置主服务器或svn分支来更改我想要提交的分支

2. 如何将更改返回到主分支 - rebase或merge - 记住，我只想为每个提交提交一个 - 除非这会使事情变得复杂 - 我真的更愿意保留我的git提交与SVN提交分开，因为我可能会启动一些东西 - 它是半工作的，并且想要提交它以便我可以尝试别的东西 - 但我不想提交这些破坏的步骤。

3. 直接从工作分支（例如bug-123）进行dcommit是否有意义？

4. 如何将bug-123的更改现在恢复为feature-1？我假设我会通过SVN repo来做这件事 - 这意味着我添加的更改将在我执行rebase时合并到什么时候才能将feature-1添加到repo中 - 但可能没有。

   < / LI>

Answer 1

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

1. 我认为没关系。重要的是，您将SVN的最新更改重新绑定到您将要提交的分支。
2. 让其他分支通过SVN接收更改。如果你想从一系列git提交中获得单个SVN提交，请先将它们压缩在一起。
3. 我认为这也无关紧要。您将从SVN重新定义最新更改，并需要在Git提交前线性地获取它们。如果你在master中执行git svn rebase，然后将master重命名为一个功能分支，或者反过来是相同的。之后你可能想要删除分支，因为它完成了它的工作（根据SVN限制，你不允许再次合并）。
4. 始终让更改流入其他分支并通过SVN重新定位。

尝试一下，尝试为您和您的团队提供最简单/实用的工作流程。尽量保持分支短命（SVN无论如何都不会得到任何概念），并记住在提交回来之前，提交必须始终在日志顶部线性化。