git windows 简易教程(优秀的程序员Git使用指南)

1 絮叨

最近因为工作有点忙,加上自己个人生活的一些琐事,突然感觉写文章太难了,不过还是慢慢坚持下来,即使更新频率变慢了。最近的主题还是那个初衷, 记录下自己日常开发工作的一些想法。

2 前言git

在日常的开发工作中,免不了会使用git进行代码管理,熟练使用git会使我们有更多的时间专注于代码编写,加快整体开发效率。 然而对我而言,git只是工具,一些常规操作已经足够了,有空有兴趣才会去深入研究它。不熟悉git也不要紧,学学就好, 快的话随便看几个命令后自己再实践一下就可以应付日常开发了。

3 常用Git命令

我日常开发有用idea去操作git,当然有些场景也会在idea的Terminal面板去手打命令,当你熟悉了之后,简直是舒服地飞起,会感觉到看似杂乱无章的各个分支里的代码,在你几个命令操作下管理得井然有序。

3.1 克隆项目 git clone

从远程库拉项目到idea: VCS->Checkout from Version Control->Git,贴上URL后点Clone,idea就会帮我们执行git clone命令。

git windows 简易教程(优秀的程序员Git使用指南)(1)

当然,也可以先git clone https://gitee.com/xxx/Test.git到本地后,在把项目导入idea中

3.2 查看分支 git branch

查看当前项目有哪些分支

git windows 简易教程(优秀的程序员Git使用指南)(2)

3.3 检出代码 git checkout

拉取远程分支代码

git checkout -b dev(本地分支名称) origin/dev(远程分支名称)

git windows 简易教程(优秀的程序员Git使用指南)(3)

3.4 创建分支 git checkout -b

有时你想自己创建一条分支可执行 git checkout -b dev(分支名)

相当于2条命令

git branch dev

git checkout dev

切记,一定要在最新master分支上创建新分支

3.5 拉取/提交/推送代码 git pull/git commit/git push

这几个操作真的是最基本了,相信在所有命令中,熟悉这个的人占极大多数,这里我一般都是借助idea操作的。

git windows 简易教程(优秀的程序员Git使用指南)(4)

如果是多人在同一分支开发的话,一般在push之前要先pull最新代码,但谁要能保证你即使pull后在到push这一瞬间,有没有人提交代码呢?

  1. 若别人有提交代码,idea会在你push时提示你要不要merge,若没有冲突会自动合并,此时git日志里会有这么一行记录 Merge remote-tracking branch origin/dev into dev git的日志记录也不会是一条完整直线了。若有冲突,需要手动解决。
  2. 若你先pull,没冲突当然最好,有冲突你会pull失败,提示本地修改会被覆盖。 这时可以git stash 暂存修改。 暂存成功后 git pull拉取代码。 git unstash将暂存的代码更新到当前分支上。

git windows 简易教程(优秀的程序员Git使用指南)(5)

git windows 简易教程(优秀的程序员Git使用指南)(6)

git windows 简易教程(优秀的程序员Git使用指南)(7)

如果此时有冲突,可手动解决,idea也提供良好的可视化图形,解决冲突变得容易许多。

左边本地代码、右边远程代码、中间合并成功之后的代码

git windows 简易教程(优秀的程序员Git使用指南)(8)

3.6 撤销操作
  1. 还没commit就想放弃修改,直接鼠标右键点击文件Revert就好。
  2. commit了之后还没push,想撤回commint前操作。 git reset --hard HEAD~ --hard直接还原到上一版本,不保留修改(慎用) git reset --soft HEAD~ --soft还原到上一版本,保留commit前的修改(常用) git reset --mixed HEAD~ --mixed 与soft不同的是,还原到git add前没暂存的文件 图形化 GIt->Repository->Reset HEAD...

HEAD~上一版本

一般都后悔操作上一步,想回退多步直接指定版本号吧 git reset --hard HEAD commit_id

  1. push之后想回退。 依然可以用上述操作,只不过在下一次push之后,会拿回退前的版本跟当前修改合并,有冲突要解决。
3.7 合并代码 git merge

这里我一般都是图形化操作,将远程代码合并到自己当前的分支上。

merge dev(分支名) into current

git windows 简易教程(优秀的程序员Git使用指南)(9)

4 多人开发合作模式

所谓的开发合作模式,简单来说就是git的分支管理。

