1
2
3
4
5
6
7
8
9
10
11

$ ll .git
total 32
-rw-r--r--   1 zhangjun  staff   23 12 20 13:48 HEAD  
drwxr-xr-x   2 zhangjun  staff   68 12 20 13:48 branches  
-rw-r--r--   1 zhangjun  staff  137 12 20 13:48 config  
-rw-r--r--   1 zhangjun  staff   73 12 20 13:48 description  
drwxr-xr-x  11 zhangjun  staff  374 12 20 13:48 hooks  
-rw-r--r--   1 zhangjun  staff  209 12 20 21:55 index  
drwxr-xr-x   3 zhangjun  staff  102 12 20 13:48 info  
drwxr-xr-x  10 zhangjun  staff  340 12 21 09:13 objects  
drwxr-xr-x   4 zhangjun  staff  136 12 20 13:48 refs

HEAD文件、index文件、objects目录、refs目录是我们这里需要重点关注的。其中，HEAD属于一种特殊的引用，其余所有引用在未压缩的情况下都存储于refs目录下。index文件为一个二进制文件，即为缓冲区，记录了工作目录下所有需要跟踪的文件的索引和状态（记住！！这里是索引，不记录实际存储对象）。三种特殊的对象（blob,tree,commit）在未压缩的情况下存储于objects目录下。我们先从最基础的Git仓库的存储单元说起：blob对象。

1
2
3
4
5

$ echo "test content" > test.txt
$ git hash-object -w test.txt  
d670460b4b4aece5915caf5c68d12f560a9fe3e4  
$ git cat-file -p  d670460b4b4aece5915caf5c68d12f560a9fe3e4  
test content

hash-object命令先会给text.txt计算出文件头，然后将文件头加上文件本身内容计算出一个SHA-1哈希值 d67046 ，通过-w参数，git会将test.txt文件进行zlib压缩，生成一个blob对象，存入git仓库，最后再返回对应的SHA-1值。在Git中，该SHA-1值即为text.txt文件的索引。（如上面所示，我们可以使用 cat-file -p 命令查看索引 d67046 指向的blob对象的具体内容， cat-file -p 命令是Git查看文件的瑞士军刀，只要是Git对象都可以通过SHA-1值查看存储的对象内容）。我们可以进入到Git的仓库目录 .git 文件夹下，看看我们的这个文件的版本记录被转存到了哪里。

1
2

$ find .git/objects -type f  
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

可以看到Git以SHA-1值的前两位作为文件目录，将blob对象存储在了.git/objects文件夹。那么一个文件的多个版本Git怎么存储呢？我们可以试验一下

1
2
3
4
5
6
7
8

$ echo "text content version 2" > test.txt
$ git hash-object -w test.txt  
2638ce0f549ff134a334e415c6e3a9fbc5ae2035
$ git cat-file -p  2638ce0f549ff134a334e415c6e3a9fbc5ae2035  
text content version 2    
$ find .git/objects -type f  
.git/objects/26/38ce0f549ff134a334e415c6e3a9fbc5ae2035  
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

可以看到git将两个版本的test.txt文件分别进行了存储，而非增量的形式存在，这是Git的默认存储方式，松散存储。好处是不用追溯多个版本去还原一个文件的内容，但同时也会牺牲一定的存储空间，Git为了解决空间利用的问题，提供了文件gc的功能，但这不是重点，我们略过不谈。 有了上面的两个blob对象，我们其实就可以进行版本管理了，向下面这样，我们可以轻松的一个文件的两个版本上进行切换。

1
2
3
4
5
6

$ git cat-file -p 2638ce0f549ff134a334e415c6e3a9fbc5ae2 > test.txt  
$ cat test.txt  
text content version 2  
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4 > test.txt  
$ cat test.txt  
test content

看，我们成功的将文件恢复至了第一个版本。

我们可以尝试一下手动创建一个tree对象。tree对象可以借助Git的缓冲区（index文件）进行创建。我们首先将文件的索引加入缓冲区，而后将缓冲区中的索引集合转化为tree对象。通过Git的 update-index 和 write-tree 命令，我们可以轻松的做到这一点。

