Git版本控制 备忘录

安装Git：

在Linux上安装Git: sudo apt-get install git

在windows上安装Git: 从https://git-for-windows.github.io下载，然后按默认设置安装，安装完成有，在Windows桌面空出右键，找到“Git Bash Here”, 蹦出一个类似命令行窗口的东西，说明Git安装成功！

创建版本库(版本库名取: learngit)命令组合：

• mkdir learngit     #创建一个普通文件夹
• cd learngit          #进入到新创建的普通文件夹
• pwd                   #查看当前路径, 返回值/users/michael/learngit, 证明当前所在位置为新建文件夹下
• git init                #git初始化所在文件夹/users/michael/learngit, 返回 Initialized empty Git repository in /users/michael/learngit/.git

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

添加文件到版本库步骤：

1. 把文件readme.txt拖入../learngit文件夹中。

2. 命令： git add readme.txt 用命令git add告诉Git，把文件添加到仓库：

3. 命令：git commit -m "wrote a readme file "  用命令git commit告诉Git，把文件提交到仓库：

查看版本库状态：

命令： git status

查看版本库的修改（在git status命令显示某个文件被修改过了，但还没有准备提交的修改时，可用以下命令查看文件修改的地方）：

命令： git diff 文件名.后缀

版本控制系统历史记录：

命令： git log  #返回commit id(版本回退需要这个值)， 时间，修改者等参数

命令： git log --pretty=oneline 一个记录精简成一行

版本回退：

命令: git reset --hard xxxx   #其中xxxx是commit id.

查看命令历史：

命令： git reflog

理解工作区、版本库、暂存区：

Git工作区: 就是已经被git初始化变成的仓库 ： ../learngit

Git版本库： 工作区中的隐藏目录.git就是Git的版本库

Git版本库里面有很东西，其中最重要的就是stage(暂存区)和Git自动创建的master(分支)，以及指向master的一个HEAD(指针).

把文件往Git版本库里添加的时候，是分两步执行的：

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

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

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

撤销修改:

申明： readme.txt是一个文件

命令： git checkout -- readme.txt

命令： git reset HEAD readme.txt

撤销，这里有一下几种情况：

1. readme.txt自修改后还没有被放到暂存区，现在，需要将工作区的readme.txt撤销修改，保持和分支一样；

　　用命令：

• • git checkout -- readme.txt
  • git status   # 使用git status查看结果发现，工作区和版本库是没有需要提交的修改。

2. readme.txt修改后，提交到了暂存区，但还未提交到分支。现在，需要将工作区的readme.txt撤销，保持和分支一样；

　　用命令：

• • git reset HEAD readme.txt  #使暂存区里面的修改撤销，保持和分支一样。
  • git status          #使用git status查看结果，可以发现工作区的readme.txt修改了，但是暂存区的修改已经撤销了。 此时，就回到了情况1了。要撤销工作区的修改，情况1已经说过了。

3. readme.txt修改后，提交到了暂存区，后readme.txt又作了修改，现在，需要第二次撤销第二次readme.txt的修改，暂存区保存第一次readme.txt的修改。

　　用命令：

• • git checkout -- readme.txt
  • git status  #使用git status查看结果，可以发现工作区的readme.txt第二次修改撤销了，保持了第一次的修改。暂存区也保存了第一次的修改。 此时，就回到了情况2了。要撤销工作区readme.txt第一次的修改，请回到情况2.

根据情况1和情况3，git checkout -- readme.txt，就是让这个文件回到最近一次git commit或git add时的状态。

删除文件： git rm

先做好删除文件的准备工作： 在Git工作区创建一个文件test.txt. 然后运行一下指令将文件提交到Git分支。

$ git add test.txt

$ git commit -m "Add test.txt"
[master 44ed136] Add test.txt
 file changed,  insertion(+)
create mode  test.txt

现在将工作区的test.txt文件删除，并查看Git状态

$ rm test.txt

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

deleted: test.txt

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

删除了工作区的test.txt文件，有两种情况。

情况1. 是真想删除。

情况2. 是误删。

情况1，需要将删除文件这个动作提交到暂存区，再提交到分支

$ git rm test.txt
rm 'test.txt'$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    test.txt

$ git commit -m "remove test.txt"
[master 857faa2] remove test.txt
  file changed,  deletion(-)
 delete mode  test.txt

情况2，需要撤销对工作区的删除动作

$ git checkout -- test.txt

$ git status
On branch master
nothing to commit, working tree clean

远程仓库：

GitHub这个神奇的网站，它提供Git仓库托管服务，只要注册一个GitHub账号，就可以免费获得Git远程仓库。

在看下去之前，请先注册GitHub账号。

由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

1. 创建SSH Key。 在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

然后一路回车，使用默认值即可。

如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

2. 登陆GitHub, 进入settings, 点“SSH and GPG keys”, 点“New SSH Key”

填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容, 然后点“Add SSH key”. 这样SSH key就算添加成功了。

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。

如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。这个方法我们后面会讲到的，相当简单，公司内部开发必备。

添加远程库： 

有两种方案：

1. 在GitHub创建一个仓库，然后把一个已有的本地仓库与之关联。这个方案是本地库建立在先。

2. 在GitHub创建一个仓库，然后克隆到本地。这个方案是一切从零开发。

方案1：

GitHub创建好空仓库时，会给你一个远程仓库的地址: git@github.com:xxxxx/learngit.git。然后回到本地的learngit仓库下运行命令：

$ git remote add origin git@github.com:xxxxx/learngit.git

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

下一步，就可以把本地库的所有内容推送到远程库上：

$ git push -u origin master
Counting objects: , done.
Delta compression using up to  threads.
Compressing objects: % (/), done.
Writing objects: % (/), 13.73 KiB, done.
Total  (delta ), reused  (delta )
To git@github.com:michaelliao/learngit.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

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

推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样。

本地和远程的关联已经建立，以后本地提交到远程，只要通过命令：

$ git push origin master

方案2：

GitHub上创建新的仓库，勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件。

远程库已经准备好了，下一步是用命令git clone克隆一个本地库：

$ git clone https://github.com/LouisU/learngit.git
Cloning into 'learngit'...
remote: Counting objects: , done.
remote: Compressing objects: % (/), done.
remote: Total  (delta ), reused  (delta ), pack-reused
Unpacking objects: % (/), done.
Checking connectivity... done.

如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。

理解HEAD和分支：

在版本回退里，你已经知道，每次提交，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 branch dev   #创建一个分支, 分支名叫dev

$ git checkout dev  #切换到分支dev，使分支dev为当前分支，即HEAD指向dev

$ git checkout -b dev    # 创建一个分支dev，并使HEAD指向dev

$ git branch  # 查询当前分支
* dev            # git branch命令会列出所有分支，当前分支前面会标一个*号
  master  

$ git merge dev  # 把dev分支的工作成功合并到master分支上。 这是fast forward“快进模式”，直接把master指向dev的当前提交，合并速度非常快

$ git branch -d dev  # 删除dev分支

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

分支策略：

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

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

所以，团队合作的分支看起来就像这样：

# 用以下命令查看分支变化和分支合并。

$ git log --graph --pretty=oneline --abbrev-commit
*   f95cd82 merged bug fix
|\
| * 5e21af4 fix bug-
|/
* 8f36a18 branch test
* 66f3c2d change readme.txt again
* d7f7ff8 modified readme.txt
* a5ad9ad modified readme, git add, modified readme again, git commit
* b470b5a append GPL
* 397ea3f add distributed
* 8cba8b1 Add file1.txt into git
* 9ed2238 wrote a readme file

Windows特别注意：

千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可：