标准github工作流程
·
本文节选自本人博客:标准 github 工作流程
- 💖 作者简介:大家好,我是MilesChen,偏前端的全栈开发者。
- 📝 CSDN主页:爱吃糖的猫🔥
- 📣 我的博客:爱吃糖的猫
- 📚 Github主页: MilesChen
- 🎉 支持我:点赞👍+收藏⭐️+留言📝
- 💬介绍:The mixture of WEB+Iot+DeepLearning+anything🍁
前言
本文介绍一种使用最多的github工作方法,无论维护自己的项目还是开源项目,掌握这套流程就够了。
从clone到push

git clone URLgit checkout -b xxx切换至新分支xxx(相当于复制了remote的仓库到本地的xxx分支上)- 修改或者添加本地代码(部署在硬盘的源文件上)
git diff查看自己对代码做出的改变

5.git add上传更新后的代码至暂存区
6.git commit可以将暂存区里更新后的代码更新到本地git
7.git push origin xxx将本地的xxxgit分支上传至github上的git
发起PR
写自己的代码过程中发现远端GitHub上代码出现改变,则需要与远程更新合并

git checkout main切换回main分支git pull origin master(main)将远端修改过的代码再更新到本地

git checkout xxx回到xxx分支git rebase main我在xxx分支上,先把main移过来,然后根据我的commit来修改成新的内容
中途可能会出现,rebase conflict=>手动选择保留哪段代码
为什么不同merge? 因为rebase是将人家的代码git pull 到一个分支,再将我们的合并进去,这样更好。
git push -u origin xxx把rebase后并且更新过的代码再push到远端github上- 原项目主人采用
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工作流是很多开源项目、公司都在使用的一套流程,学会了他肯定对我们的编程生涯有好处的。
如果对您有帮助,麻烦点赞收藏,让更多踩坑的人看见,有任何疑问和想法,欢迎在评论区与我交流。
更多推荐
所有评论(0)