一文让你从git新手变git老司机！！！学会这套git工作流，保你打开新世界！
无论你是开发自己的项目还是参与开源项目，这一套都流程是非常不错的，不光是在个人项目中使用，在很多开源项目上，甚至于公司的项目里都会使用这一套流程，所以学会他适应它对你的编程生涯是有绝对的好处的，我曾经也对该怎么正确使用git迷茫，只会直接推送主分支或者dev分支再合并到主分支，现在我发现了一套非常不错的git工作流推荐给大家。
不习惯星球格式的访问文档：Git 工作流 - 飞书云文档 (feishu.cn)
首先我们假设在github是有一个仓库，可能是别人的也可能是我们自己的。
我们可以通过git clone 命令把远端仓库复制一个一模一样的仓库到本地。本地仓库又分为磁盘和本地Local仓库。
- 本地Local仓库：可以认为是一个本地的git仓库，这里面拥有所有你告诉git的信息
- 磁盘Disk: 这个部分是我们的源文件真正在磁盘的样子，也是我们用编辑器打开源文件的时候的状态。
在我们需要修改代码的时候，第一件事就是建立一个新的feature branch。而不是直接往master分支上面push代码。这样不会把主分支搞的很乱，甚至不能工作，这种非常有利于多人合作。
建立feature branch方法：在clone之后，使用 git checkout -b my-feature 创建一个新的分支。这个my-feature就是你要建立分支的名字，这个命令会复制一份你当前的branch分支到新的branch分支上。在我们clone之后，当前的branch或者说当前的checkout是master(main),也就是说我们复制了一份master branch到我们的新分支my-feature上。
接下来我们可以修改代码了，不管你是修改bug还是增加新的分支，当你改好代码保存文件之后，你的硬盘上的文件是有变化的，但是git对此一无所知。这个时候可以使用git diff 命令来看硬盘上的改变跟git上保存的分支有什么区别。强烈建议在做下一步之前先使用git diff 查看一下到底做了什么改变。Idea目前可以很方便就能查看改变的差异。
当我们，把修改的文件告知git的时候，可以使用 git add <changed-file> 命令把修改的文件<changed-file> 是你所有要提交修改的文件，这个命令会把修改的文件放在暂存区的地方。当把执行了git add 命令之后，git就会知道你有一些代码需要commit.
当你执行git commit 之后，会把这些修改真正的放到git里，我们的Local git 就会新增一个commit.
这个commit里面就是我们刚才做的代码改动，我们只是把这些代码改动告知了我们的local git，但是现在为止github还什么都不知道。我们需要把local git 的变化告知github，我们使用git push origin my-feature
命令之后就会发现github多出来了一个my-feature分支，这个分支里面保存着我们代码的改动。
我们非常常见的情况是，在我们修改代码的时候，master branch 又有更新了，比如说当我们push到my-featuer这个分支之后，我们发现master分支又多了update这个commit。
那么我们可能需要测试一下，我的这个feature,在新的这个update更新之下是不是还好使，所以我们要把main branch 更新,给同步到my-feature这个分支里。首先我们要更新我们的local branch.我们可以看到当前我们的local git master跟远程的master是不一样的，所以首先我们要切换到master分支，使用git checkout master命令。这个时候的硬盘代码就是init状态，而不是我们修改代码的状态了。
在切换分支之后，我们运行git pull origin master，这行命令会把远端的master给同步到本地local的master里。这个命令执行之后，远端的update这个commit就会同步到我们的local git 和disk,这个时候我们的local git 就和远端的github 一样了
然后我们回到my-feature分支上,当前状态的源代码，就是有我们修改的f-commit的变化，但是没有远端update这个变化的commit代码
为了要同步这个master的代码改变，我们使用git rebase master,这个命令的意思是把我的修改先都扔一边，把master最新修改拿过来，接着在这个最新修改的基础上，再把我的这个commit给尝试弄回去，但在这个过程中有可能会有rebase conflict，如果出现了rebase confict,就需要手动的去选择你到底要哪段代码。在rebase成功之后，我们的feature分支，就变成了下面这个样子。可以看到在rebase成功之后，我们相当于是在最新的master分支上面做了我们的修改，这也是使用rebase而不是merge的好处
在更新完我们的feature分支之后，我们需要git push my-feature,把我们local git 里面的branch push 到github 上，但是注意由于我们做了rebase，所以我们在push的时候，必须要加上-f 强制推送
到此我们一切准备就绪，我们需要把我们更新的代码合并到这个master分支里面了，这个过程我们叫做pull request,为什么要叫做pull request? 因为我们形式上认为这个主分支是属于项目的，不属于任何个人，而功能分支也就是feature 分支是属于个人的。尽管这个feature分支的主人和这个项目的主人可能是一个人。但是在这两个分支上他们是不同的角色，pull request 的意思request这个项目的主人把我这个新的分支的改变给pull到这个项目里去，所以叫pull request。在github上你可以非常方便的建立pull request。要求这个master branch 把你的这个my-feature branch上面的改动给pull进去
在这个master branch 的维护者，有时候也可能是你自己，他审查了你的代码之后，一般情况下会用squash and merge。为什么要用squash and merge操作。在我们的这个例子中my-feature这个分支只有一个commit,但是在更多情况下，我们的功能分支上面的commit 是比较乱的，有可能会有很多代码格式的改变或者是有很多bug fix。我们不希望把这些commit,每一个都放到我们的master主分支里面，我们希望我们的主分支的commit history提交记录尽可能的简洁。尤其我们希望我们的master主分支每一个commit都是正常工作的，所以在大多数情况下面对pull request 我们会选择squash and merge。squash and merge的意思就是把这个分支上的所有改变合并成一个改变，然后把这个commit给放到我们的master主分支上，也就是这些改变可能变成了update2这个ccommit。
你的代码改动都正常的合并到了master主分支里面，只是commit的结构数量和名字改变了，中pull request被merge之后，一般情况下我们会直接把远端的直接branch直接删掉。在github上有个按钮叫delete branch,但是现在还没完远端的那个my-feature被删掉了，但是我们的local git 上面还有，这个时候我们首先要切换到master分支上
然后删除掉my-feature,可以使用git branch -D my-feature命令，也可以使用编辑器可视化工具来把这个my-feature分支从local git 里面删掉
最后在mastre分支里面，我们再使用一次git pull origin master，把最新的这个更新给拉到我们local的master分支和我的Disk里,
我们在经过这些操作之后，我们的local git和Disk就又和我们的远程github一模一样了。
