我正在使用 git。到目前为止，我们是两个团队成员，致力于一个项目。到目前为止，这两项工作都略微独立，一个专注于 UI，另一个专注于 api。我喜欢每天签到多次。我的典型工作流程是：
所以我创建了一个功能分支，然后处理它，将它合并到主分支，然后推送它。删除分支并重新创建相同的分支。
该产品仍然是第一个版本，我们有一个持续集成构建服务器设置。推送的主要目的是获取监督者的增量更新。
我的问题是，
问题 #1
如果我还没有完全完成一个功能，如果它仍然是版本 1，将小单元的可编译更改推送到主分支上的主服务器是一个好习惯吗？
不，将未完成的代码引入主分支通常不是一个好习惯。您应该始终有一个模仿生产代码状态的分支。对于大多数人来说，这个分支被称为master.
为什么这很重要的一个例子是生产中的错误。如果您已经在主分支中引入了一堆半完成的工作，那么您发布的任何修复也将包括未完成的工作。此外，如果其他开发人员从该分支中撤出，并且您添加了未经测试的代码，则可能会使他们的开发复杂化。
即使您的代码尚未发布 - 您也希望拥有一个仅包含工作且经过全面测试的代码的分支。一般来说，您应该尝试尽可能地分解功能并测试小的更改。如果它们不会对已经在工作的其他任何东西产生负面影响，它们可以合并到主分支中。
无论您如何工作，您都应该尝试保留一个具有某种“权限”级别的分支 - 一个仅在满足某些条件后才合并的分支。这个标准是什么，取决于你。
您可能会决定保留一个主分支，该分支的唯一修改时间是发布新版本时。相反，您决定在您的工作经过测试后立即合并到您的主分支中。您如何决定这样做通常取决于发布策略和更广泛的工作流程。
问题2
创建分支，合并到主，推送它，删除本地分支然后重新创建它是一个好习惯吗？
无法回答是/否。对于团队如何处理代码版本控制、成员之间的协作和发布周期，有许多策略。
一般来说，在合并到主分支后立即删除分支是一种很好的做法。通常最好摆脱并避免继续使用相同的分支（通常称为具有“长寿命”的分支）。在大多数情况下，短期分支是个人开发任务的首选——但这可能会根据您的团队偏好和选择而改变。
工作流程问题
你有一个小团队，你的代码还没有发布——所以压力会更低，解决方案也会更容易，因为只有你们两个。然而，一旦你的产品上市，解决错误的压力就会更大——可能会出现发布修补程序/补丁的需求。发布周期将因越来越多的同步开发而复杂化。随着您将越来越多的开发人员添加到您的团队中，并且对版本控制有不同程度的理解，协作将变得更加混乱和容易出错。
因此，我建议您在决定工作流程时牢记以下几点。
一个流行的工作流程被称为“ git flow ”，甚至还有一个命令行工具来帮助自动化所涉及的步骤。作为一个小团队，你可能会发现它过于复杂——但我建议如果你有一个基于迭代的发布周期，这是你至少应该做的。
我其实不是 git-flow 的忠实粉丝，只是因为我觉得它实际上过于简单和二维。（我不喜欢“分散但集中”，我更喜欢实际分布式的工作流程）。
但是，如果您的发布周期非常快——在这种情况下，您可能希望采用github 本身使用的模型。他们的模型与您的模型相似，因为它们只是合并到 master 中-但是它们仅在代码通过了一些自动化测试后才这样做。github 所做的关键点还在于它们每天部署多次——而不是像大多数团队那样在发布周期内进行部署。这样一来，几乎总是会在最近引入将其投入生产的错误。这是一个更简单的策略，但并不适合所有人，请记住上面的要点，尤其是如果您有更典型的发布周期。