Git使用心得

2019-02-18  本文已影响0人  千载不变灬

之前的项目一直在使用SVN管理项目代码,协同开发的场景较少,SVN也用着也还过得去。切到新项目后,都改为了Git管理项目库。

刚从Svn切过来的时候感觉不适应,搞不懂分支,本地库,fork仓的概念,也不知道如何更好的使用Git的特性来进行多个需求和问题的并行开发。经常会遇到各种问题。现在就把一些自己理解的概念和使用场景记录下。

Git在使用时大致是有3个层级:本地仓库,远程个人fork仓库,远程origin仓库。

在这里可能很多人没有个人fork仓,直接是提交代码至origin上的分支来进行提交代码。没关系,这两者不冲突,只是使用了不同的管理方式。

所以在提交代码时,也就有以下两种路径方式:

(1)修改代码->commit到本地:xxx分支->push到origin:yyy分支->提mr合入至origin:master;

(2)修改代码->commit到本地:xxx分支->push到远程个人fork仓:yyy分支->提mr合入至origin:master;

 按照我个人使用理解,公司内的项目,可以直接使用第一种方式,省略fork的步骤。因为不对外公开源码,即使基于origin创建多个分支,导致origin分支众多,也没有太大关系。但是开源项目就不允许这么做,否则会导致origin仓库分支太杂太乱,不易于管理,只有被管理员和其它commiter认可的人才有资格操作origin仓的分支。

新项目的人以前都是搞开源项目的,因此使用时都会把origin仓fork到个人仓,也就是上面(2)的方式。

下面记录下自己在用fork仓时,主要侧重写一些使用场景的理解,命令的基本使用方法:

1.git clone ssh://xxx.xxx.com:2222/xxx.git(针对的是远程仓库)

用来下载远程仓库,可以下载origin也可以下载个人fork仓,在当前目录形成git本地仓库及该目录的本地仓master分支。

2.git remote(针对的是远程仓库)

当使用git clone下载代码后,本地仓库上显示clone下来的远程仓库名称默认为origin。

我在开发过程中,先会用git clone把自己的fork仓down下来。然后再使用git remote命令把master仓也关联到这个本地仓库。这样可以灵活的pull和push到这两个仓库中。

git remote -v //查看远程仓库详情

git remote remove test //删除远程仓库

git remote rename {oldname} {newname} //重命名

git remote add {仓库名} git地址 //关联远程仓库到本地仓库,名称可以自定义

3.git fetch(针对的是远程仓库的具体分支)

git fetch origin master:tmp //从名为origin远程仓库,下载master分支代码到本地仓库的tmp分支

如果对origin进行了fork,使用remote命令关联到本地仓库,并且名称为zhangsan。那可以继续使用fetch命令下载zhangsan的分支代码到本地仓库。例如:

git fetch zhangsan master:fork_tmp //从名为zhangsan 远程仓库,下载master分支代码到本地仓库的fork_tmp分支

4.git reset --hard {tag} //强制回退代码至tag标签(针对的是本地仓库的当前checkout的分支)

5.git rebase {目标分支} //变基操作,将{目标分支}的commit log强行同步给当前checkout的分支。主要是为了解决当前分支commit log和准备pull代码的远端仓库log不一致的问题,log不一致则会导致冲突问题。

git使用时遇到困扰我多次的一个问题

在这里重点记录下这个问题,自己遇到了三次,每次都花了很大的力气去解决。现在把问题解决的规避方案和根本原因记录下。

问题出现时的仓库情况:

本地仓库关联的远程分支有两个,一个是master仓库(名称为origin),一个是fork了master的个人仓库(名称为zhangsan)。

本地仓库checkout的是master。本地代码已经修改完毕。zhangsan的代码和master的代码已经同步至一样。

所做的操作:

(1)commit代码到本地仓库分支,push代码至zhangsan:bugxxx分支;

(2)在zhangsan仓库的页面上,将bugxxx的代码提mr至master;

(3)管理员将代码合入master。

到现在为止,所有都是正常的。然后我发现代码没有修改完全,需要继续修改代码,然后再mr至master。

这时候我按照以前svn的思路,我认为可以直接从master仓库pull代码到本地仓库,因为不管别人有没有合入的东西,至少我跟origin:master的代码是一致的,我pull代码下来,应该是没有问题的。

但实际上,我pull代码下来的时候,已经变成了冲突,需要merge处理代码。但此时我无论如何merge,一直没有达到我预期的效果:本地仓库和master仓库一致。除非reset回退、rebase新的master本地仓库或者重新clone代码下来。

这到底是为什么呢?

其实问题就出在上面第三步中,第三步管理员其实没有直接同意我的mr,而是close我的mr。管理员在自己本地仓库pull了zhangsan:bugxxx分支的代码,再push到了master。所以我本地仓库代码虽然和master代码是一致的,但是commit id是不同的。因此我将master的代码pull到本地仓库的时候就提醒了代码冲突。

如何规避:

解决问题的办法就是先将本地修改的代码stash一把(如果有的话),然后将origin:master分支fetch至local_master,然后将当前开发分支rebase至local_master。这样commit log就一致了,再unstash代码下来。千万不能reset回退或者clone代码下来,因为reset会导致你本地修改代码丢失,重新clone会导致stash数据丢失。

根本解决方法:

其实造成这个问题的根本原因还是对Git的不了解,不知道如何使用它完成多特性开发。

我所有的操作都是在local:master上完成的,我本地只用了这一个分支来开发,完成提交、同步等的操作,不仅工作是串行的,而且容易就会造成commit log不一致的问题。

正确的做法是local:master只用来pull代码。如果遇到要开发特性的情况,则直接git checkout -b {新分支}。在新分支上开发完毕,提交代码。此时再切回local:master,pull代码也不会报错,因为一直与origin:master的commit log是同步的。

上一篇下一篇

猜你喜欢

热点阅读