git操作

https://www.liaoxuefeng.com/wiki/896043488029600 

Git 分布式版本控制系统

先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。

那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

git基础命令

添加用户名和邮箱

 $ git config --global user.name "rw"

 $ git config --global user.email "553@qq.com"   配置用户名和邮箱名

注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

用cd进入git仓库目录

$ mkdir learngit
$ cd learngit
$ pwd //显示当前目录
/Users/michael/learngitcd
在我的文档中 创建了一个空目录
$ git init //此命令初始化!一个新本地仓库，它在工作目录下生成一个名为.git的隐藏文件夹。

 

把文件添加到仓库  git add

$ git add readme.txt(任意文件名都行)

把文件提交到仓库用命令 git commit

$ git commit -m "wrote a readme file"

会提示 

[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；2 insertions：插入了两行内容（readme.txt有两行内容）。 deletions 删除了几行

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

$ git add file1.txt

$ git add file2.txt file3.txt

$ git commit -m "add 3 files."

查看仓库当前状态  git status 

比如修改了readme.text内容 再运行 git status代码 会提示如下

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

    modified:   readme.txt

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

 

上面的命令告诉我们 readme.text被修改了。但是还没准备的提交

查看修改内容 git diff

git diff 就是查看difference 如果输入git diff 我们可以看到

$ git diff readme.txt 
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.  //这里提示了添加了什么 减少了什么

 

知道了修改了什么东西后 我们可以再git add 和 git commit 提交代码到仓库，再git add 之后 我们不放心的话 

可以再运行 git status 查看仓库状态

$ git status
On branch master
Changes to be committed://要提交的更改
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme.txt   //修改的文件

 

觉得没问题了。再git commit -m ""

cat 将文件内容显示打印

git cat readme.txt

git时光机

再不断对文件进行修改，再不断提交到版本库里后，git会帮你快照保存。称为commit 一旦把文件误删了，改乱了。可以从最近的一个commit恢复 然后继续工作

显示从最近到最远的提交日志 git log

可以看到3次提交

$ git log 
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 21:06:15 2018 +0800

    append GPL  //这里的值是git commit -m" " -m后面输入的内容

commit e475afc93c209a690c39c13a46716e8fa000c366
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 21:03:36 2018 +0800

    add distributed  //一样 -m内容

commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao <askxuefeng@gmail.com>
Date:   Fri May 18 20:59:18 2018 +0800

 wrote a readme file  //一样  -m内容

 

嫌输出信息太多 可以加上 --pretty=oneline 参数 

$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed  
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file

//-m前面的一大串数字是16进制的数字，可视化工具查看git历史，可以查看到提交历史时间线。

 

还原版本git reset

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交1094adb...（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

现在，我们要把当前版本回退到上一个版本，就可以使用git reset命令：

$ git reset --hard HEAD^   //退回上一个版本
HEAD is now at e475afc add distributed //上一个版本的-m内容

 

使用了还原版本后，这个版本之后的用git log 就看不到了

如果想回到使用还原版本之前的代码。需要趁着命令行还没关 找到那个append GPL的commit id是1094adb...，于是就可以指定回到未来的某个版本

$ git reset --hard 1094a 把HEAD改成指定commit id

HEAD指针

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：

┌────┐
│HEAD│
└────┘
   │
   └──> ○ append GPL
        │
        ○ add distributed
        │
        ○ wrote a readme file

改为指向add distributed：

┌────┐
│HEAD│
└────┘
   │
   │    ○ append GPL
   │    │
   └──> ○ add distributed
        │
        ○ wrote a readme file

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？

在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

git reflog

查看命令历史 以确定回到未来哪个版本

工作区

就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

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

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

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

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

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

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

总的来说就是，文件在工作区编写修改完后。git add到了暂存区 ，然后暂存区文件多了 git commit 一次性提交

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：

Git跟踪并管理的是修改，而非文件。

我们回顾一下操作过程：

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

你看，我们前面讲了，Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

查看工作区与版本库里面最新版本区别

git diff HEAD --file名

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

丢弃工作区修改

git checkout --file名

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

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

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

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

修改暂存区

git reset HEAD file名

再没被commit 提交前 用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区

如果添加到了版本库，可以通过版本回退。前提是没被推送到远程版本库。如果推送了。那大家都能看到

删除文件

git rm file <filename> 同时从工作区和索引中删除文件。即本地的文件也被删除了。

git rm --cached <filename> 从索引中删除文件。但是本地文件还存在， 只是不希望这个文件被版本控制。

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

远程仓库

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。

实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

公钥 私钥

第一步、创建SSH Key  看看本地电脑用户主目录下有没有.ssh目录，如果有 看看目录下有没有 id_rsa 和id_rsa.pub这两个文件

如果有 就直接下一步，没有就打开git bash 创建SSH key

$ ssh-keygen -t rsa -C "你的邮箱地址"

 

然后一路回车 使用默认设置 无需设置密码

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

第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：

然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：

填上任意title 在key本文框 粘贴 id_rsa.pub内容，
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

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

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

现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。

github创建新仓库

首先，登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库：

在Repository name填入learngit，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：

目前，在GitHub上的这个learngit仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。

现在，我们根据GitHub的提示，在本地的learngit仓库下运行命令：

添加远程库

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

$ git remote add origin git@github.com:这里填github用户名/learngit.git

然后把本地库所有内容推送到远程库

$ git push -u origin master

扩展

git push显示错误 Connection closed by remote host ，可能是网络被劫持 可以通过添加host修改 192.30.253.112 github.com

 

git push 命令  推送

把当前分支master推送到远程，第一次推送加上了-U参数。Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！

从远程库克隆

git clone 

知道库名和github账号后 

$ git clone git@github.com:github账号名/库名.git

 

你也许还注意到，GitHub给出的地址不止一个，还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。

使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

分支管理

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

创建和合并分支

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  创建分支 git branch 分支名  切换分支 git checkout 分支名或者 git switch 分支名

创建+切换分支 git checkout -b 分支名 或者 git switch -c  分支名 合并某分支到当前分支  git merge 分支名

删除分支 git branch -d分支名

解决冲突

当分支跟主分支分别修改了文件 而且还提交了。比如这样

 

 

 git 就无法快速合并了。只能试图把各自的修改合并起来。但是可能会有冲突，如果报错了就要手动解决冲突

git status 会告诉我们冲突的文件 直接查看冲突的文件。git会用 <<<<<< =====>>>>>>来标记不同分支内容

比如 

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

 

手动修改完，再提交。分支图会变成

 

之后就可以删除 feature分支了

分支管理策略

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

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

比如 git merge --no-ff dev 再commit提交后 用git log 可以看出来谁做过合并，而fast forward看不出谁做了合并

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

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

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

 

bug修复

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场 git stash一下，然后去修复bug，修复后，

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

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

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

Feature 分支

开发一个新功能，最好新建一个分支，如果要丢弃一个没有被合并的分支 可以通过git branch -D 分支名强行删除

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

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

更详细的 git remote -v 

origin  git@github.com:rw1397/learngit.git (fetch) 抓取
origin  git@github.com:rw1397/learngit.git (push)  推送

 

推送分支

git push origin master  也可以换成其他分支 比如dev git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；要推送哪个分支是看你工作需要

抓取分支

如果你换了台电脑，或者在另一个目录下克隆远程库 只能看到本地的master分支，要在其他分支修改的话

就要创建origin的dev到本地  

$ git checkout -b dev origin/dev

 

这样就可以继续在dev上修改 是不是把dev分push到远程

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

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

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

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

创建标签

打标签 git tag tagname

首先切换到要打标签的分支上，然后git tag <name> 就可以打一个新标签  例

$ git tag v1.0

git tag 查看所有标签   

默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？

方法是找到历史提交的commit id，然后打上就可以了：

git log --pretty=oneline --abbrev-commit 查看最近的所有修改 在这里可以看到commit id 

知道commit id后 git tag v1.0 <填commit id>

标签不是按时间排序的，而且按字母排序的

带说明标签

带说明标签 git tag -a v0.8 -m"fix bug" <填commit id>   git show <tagname>可以看到说明文字

标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

标签操作

比如 git tag -d v1.0 

而且创建的标签只存储在本地，不会自动推动到远程，所以可以安全删除

推送标签到远程  git push origin <tagname>  一次性推送全部未推送到远程的本地标签 git push origin --tags

但是推送到远程后删除标签就比较麻烦 先要本地，再删远程it push origin :refs/tags/<tagname>

git操作

忽略文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件

不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

搭建 git 服务器

在远程仓库一节中，我们讲了远程仓库实际上和本地仓库没啥不同，纯粹为了7x24小时开机并交换大家的修改。

GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器作为私有仓库使用。

搭建Git服务器需要准备一台运行Linux的机器，强烈推荐用Ubuntu或Debian，这样，通过几条简单的apt命令就可以完成安装。

假设你已经有sudo权限的用户账号，下面，正式开始安装。

第一步，安装git：

$ sudo apt-get install git

第二步，创建一个git用户，用来运行git服务：

$ sudo adduser git

第三步，创建证书登录：

收集所有需要登录的用户的公钥，就是他们自己的id_rsa.pub文件，把所有公钥导入到/home/git/.ssh/authorized_keys文件里，一行一个。

第四步，初始化Git仓库：

先选定一个目录作为Git仓库，假定是/srv/sample.git，在/srv目录下输入命令：

$ sudo git init --bare sample.git

Git就会创建一个裸仓库，裸仓库没有工作区，因为服务器上的Git仓库纯粹是为了共享，所以不让用户直接登录到服务器上去改工作区，并且服务器上的Git仓库通常都以.git结尾。然后，把owner改为git：

$ sudo chown -R git:git sample.git

第五步，禁用shell登录：

出于安全考虑，第二步创建的git用户不允许登录shell，这可以通过编辑/etc/passwd文件完成。找到类似下面的一行：

git:x:1001:1001:,,,:/home/git:/bin/bash

改为：

git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell

这样，git用户可以正常通过ssh使用git，但无法登录shell，因为我们为git用户指定的git-shell每次一登录就自动退出。

第六步，克隆远程仓库：

现在，可以通过git clone命令克隆远程仓库了，在各自的电脑上运行：

$ git clone git@server:/srv/sample.git
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.

剩下的推送就简单了。

管理公钥

如果团队很小，把每个人的公钥收集起来放到服务器的/home/git/.ssh/authorized_keys文件里就是可行的。如果团队有几百号人，就没法这么玩了，这时，可以用Gitosis来管理公钥。

这里我们不介绍怎么玩Gitosis了，几百号人的团队基本都在500强了，相信找个高水平的Linux管理员问题不大。

管理权限

有很多不但视源代码如生命，而且视员工为窃贼的公司，会在版本控制系统里设置一套完善的权限控制，每个人是否有读写权限会精确到每个分支甚至每个目录下。因为Git是为Linux源代码托管而开发的，所以Git也继承了开源社区的精神，不支持权限控制。不过，因为Git支持钩子（hook），所以，可以在服务器端编写一系列脚本来控制提交等操作，达到权限控制的目的。Gitolite就是这个工具。

这里我们也不介绍Gitolite了，不要把有限的生命浪费到权限斗争中。

个人总结重点

给git仓库添加邮箱和用户名  git config user.name "<name>"  git config user.email "<email>"

初始化一个新本地仓库  git init  文件添加到暂存区 git add <filename>  文件提交到分支 git commit -m "注释"

查看仓库状态 git status 查看修改内容 git diff   文件内容打印 git cat <filename>    查看最近三次提交 git log

查看完整提交缩写 git log --pretty==online -abbrev-commit   查看命令历史 git reflog

修改还原版本 git reset --hard HEAD^ 几个^退几步，多了就~ 比如~10 退10步   要退回指定的 就把HEAD改成commit id

丢弃工作区修改  git checkout --<filename> 在工作区 就恢复到版本库状态 在暂存区 就恢复到刚添加到暂存区状态

撤销暂存区，放回工作区 git reset HEAD <filename>  删除文件   git rm file 从工作区和索引删除文件

远程仓库 把自己公钥 添加到github SSH keys里面 就能往github推送东西了

git push origin master 推送主分支到origin远程库,也可以把master换成其他分支名   查看远程库信息 git remote -v

克隆 git clone git@gibhub.com:<github账号名>/<库名>.git   创建origin的分支到本地 git checkout -b <branchname> origin/<branchname>

查看分支 git branch  查看所有分支 git branch -a  创建分支 git branch <branchname>  切换分支 git checkout <branchname>或者 git switch  <branchname>

创建+切换分支 git checkout -b  <branchname>或者 git switch -c   <branchname> 合并某分支到当前分支 

git merge <branchname>

打标签 git tag <tagname> 给特定commit id 打标签 git tag <tagname><commitid> 查看标签 git tag 打说明标签 git tag -a v1.0 -m"说明"<commitid>  删除标签 git tag -d <tagname>  推送标签 git push origin<tagname>