1
2
3
4
5
6
7
8
9
10
11

$ git update-index --add test.txt  
$ git write-tree  
19600deac4f0ab9b5fa0fc61c9ee03647cfe61ce   
$ git cat-file -t 19600deac4f0ab9b5fa0fc61c9ee03647cfe61ce  
tree  
$ git cat-file -p 19600deac4f0ab9b5fa0fc61c9ee03647cfe61ce  
100644 blob 2638ce0f549ff134a334e415c6e3a9fbc5ae2035	test.txt  
$ find .git/objects -type f  
.git/objects/19/600deac4f0ab9b5fa0fc61c9ee03647cfe61ce  
.git/objects/26/38ce0f549ff134a334e415c6e3a9fbc5ae2035  
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

我们将Git缓冲区中的所有索引以类似快照的形式生成了一个SHA-1值为 19600d 的tree对象，该tree对象即为此次缓冲区的历史版本。这里细心的同学会注意到，我们并没有对 test.txt 对象做 hash-object -w 操作，但是同样在objects目录下生成了 2638ce 对象。我们可做这样的猜想，Git的 update-index 命令在执行时，会先执行 hash-object 命令，为文件生成SHA-1值，如果SHA-1值不存在于缓冲区，或者与现有缓冲区中的SHA-1值不同，则会先执行命令 hash-object -w 操作，生成blob对象，然后再新增或者更新文件的索引至缓冲区。 我们再尝试增加一个文件验证一下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ echo "new text" > new.txt  
$ git update-index --add new.txt   
$ git ls-files --stage
100644 blob eee417f1b97a31f35ceb5f0e7d0bae6e78c5290a 0  new.txt  
100644 blob 2638ce0f549ff134a334e415c6e3a9fbc5ae2035 0  test.txt
$ find .git/objects -type f
.git/objects/19/600deac4f0ab9b5fa0fc61c9ee03647cfe61ce  
.git/objects/26/38ce0f549ff134a334e415c6e3a9fbc5ae2035  
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
.git/objects/ee/e417f1b97a31f35ceb5f0e7d0bae6e78c5290a
$ git write-tree  
369fe222da08762cb4f02ddee8efc4637afbc5a2
$ git cat-file -p 369fe222da08762cb4f02ddee8efc4637afbc5a2  
100644 blob eee417f1b97a31f35ceb5f0e7d0bae6e78c5290a	new.txt  
100644 blob 2638ce0f549ff134a334e415c6e3a9fbc5ae2035	test.txt

这一次，我们在执行 update-index -add 命令后，执行了 ls-files --stage 命令，该命令可以查看缓冲区中的索引情况。这里，我们看到在 update-indxe -add 命令之后，objects目录新生成了一个索引为 eee417 的blob对象，而后该索引被加入到缓冲区中。在执行 write-tree 命令后，我们看到生成的tree对象的内容即为缓冲区的一个快照。

有了tree对象，我们就可以方便的将整个项目的工作目录进行版本管理了。首先将整个工作目录的文件加入缓冲区（即加入索引），然后再通过缓冲区生成tree对象，这样就不用一个个的为项目中的文件使用 hash-object 命令，添加版本控制了。但一个项目在迭代过程中，肯定会产生很多的tree对象，怎么组织这些tree对象，串联出一个项目的时间线（即历史信息）呢？怎么样能够随时在一个项目不同时期的版本上随意切换呢？Git为我们提供了一个很好的解决方案：commit对象。

每个commit对象必然携带一个tree对象，即一一对应。这样，commit对象就像是tree对象的一个“说明书”，提供了tree对象的提交时间和提交描述，最重要的是，提供了父亲tree对象的“说明书”的地址（即父亲commit对象指针）。这样零散的tree对象就通过commit对象，在时间线上被前后串联了起来。我们想要查看一个文件的历史版本，只需要在commit对象上追溯，找到这个文件相关的所有commit对象指向的tree对象，接着再找到所有tree对象中，该文件的索引值，就可以随意翻看这个文件的所有历史改动。

