阅读 3253

我在工作中是这样使用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 clone https://gitee.com/xxx/Test.git到本地后,在把项目导入idea中

3.2 查看分支 git branch

查看当前项目有哪些分支

3.3 检出代码 git checkout

拉取远程分支代码

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

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操作的。

如果是多人在同一分支开发的话,一般在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将暂存的代码更新到当前分支上。


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

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

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

4 多人开发合作模式

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

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

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

复杂点的多了功能分支featurebug修改分支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】不用提交本地文件或者一些带有个人配置的文件,如.idea文件夹里的文件。配置文件中ip最好是127.0.0.1,这样提交时所有人本地都能用,各种中间件的账号密码也可以统一,如果非要用自己的配置,那你就不要提交这些文件到Git上了,不然别人拉项目总有冲突!!!(强烈补充,深受其害)

6 总结

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

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

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

想要获取更完整的内容可参考廖雪峰老师的git教程

再推荐一个外国小姐姐写的git命令动图展示

咱们下期见吧!!!!

关注下面的标签,发现更多相似文章
评论