Question

我正在寻找一些关于如何使用Git＆amp; amp;和我的团队正确构建工作流程的建议GitHub的。

我们是最近的svn转换器，我们应该如何最好地设置我们的日常工作流程。

这是一个小背景：我对命令行感到满意，我的团队很新，但可以使用命令。我们都在与3个环境（开发，分期和生产）合作开展同一个项目。我们是开发人员和设计师因此有些人使用git GUI和一些CLI。

我们在svn中的设置是这样的：

我们有一个分支，用于开发，分期和生产。
当人们对代码有信心时，他们会提交然后将其合并到分段中。
服务器会自行更新，在发布日（每周）我们会做差异并将更改推送到生产服务器。

现在我设置了这些分支，并在服务器运行的情况下完成了这个过程，但实际的工作流程让我感到困惑。

每当有人对文件进行更改时，他们会创建一个新的分支，提交，合并和删除该分支，这似乎有些过分。根据我的阅读，他们可以在特定的提交（使用哈希）上做到这一点，我有这个权利吗？这是用Git解决问题的可接受方式吗？

非常感谢任何建议。

Answer 1

您可以从svn逐字复制您的工作流程。 Git可以做任何事情（但它可以做更多！）。但是，尽管使用了CVS，您的工作流程仍可以得到改进。

如果你想在你描述的工作流程中保持最小数量的分支（这是你不熟悉git的事实上会简化事情）我建议（而不是一个开发分支）三个开发者分支：devel-john，devel-mary等：

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

这很方便：所有开发更改都会被推送到中央存储库（这对git而言通常是一件好事）没有冲突，并且任何愿意/有义务进行合并的人（例如进入临时分支）随时合并

Answer 2

使用DVCS时要记住的想法是：

发行版：即使你有一个中央GitHub，开发者也不仅限于发布（推送）那个 GitHub回购。他们可以 fork the repo 并在他们自己的版本中发布（从官方中央GitHub仓库获取 - 称为“上游”）。
好处是他们可以根据需要多次重写历史记录（reset，rebase --onto，rebase -i，...），最后，他们会提出拉取请求，允许集成商管理他们的变化。
其中一个 publication ：在您自己的本地仓库中，您可以根据需要设置多个分支（当然，不是每个文件修改一个，但是一个用于您需要开发的任何新任务或任务集但您也可以设置将被推送（“发布”）到您的远程仓库的公共分支请参阅Git workflow上的这个问题，以及JC Hamano关于远程分支的文章：
o Fun with remote branches (1)
o Fun with remote branches (2)
短语“当人们对他们提交的代码有信心，然后将其合并到分段”时，不应该适用于DVCS：提前提交，经常提交，但只在你想要时推送（“发布”）。
< / LI>

Answer 3

ProGit book中还介绍了一些项目工作流程，它们显示了开发人员每天都会使用的Git命令。

在http://nvie.com/git-model

中描述了一个备受好评的Git分支模型

Answer 4

Great post on GitHub Workflow由一位GitHub创作者Scott Chacon和提到的Pro Git book的作者：P

Answer 5

根据您的工作流程，您可以在中央存储库（即github上）上有一些“重要”分支，人们可以在本地克隆。这些对应于'稳定'，'beta'，'开发'等。关于可能的一组分支的好文章是this。

完成后，您可以让人们使用自己的策略。我更喜欢为主要项目保留主题分支，并且有一个叫做“快速修复”的快速修复我需要做的事情。如果你有一个团队在一个主要项目上工作，他们想要在一个与主要仓库隔离的单独分支上，你可以让他们在没有任何干预的情况下这样做。如果人们喜欢有很多小小的树枝来尝试等等，他们也可以做到这一点。

至于自动测试并从分段集成到生产中，您可以配置git挂钩来执行此操作，也可以让系统运行，定期为您执行此操作并报告问题。

Git＆amp; amp;的最佳工作流程Github上

5 个答案: