本篇内容参考廖雪峰大佬的博客教程进行学习,初学者强烈推荐阅读!!!
Git简介
简单的说,Git就是一个版本控制系统,但如果第一次听到这个名词可能并不理解它到底是什么?什么叫版本控制?
就拿写论文来举例,我们在写论文的时候通常会经历多次修改,例如首先是初稿,然后要经过修改1、修改2、修改n、最后一次修改、最终版、最终版修改1、…遗书!。总之要经历无数次修改,无穷无尽,回忆起来都是泪😇。
其实这里每一次修改后的文件就是所谓的版本,而版本控制的意思其实就是有这么一个软件可以自始至终监控并记录每个人所做的每一次修改,这样就可以更好地去管理。
Git安装
Git最早是在Linux中开发的,目前已经被移植到了Windows和Mac OS平台
安装很简单,可以参考官网,这里不再赘述
Git用法总结
创建版本库
版本库,也就是要让Git追踪管理的仓库,实际上就是一个目录
首先我们要创建一个目录(使用已经存在的目录也可以),然后在该目录下执行git init
,这表示从现在开始,这个目录下发生的所有操作行为将由Git进行监控
$ git init
Initialized empty Git repository in C:/Users/iniduoH/Desktop/git-test/.git/
执行git init
后会在当前目录下生成一个.git
目录,这个目录是用来追踪版本库的,不要随意改动
添加文件到仓库
创建版本库后,可以在该目录下创建一个文件,然后使用git add
命令将文件先添加到暂存区,然后使用git commit -m "提交说明"
,将文件提交到仓库,作为一个版本
$ touch readme.txt
$ echo "This is a readme file." > readme.txt
$ git add readme.txt
$ git commit -m "First create readme.txt."
[master (root-commit) 18a9b90] First create readme.txt.
1 file changed, 1 insertion(+)
create mode 100644 readme.txt
查看当前版本库状态和文件变化
执行git status
命令可以让我们时刻掌握仓库当前的状态,比如当前目录下的文件是否是最新的版本?是否有准备提交的修改?
$ git status
On branch master
nothing to commit, working tree clean
此时,如果我们修改一下readme.txt
文件,再执行git status
,可以看到状态发生了变化
$ echo "add some content" > readme.txt
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
此时,我们可以使用git diff
查看做了什么修改
$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index d344129..eaada2c 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1 @@
-This is a readme file.
+add some content
最后,再次进行提交
$ git add readme.txt
$ git commit -m "first revise"
$ git status
On branch master
nothing to commit, working tree clean
版本更新日志和版本回退
版本更新日志
只要我们使用git commit
进行提交,那么每一次提交后的版本都会被git记录下来
可以通过git log
命令查看版本历史记录,显示最远到最近的提交日志,可以使用--pretty=oneline
精简输出;日志中显示的很长的一串类似d38970...
的字母和数字组合就是commit id
(版本号)
$ git log
commit d389705e7e7f9972c428c5b93b8d2f75e564c774 (HEAD -> master)
Author: Kaiyuan <[email protected]>
Date: Wed Dec 6 09:15:50 2023 +0800
first revise
commit 18a9b90252b13afe49d65b9cfccfb473bf88ad61
Author: Kaiyuan <[email protected]>
Date: Wed Dec 6 09:07:42 2023 +0800
First create readme.txt.
$ git log --pretty=oneline
d389705e7e7f9972c428c5b93b8d2f75e564c774 (HEAD -> master) first revise
18a9b90252b13afe49d65b9cfccfb473bf88ad61 First create readme.txt.
版本回退
现在,如果我们想回退到之前的某个版本可以使用git reset
指令,但是我们需要指定要回退的版本。
首先,我们可以使用版本号回退;其次,在git中用HEAD表示当前版本,也就是最新的提交,上一个版本记作HEAD^
,上上一个版本记作HEAD^^
,当然往上100个版本写100个^
比较容易数不过来,所以写成HEAD~100
,所以也可以用HEAD标记回退
- 版本号回退
$ git reset --hard 18a9
HEAD is now at 18a9b90 First create readme.txt.
$ git log
commit 18a9b90252b13afe49d65b9cfccfb473bf88ad61 (HEAD -> master)
Author: Kaiyuan <[email protected]>
Date: Wed Dec 6 09:07:42 2023 +0800
First create readme.txt.
- HEAD标记回退
$ git reset --hard HEAD^
HEAD is now at 18a9b90 First create readme.txt.
$ git log
commit 18a9b90252b13afe49d65b9cfccfb473bf88ad61 (HEAD -> master)
Author: Kaiyuan <[email protected]>
Date: Wed Dec 6 09:07:42 2023 +0800
First create readme.txt.
恢复未来的版本
由于回退版本后,git log
只会显示当前版本和之前的版本
如果回退后想恢复至未来的某个版本,则首先需要使用git reflog
查看未来某个版本的版本号,然后使用git reset
恢复(实际上git reflog
会记录每次对版本的操作)
$ git reflog
18a9b90 (HEAD -> master) HEAD@{0}: reset: moving to HEAD^
d389705 HEAD@{1}: reset: moving to d389
18a9b90 (HEAD -> master) HEAD@{2}: reset: moving to 18a9
d389705 HEAD@{3}: commit: first revise
18a9b90 (HEAD -> master) HEAD@{4}: commit (initial): First create readme.txt.
$ git reset --hard d389
HEAD is now at d389705 first revise
$ git log
commit d389705e7e7f9972c428c5b93b8d2f75e564c774 (HEAD -> master)
Author: Kaiyuan <[email protected]>
Date: Wed Dec 6 09:15:50 2023 +0800
first revise
commit 18a9b90252b13afe49d65b9cfccfb473bf88ad61
Author: Kaiyuan <[email protected]>
Date: Wed Dec 6 09:07:42 2023 +0800
First create readme.txt.
工作区和暂存区
工作区(Workspace)
也就是当前能看到的目录,使用git init初始化的目录,其中的.git
目录不属于工作区,而是git的版本库
我们正是在工作区中对内容进行增删改之类的操作
暂存区(Stage)
在git的版本库中,包含了暂存区、分支等诸多内容,默认git会为我们创建第一个分支master
和一个指向master
的指针HEAD
当我们执行git add
指令的时候就是把文件修改添加到暂存区
然后执行git commit
指令将暂存区的内容提交到当前分支,同时HEAD
执行当前分支的最新提交版本
撤销修改
撤销对工作区内容的改动
有两种指令可以丢弃工作区的改动:git checkout -- <filename>
或 git restore <filename>
其中,git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”
$ echo "add more content" >> readme.txt
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout -- readme.txt
$ git status
On branch master
nothing to commit, working tree clean
如果是已经添加至暂存区后又做了修改,同样撤销的是对工作区的修改,暂存区不变
撤销添加至暂存区的内容
使用git restore --staged <filename>
或 git reset HEAD <filename>
可以撤销添加至暂存区的这项操作,但是并没有撤销工作区的改动(也就是回到工作区修改完还没添加至暂存区的状态),如果想继续撤销工作区的修改则需要再执行上一小节的指令
$ echo "add more content" >> readme.txt
$ git add readme.txt
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: readme.txt
$ git restore --staged readme.txt
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
删除文件
在工作目录删除文件后,如果要提交删除后的版本,使用git rm <filename>
确定要删除的文件(也可以使用git add <filename>
,效果相同),然后使用git commit -m "message"
进行提交
$ touch test.txt
$ git add test.txt
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: test.txt
$ git commit -m "add a new file"
[master b5a9f5b] add a new file
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test.txt
$ git status
On branch master
nothing to commit, working tree clean
$ 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 restore <file>..." to discard changes in working directory)
deleted: test.txt
no changes added to commit (use "git add" and/or "git commit -a")
$ git rm test.txt
rm 'test.txt'
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: test.txt
$ git commit -m "delete test.txt"
[master c502366] delete test.txt
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 test.txt
$ git log --pretty=oneline
c502366af0b3d6ad17053a7734d05a1e88ac0f3b (HEAD -> master) delete test.txt
b5a9f5bdd1b1d8357aa08fbba10fb26364329a0d add a new file
d389705e7e7f9972c428c5b93b8d2f75e564c774 first revise
18a9b90252b13afe49d65b9cfccfb473bf88ad61 First create readme.txt.
如果删错了,也可以通过上面的撤销修改来进行恢复
使用git rm
可以删除一个文件,由于git的回退机制所以永远不用担心误删,但要注意从来没有被添加到版本库的文件是无法被恢复的
分支管理
所谓分支,可以大概理解为在当前版本库下(假设是master
)分叉出一条线,有点类似世界线和平行世界的概念,这条独立的线继承了当前版本库的全部内容,并且之后在这条独立的线上进行修改和提交等一系列操作均不会影响此前的master
分支
Git在初始化后会默认生成一个master
分支,并且只有这一条分支,我们一开始对版本库进行的操作均是在这条分支上进行
其实在前面版本回退部分提到的HEAD
指针严格意义上就是指向的当前分支的最新提交
创建/切换分支
首先可以使用git branch <branch_name>
创建一个分支,创建后可以直接执行git branch
查看所有分支和当前分支(当前分支前有*
标注),然后使用git checkout <branch_name>
或 git switch <branch_name>
切换分支
另外也可以通过git checkout -b <branch_name>
或 git switch -c <branch_name>
创建并切换到分支
$ git branch test
$ git branch
* master
test
$ git switch test
Switched to branch 'test'
$ git branch
master
* test
合并分支
首先在新分支上对文件进行一些修改并提交
$ git branch
master
* test
$ echo "add some contents" >> file1.txt
$ git add file1.txt
$ git commit -m "add contents in test branch"
[test 6a02dba] add contents in test branch
1 file changed, 1 insertion(+), 1 deletion(-)
在分支上完成修改工作后可以将其合并到主分支(master
)上,首先要先切换到master
分支,再执行git merge <branch_name>
将其他分支合并到当前分支
$ git switch master
Switched to branch 'master'
$ git merge test
Updating d038d5e..6a02dba
Fast-forward
file1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
只要两个分支没有对同一部分内容进行修改,那么上面的操作通常就可以顺利合并分支,否则的话就会因为冲突导致合并失败,因为git不知道该保存哪个分支的修改,然后就需要手动解决冲突
删除分支
使用git branch -d <branch_name>
删除分支
$ git branch -d test
Deleted branch test (was 6a02dba).
$ git branch
* master
解决合并冲突
现在就说明一下如果两个分支对同一部分内容进行了修改,然后在合并时的冲突问题
首先创建一个分支,并在一个文件中添加一行内容并提交
$ git branch test
$ echo "test" >> file1.txt
$ git add file1.txt
$ git commit -m "add content test"
[master 1ca71d8] add content test
1 file changed, 1 insertion(+)
然后回到master
分支,在同一个文件添加另外的一行内容并提交
$ git switch master
Already on 'master'
$ echo "master" >> file1.txt
$ git add file1.txt
$ git commit -m "add content master"
[master edcf03d] add content master
1 file changed, 1 insertion(+)
此时使用git merge
进行合并,可以发现由于存在冲突导致合并失败,可以通过git status
查看状态
$ git merge test
Auto-merging file1.txt
CONFLICT (content): Merge conflict in file1.txt
Automatic merge failed; fix conflicts and then commit the result.
$ git status
On branch master
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: file1.txt
no changes added to commit (use "git add" and/or "git commit -a")
当使用git merge
合并失败后,会进入到用于解决合并冲突的"模式或者过程",此时如果我们想取消合并需要执行git merge --abort
退出该"模式"。而如果想解决冲突并继续合并,则需要进入对应的文件进行修改
在这个"模式"下使用文本编辑器打开冲突文件后就会发现git使用<<<<<<< HEAD
,=======
,和>>>>>>> BRANCH-NAME
标记出了冲突内容的位置,此时我们需要将编辑的部分替换为我们希望合并后的内容(可以改为任意内容,甚至可以两个分支中的内容都无关),替换后使用git add
和git commit
添加并提交就可以完成合并(不再需要重新执行git merge
)
下面是操作示例:
首先查看冲突文件的内容:
...
...
<<<<<<< HEAD
master
=======
test
>>>>>>> test
随便替换为以下内容:
...
...
whatever I want
然后提交后就可以完成合并
$ git add file1.txt
$ git commit -m "fix conflicts"
[master 012bc8d] fix conflicts
$ cat file1.txt
...
...
whatever I want
用带参数的git log
也可以看到分支的合并情况(其中*
表示的是右侧log内容对应的分支):
$ git log --graph --pretty=oneline --abbrev-commit
* 012bc8d (HEAD -> master) fix conflicts
|\
| * 343e28f (test) test
* | 7a21c8f master
|/
* edcf03d add content master
* 1ca71d8 add content test
* 6a02dba add contents in test branch
* d038d5e correct the conflict
|\
| * b60ea8a add content dev
* | e46fa81 add content master
|/
* 0f45bbb add a file1.txt
* c502366 delete test.txt
* b5a9f5b add a new file
* d389705 first revise
* 18a9b90 First create readme.txt.
标签管理
发布一个版本时,可以先在版本库中打一个标签(tag),这样就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照
Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的
另外使用标签可以避免使用冗长的版本号,有点相当于版本号替代的感觉
创建标签
使用git tag <tag_name>
就可以默认在最新提交的版本上打一个标签
$ git log --pretty=oneline
012bc8dd722025bb10190a08be5e20ccb064a927 (HEAD -> master) fix conflicts
7a21c8fb8b2f068e00c8c223177fb123aeab2dd3 master
343e28f6666f1a996e59c2826c17435204f979c3 test
$ git tag v1.0
$ git log --pretty=oneline
012bc8dd722025bb10190a08be5e20ccb064a927 (HEAD -> master, tag: v1.0) fix conflicts
7a21c8fb8b2f068e00c8c223177fb123aeab2dd3 master
343e28f6666f1a996e59c2826c17435204f979c3 test
如果想给某个历史版本打标签就需要在后面加上版本号(commit_id),git tag <tag_name> <commit_id>
$ git tag v0.9 7a21
$ git log --pretty=oneline
012bc8dd722025bb10190a08be5e20ccb064a927 (HEAD -> master, tag: v1.0) fix conflicts
7a21c8fb8b2f068e00c8c223177fb123aeab2dd3 (tag: v0.9) master
343e28f6666f1a996e59c2826c17435204f979c3 test
使用git tag
可以查看存在的标签,使用git show <tag_name>
可以查看标签信息
$ git tag
v0.9
v1.0
$ git show v0.9
commit 7a21c8fb8b2f068e00c8c223177fb123aeab2dd3 (tag: v0.9)
Author: Kaiyuan <[email protected]>
Date: Thu Dec 7 17:35:17 2023 +0800
master
diff --git a/file1.txt b/file1.txt
index 1f143a0..d958a1b 100644
--- a/file1.txt
+++ b/file1.txt
@@ -2,3 +2,4 @@ file 1
correct the conflictadd some contents
test
master
+master
还可以创建带有说明的标签,需使用git tag -a <tag_name> -m <tag_message> <commit_id>
命令创建,然后使用git show <tag_name>
就可以看到说明
$ git tag -a v0.8 -m "version 0.8" 343e
$ git tag
v0.8
v0.9
v1.0
$ git show v0.8
tag v0.8
Tagger: Kaiyuan <[email protected]>
Date: Thu Dec 7 22:35:53 2023 +0800
version 0.8
commit 343e28f6666f1a996e59c2826c17435204f979c3 (tag: v0.8)
Author: Kaiyuan <[email protected]>
Date: Thu Dec 7 17:34:34 2023 +0800
test
diff --git a/file1.txt b/file1.txt
index 1f143a0..4caed33 100644
--- a/file1.txt
+++ b/file1.txt
@@ -2,3 +2,4 @@ file 1
correct the conflictadd some contents
test
master
+test
注意:标签总是和某个commit挂钩。如果这个commit既出现在master分支,又出现在dev分支,那么在这两个分支上都可以看到这个标签
删除标签
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地使用git tag -d <tag_name>
安全删除
如果要推送某个标签到远程仓库(远程仓库将在后面介绍),需要使用命令git push <remote_repo_name> <tagname>
,或者也可以使用git push <remote_repo_name> --tags
一次性推送全部尚未推送到远程的本地标签
如果标签已经推送到远程,要删除远程标签就麻烦一点,需要先使用git tag -d <tag_name>
从本地删除,然后使用git push <remote_repo_name> :refs/tags/<tag_name>
远程仓库
远程仓库可以大概理解为一台用于发布版本库的服务器,每个人可以把各自的提交推送的服务器仓库里,也可以从服务器仓库拉取别人的提交
Github就是知名的仓库托管网站,当然也可以搭建自己的Git服务器
Github
这里简单介绍一下添加Github远程仓库,由于国内无法访问Github,因此下面的操作在国内可能无法成功
首先,要注册一个Github账号,当然这里要访问的话也是需要一些"魔法",总之先要注册后登录账号,然后创建一个远程仓库(Create a new repository)
关联远程库(本地->远程)
我们要将本地仓库关联到创建的远程仓库上,这里有两种方式去连接:HTTPs(例如 https://github.com/user/repo.git
)和SSH(例如 [email protected]:user/repo.git
)。使用HTTPs的方式需要提供用户名和密码,而使用SSH的方式则需要在本地用户根目录下的.ssh
目录中生成密钥对,并将公钥保存到Github账户中,其中使用SSH速度更快,这里主要介绍SSH方式
将SSH公钥上传到Github后就可以在本地仓库中使用git remote add <shortname> <url>
进行关联,可以使用git remote -v
查看远程库信息。这里将远程库命名为origin
,也可以改成别的,但这是Git远程库默认的通用名字
$ git remote add origin [email protected]:user/repo.git
$ git remote -v
origin [email protected]:user/repo.git (fetch)
origin [email protected]:user/repo.git (push)
然后使用git push -u origin master
将本地库中master
分支中的内容推送至远程库origin
中
$ git push -u origin master
Enumerating objects: 6, done.
Delta compression using up to 2 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (6/6), 492 bytes | 492.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:mghts/learngit.git
* [new branch] master -> master
branch 'master' set up to track 'origin/master'.
由于远程库是空的,我们第一次推送master
分支时,通过使用-u
参数,k可以将本地分支与远程分支进行关联,并指定远程分支为默认的上游(upstream)分支。通过使用-u
参数,可以简化以后的git push
命令,因为在建立关联关系后,Git 将记住默认的上游分支,后续的git push
命令就可以直接使用而不需要指定远程和分支
删除/修改远程库:
如果想删除远程库,可以使用git remote rm <repo_name>
命令
如果想修改远程库的URL可以使用git remote set-url <repo_name> <URL>
如果想重命名远程库可以使用git remote rename <old_name> <new_name>
$ git remote rm origin
$ git remote set-url origin [email protected]:OWNER/REPOSITORY.git
$ git remote rename origin destination
从远程库克隆(远程->本地)
首先在Github上创建一个远程库,在创建时勾选Initialize this repository with a README
然后使用git clone <URL>
克隆一个本地库
$ git clone [email protected]:user/repo.git
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.
这个克隆下来的本地库会自动关联远程库信息
自建Git服务器
首先确保服务器安装了git,安装后新建一个git用户,并在git用户目录下创建一个.ssh
目录
$ adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
然后要在.ssh
目录下新建一个authorized_keys
文件用于存放访问者的SSH公钥,这里要注意该文件的权限一定要设为600
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
然后新建一个目录(通常为.git
结尾)并使用git init --bare
初始化为一个git空仓库,然后开发者就可以设置该仓库为远程仓库并进行关联、推送、克隆等操作
git init --bare
创建的是一个“裸”(bare)的Git仓库。与普通的Git仓库不同,裸仓库通常不包含工作目录,它仅包含Git版本控制所需的元数据和对象数据库。具体来说,
--bare
选项用于创建一个没有工作目录的Git仓库,这种仓库通常用于作为集中式的版本库,用于共享和协作。裸仓库中没有实际的项目文件,只存储Git的版本历史信息。这种类型的仓库通常用于服务器上,以便多个开发者能够推送(push)和拉取(pull)代码,而不涉及工作目录。裸仓库通常用于搭建集中式的版本控制系统,例如在团队或项目的服务器上。它们不包含项目文件,因此不能直接用于工作或开发,而是用于协作和共享代码。在裸仓库中,分支、标签和其他Git的元数据信息都存储在.git目录中,而不是与工作目录一起存储。
$ mkdir /home/git/temp.git
$ cd /home/git/temp.git
$ git init --bare
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /home/git/temp.git/
$ cd ..
$ chown -R git:git temp.git
出于安全考虑,最好禁止git用户登陆shell,可以为git指定一个名为git-shell的受限shell工具,这样,git用户可以正常通过ssh使用git,但无法登录shell,因为我们为git用户指定的git-shell每次一登录就自动退出
可以使用which git-shell
查看git-shell是否存在系统中并确定其位置,然后可以使用chsh <username> -s <shell>
命令修改任一系统用户的shell;除了该方法,也可以直接修改/etc/passwd
文件中git用户的shell
禁止shell登录后,后续我们想新建一个空仓库就需要root用户去创建,创建并初始化后就需要注意修改这个仓库的所属用户,不然git没权限访问也就是需要chown -R git:git example.git
$ which git-shell
/usr/bin/git-shell
$ chsh git -s /usr/bin/git-shell
$ cat /etc/passwd
git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
然后可以参考前面的内容进行关联或者克隆远程仓库等操作,但需要注意的是,有时候我们的服务器SSH使用的并不是默认的22号端口,这时候需要修改URL为ssh://<git_user>@<ip_addr>:<port_number><remote_repo_path>
,例如:
$ git remote add origin ssh://[email protected]:1234/home/git/repo/git
$ git clone ssh://[email protected]:1234/home/git/repo/git
后记
本篇内容应该可以包含所有git的基本用法,尤其是对于我这种非开发人员(甚至是本地用户)绝对够用了。
写完最后发现其实还蛮多的,但git的用法和功能远不止这些,至于其他的用法后续会通过额外的小篇章进行补充