每个公司因为业务量不同、服务器数量不同,都有自己的管理规范。

简单点的可能只有主干master、开发分支dev。

复杂点的多了功能分支feature、bug修改分支fixbug,甚至还有测试分支test、预发布分支pre-release。

当然,这些不同场景的叫法和命名都是自己定义的,但你的项目再简单,最好不要简化到只有master和dev分支。

我曾入职一家公司,看到里面的项目只有master和dev,就直接跟当时的开发说你们这样干,不会遇到某某问题吗?没想到 一语中的,所以后面才规范了分支管理规范。

那会有什么问题?

  • master是线上稳定的代码分支,一般不能直接在上面修改,这时产品来了2个或以上需求,因进度不同不能同时上线, 这时你们共用一个dev,那岂不是把别人未测试过的代码给上了?你可能会说我们公司需求不多,上线一个功能才开发下一功能,那自己私下想写些demo测试优化,还不是要在dev上改?
  • 2个功能需求想一起测试、一起上线,那我都在dev开发?最好还是分开,各自建自己的分支开发,避免其他同事在解决冲突时因不熟悉git把你的代码给干掉了。后面想一起上线时再一起合并即可。

目前自己在用的管理模式,master 多个feature分支,仅此而已:

  1. 需求下来,在master上建个功能分支,命名f 时间 功能名,如:f_20200521_coupon(暂且定义A)。
  2. 本地开发、服务器上测试都直接部署功能分支的代码。
  3. 测试通过即将上线时,checkout本地的master,git pull拉最新代码。
  4. 再切换回自己的功能分支A,并merge matser into current,手动解冲突。
  5. 如果想连同他人的分支(暂且定义B)一起上线,最好先叫你的伙伴先合master代码,然后重复3、4步,checkout B、切换A、merge B。
  6. 在gitlab等私服申请请求合并,merge A into matser,这时绝对不会有冲突产生。
  7. 合并到master后删除自己的功能分支。
  8. 服务器上部署master上线。

为什么有第3步?其实是为了第4、第6步服务的,得先保证你本地的matser是线上最新的,经过第4步之后去到第6步,因为master是最新且在第4步已解决冲突,到了第6步就绝对不会有冲突。

为什么不直接在第3步后就 merge A into current(master)?为了安全,master一般不能在本地直接操作,是一个受保护的分支。

为什么在第4步merge matser into A后还要在第6步merge A into matser,绕来绕去,在逗我吗?上面已经回答了,master分支一般是有权限(受保护)的,merge A into matser不能在本地操作,只能在gitlab(git私服)上操作,但gitlab上又不能手动解决冲突,所以我们要先在本地merge matser into A并手动解决冲突,再到第6步就可以完美合并。

是不是被我绕晕了......???

另外,遇到线上bug得紧急修复,也能建个功能分支,然后按上述方法操作。

如果只是改的线上的极小功能(文案,简单判断之类的)又想快速上线,而且你还有操作matser的权限,那大可不必按上述方式,直接master上改后提交就行,多爽是吧。

5 建议

【建议1】一定要在最新的master上新建分支,不然后面上线时会上了别人未测试的代码。

【建议2】做好一个功能点就提交代码,避免意外事件导致代码丢失。和别人一起在同一分支开发时,尽早提交可以不用解决冲突, 把这事留给别人哈哈哈。

【建议3】解决冲突时如果不确定会不会处理不当,最好拉上之前写这段代码的同事一起看。

【建议4】上线合并到master后最好开发群通知一下,让其他开发同事尽早拉最新master代码合到自己的分支。

【建议5】跟建议4关联,开发周期较长,应及时将线上最新master合到当前正在开发的分支,避免最后上线前花时间解决大量冲突,同时尽早避免自己依赖的上游业务被修改而引发新的异常发生。

【建议6】不定期的code review。

【建议7】......................

6 总结

本文介绍了自己平时常用的git命令和一些常规操作、分支管理模式、项目上线规范、日常开发的建议等等,偏向基础,太难也写不出,只是记录自己平时的工作和一些想法。

作为一个git的新手,甚至还不知道git是什么,没什么大不了的,现在学学就好。

但如果你同时是一个开发团队的leader,还没有很好的git管理规范的话,那确实得认认真真去学一下了。

作者:悟空GoKu链接:https://juejin.im/post/5ec7859ae51d45788f0d6cd1

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。