我们可以通过Git的 commit-tree 命令来模拟一下commit的串联。
我们先将我们刚才获取到的第一个tree对象 19600d 进行一次提交

1
2

$ echo "first commit" | git commit-tree 19600deac4f0ab9b5fa0fc61c9ee03647cfe61ce  
d6da9cff6a5278d68c34f53edd3cfac8739d8fcd

这样我们得到了一个 d6da9c commit对象，继续将第二个tree对象进行提交，并指定 d6da9c 为其父commit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$ echo "second commit" | git commit-tree 369fe222da08762cb4f02ddee8efc4637afbc5a2 -p d6da9c  
8cbf9de25c7bf88fa3cb55718d90da9601162ed3  
$ git log --stat 8cbf9  
commit 8cbf9de25c7bf88fa3cb55718d90da9601162ed3  
Author: 张钧 <jun.zhang@xxx.com>  
Date:   Wed Dec 21 09:13:26 2016 +0800  

    second commit  

 new.txt | 1 +  
 1 file changed, 1 insertion(+)  

commit d6da9cff6a5278d68c34f53edd3cfac8739d8fcd  
Author: 张钧 <jun.zhang@xxx.com>
Date:   Wed Dec 21 09:12:29 2016 +0800  

    first commit  

 test.txt | 1 +  
 1 file changed, 1 insertion(+)

通过 git log 命令，我们发现，两个commit对象已经串联了起来，我们已经有了一个工作目录的历史版本记录，如下图所示。

1

$ git update-ref refs/heads/master 8cbf9de25c7bf88fa3cb55718d90da9601162ed3

我们通过 git update-ref 命令创建了一个 master 引用，现在我们分别使用 master 引用和SHA-1哈希值查看一次log。

1
2
3
4
5
6

$ git log --pretty=oneline master  
8cbf9de25c7bf88fa3cb55718d90da9601162ed3 second commit  
d6da9cff6a5278d68c34f53edd3cfac8739d8fcd first commit  
$ git log --pretty=oneline 8cbf9de25c7bf88fa3cb55718d90da9601162ed3  
8cbf9de25c7bf88fa3cb55718d90da9601162ed3 second commit  
d6da9cff6a5278d68c34f53edd3cfac8739d8fcd first commit

效果完全一样，还有一个有意思的地方，执行一下 git branch 命令看看

1
2

$ git branch  
* master

其实通过 git update-ref 命令，我们已经创建了一个 branch 。实际上，每当你执行 git branch (分支名称) 这样的命令，Git 基本上就是执行 update-ref 命令，把你现在所在分支中最后一次提交的 SHA-1 值，添加到你要创建的分支的引用。同样的原理也适用于 git tag 命令，区别仅是 branch 的引用存储在 refs/heads 而 tag 的引用存储在 refs/tags 。 现在的问题是，在上面执行命令时，我们指定了SHA-1值为 8cbf9d ，所以一切顺利。但是当你执行 git branch (分支名称) 这条命令的时候，如果你不知道最后一次提交的SHA-1值，该怎么办呢？

这里Git增加了一个比较特殊的引用：HEAD。可以观察一下HEAD文件的内容

1
2

$ cat .git/HEAD  
ref: refs/heads/master

可以发现HEAD文件，实际是一个指向引用的引用。Git将它设定为始终指向了当前工作目录的最后一次提交的 SHA-1 值。例如现在，HEAD指向了 master 引用，实际也就是指向了当前工作目录的最新一次commit： 8cbf9d 。这样的做法，对于打出新的tag和branch来说非常方便，只需把HEAD指向的commit的SHA-1值添加到你要创建的 branch 或者 tag 的引用上即可。

最后，我们还有一类特殊的我们一带而过：remotes。这类引用指代了本地仓库关联的远程仓库的引用情况。如果你在进行团队协作可发，那么很可能你会使用到到remotes引用。

所以，全局的来看，Git的核心结构大致是如下这样的

1
2
3
4
5
6
7
8

