Git教程2——Git基本操作

偏执的太偏执、 2021-09-22 05:04 417阅读 0赞

**创建版本库**  
如果你打算使用 Git 来对现有的项目进行管理，例如我在D盘mygit目录下新建一个git版本库。

$ cd d: $ cd mygit $ pwd

![Center][]  
pwd命令用于显示当前目录。在我的机子上，这个仓库位于d:\\mygit。如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。  
通过git init命令把这个目录变成Git可以管理的仓库

$ git init

![Center 1][]  
这时候你的mygit目录下会多了一个.git的目录，这个目录是Git来跟踪管理版本的，没事千万不要手动乱改这个目录里面的文件，否则会把git仓库给破坏了。如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。  
  
**克隆现有的仓库**  
如果你想获得一份已经存在了的 Git 仓库的拷贝，比如说，你想为某个开源项目贡献自己的一份力，这时就要用到 git clone 命令。 如果你对其它的 VCS 系统（比如说Subversion）很熟悉，请留心一下你所使用的命令是"clone"而不是"checkout"。 这是 Git 区别于其它版本控制系统的一个重要特性，Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成你的工作所需要文件。 当你执行 git clone 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。 事实上，如果你的服务器的磁盘坏掉了，你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库（虽然可能会丢失某些服务器端的挂钩设置，但是所有版本的数据仍在）。  
克隆仓库的命令格式是 ：

$ git clone url

这会在当前目录下创建一个名为 “mygit” 的目录，并在这个目录下初始化一个 .git 文件夹，从远程仓库拉取下所有数据放入 .git 文件夹，然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 mygit文件夹，你会发现所有的项目文件已经在里面了，准备就绪等待后续的开发和使用。 如果你想在克隆远程仓库的时候，自定义本地仓库的名字，你可以使用如下命令：

$ git clone url Mygit

这将执行与上一个命令相同的操作，不过在本地创建的仓库名字变为 Mygit。  
Git 支持多种数据传输协议。 上面的例子使用的是 https:// 协议，不过你也可以使用 git:// 协议或者使用 SSH 传输协议，比如 *user@server:path/to/repo.git* 。  
  
**添加内容到版本库**  
工作目录下的每一个文件不外乎这两种状态：已跟踪或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。 工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。  
编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 我们逐步将这些修改过的文件放入暂存区，然后提交所有暂存了的修改，如此反复。所以使用 Git 时文件的生命周期如下：  
![Center 2][]  
需要再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从10KB改成了20KB，但到底改了啥，版本控制系统不知道，也没法知道。  
不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。  
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift\_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。  
  
使用Windows的童鞋要特别注意：  
千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议使用Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可：  
![Center 3][]  
  
使用Git提交文件到版本库共有两步：  
第一步：是使用 git add 把文件添加进去，实际上就是把文件添加到暂存区。  
第二步：使用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支上。  
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以现在，git commit就是往master分支上提交更改。  
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。  
  
现在开始测试，编写一个test.txt文件，随便写点内容。一定要放到mygit目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。  
第一步，用命令git add告诉Git，把文件添加到仓库：

$ git add test.txt

如果没有任何显示，就说明添加成功了，Unix的哲学是“没有消息就是好消息”。  
第二步，用命令git commit告诉Git，把文件提交到仓库：

$ git commit -m "提交的注释"

![Center 4][]  
git commit命令执行成功后会告诉你，1个文件被改动（我们新添加的test.txt文件），插入了一行内容（test.txt有一行内容）。  
为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

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

我们已经成功地添加并提交了一个test.txt文件，下面可以通过命令git status来查看是否还有文件未提交，如下：  
![Center 5][]  
说明没有任何文件未提交，换句话说，所有已跟踪文件在上次提交后都未被更改过。 此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。最后，该命令还显示了当前所在分支，并告诉你这个分支同远程服务器上对应的分支没有偏离。 现在，分支名是 “master”,这是默认的分支名。新项目中，添加所有文件很普遍，我们可以使用 git add . 命令来添加当前项目的所有文件。现在继续，我们再往test.txt中添加一点内容，现在，运行git status命令看看结果：

$ git status

