Git和Github的最佳工作流程

Question

17

我正在寻求关于如何使用Git & GitHub为我的团队正确构建工作流程的建议。

我们最近从svn转换过来，对于如何最好地设置我们的日常工作流程有些困惑。

以下是一些背景介绍：我熟悉命令行，而我的团队对此还比较新，但他们可以遵循使用命令。我们都在同一个项目上工作，有3个环境（开发、预备和生产）。我们由开发人员和设计师组成，因此有些人使用git GUI，有些人使用CLI。

我们在svn中的设置大致如下：

现在我已经设置好这些分支并让服务器运行了该过程，但实际工作流程让我感到困惑。

似乎每次有人更改文件时都会创建一个新分支、提交、合并和删除该分支，这似乎过于复杂了。根据我的阅读，他们可以在特定的提交（使用哈希）上进行操作，我理解得对吗？这是使用Git的可接受方式吗？

任何建议都将不胜感激。

- Tom Schlick

5个回答

3

使用分布式版本控制系统时需要记住以下几点：

distribution: 即使你只有一个中心GitHub，开发者并不限于仅将内容（推）发布到该GitHub存储库。他们可以fork the repo并在自己的版本中发布（同时从官方中心GitHub存储库 -- 称为“upstream” -- 获取）。
优势在于他们可以重写历史（reset、rebase --onto、rebase -i等），在最后，他们会发出pull请求，允许集成器管理他们的更改。
其中之一是publication：在你自己的本地存储库中，你可以设置任意多个分支（当然不是每次文件修改都需要一个新分支，而是针对你需要开发的任何新任务或一组任务）。
但是，你也可以设置公共分支，这些分支将被推送（“发布”）到你的远程存储库中。
请参阅关于Git workflow的问题，以及JC Hamano关于远程分支的文章：
o Fun with remote branches (1)
o Fun with remote branches (2)
DVCS不应用“当人们对代码有信心时，他们会提交并将其合并到分段中”这一短语：尽早提交，经常提交，但仅在你想要的时候推（“发布”）。

- VonC

3

在ProGit书籍中还描述了一些项目工作流程，展示了开发人员将使用的Git命令来跟踪日常工作。

在http://nvie.com/git-model上描述了一个备受推崇的Git分支模型。

- Alec the Geek

3

由GitHub创建者之一Scott Chacon和提到的Pro Git书籍的作者所撰写的GitHub工作流程的优秀文章。

- lukmdo

下一篇GitHub博客文章，解释为什么拉取请求如此好用。 - lukmdo

1

根据您的工作流程，您可以在中央存储库（例如Github）上拥有一些“重要”的分支，供人们本地克隆。这些分支将对应于“稳定版”、“测试版”、“开发版”等。关于可能的分支集合，可以参考this的一篇不错的文章。

完成上述步骤后，您可以让人们使用自己的策略。我更喜欢为主要项目保留主题分支，并创建一个名为“快速修复”的分支，用于需要快速处理的问题。如果您有一个团队正在进行一个他们想要从主存储库中分离出来的主要项目，您可以让他们自行操作而无需干预。如果人们喜欢创建许多小分支以尝试各种东西等，他们也可以这样做。

至于自动测试和从暂存环境集成到生产环境，您可以配置git钩子来执行此操作，或者运行一个系统，在规律的时间间隔内为您执行此操作并报告问题。

- Noufal Ibrahim

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Antony Hatchkins · Accepted Answer

你可以直接复制从 SVN 获得的工作流程。Git 可以做到 SVN 能做的一切（但它可以做更多！）。但是尽管使用 CVS，你的工作流程可能仍有改进空间。

如果你想保持分支数量最小化（在你不熟悉 Git 的情况下会使事情简单化），在你描述的工作流程中，我建议你拥有三个每个开发者的分支，而不是一个开发分支：devel-john、devel-mary 等。

devel-john >--\
               \
devel-mary >------> staging ---> production
               /
devel-peter >-/

这很方便：所有开发更改都会被推送到中央代码库（即使对于git来说，这通常也是一件好事），而且任何愿意/有义务进行合并的人（例如合并到暂存分支）都可以随时合并，而不会出现冲突。