$ git clone git@10.3.4.127:ucarapi/test.git
Cloning into 'test'...
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 13 (delta 1), reused 0 (delta 0)
Receiving objects: 100% (13/13), done.
Resolving deltas: 100% (1/1), done.
Checking connectivity... done.

这样， test.git 仓库的所有对象以及引用都已同步至本地了。有一点不同的是，本地仓库的分支结构，并没有和我们预期的一样和远程仓库保持一致。我们的远程仓库上存在了两个分支，一个master一个newFeature。我们可以在本地仓库上通过 git branch 查看一下分支情况。

1
2

$ git branch
* master

我们会发现，本地仓库里并没有newFeature分支。这时怎么回事呢？实际上 git clone 将test仓库的所有对象信息都同步至了本地仓库。但是对于引用，Git对于远程仓库的引用做了特殊处理，在本地将这些引用信息保存为了remotes引用（前面有提到过）。为了解释这一点，我们可以看看git仓库中的情况。

1
2
3
4

$ cat .git/packed-refs  
# pack-refs with: peeled fully-peeled
2887c8545d14da32961c4606af2ceb6cfb4247fd refs/remotes/origin/master
a4a5b5526bf0dcec1cb1d34076d0f2b7ae60e49a refs/remotes/origin/newFeature

这里我们查看了.git/packed-refs信息，Git在进行远程仓库之间的信息交互时，为了节省流量会将对象和引用进行压缩，所以现在远程仓库中的引用信息被压缩在了packed-refs目录。我们看到，远程仓库的分支引用都完好的保存了下来。我们继续看一下分支引用所指向的commit的日志信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$ git log a4a5b5526bf0dcec1cb1d34076d0f2b7ae60e49a 
commit a4a5b5526bf0dcec1cb1d34076d0f2b7ae60e49a
Author: 张钧 <jun.zhang@xxx.com>
Date:   Mon Dec 26 16:28:41 2016 +0800

    newFeature

commit 2887c8545d14da32961c4606af2ceb6cfb4247fd
Author: 张钧 <jun.zhang@xxx.com>
Date:   Wed Dec 21 23:09:37 2016 +0800

    commit 3.2

commit 8cbf9de25c7bf88fa3cb55718d90da9601162ed3
Author: 张钧 <jun.zhang@xxx.com>
Date:   Wed Dec 21 09:13:26 2016 +0800

    second commit

commit d6da9cff6a5278d68c34f53edd3cfac8739d8fcd
Author: 张钧 <jun.zhang@xxx.com>
Date:   Wed Dec 21 09:12:29 2016 +0800

    first commit

可以看到 这个commit关联了3个commit，我们去Git仓库中看看这些commit是否存在。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ git verify-pack -v .git/objects/pack/pack-7868e822bc1d53620a707a9ed966be65cf75301e.idx
a4a5b5526bf0dcec1cb1d34076d0f2b7ae60e49a commit 219 162 12
2887c8545d14da32961c4606af2ceb6cfb4247fd commit 219 159 174
8cbf9de25c7bf88fa3cb55718d90da9601162ed3 commit 222 161 333
d6da9cff6a5278d68c34f53edd3cfac8739d8fcd commit 173 130 494




    

9485c511eefddc52614b9b6aaceeb62a2bb3ebe4 tree   149 133 624
eee417f1b97a31f35ceb5f0e7d0bae6e78c5290a blob   9 18 757
954a536f7819d40e6f637f849ee187dd10066349 blob   7 16 775
bc356e0f3db2ab50f9080abe9063d40247a81e3c blob   11 20 791
d670460b4b4aece5915caf5c68d12f560a9fe3e4 blob   13 22 811
e0174588e623af8f2b8060b06bbb95bd79b7ba8a tree   8 19 833 1 9485c511eefddc52614b9b6aaceeb62a2bb3ebe4
369fe222da08762cb4f02ddee8efc4637afbc5a2 tree   71 76 852
2638ce0f549ff134a334e415c6e3a9fbc5ae2035 blob   23 33 928
19600deac4f0ab9b5fa0fc61c9ee03647cfe61ce tree   36 47 961
non delta: 12 objects
chain length = 1: 1 object
.git/objects/pack/pack-7868e822bc1d53620a707a9ed966be65cf75301e.pack: ok

