Git的常用基本操作

创建版本仓库

Bash

$ mkdir mygit
$ cd mygit
mygit$ pwd
/Users/zhouweiwei/mygit

通过git init命令把这个目录变成Git可以管理的仓库：

Bash

mygit$ git init
Initialized empty Git repository in /Users/zhouweiwei/mygit/.git/

目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。如果要真正使用版本控制系统，就要以纯文本方式编写文件。

三、添加一个文件

第一步，用命令git add告诉Git，把文件添加到仓库：

Bash

mygit$touch read.txt
mygit$git add read.txt

第二步，用命令git commit告诉Git，把文件提交到仓库：

Bash

mygit$git commit -m "wrote a txt file"
[master 6899a3b] wrote a txt file
 1 file changed, 1 insertion(+)
 create mode 100644 read.txt

add支持一次添加多个文件（git add -A）后，commit支持一次提交所有add的文件。

git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

四、查看结果

git status命令可以让我们时刻掌握仓库当前的状态，如无变化或有修改

Bash

mygit$vim read.txt
mygit$git status
On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   read.txt

no changes added to commit (use "git add" and/or "git commit -a")

mygit$git diff read.txt

五、提交修改

Bash

mygit$git add read.txt
mygit$git status
On branch master
Changes to be committed:
  (use "git reset HEAD ..." to unstage)

modified:   read.txt

mygit$git commit -m "modify read"
[master 871ed58] modify read
 1 file changed, 1 insertion(+), 1 deletion(-)
 
mygit$git status
On branch master
nothing to commit, working tree clean

六、查看提交日志

Bash

mygit$git log

显示从最近到最远的提交日志，如果退出查看日志，敲键盘 q

查看简单日志信息：

Bash

mygit$git log --pretty=oneline
871ed587ca6af9f45f07e88dfdb34db3f088c008 (HEAD -> master) modify read
6899a3b7be98eb0ca635bc768bacb7601cacbcb2 wrote a txt file

七、回退到上一个版本

Bash

mygit$git reset --hard HEAD^
HEAD is now at 6899a3b wrote a txt file

如果此时后悔了，不想回退：

Bash

mygit$git reset --hard 871ed587c
HEAD is now at 871ed58 modify read

mygit$git log

当你回退版本的时候，Git仅仅是把HEAD从指向版本的commit id

八、查看每次的命令记录

Bash

mygit$git reflog
871ed58 (HEAD -> master) HEAD@{0}: reset: moving to 871ed587c
6899a3b HEAD@{1}: reset: moving to HEAD^
871ed58 (HEAD -> master) HEAD@{2}: commit: modify read
6899a3b HEAD@{3}: commit: wrote a txt file

第一次修改 -> git add -> 第二次修改 -> git commit

实际只提交第一次的修改，如果要一起提交，如下：

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

九、丢弃工作区的修改

Bash

mygit$git checkout -- read.txt

意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

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

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

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

十、丢弃缓存区的修改

Bash

mygit$git reset HEAD read.txt

还没推送远程版本库，提交本地版本库的修改：git reset HEAD

十一、从仓库中删除文件

Bash

mygit$rm read.txt
mygit$git status
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

deleted:    read.txt

no changes added to commit (use "git add" and/or "git commit -a")

mygit$git rm read.txt
rm 'read.txt'

mygit$git commit -m "remove read.txt"
[master c937ac8] remove read.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 read.txt

因为误删想要还原：

Bash

mygit$git checkout -- read.txt
error: pathspec 'read.txt' did not match any file(s) known to git.

mygit$git reset --hard 871ed58
HEAD is now at 871ed58 modify read

十二、创建远程仓库（略）

https://github.com

从远程仓库克隆一个本地仓库：

Bash

mygit$mkdir remot
mygit$cd remot

remot$git clone [e-mail]:aihuman/hiapi.git
Cloning into 'hiapi'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

十三、分支管理

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

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

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

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

假如我们在dev上的工作完成了，就可以把dev合并到master上。

Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并

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

Bash

mygit$git checkout -b dev
Switched to a new branch 'dev'

相当于：

Bash

mygit$git branch dev
mygit$git checkout dev
Already on 'dev'

修改dev分支，合并到master分支，最后删除dev分支

Bash

mygit$git branch
* dev
  master
mygit$vim read.txt
mygit$git add read.txt
mygit$git commit -m "dev 001"
[dev 9c22b66] dev 001
 1 file changed, 1 insertion(+), 1 deletion(-)
 
mygit$git checkout master
Switched to branch 'master'

mygit$cat read.txt
222111
mygit$git checkout dev
Switched to branch 'dev'

mygit$cat read.txt
333222111

mygit$git merge dev
Already up to date.

mygit$git checkout master
Switched to branch 'master'

mygit$cat read.txt 
222111

mygit$git merge dev
Updating 871ed58..9c22b66
Fast-forward
 read.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
mygit$cat read.txt
333222111
mygit$git branch -d dev
Deleted branch dev (was 9c22b66).
mygit$git branch
* master

远程提交新的分支和远程拉取新分支

Bash

git push --set-upstream origin dev1
git checkout -b dev1 origin/dev1

十四、解决冲突

在同一个节点后，master分支和dev分支都有新的提交，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。

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

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

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

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

Bash

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

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

十五、临时修复bug

工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

Bash

mygit$git stash
mygit$git checkout master
mygit$git checkout -b bug-101

修复完成后，切换到master分支，并完成合并，最后删除bug-101分支

Bash

mygit$git stash list
mygit$git checkout dev
mygit$git status

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

Bash

mygit$git stash pop
mygit$git stash list

多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

Bash

mygit$git stash apply stash@{0}

删除stash（全清 or 清除部分）

mygit$git stash clear #清空所有内容

mygit$git stash drop stash@{0} #删除第一个队列

十六、远程库

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

Bash

mygit$git remote
mygit$git remote -v

十七、推送分支

Bash

mygit$git push origin master
mygit$git push origin dev

并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

master分支 是主分支，因此要时刻与远程同步；

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

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

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

十八、多人合作

如果A同学在dev分支修改并提交一些内容，B同学对相同文件也做了修改，试图推送失败，应先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送

Bash

mygit$git branch --set-upstream-to=origin/dev dev
mygit$git pull

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

1、首先，可以试图用git push origin 推送自己的修改；

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

3、如果合并有冲突，则解决冲突，并在本地提交；

4、没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to origin/。

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

十九、标签管理

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e...”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

标签操作

Bash

mygit$git branch
mygit$git checkout master
mygit$git tag v1.0

mygit$git tag
v1.0
mygit$git tag v0.9 f52c633
mygit$git tag
v0.9
v1.0

mygit$git show v0.9
mygit$git push origin v1.0
mygit$git push origin --tags
mygit$git tag -d v0.9
mygit$git push origin :refs/tags/v0.9 #删除远程标签
mygit$git tag -d v0.1

更新远程 tag

Bash

git tag -l | xargs git tag -d
git fetch --tags
git tag

二十、补充

commit虽然可以cherry pick到其它分支上去，但是在新分支上对应的id也会发生变化

注意：
1. 分支上的代码是随时可变的 ===》定位代码和分布都不能用分支，
2. commitid和tag都是固定的，它们代表的代码是不可变的 ===》可以用于定位代码、发布 ===》其中tag能明确指出版本号或是描述发布信息，所以用tag

审核编辑：彭静