首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

几个让你对Git顿悟的例子

在gitlab QQ群,时常见到的问题就是git初学者以SVN为基准来问问题,为什么git不支持XXX,svn都支持了。这个功能git应该怎么做?而最基本的git命令都懒得看。每当这时候,虫虫都会很不耐烦好气地告诉他:"直接用SVN好了,git不支持"。很多人来git只是为了因为git流行热门,或者他的领导让他来用git。他自己对git知之甚少,他最常做的事情就是要给领导出一个实时备份、高可用的gitlab架构等问题。

关于git基础相关,虫虫也写了《Git初步,理清基本的git(github)流程》,《git分支概念和分支相关操作》,《Git鲜为人知的四个命令:bisect,blame,reflog和提交范围》等文章,大家可以参考阅读。本文虫虫以几个例子,让你顿悟,说明下git的真正的做事的方式—— "Thinking in Git",纠正一下长期svn使用后遗留下的思维方式,和git完全不一样的方式。

1. 本地和远程仓更改不需要有关系。

在使用svn的时候,很多人习惯使用"svn status -u"来查看如果我运行svn update会发生什么变化。很多人以为git也是这样,想知道git中对应的操作。你告诉他使用"git status" 。这个命令会列出,你最近一次Pull操作之后本地的变化。要查看服务器上的更改,我们首先需要执行"git fetch"。

对git来说本地仓和远程仓实际上是两套独立变化的,本地变化和服务器上的变化(可以被其他人push变化),要分开看,你无需考虑太多他们之间的差异,你只需Pull合并远方变化,并把本地变化push就ok。

2.合并版本是让老的commit可用。

我们这儿说合并只是让某些代码变化(commit)可用。很多人认为,合并不过是把分支的变动变为主分支的commit,这个认识是片面的有问题的,实际上合并是让某分支的commit被其分支可见(用)。例如,通过git log查看一个文件的变化,可以显示交错的两个不同分支的提交,两个提交之间的差异(时间上相邻,但在两个不同的分支上),可能变化非常大。

3.合并提交的含义

对于初学者git合并可能很难理解,他们时常关注到合并的细枝末节,比如为什么要三方合并?。在理解git合并时候不能用 "这个commit文件变化差异",从文件差异,代码变化来看,合并提交并没有任何的变化。而要记住git合并提交是为了获得其他分支提交的内容,这些内容(分支commit)是通过合并来变得可读(用)。

4.合并是双向的

如果有一个长期运行的分支Dev,你最终会想将它合并到master中,则你可以通过定期将master合并到Dev中(并修复其中的冲突)来一次解决合并冲突问题。最终目的是将Dev中的所有更改合并到master中,但这只能在Dev按预期完成时才行。如果一直独立Dev分支的话,可能会导致其严重落后于主分支,这样最终合并时候将会是个噩梦。由于合并是双向的,我们不必等到Dev完成之后才最终合并。而通过定期将master合并到Dev,这样最终从Dev并到主分支时,冲突已经没有多少了。

5.如果合并失败,你可以重新开始。

在svn中,很多人经常要使用"-dry-run"来查看执行某个操作会发生什么(但实际上没有这样做)。在git中,所以转到git后他们也想要git也这样做,但是我告诉他们这实际一点意义都没有,git也没有这样的操作。但是git特性,使得所有操作根本无需考虑后果,反正总能找回来。例如,要合并了一些更改,但是合并时你搞乱了,怎么办?No problem!,reset反悔一下就行。执行"git reset -hard HEAD~",就反悔了。现在你可以继续合并,你可以这样随便做,就像vim中的对编辑redo一样,无任何限制,直到你搞好,期间你不怕搞乱,不怕搞错。

6.提交的更改可以重新设置为本地更改。

有时候我们正在一个分支做修改(比如Temp分支),但是需要跳转到另一个分支并对其做修改。有些人习惯于用stash暂存当前变化。但是更好的做法是提交一个commit,并注明其代码状态。只是,不要将其push到远程仓。当我们回到分支Temp时,只需"git reset HEAD ~"来重新获到之前提交的变化,这样我们就能迅速的回到之前的工作状态(代码行)。

Think in Git

不管理你阅读了多少git使用的教程,以及如何组织git方法。但是如果你不能迅速转化到git 思维方式的话,那你永远体会不到git真正的好处在哪里,也不能让git的这些优势给你带来生产力的提高。我还是我在群里给新手建议的观点,如果你不能做到"Think in git"的话,一定不要与svn做对比,按照svn思维的话,那你还是用svn好了!如果你的领导不能理解"Think in git",你也不要给他推荐git,因为他会给你提出很多svn思维式的,你用git更本无法满足的问题。(实际上git中根本不用考虑这些问题,所以也就不必要满足)。

在本文中虫虫举了几个例子帮你顿悟git,think in git,我坚信git可以给代理生产力的飞速提高,但是首先你要"Think in git"。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180626A05QIE00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券