前面说到了，Git在进行远程仓库同步时会压缩对象和引用以节省流量。这里对象都被压缩在了 .git/objects/pack 包的.pack文件下，同时Git还为pack文件创建了索引文件，.idx文件。我们可以通过 git verify-pack 访问索引文件，来检查pack包中的文件内容。这里前四条索引恰好就是我们要找的4条commit记录，可见newFeature分支已经被我们完整的从远程仓库克隆了下来。为了证明这一点，我们可以断网尝试切换分支到newFeature。

1
2
3
4
5
6
7
8

$ git branch
* master
$ git checkout newFeature
Branch newFeature set up to track remote branch newFeature from origin.
Switched to a new branch 'newFeature' 
$ git branch
master
* newFeature

我们并没有经过网络传输，在本地成功切换到了newFeature分支。

1
2
3

$ git branch newFeature1
$ git checkout newFeature1  
Switched to branch 'newFeature1'

这样，我们就已经切换至最新的分支了。我们尝试在新分支上做点改动。

1
2
3
4
5
6

$ echo "newFeature1" > newFeature1.txt
$ git add newFeature1.txt  
$ git commit -m 'newFeature1 commit'  
[newFeature1 36161ba] newFeature1 commit
 1 file changed, 1 insertion(+)
 create mode 100644 newFeature1.txt

我们成功在分支 newFeature1 上提交了改动。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ rm newFeature1.txt  
$ git status
On branch newFeature1
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:    newFeature1.txt

no changes added to commit (use "git add" and/or "git commit -a")  
$ git rm newFeature1.txt
$ git commit -am "remove newFeature1.txt"  
[newFeature1 5ab34cb] remove newFeature1.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 newFeature1.txt

这样，我们就成功删除了newFeature1.txt文件同时移除了该文件的版本控制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

$ git revert HEAD
[newFeature1 e50edf7] Revert "remove newFeature1.txt"
 1 file changed, 1 insertion(+)
 create mode 100644 newFeature1.txt  
$ ll
-rw-r--r--  1 zhangjun  staff   9 12 26 17:04 new.txt
-rw-r--r--  1 zhangjun  staff   7 12 26 17:04 new2.txt
-rw-r--r--  1 zhangjun  staff  11 12 29 16:31 newFeature.txt
-rw-r--r--  1 zhangjun  staff  12 12 29 22:41 newFeature1.txt
-rw-r--r--  1 zhangjun  staff  13 12 26 17:04 test.txt  
$ git log 
commit e50edf76fe3db0b9b43e86a41439cdfd86dc9ae9
Author: 张钧 <jun.zhang@xxx.com>
Date:   Thu Dec 29 22:41:19 2016 +0800

    Revert "remove newFeature1.txt"

    This reverts commit 5ab34cb84ad78e0896e4b35bb7cc6e122d03fa34.

commit 5ab34cb84ad78e0896e4b35bb7cc6e122d03fa34
Author: 张钧 <jun.zhang@xxx.com>
Date:   Wed Dec 28 20:42:46 2016 +0800

    remove newFeature1.txt

commit 36161ba9d436e41410f381ba02376dcaef453ab4
Author: 张钧 <jun.zhang@xxx.com>
Date:   Tue Dec 27 10:09:56 2016 +0800

    newFeature1 commit  
...

看，newFeature1.txt文件又回来了，同时log日志中多出了一次commit记录，标识了我们对本地Git仓库进行了一次revert操作。

而 git rebase 命令则是将master分支上打出newFeature1分支之后的commit记录全部挂起，然后将master分支重新定位至newFeature1分支的最后一次commit记录，最后再将挂起的commit记录依次添加到重新定位的commit记录之后。这样将产生一个直线形的提交树，就像下面这样