![Center 6][]  
上面的命令告诉我们，readme.txt被修改过了，但还没有放到暂存区。要暂存这次更新，需要运行 git add 命令。git status命令是个多功能命令：可以让我们时刻掌握仓库当前的状态，可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。好了，虽然Git告诉我们test.txt被修改了，但如果能看看具体修改了什么内容，那就更好了。例如放假归来第一天上班，已经记不清上次都做了什么修改，怎么办？这时可以使用git diff这个命令看看：

$ git diff test.txt

![Center 7][]  
git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，文件内容从一行增加到了两行，添加了一行”222222“。要注意的是，git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。 所以有时候你一下子暂存了所有更新过的文件后，运行 git diff 后却什么也没有，就是这个原因。知道了对test.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件都是需要两步，第一步使用"git add . "命令。

$ git add .

同样没有任何输出，在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：  
![Center 8][]  
只要在 Changes to be committed 这行下面的，就说明是已暂存状态。 如果此时提交，那么该文件此时此刻的版本将被留存在历史记录中，现在可以放心地提交了：

$ git commit -m "222222"

![Center 9][]  
提交后，我们再用git status命令看看仓库的当前状态：  
![Center 10][]  
Git告诉我们当前没有需要提交的修改，而且工作目录是干净的  
  
**跳过使用暂存区域**  
尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。 Git 提供了一个跳过使用暂存区域的方式， 只要在提交的时候，给 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤。  
  
**查看提交历史**  
现在已有提交的版本了，我再修改几次文件，像这样，你不断对文件进行修改，然后不断提交修改到版本库里。那么我现在想查看下历史记录，如何查呢？我们现在可以使用命令 git log 来查看：

$ git log

![Center 11][]  
默认不用任何参数的话，git log 会按提交时间列出所有的更新，最近的更新排在最上面。 这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。 git log命令显示从最近到最远的显示日志，这个命令会列出每个提交的 SHA-1 校验和、作者的名字和电子邮件地址、提交时间以及提交说明。  
git log 有许多选项可以帮助你搜寻你所要找的提交， 接下来我们介绍一个常用的选项是 ---pretty，这个选项可以指定使用不同于默认格式的方式展示提交历史，比如用 oneline 将每个提交放在一行显示，查看的提交数很大时非常有用，另外还有 short，full 和 fuller 可以用，展示的信息或多或少有些不同。现在做个示范：

$ git log --pretty=oneline

![Center 12][]  
  
**版本回退**  
现在准备把test.txt回退到上一个版本，怎么做呢？首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交82f4ac...a841d0（注意我的提交ID和你的肯定不一样），可以使用如下2种命令，第一种是：git reset --hard HEAD^ 那么如果要回退到上上个版本只需把HEAD^ 改成 HEAD^^ 以此类推。那如果要回退到前100个版本的话，使用上面的方法肯定不方便，我们可以使用下面的简便命令操作：git reset –-hard HEAD~100 即可。

$ git reset --hard HEAD~100

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

$ git reset --hard HEAD^

![Center 13][]  
再来查看下 test.txt内容，通过命令cat test.txt查看：  
![Center 14][]  
可以看到，内容已经回退到上一个版本了。我们可以继续使用git log 来查看下历史记录信息，如下：  
![Center 15][]  
我们看到注释为“add 333333”的那次看不到了，但是现在我想重新返回到最新的版本，我们可以通过版本号回退，使用命令方法如下：git reset --hard 版本号 ，版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。但是现在的问题假如我已经关掉过一次命令行或者版本号我并不知道呢？要如何知道已经回退内容的版本号呢？可以通过如下命令即可获取到版本号：git reflog 演示如下：

$ git reflog

![Center 16][]  
通过上面的提示，我们可以知道版本号是63f24e4，现在可以使用命令git reset --hard 63f24e4来恢复了。演示如下：

$ git reset --hard 63f24e4

![Center 17][]  
再看下test.txt的内容  
![Center 18][]  
  
