Git教程_2 所有操作讲解

r囧r小猫 2023-01-05 03:56 214阅读 0赞

https://gitee.com/fakerlove/git

### 文章目录 ###

*  2. 所有操作讲解
 *   *  2.1 创建版本库
     *  2.2 文件的基本操作
     *   *  1. 创建
         *  2. 添加
         *  3. 提交
     *  2.3 工作区和暂存区
     *  2.4 修改
     *   *  1、管理修改
         *  2、撤销修改
     *  2.5 分支管理
     *   *  1、创建与合并分支
         *  2、解决冲突
         *  3、分支管理策略
         *  4、bug分支
         *  5、Feature分支
         *  6、多人协作
         *  7、标签管理

# 2. 所有操作讲解 #

## 2.1 创建版本库 ##

1、创建一个空目录（最好不要包含中文）

mkdir mymenu
    cd mymenu
    pwd

pwd命令显示当前目录

2、初始化仓库

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

git init

结果

Initialized empty Git repository in /Users/hxk/mymenu/.git/

初始化了一个空的仓库，目录下多了.git目录

系统自动创建了唯一一个master分支

版本控制系统只能跟踪文本文件的改动，且编码方式是utf-8

## 2.2 文件的基本操作 ##

### 1. 创建 ###

Hello World

### 2. 添加 ###

git add readme.txt

### 3. 提交 ###

git commit -m "a new file"

\-m后面输入的是本次提交的说明，提交成功后会显示：

`1 file changed`：1个文件被改动（我们新添加的readme.txt文件）；

`2 insertions`：插入了两行内容（readme.txt有两行内容）。

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

git add file1.txt
    git add file2.txt file3.txt
    git commit -m "add 3 files."

如果提交的备注写错了，可以用以下命令修改刚刚提交的备注

git commit --amend

3、修改文件

将test.txt文件修改如下：

Hello World ABC

提交

git add test.txt
    git commit -m "append ABC"

每次commit都会生成一个“快照”

4、查看历史记录

git log

结果

commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
    Author: hxk <hxk@gmail.com>
    Date:   Fri July 20 21:06:15 2018 +0800
        append ABC
    commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
    Author: hxk <hxk@gmail.com>
    Date:   Fri July 20 20:59:18 2018 +0800
        a new file

git log显示最近到最远的提交日志，我们可以看到两次提交，最后一次是append ABC

git的版本号是用SHA1计算出来的一个16进制数

如果嫌输出信息太多，可以加上–pretty=oneline

git log --pretty=oneline

结果

1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append ABC
    eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 a new file

5、回退历史版本

git reset

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

回退上一版本

git reset --hard HEAD^
    HEAD is now at eaadf4e a new file

这时再次查看历史版本

git log

结果

commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
    Author: hxk <hxk@gmail.com>
    Date:   Fri July 20 20:59:18 2018 +0800
        a new file

之前那个版本已经看不到了，这时如果想回到之前那个版本，需要知道版本号，git内部有个指向当前版本的head指针，将指针从当前版本指回去，所以git回退版本特别快

git reset --hard 1094adb7

6、查看历史命令

要是不记得刚才的版本号了，可以使用以下命令：

git reflog

7、查看状态

git status

## 2.3 工作区和暂存区 ##

Git和SVN的一个不同之处就是有暂存区的概念

名词解释：

工作区（Working Directory）：指的是在电脑里能看到的目录，比如mymenu文件夹就是一个工作区

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

git add是把需要提交的文件添加到暂存区

![img][]

git commit是把暂存区的所有内容提交到当前分支

\-------------------------测试一下--------------------------

在工作区新增一个testfile文本文件

