ubuntu 16.04 git的使用方法

##一.git安装与基础
![title](https://leanote.com/api/file/getImage?fileId=5c11c616ab644107150014e9)

(1)ubuntu 16.04 安装git的方法:
https://blog.csdn.net/qq282330332/article/details/51855252
主要指令:`sudo apt-get install git`

(2)ubuntu从github上克隆项目:
在终端的git指令(后面是网址),不用像VS2017中那样要先建一个空文件夹作为本地仓库,而是会自动生成在/home目录下:
`git clone https://github.com/804463592/pytorch_siamese_minist.git`

(3)为了更好地使用 git, 我们同时也记录每一个施加修改的人. 这样人和修改能够对应上. 所以我们在 git 中添加用户名 user.name 和 用户 email user.email:

`$ git config --global user.name "804463592"`

`$ git config --global user.email "804463592@qq.com"`
(4)`clear` 清理指令
(5)cd到桌面的某个文件夹，除了可以直接`cd ~/desktop/gitTUT`以外，还可以分两步执行`cd ~/desktop`和`cd gitTUT`，其他文件夹类似。
##二.新建一个仓库添加仓库
cd到某个特定的文件夹后，`git init`指令即可创建一个新的git本地仓库。此时在此文件夹就会创建一个`.git`的文件夹，而且是一个隐藏文件夹，这就是我们的本地仓库。通过`ls -a`查看所有文件，ctrl+h 直接显示隐藏文件

建立一个新的文件`touch 1.py`

现在我们能用 status 来查看版本库的状态:
指令：`git status`
![title](https://leanote.com/api/file/getImage?fileId=5c109731ab64416973002919)

现在 1.py 并没有被放入版本库中 (unstaged), 所以我们要使用 add 把它添加进版本库 (staged):
`$ git add 1.py`
再次`git status`可以发现已经添加了新文件，但是没有commit提交
如果想一次性添加文件夹中所有未被添加的文件, 可以使用这个:
`$ git add .`

我们已经添加好了 1.py 文件, 最后一步就是提交这次的改变, 并在 -m 自定义这次改变的信息:

`$ git commit -m "create 1.py"`

如图：
![title](https://leanote.com/api/file/getImage?fileId=5c10987bab64416973002954)

现在再使用`git status`，可以发现仓库状态又改变了~~~

整个修改的文件状态流程图为：
![title](https://leanote.com/api/file/getImage?fileId=5c10a0cbab64416b74002b82)

##三.记录修改

使用`git log`查看之前的所有更改记录

我们使用一个编辑器，比如notepad++，打开1.py，修改文件，保存。此时，我们再使用`git status`可以发现文件已经变成modified（红色的）状态了，这时是不能直接commit的，否则会显示no changes add to commit
commit提交之前，需要使用`git add 1.py`指令，将文件转为绿色的modified（绿色的）状态，也就是stage状态，最后，再commit即可，指令为`git commit -m "change 1"`

那么如何查看修改记录呢？
`git log`只是查看每次修改记录提交的注释，要查看具体的修改记录，使用`git diff`查看从unmodified变为modified的修改情况，包括具体怎样修改的；比如我们把1.py中的a =1变为a =2，增加变量b = 1；使用`git diff`查看则为：
![title](https://leanote.com/api/file/getImage?fileId=5c10a458ab64416b74002c2e)
-
如果使用了add指令，则是进入到staged的状态，再使用"git diff"是查看不了改动信息的，如果你已经 add 了这次修改, 文件变成了 “可提交状态” (staged), 我们可以在 diff 中添加参数 --cached 来查看修改:
```
$ git add .   # add 全部修改文件
$ git diff --cached

# 输出
diff --git a/1.py b/1.py
index 1337a53..ff7c36c 100644
--- a/1.py
+++ b/1.py
@@ -1 +1,2 @@
-a = 1
+a = 2
+b = 1
```
**查看 staged & unstaged (HEAD)**
还有其他的方法：
还有种方法让我们可以查看 add 过 (staged) 和 没 add (unstaged) 的修改, 比如我们再修改一下 1.py 但不 add:
```
a = 2
b = 1
c = b
```
目前 a = 2 和 b = 1 已被 add, c = b 是新的修改, 还没被 add.
```
# 对比三种不同 diff 形式
$ git diff HEAD     # staged & unstaged

@@ -1 +1,3 @@
-a = 1  # 已 staged
+a = 2  # 已 staged
+b = 1  # 已 staged
+c = b  # 还没 add 去 stage (unstaged)
-----------------------
$ git diff          # unstaged

@@ -1,2 +1,3 @@
 a = 2  # 注: 前面没有 +
 b = 1  # 注: 前面没有 +
+c = b  # 还没 add 去 stage (unstaged)
-----------------------
$ git diff --cached # staged

@@ -1 +1,2 @@
-a = 1  # 已 staged
+a = 2  # 已 staged
+b = 1  # 已 staged

```
关于这个，莫凡python讲的很好~链接为：
https://morvanzhou.github.io/tutorials/others/git/2-2-modified/

##四.回到从前
###4.0 撤销修改
`git checkout --file`可以丢弃工作区的修改，命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次`git commit`或`git add`时的状态，因此untracked的文件是无法恢复的（只能ctrl+z）。

###4.1 基本使用
版本回退主要使用`git reset`命令
```
git reset --hard HEAD^ #从当前提交，回退1个版本，下同
git reset --hard HEAD~1 
git reset --hard HEAD~3 #回退3个版本

git reset --soft commit-id #后面接commit-id也可以
```
###4.2 reset包含三种模式：（1）`--hard`（2）`--mixed`（3）`--soft`
![title](https://leanote.com/api/file/getImage?fileId=5e08a107ab64410723002f98)
#### 4.2.1 reset --hard：重置stage区和工作目录:
`reset --hard `会在重置 `HEAD` 和`branch`的同时，重置`stage`区和工作目录里的内容。当你在 `reset` 后面加了 `--hard` 参数时，你的`stage`区和工作目录里的内容会被完全重置为和HEAD的新位置相同的内容。换句话说，就是你的没有`commit`的修改会被全部擦掉。
#### 4.2.2 reset --soft：保留工作目录，并把重置 HEAD 所带来的新的差异放进暂存区
`reset --soft` 会在重置 HEAD 和 branch时，保留工作目录和暂存区中的内容，并把重置 `HEAD` 所带来的新的差异放进暂存区。

总结: **`--soft 和 --hard 的区别：`**--hard 会清空工作目录和暂存区的改动,而 --soft则会保留工作目录的内容，并把因为保留工作目录内容所带来的新的文件差异放进暂存区。

####4.2.3 reset 不加参数(mixed)：保留工作目录，并清空暂存区
`reset`如果不加参数，那么默认使用`--mixed` 参数。它的行为是：保留工作目录，并且清空暂存区。也就是说，工作目录的修改、暂存区的内容以及由`reset` 所导致的新的文件差异，都会被放进工作目录。简而言之，就是「把所有差异都混合（mixed）放在工作目录中」。

##五.分支管理
###5.1 分支创建与切换

```
git branch #查看分支
git branch dev #创建dev分支
git checkout dev #切换到dev分支
```

```
git checkout -b dev #创建dev分支，然后切换到dev分支
```

###5.2分支合并，以及删除
```
git merge <name> #合并某分支到当前分支，默认快速合并，一旦分支删除，commit信息丢失
git merge –no-ff -m "merge with no-ff" dev #禁止快速合并，这样以commit的方式合并（所以要填写-m信息），即便dev被删除，以前的commit信息依然保留

git branch -d <name> #删除分支
git push origin --delete dev #删除远程origin上的dev分支，等同于提交空的分支，即删除：git push origin:dev
```
###5.3 远程分支关联
`git branch -vv` 可以查看一下目前分支的“关联”情况
配置本地分支与远程分支的三种方法：
####5.3.1.检出时建立关联关系：
```
git checkout -b dev origin/dev
```
当我们检查时，git会自动为我们检出的分支和远程分支建立关联关系；
####5.3.2.提交时配置关联关系：
```
`git push -u origin <remote_branch>`或`git push --set-upstream origin <remote_branch>`
```
注：默认配置下，提交时本地分支需和远程分支同名
####5.3.3.更改git/config文件：
```
git branch --set-upstream-to <remote_branch>
```
无论使用上述那种方法，本地分支和远程分支的“关联”最终都会写到config文件。

**很好的参考：**
https://www.cnblogs.com/kesimin/p/9936280.html
###5.4 一般的分支策略

首先，`master`分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
干活都在`dev`分支上，`dev`分支是不稳定的，新版本版本发布时，再把dev分支合并到`master`上，在`master`分支发布新版本；
每个人都在`dev`分支上干活，每个人都有自己的分支，时不时地往`dev`分支上合并就可以了。
    
##六.推送和拉取（GitHub或者码云）
###6.1 git push的基本使用
####6.1.0 添加远程库

```
$ git remote add origin git@github.com:804463592/learn_git.git
```
确保在远程库上有该仓库，并根据用户名（路径，如果是自建git服务器的话），仓库名，使用以上命令添加远程库。
添加完可以使用`git remote [-v]`查看信息：
```
git remote
```
####6.1.1  git push基本用法
```
$ git push <远程主机名> <本地分支名>:<远程分支名>
```
**注意**，`分支推送顺序的写法是<来源地>:<目的地>，所以git pull是<远程分支>:<本地分支>，而git push是<本地分支>:<远程分支>。`比如:`git push origin local_dev:dev`,这说明，推送到不同名的分支也是可以的，且无论是 `git push`还是`git push local_branch`,都需要本地分支与远程分支同名，当需要将本地分支推送到远程不同名分支，则需要使用这种指明本地分支，远程分支的方式。

还有，不要自以为是的像这样推送：
```
git push origin libo:origin/libo #这可不是将本地的libo推送到远程的libo，而是会在远程建一个分支origin/libo`
```
####6.1.2 省略远程分支
如果**省略远程分支名**，则表示将本地分支推送与之存在”追踪关系”的远程分支(通常两者同名)，如果该远程分支不存在，则会被新建。但是，当前本地分支与远程分支并未建立"追踪关系"，除非使用`--set-upstream`(新版本是`--set-upstream-to`，比如`git push --set-upstream-to origin local_dev`)指定，否则每次push时，依然需要手动指定`<本地分支>:<远程分支>`。
```
$ git push origin master
```
上面命令省略了远程分支名字，则表示，将本地的`master`分支推送到`origin`主机的`master`分支。如果后者不存在，则会被新建。

####6.1.3 省略本地分支
如果省略本地分支名，则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支。
```
    $ git push origin :master
     
    # 等价于
     
    $ git push origin --delete master
```
上面命令表示删除origin主机的master分支。
####6.1.4 省略本地和远程分支
如果当前分支与远程分支之间存在追踪关系，则本地分支和远程分支都可以省略。
```
$ git push origin
```
上面命令表示，将当前分支推送到origin主机的对应分支。
####6.1.5 省略所有分支及主机名
#####6.1.5.1 基本方式
如果当前分支只有一个追踪分支，那么主机名都可以省略。
```
$ git push
```
如果当前分支与多个主机存在追踪关系，则可以使用`-u`选项指定一个默认主机，这样后面就可以不加任何参数使用`git push`。
```
$ git push -u origin master
```
上面命令将本地的master分支推送到origin主机，同时指定origin为默认主机，并关联分支，后面也就可以不加任何参数使用git push了。

#####6.1.5.2 推送方式
不带任何参数的git push，默认只推送当前分支，这叫做`simple`方式。此外，还有一种`matching`方式，会推送所有有对应的远程分支的本地分支。Git 2.0版本之前，默认采用matching方法，现在改为默认采用`simple`方式。如果要修改这个设置，可以采用`git config`命令。
```
    $ git config --global push.default matching
    # 或者
    $ git config --global push.default simple
```    
还有一种情况，就是不管是否存在对应的远程分支，将本地的所有分支都推送到远程主机，这时需要使用`–all`选项。
```
$ git push --all origin
```
上面命令表示，将所有本地分支都推送到origin主机。

如果远程主机的版本比本地版本更新，推送时Git会报错，要求先在本地做`git pull`合并差异，然后再推送到远程主机。这时，如果你一定要推送，可以使用`--force`选项。
```
$ git push --force origin
```
上面命令使用`--force`选项，结果导致在远程主机产生一个”非直进式”的合并(non-fast-forward merge)。除非你很确定要这样做，否则应该尽量避免使用`--force`选项。
最后，git push不会推送标签(tag)，除非使用–tags选项。
```
$ git push origin --tags
```
###6.2 git pull的基本使用
####6.2.1 基本使用
可以在任何位置，新建一个空文件夹，使用以下命令，通过ssh协议克隆远程仓库：
```
git clone git@github.com:804463592/learn_git.git
```
如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。当然，前提是你取得ssh权限。
####6.2.2 git pull 的三种使用方式
```
git pull origin <remote_branch>：<local_branch>
git pull origin <remote_branch>
git pull
```
#####6.2.2.1 `git pull origin remote_branch：local_branch`
当前分支是`dev`，但是你想把远程`master`同步到本地`master`，但又不想使`checkout`切换到`master`分支；
这时你就可以使用`git pull origin master：master`
#####6.2.2.2 `git pull origin remote_branch`
将指定远程分支同步到当前本地分支(HEAD分支（HEAD分支指向当前位置）
####6.2.2.2 `git pull`
场景：本地分支已经和想要拉取的分支建立了“关联”关系；
作用：拉取所有远程分支的新版本"坐标"，并同步当前分支的本地代码(具体根据关联分支而定)

####6.2.3 SSH密钥与多人协作
由于你的本地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"
#"youremail@example.com"为你git设置的邮箱，比如我的是804463592@qq.com
```
你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。

如果一切顺利的话，可以在用户主目录里找到`.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`文件的内容即可(可以为每个公钥命名)。拥有ssh权限的克隆你github仓库里的任何一个仓库，所以适合自己用（当然在互相信任的前提下，用来多人协作也没什么不可）：假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

多人协作还可以在github的仓库中添加`Collaborators `，这样，别人登录自己的github账户，使用https协议，也能克隆，推送，拉取你的仓库。

###6.3 git fetch的基本使用
git fetch 有四种基本用法
####6.3.1. ` git fetch `
这将更新git remote 中所有的远程repo 所包含分支的最新commit-id, 将其记录到.git/FETCH_HEAD文件中

####6.3.2 ` git fetch remote_repo`
这将更新名称为remote_repo 的远程repo上的所有branch的最新commit-id，将其记录。

####6.3.3 `git fetch remote_repo remote_branch_name`
这将这将更新名称为remote_repo 的远程repo上的分支： remote_branch_name

####6.3.4 `git fetch remote_repo remote_branch_name:local_branch_name`
这将这将更新名称为remote_repo 的远程repo上的分支： remote_branch_name ，并在本地创建local_branch_name 本地分支保存远端分支的所有数据。

`FETCH_HEAD`： 是一个版本链接，记录在本地的一个文件中，指向着目前已经从远程仓库取下来的分支的末端版本。如下查看FETCH_HEAD信息：
```
git log -p FETCH_HEAD
```

###七.其他
####7.1  删除文件
```
#删除文件
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")rm test.txt
#提交到git
git rm test.txt
git commit -m "blabla..."
#由于提交到了git，可以使用checkout恢复
git checkout test.txt
```
####7.2 查看信息
```
git status #查看当前分支工作状态

git log  #查看commit提交记录
git log -graph
git log –graph –pretty=oneline –abbrev- #图的形式，简写commit-id

git reflog #查看命令操作记录
```
####7.3 内容对比
#####7.3.1 `git diff`：
当工作区有改动，临时区为空，diff的对比是“工作区与最后一次commit提交的仓库的共同文件”；当工作区有改动，临时区不为空，diff对比的是“工作区与暂存区的共同文件”。

#####7.3.2 `git diff --cached` 或 `git diff --staged`：
显示暂存区(已add但未commit文件)和最后一次commit(HEAD)之间的所有不相同文件的增删改(`git diff --cached`和`git diff –staged`相同作用)

#####7.3.3 `git diff HEAD`：
显示工作目录(已track但未add文件)和暂存区(已add但未commit文件)与最后一次commit之间的的所有不相同文件的增删改。

######7.3.3.1:`git diff HEAD~X`或`git diff HEAD^^^…`(后面有X个^符号，X为正整数):
可以查看最近一次提交的版本与往过去时间线前数X个的版本之间的所有同(3)中定义文件之间的增删改。

#####7.3.4 `git diff <分支名1> <分支名2>` ：
比较两个分支上最后 commit 的内容的差别

######7.3.4.1  `git diff branch1 branch2 --stat `:
显示出所有有差异的文件(不详细,没有对比内容)

######7.3.4.2  `git diff branch1 branch2`: 
显示出所有有差异的文件的详细差异(更详细)
######7.3.4.3  `git diff branch1 branch2 具体文件路径`:
显示指定文件的详细差异(对比内容)

我们有2个分支：`master、dev(dev为develop的缩写,应是开发新功能的Feature分支)`，查看这两个 branch 的区别，除了上面(abc)还有以下几种方式：

######7.3.4.4 `git log dev ^master`:
查看 dev中log有的commit，而 master中log没有的commit

######7.3.4.5 `git log master..dev`:
查看 dev 中的log比 master中的log多提交了哪些内容(注意，列出来的是两个点“..”后边（此处即dev）多提交的内容)

######7.3.4.6` git log dev...master`: 不知道谁提交的多谁提交的少，单纯想知道有什么不一样

lee-romantic 's Blog

导航

最近发表

友情链接