**撤消操作**  
在任何一个阶段，你都有可能想要撤消某些操作。 这里，我们将会学习几个撤消你所做修改的基本工具。 注意，有些撤消操作是不可逆的。 这是在使用 Git 的过程中，会因为操作失误而导致之前的工作丢失的少有的几个地方之一。  
有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 --amend 选项的提交命令尝试重新提交：

$ git commit --amend

这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息。  
文本编辑器启动后，可以看到之前的提交信息。 编辑后保存会覆盖原来的提交信息。  
例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

$ git commit -m 'initial commit'
    $ git add forgotten_file
    $ git commit --amend

最终你只会有一个提交 - 第二次提交将代替第一次提交的结果。  
  
**取消暂存的文件**  
接下来演示如何操作暂存区域与工作目录中已修改的文件。 这些命令在修改文件状态的同时，也会提示如何撤消操作。 例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交，但是却意外地输入了 git add \* 暂存了它们两个。 如何只取消暂存两个中的一个呢？ git status 命令提示了你：  
![Center 19][]  
在 “Changes to be committed” 文字正下方，提示使用 git reset HEAD <file>... 来取消暂存。 所以，我们可以这样来取消暂存 a.txt 文件：  
![Center 20][]  
这个命令有点儿奇怪，但是起作用了。 CONTRIBUTING.md 文件已经是修改未暂存的状态了。虽然在调用时加上 --hard 选项可以令 git reset 成为一个危险的命令（译注：可能导致工作目录中所有当前进度丢失！），但本例中工作目录内的文件并不会被修改。 不加选项地调用 git reset 并不危险 — 它只会修改暂存区域。  
  
**管理修改**  
Git跟踪并管理的是修改，而非文件。什么是修改？增加删除内容都是修改，甚至创建一个新文件，也算一个修改。为了证明Git管理的是修改，而不是文件，我们做一个实验。第一步，对test.txt做一个修改，比如加一行内容，然后添加：  
![Center 21][]  
然后，再修改test.txt，提交后再看状态：  
![Center 22][]  
第二次的修改并没有被提交。我们回顾一下操作过程：第一次修改 -> git add -> 第二次修改 -> git commit  
Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。  
提交后，用git diff HEAD -- test.txt命令可以查看工作区和版本库里面最新版本的区别：

$git diff HEAD -- test.txt

![Center 23][]  
第二次修改确实没有被提交。  
那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了  
  
**撤销修改**  
现在做了半天工作了，在我未提交之前，我发现添加的内容(例如我加了777777)有误，所以我得马上恢复以前的版本，现在我可以有如下几种方法可以做修改：  
第一：如果我知道要删掉哪些内容的话，直接手动更改去掉那些需要的文件，然后add添加到暂存区，最后commit掉。  
第二：我可以直接恢复到上一个版本。使用 git reset --hard HEAD^  
但是现在我不想使用上面的2种方法，我想直接想使用撤销命令该如何操作呢？  
git status 也告诉了你应该如何做。首先在做撤销之前，我们可以先用 git status 查看下当前的状态  
![Center 24][]  
Git会告诉你，git checkout -- <file> 可以丢弃工作区的修改，如下命令：  
git checkout -- test.txt,如下所示：

$ git checkout -- test.txt

![Center 25][]  
命令 git checkout --test.txt 意思就是，把test.txt文件在工作区做的修改全部撤销，这里有2种情况：  
1. readme.txt自动修改后，还没有放到暂存区，使用撤销修改就回到和版本库一模一样的状态。  
2. 另外一种是readme.txt已经放入暂存区了，接着又作了修改，撤销修改就回到添加暂存区后的状态。  
  
上面是第一种情况，下面再测试下第二种情况，也就是已经git add了，但还没有git commit  
![Center 26][]  
庆幸的是，在commit之前，你发现了这个问题。用git status查看一下，修改只是添加到了暂存区，还没有提交。Git同样告诉我们，用命令git reset HEAD <file> 可以把暂存区的修改撤销掉（unstage），重新放回工作区：  
![Center 27][]  
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。  
再用git status查看一下，现在暂存区是干净的，工作区有修改：  
![Center 28][]  
接着撤销工作区的修改：  
![Center 29][]  
总之，就是让这个文件回到最近一次git commit或git add时的状态。  
注意：命令git checkout --readme.txt 中的"--"很重要，如果没有"--"的话，那么命令变成创建分支了。  
  