先用`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:   test.txt
    Untracked files:
      (use "git add <file>..." to include in what will be committed)
        testfile
    no changes added to commit (use "git add" and/or "git commit -a")

Git非常清楚地告诉我们，`test.txt`被修改了，而`testfile`还从来没有被添加过，所以它的状态是`Untracked`。

将testfile提交后再查看状态

git status

结果

On branch master
    Changes to be committed
      (use "git reset HEAD <file>..." to unstage)
        new file:   testfile
        modified:   test.txt

提交后没有对工作区进行修改的话，查看状态，工作区是干净的

git status

结果

On branch master
    nothing to commit, working tree clean

\-------------------------------测试结束------------------------------------

## 2.4 修改 ##

### 1、管理修改 ###

那么，为什么说git比svn优秀呢？因为git跟踪并管理的是修改，而不是文件

修改test.txt文件内容，添加一行

cat test.txt

结果

Hello World ABC
    This is the second line

然后添加文件

$ git add test.txt

再次修改test.txt

cat test.txt

结果

Hello World ABC
    This is the second line
    This is the third line

提交

git commit -m "test add lines"

这时我们发现，第二次的修改未提交，这是为什么呢？

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

add将工作区的修改存入暂存区，但是第二次修改并未存入暂存区，git commit只负责把暂存区的修改提交，所以正确的顺序应该是：

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

提交后，查看工作区和版本库里面最新版本的区别：

git diff HEAD -- test.txt

### 2、撤销修改 ###

1）丢弃工作区的修改 `git checkout -- file（--`很重要，没有`--`，就变成了“切换到另一个分支”的命令`）`：

git checkout -- test.txt

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

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

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

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

2）把暂存区的修改撤销掉（unstage），重新放回工作区 `git reset HEAD <file>`：

git reset HEAD test.txt

结果

Unstaged changes after reset:
    M    test.txt

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

3、删除文件

工作区中删除文件

rm test.txt

一是要从版本库中删除该文件，那就用命令`git rm`删掉，并且`git commit`：

git rm test.txt
    git commit -m "remove test.txt"

二是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

git checkout -- test.txt

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

PS: 手动删除文件，然后使用git rm 和git add效果是一样的。

## 2.5 分支管理 ##

### 1、创建与合并分支 ###

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

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

![img][img 1]

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

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

![img][img 2]

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

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

![img][img 3]

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

![img][img 4]

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

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

![img][img 5]

\------------------------------------测试开始---------------------------------------------------

1）创建分支 git branch

切换分支 git checkout

首先，我们创建`dev`分支，然后切换到`dev`分支：

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

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

git branch dev
    git checkout dev

结果

Switched to branch 'dev'

2）查看分支 git branch

然后，用`git branch`命令查看当前分支：

git branch

结果

* dev
      master

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

然后，我们就可以在`dev`分支上正常提交，比如对test.txt做个修改，再提交，`dev`分支的工作完成后，我们就可以切换回`master`分支：

git checkout master

结果

Switched to branch 'master'

切换回`master`分支后，再查看一个test.txt文件，刚才添加的内容不见了！因为那个提交是在`dev`分支上，而`master`分支此刻的提交点并没有变：

![img][img 6]

3）合并某个分支到当前分支 git merge

现在，我们把`dev`分支的工作成果合并到`master`分支上：

git merge dev

`git merge`命令用于合并指定分支到当前分支。合并后，再查看test.txt的内容，就可以看到，和`dev`分支的最新提交是完全一样的。

4）删除分支 git branch -d

合并完成后，就可以放心地删除`dev`分支了：

git branch -d dev

结果

Deleted branch dev (was b17d20e).

删除后，查看`branch`，就只剩下`master`分支了：

git branch

结果

* master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在`master`分支上工作效果是一样的，但过程更安全。

### 2、解决冲突 ###

创建一个新的分支feature1

git checkout -b feature1

结果

Switched to a new branch 'feature1'

将test.txt修改了一下，加上“AND Simple”，在feature1分支上提交

Hello World ABC
    This is the second line AND Simple

切换到master分支

git checkout master

在master分支上，将test.txt的最后一行加上“& Simple”，提交：

Hello World ABC
    This is the second line & Simple

当两个分支都分别有了新的提交，如下图所示：

![img][img 7]

这种情况下无法进行快速合并，只能试图把各自的修改合并起来，这样有可能会造成冲突：

git merge feature1

结果

Auto-merging test.txt
    CONFLICT (content): Merge conflict in test.txt
    Automatic merge failed; fix conflicts and then commit the result.

这时我们必须手动解决冲突后再提交，git status可以查看冲突的文件：

git status

结果

On branch master
    Your branch is ahead of 'origin/master' by 2 commits.
      (use "git push" to publish your local commits)
    You have unmerged paths.
      (fix conflicts and run "git commit")
      (use "git merge --abort" to abort the merge)
    Unmerged paths:
      (use "git add <file>..." to mark resolution)
        both modified:   test.txt
    no changes added to commit (use "git add" and/or "git commit -a")

查看test.txt文件的内容：

Hello World ABC
    <<<<<<< HEAD
    This is the second line & Simple
    =======
    This is the second line AND Simple
    >>>>>>> feature1

Git用`<<<<<<<`，`=======`，`>>>>>>>`标记出不同分支的内容，我们修改如下后保存：

This is the second line and Simple

再提交

git add test.txt 
    git commit -m "conflict fixed"
    [master cf810e4] conflict fixed

现在，`master`分支和`feature1`分支变成了下图所示：

![img][img 8]

用git log --graph --pretty=oneline --abbrev-commit可以看到分支的合并情况，包括分支合并图(–graph)、一行显示(–pretty=oneline)、提交校验码缩略(–abbrev-commit)显示：

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

结果

*   cf810e4 (HEAD -> master) conflict fixed
    |\  
    | * 14096d0 (feature1) AND simple
    * | 5dc6824 & simple
    |/  
    * b17d20e branch test
    * d46f35e (origin/master) remove test.txt
    * b84166e add test.txt
    * 519219b git tracks changes
    * e43a48b understand how stage works
    * 1094adb append ABC
    * eaadf4e a new file

最后，删除`feature1`分支：

git branch -d feature1

结果

Deleted branch feature1 (was 14096d0).

### 3、分支管理策略 ###

通常，合并分支时，Git会用快速合并模式（`Fast forward）`，但这种模式下，删除分支后，会丢掉分支信息。

如果用普通合并模式，从分支历史上就可以看出分支信息。

那么，如何使用普通合并模式呢？我们可以用–no-ff参数

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

不使用`Fast forward`模式，merge后就像这样：如下图所示：

![img][img 9]

分支策略

master分支是最稳定的，只能用于发布新版本，平时不能在上面进行开发，要在新建的分支上进行开发，比如dev，这时dev是不稳定的，到产品1.0发布时，将dev分支和master分支合并，在master分支上发布1.0版本。

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

![img][img 10]

### 4、bug分支 ###

修复bug时，我们会创建一个bug分支进行修复，修复完合并，删除分支。

如果手头上有未完成的工作，先把工作现场git stash一下：

git stash

结果

Saved working directory and index state WIP on dev: f52c633 add merge

查看下工作区是否干净

$ git status

等bug修复完分支删除后，我们先查看下stash

$ git stash list
    stash@{0}: WIP on dev: f52c633 add merge

恢复工作现场

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

可以多次stash，恢复指定的stash；

$ git stash apply stash@{0}

2）用`git stash pop`，恢复的同时把stash内容也删了：

$ git stash pop

### 5、Feature分支 ###

开发一个新功能，需要新建一个分支。

如果这个功能还未合并就要取消，要使用-D强行删除

$ git branch -D 分支名

### 6、多人协作 ###

当你从远程克隆时，git自动把本地master分支和远程master分支对应起来，远程仓库默认名为origin

1）查看远程库的信息

$ git remote

查看远程库的详细信息

$ git remote -v

2）推送分支

将本地master分支推送到远程库

如果不推送到远程，本地分支对于其它人就是不可见的

$ git push origin master

3）抓取分支

如果本地分支推送到远程库的文件有冲突，推送失败，我们就得先从远程库中抓取最新的提交合并到本地，解决冲突再提交。

$ git pull

如果git pull报错：没有指定本地分支与远程分支的链接，我们就要手动设置一下

git branch --set-upstream-to=origin/<远程分支名> 本地分支名

4）Rebase

rebase操作可以把本地未push的分叉提交历史整理成直线；

目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

$ git rebase

和merge的对比示意图如下：

merge–>

![这里写图片描述][79735c61e2e748e839968769deb7073f.png]

rebase–>

![这里写图片描述][0ffc0dfbc3dfc7e30b0837df9775b6d8.png]

### 7、标签管理 ###

切换到需要打标签的分支上

1）新建一个标签（默认为`HEAD`，也可以指定一个commit id）

创建带有说明的标签，用`-a`指定标签名，`-m`指定说明文字

$ git tag <标签名>
    $ git tag <标签名> <commit id>
    $ git tag -a <标签名> -m "备注"

2）查看标签

标签不是按时间顺序列出，而是按字母排序的。

git tag查看所有标签，用git show 标签名查看指定的某个标签信息

$ git tag
    $ git show <标签名>

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

3）删除标签

创建的标签都只存储在本地，不会自动推送到远程，所以打错的标签可以在本地安全删除；

$ git tag -d <标签名>

如果标签已经推送到远程，要先从本地删除，再从远程删除

$ git tag -d <标签名>
    $ git push origin :refs/tags/<标签名>

4）推送标签到远程

推送某个标签到远程 `git push origin <tagname>`

推送全部尚未推送到远程的本地标签 `git push origin --tags`

git push origin <标签名>
    git push origin --tags

以上。

[img]: /images/20221119/759af9a2eaeb4506862af340bff7149e.png
[img 1]: /images/20221119/acdaf378baeb4f0b90f4496b1e225b67.png
[img 2]: https://img-blog.csdnimg.cn/img_convert/e71297a86ad0a283144f49f5c27f59f5.png
[img 3]: https://img-blog.csdnimg.cn/img_convert/cc45473af50c908f1352593a4260df9d.png
[img 4]: https://img-blog.csdnimg.cn/img_convert/4d797ed1c045cf709795d7bbac478449.png
[img 5]: https://img-blog.csdnimg.cn/img_convert/f7c6ff544d05977083e17dfb796d01ac.png
[img 6]: https://img-blog.csdnimg.cn/img_convert/17d4bb51162f537d6bd4f20d00f694cf.png
[img 7]: https://img-blog.csdnimg.cn/img_convert/666d76f5081a8592fbdf6832fbaa25d8.png
[img 8]: https://img-blog.csdnimg.cn/img_convert/d347fc743826f2d9d6871b71423755ac.png
[img 9]: https://img-blog.csdnimg.cn/img_convert/70ec97649e076d8bd315732dc9c21913.png
[img 10]: https://img-blog.csdnimg.cn/img_convert/61f049280e073d9f1ef61d31eecfa16d.png
[79735c61e2e748e839968769deb7073f.png]: https://img-blog.csdnimg.cn/img_convert/79735c61e2e748e839968769deb7073f.png
[0ffc0dfbc3dfc7e30b0837df9775b6d8.png]: https://img-blog.csdnimg.cn/img_convert/0ffc0dfbc3dfc7e30b0837df9775b6d8.png