workflow - 寻找理想的 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 提交消息 - 我想更频繁地提交更具体的评论，然后 dcommit 到 svn 并为团队的其他成员发送一条消息。我假设为此我将使用 git merge --squash 或 git rebase --interactive 。

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

//它始于...git svn clone <repo>

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

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

//回到 master 进行第 5 步git checkout master

//获取其他开发人员所做的任何更改git svn rebase

//git checkout bug-123

//rebase 分支，所以我有更少的小改动。不确定这里..git rebase master || git svn rebase//假设我正在做一个 FF rebase，所以我的提交只是当前 repo 的插件
//我不知道我是 rebase master 还是 svn repo 或者这无关紧要。

//需要将我的更改返回给 master 以发送出去git checkout master

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

//将我的更改推送回团队git dcommit

所以有几个问题:

我应该如何将更改放入我想要提交的分支中 - 通过重新设置 master 或 svn 分支

我如何将更改返回到主分支 - rebase 或合并 - 请记住，我只希望每次提交一次提交 - 除非这会使事情复杂化 - 我真的希望将我的 git 提交与 SVN 提交分开，因为我可能会开始一些事情——它是半成品，并且想要提交它以便我可以尝试其他东西——但我不想提交这些损坏的步骤。

直接从工作分支进行 dcommit 是否有意义(例如 bug-123)？

我如何将 bug-123 的更改恢复到 feature-1？我假设我将通过 SVN 存储库进行操作 - 这意味着我添加的更改将在我将功能 1 添加到存储库时进行 rebase 时合并 - 但可能不会。

Answer 1

我不是专家，但这些是我的经验( related answer )。

我觉得没关系。重要的是，您将 SVN 中的最新更改重新设置到您要提交的分支中。

让其他分支通过 SVN 接收更改。如果您希望从一系列 git 提交中获得单个 SVN 提交，请先将它们压缩在一起。

我觉得这也没关系。您将从 SVN 重新设置最新更改的基础，并且需要在您的 Git 提交之前线性地获取它们。如果您在 master 中执行 git svn rebase，然后将 master 重新设置为功能分支，或者反过来也是一样的。之后您可能想要删除分支，因为它已经完成了它的工作(根据 SVN 限制，您不能再次合并)。

始终让更改通过 SVN rebase 流入其他分支和存储库。

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