二者的特性可以从两个命令的语义上清晰的体现出来：merge将改变 融合 到当前的分支中从而产生新的提交，这样这个提交会像新生的提交一样，排列在提交记录的最前面；rebase不产生新的提交，而是将分支 重定向 到了新的提交树上，通过 改变历史 达到改变分支代码的效果。二者依其特性各有各自的适用场景：

git merge 适用于在开发完成后合并自己的代码至发布分支时使用，因为rebase不能很好的记录分支的合并的时间点——一旦rebase相当于就改变了历史，没法追溯是在哪个commit节点时进行的代码合并。从团队代码管理的角度来说，管理员会更希望看到发布分支上的每一个合并动作发生的时间，提交人，合并的代码内容等等。这些都是rebase没办法做到的。

git rebase 适用于在开发过程中同步别人的变更代码时使用，因为从时间上来看变更的代码在你开发的代码之前进入了远程仓库，同步时采用rebase不会产生多余的commit记录，且历史记录看上去也更加自然——因为变更的历史记录都会自然而然的排列在你的提交之前。

我们试着将我们的代码合并会master分支，既然是合并回master分支，那么我们使用 git merge 命令来完成这一操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$ git checkout master
$ git merge newFeature1
$ git log --graph
*   commit 479b622da90b67891329ee0b898a690fa6d13f3a
|\  Merge: 5fc6e12 e50edf7
| | Author: 张钧 <jun.zhang@xxx.com>
| | Date:   Thu Jan 5 17:16:35 2017 +0800
| |
| |     Merge branch 'newFeature1'
| |
| |     merge信息
| |
| * commit e50edf76fe3db0b9b43e86a41439cdfd86dc9ae9
| | Author: 张钧 <jun.zhang@xxx.com>
| | Date:   Thu Dec 29 22:41:19 2016 +0800
| |
| |     Revert "remove newFeature1.txt"
| |
| |     This reverts commit 5ab34cb84ad78e0896e4b35bb7cc6e122d03fa34.
| |

可以看到我们产生了一个梯形的提交树（前面的提交记录太长未予展示），同时多了一个因为merge产生的commit 479b62 同时提示我们这个merge是因为两个commit记录 5fc6e12 和 e50edf7 融合产生的。

我们先查看一下我们需要推送的远程仓库地址是否正确，这一步可以使用 git remote -v 来查看。

1
2
3

$ git remote -v
origin	git@10.3.4.127:ucarapi/test.git (fetch)
origin	git@10.3.4.127:ucarapi/test.git (push)

可以看到 我们现在有一个叫做 origin 的远程仓库地址。现在我们从 origin 上抓取最新的代码至本地仓库。这里我们可以使用 git pull 命令 或者 git fetch 命令 。 二者的区别在于 git pull 命令会在将commit同步至本地仓库的同时，尝试在指定的分支上（或者默认追踪的分支上）进行 git merge 操作。即 git pull 相当于 git fetch + git merge 。这里我们为了节省操作步骤使用 git pull （命令的参数格式请自行查阅文档，此处不再详述）

1
2
3
4

$ git pull origin master
From 10.3.4.127:ucarapi/test
 * branch            master     -> FETCH_HEAD
Already up-to-date.

好了，我们成功同步了本地的代码。此时我们可以保证我们的代码在同步至远程分支时不再产生冲突。

1
2
3
4
5
6
7
8

$ git push origin master
Counting objects: 10, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (10/10), 1.22 KiB | 0 bytes/s, done.
Total 10 (delta 2), reused 0 (delta 0)
To git@10.3.4.127:ucarapi/test.git
   2887c85..479b622  master -> master

这样我们成功的将代码发布至了远程仓库。

到此为止，我们就基本完成了开发工作过程中的整个生命周期。当然，在开发过程中还会遇到一些不在上述描述范围内的状况。例如代码冲突（在pull阶段可能发生），解决代码冲突的方式有很多，这里碍于篇幅原因，不再详述。

推送一个tag至远程仓库： git push origin v1.0

推送所有tag至远程仓库： git push origin --tags

首先要使用Git，需要下载Git客户端，可以从官网下载。下载安装完成后，在IDEA中配置执行文件路径。