Git工作流程：澄清和避免反模式 [英] Git Workflow: Clarification and Avoiding Antipatterns

问题描述

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

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

---

基础知识

• 分支 - 所有代码
  开发被合并。这代表最新增加的
  个别开发分支的代码库。
  
• 'dev_'分支 - 本地私人开发分支应用于开发新的
  功能。如果您需要将分支推送到服务器（这样您可以在计算机之间轻松切换
  ），请确保开发分支
  名称包含用户名，例如'dev_andy_authentication'。


• 暂存分支 - 在从主分支部署特定代码
  之前，必须在与生产
  环境匹配的环境中对代码进行严格测试可能。 master分支中的代码是
  ，合并到暂存分支中进行测试，并且一旦通过测试，就是
  符合生产条件。 生产分支
- 来自staging分支的稳定代码集成到生产分支中，用发行版本号标记，然后部署到生产服务器。

---

发展

支部：主人

使用本地，专用功能分支来分隔代码：

• 切换到'master'分支：git checkout master


• 创建一个新的专用功能分支：git checkout -b dev_newfeaturename


• 添加功能


• 阶段更改：git add。提交'dev_newfeaturename'中的更改：git commit -m提交描述

整合来自'dev_newfeaturename'分支的变化：

• 切换到'master'分支：git chec kout 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
    
  • 将所有更改的'主'代码重新集成到'dev_newfeaturename'分支：git rebase --interactive master
  
  
  • 要通过合并提交来清理历史记录，请将操作从pick更改为squash，将第二次提交压缩为第一个
  
  
  • 切换到'master'分支：git checkou t master
  
  
  • 将变化推送到远程'master'：git push origin master
  
  
远程更改'master'：git pull --rebase origin master

• 将所有对'master'的更改推回服务器：git push origin master

<

• 
  
• 'Master'成为所有当前开发功能的工作树。


• 定期从远程拖拉'主'更改：git pull - -rebase出发大师

---

暂存

Branch：staging

• 一旦发布了一定数量的功能/错误修复程序，请确保'master'运行正常，然后通过以下方式合并到'暂存'中：
  
  
  
  • 切换到'暂存'分支：git checkout staging
  master'进入'staging'：git merge --no-ff master
  
  • 将'staging'推送到远程仓库：git push origin staging
  li>
  


• 将'分段'分支部署到分段服务器并进行严格测试 - 分段服务器应尽可能地复制生产环境。 $ b
• 如果任何测试失败，请返回到'master'分支，修复所有相关问题，然后重新启动暂存过程。 如果所有测试都通过，请继续进行生产过程。 / li>
  

---

生产

分支：生产

• 暂存分支中的代码已经过测试并通过后，切换到'production'分支：git checkout production
• 
  
• 将'staging'中的更改集成到生产中：git merge --no-ff staging


• 使用顺序发布版本号的代码：git tag -a 0.1


• 将'生产'分支推送到生产服务器并进行测试以确保正确部署。 / li>
  

<你写道：

如果' dev_newfeaturename '分支更复杂，需要多次提交才能保留在历史记录中：

• 切换到' code> 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需要在历史中清理那些提交：`git merge dev_newfeaturename

---

关于每个开发状态的分支（staging，prod），我不会推荐这种方法，除非您在这些分支中主动生成新的提交。

在你引用的文章中记住关于no-ff的句子：

-no-ff 是文档。

人们可以使用合并提交来表示生产代码的最后部署版本。

这是一个反模式。使用标签。

I am in the process of developing a Git workflow for a web app project I am working on. I have used Git for several years, but only as a solo developer. I have put a set of procedures together, and yesterday ran across this article on HN: http://sandofsky.com/blog/git-workflow.html

Based on the article I have adjusted my procedures and would appreciate some feedback. I want to make sure I am interpreting the article correctly and not contributing to issues down the road. Based on the article in question, and the desire to provide good working standards, are there any issues with the following procedures?

---

Basics

