2

我试图弄清楚使用 Git 同步多个开发人员同时使用的代码库的最佳工作流程是什么。我的团队负责人为我提供了一个脚本，其中添加了我需要同步的几乎所有代码文件，而忽略了批处理文件、编译文件等。

一般来说，我认为我应该做的是在我开始解决问题之前同步，然后在我完成测试时同步。但是，我担心这会在我提取 repo 的代码和发布我的代码之间造成很长的时间间隔。这意味着，例如，我可能会使用一些在我不知情的情况下已被破坏或修复的功能，或者我可能会在此期间无意中破坏了一些其他人正在使用的代码。另外，我认为发布“未完成”的代码可能是一种不好的做法，但我不确定。

如何管理我的同步，以便尽可能少地干扰其他人的代码，并避免较长的周转时间？欢迎任何建议。

4

2 回答 2

2

在这种情况下，我的策略（还有很多其他策略）是：

1.) 在自己的存储库中为自己创建两个分支。一种具有可供发布的工作代码（您的发布分支），另一种用于开发/错误修复（您的开发分支）。

2.) 一般来说：您的开发分支从源代码和发布分支获取最新代码。这样，如果源有任何更改，您可以获取并保持最新。此外，如果您的开发方面有变化，您可以获取它。（例如，您准备发布，但刚刚意识到源 API 已更改。）。你最终会得到一个 devel 分支，其中包含你的（稳定的）更改加上源代码的更改，以及你可以处理的（不稳定的）修复。

3.) 一旦您准备好开发，将您的修复分支合并到您的发布分支中，并提供您的发布分支代码以供审查/集成给领导。如果同时发生了一些变化并且确实需要修复，您将返回到第 2 步。）。

我们的想法是随时都有一个发布，但不断地将更改和修复流入其中，使其保持稳定和最新，同时拥有一个不稳定的开发分支，其中包含来自所有来源的最新代码。

(project)           src-branch ----*----*---*-----*----------*------M
                                    \              \               /
(personal) devel/bugfix-branch ------M-*-*--*-------M-M---*--*----/--
                                             \       /         \ /
(personal)      release-branch ---------------M-*---*----*--*---M----

                               ------ time ----->

Legend: * commit, M merge

在最后一步中，您实际上会提供一个 git-diff 补丁，或者让负责人从您的发布分支（您的BARE存储库）中获取您的贡献，以便审查/集成到项目源中。

于 2012-09-17T17:29:01.353 回答
1

如果您正在寻找工作流程信息，请查看此处提供的文章http://nvie.com/posts/a-successful-git-branching-model/。它描述了一种 Git 工作流程（以及有助于管理存储库分支的优秀 Git 插件）。

于 2012-09-17T18:36:45.860 回答