前言
记得我正式在第一家公司实习的时候（2022.09），当时的团队就出现过git开发流程的问题，包括但不限于：分支如何管理、合并分支用rebase/merge，如何进行release版本的管理等等。这些问题在接下来的文章中都会迎刃而解。
你有想过现在最规范、最火热的git工作流是怎样的吗？我们可以来看看的atlassian这篇文章，原文链接git-feature-workflow，下面的翻译加入了我的很多解释和具体命令，相信比原文容易理解的多。
Git功能分支工作流
核心思想
Feature Branch Workflow背后的核心思想是，所有功能开发都应该在专用分支而不是主分支中进行。这种封装使得多个开发人员能够轻松地处理特定特性需求，而不会干扰主代码库。
这还意味着主分支永远不会包含带有漏洞的代码，这对持续集成开发来说是一个巨大的优势。
Git 特征分支工作流是一种可组合工作流，可由其他高级 Git 工作流利用。我们在Git工作流概述页面中讨论了其他Git工作流。Git Feature Branch Workflow是针对分支模型的，这意味着它是管理和创建分支的指导框架。比如说和git-fork-workflow（每个开发人员都进行项目仓库的fork，在自己fork的仓库进行开发）以及git-rebase-workflow（每次合并使用rebase命令）结合起来。
同事讨论
分支特性开发还使利用pull-request成为可能，这是围绕分支发起讨论的一种方式。它们为其他开发人员提供了在功能集成到正式项目之前讨论该功能的机会。
比如，如果您卡在功能中，您可以打开一个pull-request请求，请求同事提供建议。重点在于，拉入请求使您的团队能够非常容易地对彼此的工作发表评论。
比如，我们需要开发一个新功能k8s-opertion
git checkout -b k8s-opertion- 进行开发，期间有一些问题，你想让同事评估一下你的代码
git add + git commit + git push -u k8s-opertion- 这个时候就已经
push到这个分支了 - 给相应的
url给你同事
如何使用
Feature Branch Workflow假定一个中央存储库，main/master表示正式的项目历史。开发人员不直接在本地主分支上提交，而是每次开始使用新功能时都创建一个新分支，对应着一个需求。特征分支应具有描述性名称，如animated-menu-items 或 issue-#1061。其理念是给每个分支机构一个明确、高度集中的目标。Git在主分支和功能分支之间没有技术上的区别，因此开发人员可以编辑、存放和提交对功能分支的更改。
此外，可以特征分支推送到中央存储库。这使得与其他开发人员共享特性成为可能，而无需接触任何官方代码。由于main是唯一的"特殊"分支，所以在中央存储库中存储多个特征分支不会造成任何问题。当然，这也是备份每个人本地承诺的便捷方式。以下是功能分支生命周期的演练。
1.每次开发从主分支开始
所有功能分支都是根据项目的最新代码状态创建的。本指南假定在主分支中进行维护和更新。
css
git checkout main
git fetch origin
git reset --hard origin/main上面的三条命令，作用分别是：
- 回到主分支
- 同步远程仓库的所有变更
- 将代码回退到最新的
main分支头指针指向处，也就是把git日志和本地工作目录代码都和main分支同步
注意：如果这里你还有正在开发、为提交的功能，用git pull去替换reset，或者先git stash。
2.进入到功能分支
为您处理的每个功能或问题使用单独的分支。创建分支后，在本地切换到这个分支，这样您所做的任何更改都将在该分支上。
git checkout -b new-feature
该命令用于切换到新分支，如果不存在则创建。
在此分支上，以通常的方式编辑、暂存和提交更改，根据需要使用尽可能多的提交来构建特性。在特性上工作，并像任何时候使用Git一样进行提交。准备就绪后，推送提交，更新分支上的特性分支。
sql
git status
git add <some-file>
git commit将功能分支上推到中央存储库。这可以作为方便的备份，当与其他开发人员协作时，这将使他们能够查看对新分支的提交。
git push -u origin new-feature
-u用于跟踪该远程分支，之后在这条分支上再进行推送，只需要git push，不用指定分支了。
3.合并分支
在合并之前，如果其他人对相同文件进行了更改，则可能需要解决合并冲突。当拉取请求获得批准且无冲突时，可以将代码添加到主分支。
原文中还有一个例子来对这个git工作流进行讲解，看了一下感觉没什么翻译的必要，有兴趣的可以看看。