• master branch - The main, working branch into which all code development is merged. This represents the most recent additions to the codebase from individual development branches.
• 'dev_' branches - Local, private development branches should be used for developing new features. If you need to push the branch to the server (so you can switch easily between computers) please make sure that the dev branch name includes the user name, like 'dev_andy_authentication'.
• staging branch - Before deployment of certain code from the master branch, the code must be tested in an environment that matches the production environment as closely as possible. Code from the master branch is merged into the staging branch, tested, and, once it passes tests, is eligible for production.
• production branch - Stable code from the staging branch is integrated into the production branch, tagged with a release version number, then deployed to the production server(s).

---

Development

Branch: master

• Use local, private feature branches to separate code:
  • Switch to ‘master’ branch: git checkout master
  • Create a new, private feature branch: git checkout -b dev_newfeaturename
  • Make feature additions.
  • Stage changes: git add .
  • Commit changes in ‘dev_newfeaturename’: git commit -m "commit description"
• To integrate changes from 'dev_newfeaturename' branch:
  • Switch to ‘master’ branch: git checkout master
  • Check for remote changes to ‘master’: git pull --rebase origin master
  • If changes in 'dev_newfeaturename' branch are relatively small:
    • Integrate changes from ‘dev_newfeaturename’ branch into master: git merge --squash dev_newfeaturename
    • Write a detailed commit message of changes implemented from 'dev_newfeaturename' branch: git commit -v
  • If changes in 'dev_newfeaturename' branch are more complex, requiring multiple commits to remain in the history:
    • Switch to ‘dev_newfeaturename’ branch: git checkout dev_newfeaturename
    • Reintegrate any changed ‘master’ code into ‘dev_newfeaturename’ branch: git rebase --interactive master
    • To cleanup history by combining commits, change the operation from "pick" to "squash", which squashes the second commit into the first
    • Switch to ‘master’ branch: git checkout master
    • Push changes to remote ‘master’: git push origin master
  • Check for remote changes to ‘master’: git pull --rebase origin master
  • Push all changes to 'master' back to the server: git push origin master
• ‘Master’ becomes the working tree of all currently developed features.
• Periodically pull ‘master’ changes from remote: git pull --rebase origin master

---

Staging

Branch: staging

• Once a release of a certain number of features/bug fixes has been scheduled, ensure that ‘master’ is functioning properly then merge into ‘staging’ by:
  • Switch to ‘staging’ branch: git checkout staging
  • Integrate changes from ‘master’ into ‘staging’: git merge --no-ff master
  • Push ‘staging’ to remote repo: git push origin staging
• Deploy ‘staging’ branch to staging server and test rigorously - staging server should replicate production environment as closely as possible.
• If any testing fails, return to ‘master’ branch, fix any associated issues, and restart the Staging process.
• If all testing passes, proceed to Production process.

---

Production

Branch: production

• Once code in the staging branch has been tested and has passed, switch to the ‘production’ branch: git checkout production
• Integrate changes from ‘staging’ into production: git merge --no-ff staging
• Tag code with sequential release version number: git tag -a 0.1
• Push ‘production’ to remote repo: git push origin production
• Deploy ‘production’ branch to production server and test to ensure proper deployment.

解决方案

You wrote:

If changes in 'dev_newfeaturename' branch are more complex, requiring multiple commits to remain in the history:

• Switch to ‘dev_newfeaturename’ branch: git checkout dev_newfeaturename
• Reintegrate any changed ‘master’ code into ‘dev_newfeaturename’ branch: git rebase --interactive master
• To cleanup history by combining commits, change the operation from "pick" to "squash", which squashes the second commit into the first
• Switch to ‘master’ branch: git checkout master
• Push changes to remote ‘master’: git push origin master

I think you forget the fast-forward merge of 'dev_newfeaturename' into ‘master’:
The rebase allows you to replay 'dev_newfeaturename' on top of ‘master’, cleaning up the commits in that process. That is good.
But if you want to push back master to the remote, master needs those cleaned commits in its history: `git merge dev_newfeaturename

---

Regarding a branch per development state (staging, prod), I wouldn't recommend that approach, unless you are actively producing new commits in those branches.
Remember the sentence about no-ff in the article you reference:

The only remaining argument for –no-ff is "documentation."
People may use merge commits to represent the last deployed version of production code.
That’s an antipattern. Use tags.

这篇关于Git工作流程：澄清和避免反模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！