**删除文件**  
假如我现在版本库mygit目录添加一个文件a.txt,然后提交，如下：  
![Center 30][]  
通常情况下，可以直接在文件管理器中把没用的文件删了，或者用rm命令删了：

$ rm a.txt

这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：  
![Center 31][]  
现在有两种情况，一是确实要从版本库中删除该文件，那就用命令git rm 命令删掉，并且git commit：

$ git rm a.txt
    $ git commit -m "delete a.txt"

![Center 32][]  
现在，文件就从版本库中被删除了。  
另一种情况是删错了，只要没有commit，那么版本库里还有，所以可以很轻松地把误删的文件恢复到最新版本：  
![Center 33][]  
git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

[Center]: /images/20210920/92ba69ffef774b97b96cf9191a9ba1bf.png
[Center 1]: /images/20210920/d4f9ad28aaf8480a87fadbfa6308e08e.png
[Center 2]: /images/20210920/81f25d467c164fe9ae86eed32c957207.png
[Center 3]: /images/20210920/0144428927964ede837aa26b11f16048.png
[Center 4]: /images/20210920/ef6e7b7e96174450b7f5d2351883d2b8.png
[Center 5]: /images/20210920/e96866c9aea54807b0e0135a6b103a0e.png
[Center 6]: /images/20210920/ed08a2bb4bdc4b8ea4ed1713de0cdd5f.png
[Center 7]: /images/20210920/c00ee1f7b0854063be43620b7bdec7d0.png
[Center 8]: /images/20210920/4834f23fe7f841d8ae9413bb9a0edd0f.png
[Center 9]: /images/20210920/0d6dbd1ce0a246b8a0e5a5f3df4a90c9.png
[Center 10]: /images/20210920/b291aeeef1f44d7a8cfab4c15d733e8d.png
[Center 11]: /images/20210920/6284dc7f8c424d5a9a7d1e5eb2353764.png
[Center 12]: /images/20210920/0fdfd1e50e234dd0b48e618471e89419.png
[Center 13]: /images/20210920/fa4ce76ac79a450ca1c33b0c56d71be6.png
[Center 14]: /images/20210920/53f4891f172b4179a737d7ae7cdc5cf8.png
[Center 15]: /images/20210920/f3268f22cb44488d8340c950326f15c4.png
[Center 16]: /images/20210920/f38e3be886fc4e208f6e2f16896328c7.png
[Center 17]: /images/20210920/18b39248a7f54f6b8b13ff944ae7ffe4.png
[Center 18]: /images/20210920/d25bcd5a44c24f799944204120ac40a5.png
[Center 19]: /images/20210920/252bf27bf80448888baaf66cf3486cb3.png
[Center 20]: /images/20210920/4252374f5d0a40daa0fd4ca3d5684405.png
[Center 21]: /images/20210920/2c779a7248854d1cb2012abbd2a55742.png
[Center 22]: /images/20210920/1893cd801a0e445293d2e5175bae4ebd.png
[Center 23]: /images/20210920/a8cb25c8c3fb49059839341a4111f77e.png
[Center 24]: /images/20210920/cb64744e6beb4debb268113da62633b9.png
[Center 25]: /images/20210920/6498e5f7cfc944b4bd2cd1bf9b20f767.png
[Center 26]: /images/20210920/7c74b499ee564679a3f953ccd721a4f3.png
[Center 27]: /images/20210920/844ab50d97c8447fb413294c1b4df7f0.png
[Center 28]: /images/20210920/216210e3d2554854b5b06f77eb2b162b.png
[Center 29]: /images/20210920/c533a7ea24894f4fb8f913ce9ccc326b.png
[Center 30]: /images/20210920/1bfeefb1a35342d5b8fa9f559116c1a1.png
[Center 31]: /images/20210920/594b637114014ec6a2ab8b27b4b4e7c2.png
[Center 32]: /images/20210920/03b93115df15470688faa294d6d2359c.png
[Center 33]: /images/20210920/3a574820812e435b878e53e21f22a87a.png