谈: git rebase / merge, checkout / reset.

1,033 阅读3分钟

前言

Git这个工具在我们当下的工作中密不可分,由此也衍生出了很多可视化工具(sourceTree,小乌龟 ...),用来帮助我们更加简单的操作本地与远程代码仓库.但这种方式其实比较僵硬,还是自己敲git 命令更能感觉到一切仅在掌控之中.除了平常的一些操作,本文记录几个起初开始工作不怎么使用的命令.

标签

在我日常开发中, 每次上线版本会去打tag.这样子不仅可以用来区分每次上线的版本,也可以随时回滚.(填绩效的时候方便查日志...)

git tag

$ git tag -a v1.0 -m "version 1.0"
$ git push origin v1.0 // 如果远程有这个名字的分支,那么会push失败. 注意这个不能重复.

是的,很简单.只需要在上线的时候添加就行了.我们在查看历史版本可以直接执行git tag.一目了然有没有.如果要回滚代码的话:

$ git checkout  v1.0  // 直接切回上一个版本

合并

我们的代码仓库主分支肯定只有一个,那多人合作开发就会涉及到合并的操作,把自己开发的代码合并到主分支上.那这里涉及到两个操作git rebasegit merge.

git rebase

$ git:(master) git rebase develop 

git rebase翻译过来是变基.那他合并的策略也是这样.比如我们要把master分支上的别的同事提交代码合并到我们自己的分支,那rebase会首先把我们分支上的代码存在.git/rebase目录下,然后再拉去master上的代码(改变基底),然后再把我们之前的代码合并到我们的分支上.(可能有点绕,多想一下.) 在开发中我们还会使用git rebase,来操作当前commit,用来合并多个commit为一个,这样利于提交记录清晰,便于阅读与管理.

git merge

$ git:(master) git merge develop 

git merge的本意就是合并.那他合并的策略也是这样.比如我们要把master分支上的别的同事提交代码合并到我们自己的分支,那就会直接把两者合并. 它们两个的区别,首先都可以达到代码合并的目的,但是直接区别就是合并的策略不同,git rebase比较条理,谁的分支是谁的生命线.git merge合并之后会永远以主分支为准.这边用一张图来说明一下:

WechatIMG139.jpeg 从图上直接可以看出来两者的关系.如果碰到代码冲突的话,使用git rebase也可以在解决完冲突之后,执行continue继续合并.

回滚

代码提交到远程突然想到有问题,项目上线碰到问题等等这些,都需要做回滚操作.

git reset

git reset [--hard | --mixed | --soft] [<commit>] 

--hard 会改变版本库的HEAD引用指向,缓存区/工作区的内容,执行后HEAD引用会指向commit指向的版本.缓存区/工作区内容都会被替换

--mixed 使用这个参数,工作区代码不会刷新,HEAD的引用指向会被改变,缓存区内容也会更新

--soft 只会改变HEAD引用的指向

git checkout

checkout 一般用来切换分支,也可以回滚代码.

git checkout branchName

checkout 回滚的话,它改变的是HEAD引用的指向,需要注意的是工作区的内容会更新.

大概意思就是下图这样:

WechatIMG141.jpeg

总结

文中提到的这些git的指令与工作息息相关,开始使用可能会碰到一些问题.但多操作 多使用,慢慢就会掌握.毕竟git就其他技术来说还是相对更新较慢的.

加油.