Git工作流程：澄清和避免反模式

Question

我正在为我正在开发的网络应用项目开发Git工作流程。我已经使用Git好几年了，但只是作为一个独立的开发人员。我已将一组程序放在一起，昨天在HN上发表了这篇文章：http://sandofsky.com/blog/git-workflow.html

根据文章，我调整了我的程序，并希望得到一些反馈。我想确保我正确地解释这篇文章，而不是对未来的问题做出贡献。 根据相关文章以及提供良好工作标准的愿望，以下程序是否存在任何问题？

---

基本

• master branch - 所有代码所在的主要工作分支 发展合并。这代表了最新增加的内容 各个开发分支的代码库。
• 'dev_'分支 - 应该使用本地私有开发分支来开发新分支 特征。如果您需要将分支推送到服务器（所以你可以 在计算机之间轻松切换）请确保dev分支 name包括用户名，例如'dev_andy_authentication'。
• 登台分支 - 在从主分支部署某些代码之前， 必须在与生产匹配的环境中测试代码 环境尽可能接近。主分支的代码是 合并到临时分支，测试，并且，一旦通过测试，是 有资格生产。
• 生产分支 - 来自分段分支的稳定代码已集成到生产分支中，标记有发布版本号，然后部署到生产服务器。

---

开发

分支：主人

• 使用本地私有功能分支来分隔代码：
  • 切换到'master'分支：git checkout master
  • 创建一个新的私有功能分支：git checkout -b dev_newfeaturename
  • 添加功能。
  • 阶段变化：git add。
  • 提交'dev_newfeaturename'中的更改：git commit -m“commit description”
• 要整合来自'dev_newfeaturename'分支的更改：
  • 切换到'master'分支：git checkout master
  • 检查对'master'的远程更改：git pull --rebase origin master
  • 如果'dev_newfeaturename'分支的变化相对较小：
    • 将来自'dev_newfeaturename'分支的更改集成到master中：git merge --squash dev_newfeaturename
    • 编写从'dev_newfeaturename'分支实施的更改的详细提交消息：git commit -v
  • 如果'dev_newfeaturename'分支中的更改更复杂，则需要在历史记录中保留多个提交：
    • 切换到'dev_newfeaturename'分支：git checkout dev_newfeaturename
    • 将任何已更改的'master'代码重新集成到'dev_newfeaturename'分支中：git rebase --interactive master
    • 要通过组合提交来清理历史记录，请将操作从“pick”更改为“squash”，这会将第二次提交压缩到第一次提交
    • 切换到'master'分支：git checkout master
    • 将更改推送到远程'master'：git push origin master
  • 检查对'master'的远程更改：git pull --rebase origin master
  • 将对“master”的所有更改推送回服务器：git push origin master
• 'Master'成为所有当前开发功能的工作树。
• 定期从远程执行'master'更改：git pull --rebase origin master

---

分段

分支：暂存

• 一旦安排了一定数量的功能/错误修复，请确保'master'正常运行，然后通过以下方式合并到'staging'：
  • 切换到'staging'分支：git checkout staging
  • 将“master”中的更改集成到“staging”中：git merge --no-ff master
  • 将'staging'推送到远程仓库：git push origin staging
• 将“staging”分支部署到登台服务器并严格测试 - 登台服务器应尽可能地复制生产环境。
• 如果任何测试失败，请返回“主”分支，修复所有相关问题，然后重新启动暂存过程。
• 如果所有测试都通过，请继续进行生产流程。

---

生产

分公司：生产

• 暂存分支中的代码经过测试并通过后，切换到“生产”分支：git checkout production
• 将“暂存”中的更改集成到生产中：git merge --no-ff staging
• 带有顺序发布版本号的代码：git tag -a 0.1
• 将'生产'推送到远程仓库：git push origin production
• 将“生产”分支部署到生产服务器并进行测试以确保正确部署。

Answer 1

您写道：

  

如果“dev_newfeaturename”分支中的更改更复杂，则需要在历史记录中保留多个提交：

     

  
• 切换到“dev_newfeaturename”分支：git checkout dev_newfeaturename
  
• 将所有已更改的“master”代码重新整合到“dev_newfeaturename”分支中：git rebase --interactive master
  
• 要通过组合提交来清理历史记录，请将操作从“pick”更改为“squash”，这会将第二次提交压缩到第一次提交
  
• 切换到“master”分支：git checkout master
  
• 将更改推送到远程“master”：git push origin master
  

我认为您忘记了将“dev_newfeaturename”快速合并到“master”中： rebase允许您在“dev_newfeaturename”之上重播“master”，清理该过程中的提交。那很好。
但是如果你想将master推回到远程，master需要在其历史记录中清理提交：`git merge dev_newfeaturename

---

关于每个开发状态的分支（staging，prod），我不推荐这种方法，除非你在这些分支中积极生成新的提交。
请记住您引用的文章中关于no-ff的句子：

  

–no-ff唯一剩下的论据是“文档”   人们可以使用合并提交来表示生产代码的最后部署版本   这是反模式。使用标签。