标准github工作流程

本文节选自本人博客：标准 github 工作流程

• 💖 作者简介：大家好，我是MilesChen，偏前端的全栈开发者。
• 📝 CSDN主页：爱吃糖的猫🔥
• 📣 我的博客：爱吃糖的猫
• 📚 Github主页: MilesChen
• 🎉 支持我：点赞👍+收藏⭐️+留言📝
• 💬介绍：The mixture of WEB+Iot+DeepLearning+anything🍁

前言

本文介绍一种使用最多的github工作方法，无论维护自己的项目还是开源项目，掌握这套流程就够了。

从clone到push

1. git clone URL
2. git checkout -b xxx 切换至新分支xxx（相当于复制了remote的仓库到本地的xxx分支上）
3. 修改或者添加本地代码（部署在硬盘的源文件上）
4. git diff 查看自己对代码做出的改变
   
   5.git add 上传更新后的代码至暂存区
   6.git commit 可以将暂存区里更新后的代码更新到本地git
   7.git push origin xxx 将本地的xxxgit分支上传至github上的git

发起PR

写自己的代码过程中发现远端GitHub上代码出现改变，则需要与远程更新合并

1. git checkout main 切换回main分支
2. git pull origin master(main) 将远端修改过的代码再更新到本地
   
3. git checkout xxx 回到xxx分支
4. git rebase main 我在xxx分支上，先把main移过来，然后根据我的commit来修改成新的内容

中途可能会出现，rebase conflict=>手动选择保留哪段代码
为什么不同merge？ 因为rebase是将人家的代码git pull 到一个分支，再将我们的合并进去，这样更好。

5. git push -u origin xxx 把rebase后并且更新过的代码再push到远端github上
6. 原项目主人采用pull request 中的 squash and merge 合并所有不同的commit

收尾

1.git branch -d xxx 删除本地的git分支
2.git pull origin master 再把远端的最新代码拉至本地

总结

本文介绍的github工作流和大部分人add commit push一把梭的方式比起来还是稍显麻烦，然后在任何一个由成熟度的项目中都不可能使用add commit push一把梭的方式，这会让项目管理崩溃的。这套github工作流是很多开源项目、公司都在使用的一套流程，学会了他肯定对我们的编程生涯有好处的。

---

如果对您有帮助，麻烦点赞收藏，让更多踩坑的人看见，有任何疑问和想法，欢迎在评论区与我交流。