一小时学会git使用

##安装git

  • mac 安装 brew install git
  • centos 安装 yum install git
  • Ubuntu/Debian 安装 apt-get install git

##创建版本库

  • 初始化一个Git仓库,使用git init命令。
  • 添加文件到Git仓库,分两步:
    • 使用命令git add ,注意,可反复多次使用,添加多个文件;
    • 使用命令git commit -m ,完成。

瞬间Git就把仓库建好了,而且告诉你是一个空的仓库(empty Git repository),细心的读者可以发现当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。

如果你没有看到.git目录,那是因为这个目录默认是隐藏的,用ls -ah命令就可以看见

git init
git add .
git commit -m "message"

##时光机穿梭
git status命令可以让我们时刻掌握仓库当前的状态,上面的命令输出告诉我们,readme.txt被修改过了,但还没有准备提交的修改。

虽然Git告诉我们readme.txt被修改了,但如果能看看具体修改了什么内容,自然是很好的。比如你休假两周从国外回来,第一天上班时,已经记不清上次怎么修改的readme.txt,所以,需要用git diff这个命令看看

git status
git diff (file)

###版本回退

穿梭前,用git log可以查看提交历史,以便确定要回退到哪个版本。

HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id

要重返未来,用git reflog查看命令历史,以便确定要回到未来的哪个版本。

git log
git log --pretty=oneline
git reset --hard HEAD^
git reflog
git reset --hard 89403111f6a249a24ca1daac3d841072b9233582

###工作区和暂存区
工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。

Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。

我们把文件往Git版本库里添加的时候,是分两步执行的:

第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;

第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。

你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。

###管理修改

Git管理的是修改,而不是文件

git commit只负责把暂存区的修改提交,修改1,git add 修改2 ,git commit ,如果修改后没有git add ,那么第二次修改的内容没有提交。

用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别

每次修改,如果不用git add到暂存区,那就不会加入到commit中

###撤销修改

git checkout -- readme.txt 可以丢弃工作区的修改

一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;

一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。

总之,就是让这个文件回到最近一次git commit或git add时的状态。

git checkout -- file命令中的--很重要,没有--,就变成了“切换到另一个分支”的命令

用命令git reset HEAD 可以把暂存区的修改撤销掉(unstage),重新放回工作区

git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。

场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file。

场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD ,就回到了场景1,第二步按场景1操作。

场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退(git reset --hard HEAD^),不过前提是没有推送到远程库。

###删除文件

确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit

另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本

git checkout -- file

git checkout其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”

注意:从来没有被添加到版本库就被删除的文件,是无法恢复的!

命令git rm用于删除一个文件。如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容。

##远程仓库

###添加远程库

github上创建一个仓库
git remote add origin 仓库地址,origin这个名字一看就知道是远程库

把本地库的所有内容推送到远程库上 git push -u origin master

我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令

ssh连接 略 参考

###从远程库克隆

git clone git@github.com:weikeu/gitskills.git

还可以用https://github.com/weikeu/gitskills.git这样的地址。实际上,Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。

但ssh协议速度最快

clone分支 git clone -b v1.1 url链接

##分支管理

###创建与合并分支

每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。

一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点

每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。

当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上

Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化!

不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变

假如我们在dev上的工作完成了,就可以把dev合并到master上。Git怎么合并呢?最简单的方法,就是直接把master指向dev的当前提交,就完成了合并

所以Git合并分支也很快!就改改指针,工作区内容也不变!

合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支

创建分支 git checkout -b dev

git checkout命令加上-b参数表示创建并切换,相当于以下两条命令

git branch dev

git checkout dev

查看当前分支 git branch

git branch命令会列出所有分支,当前分支前面会标一个*号

修改dev分支并提交后,推上远程 git push -u origin dev

切回master分支 git checkout master

把dev分支的工作成果合并到master分支上 git merge dev

Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。

合并完成后,就可以放心地删除dev分支 git branch -d dev

###解决冲突

分别在dev和master分支修改文件并提交,然后 merge

git merge dev

存在冲突,必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件

Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容

用带参数的git log也可以看到分支的合并情况

git log --graph --pretty=oneline --abbrev-commit

当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。

用git log --graph命令可以看到分支合并图

###分支管理策略

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。

如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。

git merge --no-ff -m "merge with no-ff" dev

准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward

再用git log 查看是否有commit信息

不在master分支上干活

###Bug分支

Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作

git stash储藏

git status 查看工作区 已干净

创建bug分支 修改bug并提交

切换master分支

git merge --no-ff -m "merged bug fix 01" issue-01

回到dev分支 git status 查看工作区 干净

git stash list 查看工作现场

git stash apply stash@{0}恢复,再git stash drop删除

或者 恢复并删除 git stash pop

在master分支上修复了bug后,我们要想一想,dev分支是早期从master分支分出来的,所以,这个bug其实在当前dev分支上也存在。

要在dev上修复,我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意:我们只想复制4c805e2 fix bug 101这个提交所做的修改,并不是把整个master分支merge过来

git cherry-pick commit_id Git自动给dev分支做了一次提交

直接在dev分支上修复bug,然后在master分支上“重放”行不行?当然可以,不过你仍然需要git stash命令保存现场,才能从dev分支切换到master分支。

###Feature分支

feature分支和bug分支是类似的,合并,然后删除。

但是!

就在此时,接到上级命令,因经费不足,新功能必须取消!

虽然白干了,但是这个包含机密资料的分支还是必须就地销毁:

git branch -d feature-vulcan

销毁失败。Git友情提醒,feature-vulcan分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用大写的-D参

git branch -D feature-vulcan

开发一个新feature,最好新建一个分支;

如果要丢弃一个没有被合并过的分支,可以通过git branch -D 强行删除。

###多人协作

要查看远程库的信息,用git remote

用git remote -v显示更详细的信息

####推送分支

就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:

git push origin master

master分支是主分支,因此要时刻与远程同步;

dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;

bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;

feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。

####抓取分支

小伙伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,于是他用这个命令创建本地dev分支

git checkout -b dev origin/dev

git push origin dev

git pull失败,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接

git branch --set-upstream-to=origin/dev dev

多人协作的工作模式通常是这样:

首先,可以试图用git push origin 推送自己的修改;

如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;

如果合并有冲突,则解决冲突,并在本地提交;

没有冲突或者解决掉冲突后,再用git push origin 推送就能成功!

如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,

用命令git branch --set-upstream-to origin/

这就是多人协作的工作模式,一旦熟悉了,就非常简单。

查看远程库信息,使用git remote -v;

本地新建的分支如果不推送到远程,对其他人就是不可见的;

从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;

在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;

建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name;

从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。