git入门

git入门手册

说明

系统:Windows(影响不大,一些默认路径可能会有区别)

安装:建议参考一篇更详细的教程:Git 详细安装教程(详解 Git 安装过程的每一个步骤)_mukes的博客-CSDN博客_git安装

参考:Git - Book (git-scm.com)

​ 本文对官方文档的内容做了一些精简,主要覆盖了一些基本的操作和需求,满足同学日常使用。如果你希望更快的掌握:可以看完第一章配置后,直接跳到最后一章 Github/Gitee 的实战部分,之后再根据你的需求从目录跳到相应的章节。git 并不是一个很难的东西,基础操作只有几个命令,使用它,会让你少几次代码改崩的崩溃。需要更加详细的信息,建议去官网查看。希望补充内容,或者内容有问题,联系邮箱:1993371310@qq.com。好了,我们开始吧。

1.初次运行 git 前的配置

1.1.讲解部分(可以跳过,直接进入操作部分)

在配置之前,需要先了解一下三个级别的配置文件:

  • /etc/gitconfig,所有用户及仓库的通用配置,可以在你自己 git 的安装路径里面找到。congif 代表配置。

  • ~/.gitconfig 或者 ~/.config/git/config,一般在C:\Users\user_name 里面可以找到。user_name 代表 Windows 系统下你自己的用户名。~ 一般代表用户目录。而在 Windows 里的用户目录一般在 C 盘。那很显然这里的配置只对当前的用户有用。

  • 当前仓库下的 config ,配置只针对该仓库。

我们选择在 Git Bash 里面操作,跟 windows 的 cmd 一样。配置/编辑的语法示例

git config --global user.name "ZhangSan"
  • --global 用来配置 ~/.gitconfig 或者 ~/.config/git/config,可以替换成 --system 配置/etc/gitconfig--local 配置当前仓库下的 config 。一定要清楚你想让配置生效的范围;
  • user.name 可用其他任意变量名代替,后面跟配置的值是多少,字符串要加引号
  • 每一个级别会覆盖上一级别的配置,所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。
  • 如果使用了 --global 选项,那么该命令只需要运行一次,因为之后无论你在该系统上做任何事情, Git 都会使用那些信息

如果我们要查看配置:

$ git config --list			# 查看所有配置
$ git config user.name		# 查看指定的配置
$ git config --show--origin	# 可以查询 Git 中该变量的 原始 值,它会告诉你哪一个配置文件最后设置了该值

你可能会看到重复的变量名,因为 Git 会从不同的文件中读取同一个配置(例如:/etc/gitconfig~/.gitconfig)。 这种情况下,Git 会使用它找到的每一个变量的最后一个配置。

1.2.操作部分

配置自己的用户名和邮箱在~/.gitconfig 下,这是你安装后第一个要做的事。示例如下

$ git config --gloabl user.name "ZhangSan"
$ git config --global user.email xxxxx@163.com

在官方部分,可能还会指出让你配置编辑器,这里你可以查看一下,是不是已经配置好了(如果你根据上面推荐的 blog 安装,在安装部分应该已经选过了)

$ git config core.editor

1.3.如何获取帮助

获得详细的帮助, 表示要查询的对象

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

获得简单的帮助

$ git <verb> -h

2.获取 git 仓库

2.1.将尚未进行版本控制的本地目录转换为 Git 仓库

先进入你的项目目录,注意和 cmd 不同,用 / 而不是 \ ,并且选择进入哪个盘时直接 /c/ 。这里是以 c 盘为例的,your_path 代表你的项目在对应盘下的路径。

$ cd /c/your_path

之后执行如下。该命令将创建一个名为 .git 的子目录,这个子目录含有你初始化的 Git 仓库中所有的必须文件,这些文件是 Git 仓库的骨干。

$ git init

添加指定文件进行跟踪(指将文件纳入版本控制)。比如,我们需要跟踪 helloworld.py 文件,就如下

$ git add <file/path>
$ git add helloworld.py			# 示例

在添加时,可能会出现一个警告

warning: LF will be replaced by CRLF in timely_test.ipynb.
The file will have its original line endings in your working directory
警告:在 timely_test.ipynb 的 LR 将被替换成 CRLR。你的工作目录里的文件将还是它原始的换行。

这里只是警告,建议忽略就好。LF 和 CRLF 分时是 Linux/unix 和Windows系统上的换行符,为了方便跨平台的工作,会自动转换。会有一个参数 core.autocrlf 来设置,默认是 True。

之后执行 git commit,我这里是添加了三个文件

$ git commit -m 'initial project version'
2022-03-28_16-07

2.2.克隆现有的仓库

克隆仓库的命令是 git clone <url> 。 比如,要克隆 Git 的链接库 libgit2,可以用下面的命令:

$ git clone https://github.com/libgit2/libgit2

这会在当前目录下创建一个名为 “libgit2” 的目录,并在这个目录下初始化一个 .git 文件夹, 从远程仓库拉取下所有数据放入 .git 文件夹,然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 libgit2 文件夹,你会发现所有的项目文件已经在里面了,准备就绪等待后续的开发和使用。

如果你想在克隆远程仓库的时候,自定义本地仓库的名字,你可以通过额外的参数指定新的目录名:

$ git clone https://github.com/libgit2/libgit2 mylibgit

这会执行与上一条命令相同的操作,但目标目录名变为了 mylibgit

Git 支持多种数据传输协议。 上面的例子使用的是 https:// 协议,不过你也可以使用 git:// 协议或者使用 SSH 传输协议,比如 user@server:path/to/repo.git在服务器上搭建 Git 将会介绍所有这些协议在服务器端如何配置使用,以及各种方式之间的利弊。

3.记录每次更新到仓库

3.1.检查文件当前状态

在工作目录下的文件有两种状态已跟踪未跟踪(Untracked)。对于已跟踪的文件,可能有三种状态:未修改(Unmodified)、已修改(Modified)和已放入缓存区(Staged:changes to be commit)。这里特意注明了单词,是因为我们在检查文件状态时会看到相应的列表。检查方法如下:

$ git status
2022-03-28_16-07

上面是查询的结果,希望你可以去尝试读懂。第一句 on branch master 这个是说当前的分支是master,在安装时应该有印象,是说因为什么黑人事件改了。第二句话时是在说我未跟踪的文件 untracked files 有哪些并且给出来了。括号里告诉我怎么去跟踪。又说 nothing to commit,因为我现在还没对文件做任何修改,没有暂存的文件。最后又说了我还有未跟踪的文件。在官方文档还有一句是关于远程部署的,这里没有服务器只是在本地,所以没有。

如果你查询出来的结果跟我不一样,希望你也试着去读懂,这个很重要!在我把所有文件跟踪后,查询的结果如下:(tree 这里和 branch 对应)

2022-03-28_18-55

3.2.跟踪新文件

在配置部分已经尝试过了,这里另外说明一下,如果添加目录来跟踪,则会递归的跟踪该目录下的所有文件。

3.3.暂存已修改文件

我去修改了我的 readme.md 文件,再去查看状态有 changes not staged for commit ,即已跟踪的文件发生了变化,但是没有放到暂存区。

2022-03-28_19-10

git add 将它放到暂存区,之后再查看状态:

2022-03-28_21-15

注意: git add 这时的功能可以理解为快照,它只记录你在执行 git add 时的文件内容,如果你希望暂存新的修改,就要再执行一次 git add

3.4.状态简览

$ git status -s	# 或者
$ git status --short

这里会用一些状态标记:A (add)表示新添加到暂存区,M (modefied)表示修改过,? 表示未跟踪的文件。状态栏由两个状态标记的位置,前面的表示暂存区,后面的表示工作区。

$ git status -s
 M README				# 已修改尚未暂存
MM Rakefile				# 已修改,暂存后又做了修改
A  lib/git.rb			# 新添加到暂存区
M  lib/simplegit.rb		# 已修改且已暂存
?? LICENSE.txt			# 新添加未跟踪

3.5.忽略文件

可能有一些临时的文件,不用纳入 git,也不想看到出现在未跟踪列表。对于这种情况,可以创建一个名为 .gitignore 的文件,列出要忽略文件的格式。类似正则匹配,这里先不详细列出。你可以在这里看到更加详细的说明:https://github.com/github/gitignore

3.6.查看修改的内容

git diff 查看尚未暂存的文件更新的部分:此时比较的工作目录的当前文件与暂存区快照之间的差异。

$ git diff

git diff --staged 查看已暂存将要添加到下次提交的内容:此时比较已暂存文件与最后一次提交的文件的差异。

$ git diff --cached		# 或者
$ git diff --staged
2022-03-28_23-41

这里尝试了已暂存和上次提交的差异,@@ -4,3 +4,5@@ 后面的白色内容是原有的内容(上次提交的内容),下面绿色部分是更新的内容(已暂存的内容),我只是加了 “update!!!” 这段话。

图形化工具也可以比较文件差异。

3.7.提交更新

好了,到这里终于要提交更新 commit 了。用下面命令会把已经暂存的文件提交,注意,只有已暂存的,如果你在工作区修改了,但是没有暂时,不会对这些修改生效。

$ git commit

提交后会运行之前设置的编辑器,显示默认的提交信息,如图下图注释部分。注释上面有一个空行,需要你自己对此次提交的内容进行描述,然后保存关闭即可。

2022-03-28_23-58

3.8.跳过暂存区

会提交所有修改过的文件,这样就可以跳过 git add 步骤,但不可控,可能会提交不需要的文件。

$ git commit -a

用一张图来总结一下目前为止的一些命令吧:

2022-03-29_16-22

3.9.移除文件

从跟踪文件的清单里移除,然后提交。如果你只是从工作区自己删除文件,但是在快照里还是有这个文件的。此时运行 git status 会出现 changes not staged for commit

git rm <file> 除了会不再跟踪外,还会从工作目录中删除指定的文件

git rm -f <file> 强制(force)删除,可以删除已经放到暂存区的文件,这样的数据不能被 git 恢复。

git rm --cached <file> 只是不再跟踪,从 git 仓库中删除,但是文件仍然被保留。

$ git rm helloworld.py			# 不再跟踪且删除
$ git rm --cached helloworld.py	# 不再跟踪
$ git rm -f helloworld.py		# 强制删除,包括暂存区,不可恢复

3.10.重命名/移动文件

如果你要重命名文件可以这样做:

$ git mv pre_name new_name		# 相当于执行了下面三条命令
$ mv pre_name new_name
$ git rm pre_name
$ git add new_name

如果说你用其他方式重命名的文件,在提交前 git rm 删除旧文件名,再 git add 添加新文件名。

4.查看提交历史

这部分主要是 git log + 一些参数或者选择来实现不同的功能(对于输出的结果按q可以退出)。这里用表格列出。log 一般是日志文件

选项 说明
-p/--patch 按补丁格式显示每个提交引入的差异
--graph 在日志旁以ASCII图形显示分支与合并历史
--stat 显示每次提交的文件修改统计信息
--shortstat 只显示--stat中最后的行数修改添加移除统计
--name-only 仅在提交信息后显示已修改的文件清单
--name-status 显示新增、修改、删除的文件清单
--pretty 以不同于默认格式的方式展示提交历史,有oneline、short、full、fuller
--pretty=format 定制格式,常用选择查看Git - 查看提交历史 (git-scm.com)
--abbrev-commit 仅显示 SHA-1 校验和所有 40 个字符中的前几个字符
--since和--after 指定时间之后的提交
--until和--before 指定时间之前的提交
-<n> 限制最近的n条提交
--author 仅显示作者匹配指定字符串的提交
--commiter 仅显示提交者匹配指定字符串的提交
-S str 仅显示添加或删除内容匹配指定字符串的提交
--step 仅显示提交说明中包含指定字符串的提交
-- <path> 在 git log 选项的最后指定它们的路径

示例:

$ git log -p -2				# 显示每次提交的差异,-2只显示最近的两次提交
$ git log --stat			# 最后显示每次提交简略的统计信息
$ git log --pretty=oneline	# 每个提交在一行显示
$ git log --pretty=format:"%h - %an, %ar : %s"	# 哈希值-作者-修订日期-提交说明
$ git log --pretty=format:"%h %s" --graph	#哈希值-提交说明,添加了ASCII展示分支和合并历史
$ git log --since=2.weeks	# 最近两周的提交
$ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" --before="2008-11-01" --no-merges -- t/
# 哈希值-提交说明,作者为'Junio C Hamano',"2008-10-01"到"2008-11-01",在路径't/'下的提交

5.撤销操作

5.1.覆盖原来的提交信息

$ git commit --amend

该命令实现:将暂存区中的文件提交。在你没有跳过暂存区时,如果提交时忘记把一些修改放进暂存区,你可以用该命令,去覆盖上一次的提交,这样只会让你的提交历史好看一些,没有其他用处。例子如下:

$ git commit -m 'initial commit'
$ git add forgotten_file			# 忘记暂存的文件暂存
$ git commit --amend				# 重新提交

5.2.取消暂存/修改(本节的操作都要慎重)

$ git reset HEAD <file>			# 取消暂存,官方:比较危险的命令
$ git checkout -- <file>		# 撤销修改,把它还原成上次提交时的样子,本地修改也会消失

在 Git 中任何 已提交 的东西几乎总是可以恢复的。

需要说明的是:如果你仍然想保留对那个文件做出的修改,但是现在仍然需要撤消,保存进度与分支可能是更好的做法。后续会对分支进行说明。

6.远程仓库的操作

这一节的英文表达是 working with remotes,这部分的命令也是主要围绕 remote。这些操作中,最首先的是 git remote add <shortname> <url>,只有这样你连接到了远程仓库,并且知道它的名字和 url ,你才可以有后续的拉取、推送、重命名以及删除。

6.1.查看远程仓库

$ git remote						# 查看远程仓库
origin
$ git remote -v						# 查看远程仓库,并且会列出 URL
origin	https://github.com/schacon/ticgit (fetch)
origin	https://github.com/schacon/ticgit (push)
$ git remote show <remote>			# 查看远程仓库,这将显示更多的信息

6.2.添加远程仓库

和 git clone 效果一样,但是可以有一个shortname 来代替这个 url。使用 clone 默认以 “origin” 为简写。默认的分支是我们安装时的 master

$ git remote add <shortname> <url>	# 添加远程仓库
$ git remote add pb https://github.com/paulboone/ticgit	# 示例

6.3.拉取和推送

拉取的是你没有的数据,只是下载,不会合并或者修改,需要后续手动操作,<remote>就是 url 的简写,代表你的远程。push 将本地存储库的内容上传到远程存储库,fetch 相反。

$ git fetch <remote>				# 拉取远程仓库
$ git fetch origin					# 示例
$ git push <remote> <branch>		# 推送到远程仓库
$ git push origin master			# 示例
$ git push <remote> --all			# 推送所有分支

6.4.重命名和删除

$ git remote rename <pre_name> <new_name>	# 重命名远程仓库,这同样也会修改你所有远程跟踪的分支名字
$ git remote remove <remote>				# 删除仓库,和这个远程仓库相关的远程跟踪分支以及配置信息也会一起被删除

7.分支

(本节图源未特殊注明均来自官方:Git - 分支简介 (git-scm.com)

7.1.git的分支

如果你想在当前的主线工作上,做一些尝试,同时你又不想影响当前主线的成果。那你可以创建一个副本,它包含了当前所有的主线内容,然后在这个副本开始你的测试。你可能会把主线工作看作版本1,副本看作版本2,版本2成功了就会替换掉版本1,失败了,你还有备份。但是,这样的开销似乎有点大,如果你做的是一个大项目,保留一个完整的副本可能是十分费力的。

git,因为“快照”的保存方式,既能够实现版本控制,同时节省你的开销。

先来了解一下 Git 在暂存和提交时分别完成了什么工作:在进行暂存操作时,会计算每一个文件的校验和,并把当前版本的文件快照存到Git 仓库中。在进行提交操作时,Git 会保存一个 提交对象(commit object),该提交对象会包含一个指向暂存内容快照的指针、作者的姓名和邮箱、提交时输入的信息以及指向它的 父对象(指它的前一次提交对象) 的指针。

我们来看一个例子,将 README,test.rb,LICENSE 三个文件加入暂存区并提交:

$ git add README test.rb LICENSE
$ git commit -m 'The initial commit of my project'

此时,Git 仓库中有五个对象:三个 blob 对象(保存着文件快照)、一个 对象 (记录着目录结构和 blob 对象索引)以及一个 提交 对象(包含着指向前述树对象的指针和所有提交信息)

2022-04-10_15-24-19

对其做些修改后再次提交:

2022-04-10_15-24-19

可以看到,首次提交产生的 98ca9 提交对象没有父对象,后续普通提交操作产生的提交对象有一个父对象,而由多个分支合并产生的提交对象会有多个父对象。

7.2.分支创建

Git 分支本质上是指向提交对象的 可变指针

现在在回到我们开头的情况,你对当前的版本 master(git 默认的分支名称是master),创建一个用来尝试的分支 testing。你会有一个 HEAD 指针指向你当前所在分支的最后一次提交对象。

$ git branch testing	# 创建分支
2022-04-10_15-42-57

从上图可以看到:1.对于新创建的分支 testing,由于目前没有任何提交,和 master 指向的提交对象是一样的;2.创建分支并不会转移 HEAD 指针指向的对象,所以现在你仍然在主分支,只是多了一个指向当前提交对象的指针。你可以用以下命令查看分支所指的对象

$ git log --oneline --decorate	# 查看各个分支当前所指的对象

创建新分支的同时切换过去

$ git checkout -b testing

7.3.分支切换

$ git checkout testing		# 切换分支到 testing
2022-04-10_15-50-30

切换分支后,HEAD 指针指向了 testing 分支。再对 testing 分支做一些修改并提交:

2022-04-10_15-53-12

我们再切换到 master 分支并做一些修改后提交:

2022-04-10_15-57-49

此时我们的提交历史已经产生了分叉,你可以通过前面讲过的 git log 查看分叉历史:

$ git log --oneline --decorate --graph --all

在切换分支时,要留意你的工作目录中和暂存区没有提交的修改,它可能会阻止你的切换(对于该情况的会有一些解决办法,暂存 stashing 和修补提交 commit amending)。切换分支后,Git 会自动添加、删除、修改文件以确保此时你的工作目录和切换到的分支,最后一次提交时的样子一模一样。

7.4.分支合并与删除

$ git merge <branch>			# 合并分支
$ git branch -d <branch>		# 分支删除,d:delete

7.4.1.快进

2022-04-10_16-34-19

假如现在需要将分支 hotfix 合并到主分支 master。由于想要合并的分支 hotfix 所指向的提交 C4 是你所在的提交 C2 的直接后继, 因此 Git 会直接将指针向前移动。换句话说,当你试图合并两个分支时, 如果顺着一个分支走下去能够到达另一个分支,那么 Git 在合并两者的时候, 只会简单的将指针向前推进(指针右移),因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进(fast-forward)”

$ git merge hotfix
2022-04-10_16-38-08

合并分支后,master 和 hotfix 已经指向了同一个位置,hotfix 已经不需要了,可以删除

$ git branch -d hotfix

7.4.2.有分叉的分支合并:合并提交

2022-04-10_16-42-24

现在需要合并 iss53 和 master。master 分支所在提交并不是 iss53 分支所在提交的直接祖先,Git 不得不做一些额外的工作。 出现这种情况的时候,Git 会使用两个分支的末端所指的快照(C4 和 C5)以及这两个分支的公共祖先(C2),做一个简单的三方合并。Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交,它的特别之处在于他有不止一个父提交。

$ git merge iss53
2022-04-10_16-45-39

之后不再需要 iss53 分支,可以将其删除掉了。

$ git branch -d iss53

7.4.3.冲突的分支合并

如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git 就没法干净的合并它们。此时用 git merge ,此时 Git 做了合并,但是没有自动地创建一个新的合并提交。 Git 会暂停下来,等待你去解决合并产生的冲突。

你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并(unmerged)状态的文件。任何因包含合并冲突而有待解决的文件,都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记,这样你可以打开这些包含冲突的文件然后手动解决冲突。

在你解决了所有文件里的冲突之后,对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件,Git 就会将它们标记为冲突已解决。你可以再次运行 git status 来确认所有的合并冲突都已被解决。

如果你对结果感到满意,并且确定之前有冲突的的文件都已经暂存了,这时你可以输入 git commit 来完成合并提交。

7.5.分支管理

$ git branch			# 查看分支列表
$ git branch -v			# 查看每个分支的最后一次提交

分支列表中,前有 * 表示 HEAD 当前指向的分支。

$ git branch --merged			# 查看已经合并到当前分支的分支
$ git branch --mo-merged		# 查看尚未合并的分支
$ git branch --no-merged master # 尚未合并到 master 的分支

--merged 列出的分支列表中,分支名字前没有 * 号的分支通常可以使用 git branch -d 删除掉。你已经将它们的工作整合到了另一个分支,不会失去任何东西。对于尚未合并的分支,删除会失败,如果你仍想删除,可以根据提示,强制删除 git branch -D <branch>

8.打标签

某次提交后,需要记忆的节点,可以打标签。标签可以理解为是一个引用,他代表了你最新一次的提交。你也可以对历史的提交补上标签。标签有什么用呢?完成一个project,小改大改,我们会有好多次提交,但会有某些重要的提交,你可以对这些重要的提交打上标签。

8.1.列出标签

$ git tag					# 列出标签
$ git tag -l				# 以字母顺序列出标签
$ git tag --list
$ git tag -l "v1.8*"		# 列出1.8系列的标签,

普通的查看标签,后面的 -l--list 这个是可选的。但是如果你希望匹配某类特定的标签,则是必须的(如最后一个例子)。

8.2.创建标签

8.2.1.附注标签

附注标签是存储的一个完整对象,会包含打标签者的name,Email 和日期时间,以及标签信息(需要保留下来的,比较成熟或完整的一次提交后建议用这个)。命令为 git tag -a

$ git tag -a v1.4 -m "version 1.4"

通过 git show 可以查看标签和提交信息。

$ git show v1.4

5.2.2.轻量标签

只保存标签名字,是某个提交的引用。git tag 即可。

$ git tag v1.4

8.2.3.给历史提交打标签

也可以对过去的提交打标签。查看我历史的提交 git lag --pretty=oneline(后面的 --pretty=oneline 表示每次提交在一行显示,显示的信息会比较简略,不会有提交作者,时间日期等)。可以看到我提示有一个比较完整的提交,可能需要给他打个标签

2022-04-10_21-35-02

我们需要给他提供检验和(可以是部分校验和,校验和可以理解为识别码),来告诉它,要给哪一次提交打标签。如果我要对我最近一次比较完成的版本打标签,可以是这样的:

$ git tag -a v0.1 9b50e31447d25e82725b850b71c3f1265ad1f5c8
$ git tag -a v0.1 9b50e31

8.2.4.提交标签到远程仓库

默认 git push 不会把标签传送到远程仓库,需要像推送分支一样,再推送一次。推送指定的标签如下所示(<remote> 代表远程仓库的 url),这里我的远程仓库是 summary_generate

$ git push <remote> <tagname>
$ git push summary_generate v0.1		# 示例

如果想一次性推送所有不在远程仓库的标签(不会区分轻量标签和附注标签),可以用 --tags

$ git push <remote> --tags

8.3.删除标签

删除本地的某个标签,可以 git tag -d <tagname> ,其中 <tagname> 是你标签的名字。删除远程仓库的标签,可以 git push <remote> --delete <tagname>,或者 git push <remote> :refs/tags/<tagname>

$ git tag -d <tagname>
$ git push <remote> <tagname>
$ git push <remote> :refs/tags/<tagname>
# 下面为示例
$ git tag -d v0.1
$ git push summary_generate v0.1
$ git push summary_generate :refs/tags/v0.1

8.4.检出标签

如果想查看某个标签指向的文件版本,可以用 git chechout 。有没有注意到,这个命令是我们之前讲到的切换分支的命令。

这会有什么影响呢?在官方文档中,提到:

这会使你的仓库处于“分离头指针(detached HEAD)”的状态——这个状态有些不好的副作用:如果你做了某些更改然后提交它们,标签不会发生变化, 但你的新提交将不属于任何分支,并且将无法访问,除非通过确切的提交哈希才能访问。

因此,如果你需要进行更改,比如你要修复旧版本中的错误,那么通常需要创建一个新分支

如果是普通的查看,在 checkout 查看后注意,要再次 checkout 到你要修改的分支。不然你之后的提交将不属于任何分支。

$ git checkout 0.1

9.Github/Gitee

注册账户略

9.1.配置:SSH访问

9.1.1.生成密钥

首先你需要生成一对密钥,包含公钥和私钥,把公钥放在 GitHub 端,私钥保存在本地,这样就可以实现免密登录啦(大致原理是非对称加密,感兴趣可以自己去了解,这里不展开)。通常这个会存储在你用户目录下的 .ssh 文件夹里。

先看看你是否有这个文件夹:

进入 Git Bash 后,默认就在你的用户目录下,你会看到一个 ~,这个就是当前用户目录的意思,大概如下所示:

主机名@用户名 ~

之后 cd .ssh,看是否有该文件夹。如果没有,创建 mkdir .ssh (mkdir:make dictionary),之后进入该文件夹 cd .ssh

2022-04-10_21-35-02

之后输入ssh-keygen -t rsa -C "一段注释" 来生成公钥-私钥对。其中,-t rsa 指定密钥类型是 RSA-C "xxx" 是一段注释,一般来说明这个密钥是哪个用户的。输入之后回车。之后会让你输入一个密码,并且重复输入来验证,不需要的话直接回车就好 。

2022-04-10_21-39-02

之后 ls查看我们生成的文件,其中 id_rsa 是私钥,留在本地的,id_rsa.pub 是公钥,你需要放在服务器或者你托管的平台上。

2022-04-10_21-43-26

之后 cat id_rsa.pub 获得公钥里的内容。

2022-04-10_21-46-20

9.1.2.传到 Github

进入你的账户设置 account settings,看到 SSH 选项,点击 New SSH key

2022-04-10_21-49-49

将你通过 cat 获得的公钥,粘到 key 里,并命名在 Title,你可以用当前这个用户名。然后 add 就好了。

2022-04-10_21-54-45

目前国内使用 Github 可能有不少限制,也可用国内替代平台 gitee,这一部分的配置也是一样的。找到你账户里的 SSH公钥 就好了,不多赘述。

9.2.实战1-创新新项目并在 gitee 托管

本小节参考 gitee:简易的命令行入门教程。

先在平台创建一个仓库,仓库名称必填,其他默认,点击创建即可。这里我创建了一个 summary_generate 的仓库。

2022-04-11_13-19-59

然后回到本地。在 git bash 里操作:进入你打算创建项目的目录 cd your_path,创建你的项目目录 mkdir your_project,进入该目录 cd your_project。初始化 git git init

2022-04-11_13-25-16

创建一个 readme 文件,暂存后提交。touch readme.md 创建或修改 readme 文件。git add readme.md,暂存文件。git commit -m "添加的注释" 提交文件并对本次提交添加注释。

2022-04-11_13-30-30

(如果你只想在本地完成,那么到这里就可以了,后续你可以根据需求跳到对应的章节。可能你有回退版本的需求,后续我会尽量更新。这里先建议用 分支 去克服这样的问题,把稳定版本放在主线,开支线去做一些尝试。测试无误再做合并)

之后 git remote add <shortname> <url>,这里选择仓库的名称 summary_genarate作为shortname(远程仓库的名称),<url> 是远程仓库的地址。通过 git remotegit remote -v 查看,可以看到我们目前的远程仓库。

2022-04-11_14-22-12

关于 <url> 怎么获取,一般平台都会给出,如下:

2022-04-11_14-23-31

之后 git push <shortname> <branch>,推送分支 <branch> 到远程仓库 shortname,这里是 git push summary_generate main。期间有一个问题,输入 yes,就好。

2022-04-11_14-50-05

否则会连接失败而报错:

2022-04-11_14-56-18

再去看远程仓库,发现已经有了 readme.md 文件:

2022-04-11_14-57-06

9.3.实战2-本地项目在 gitee 托管

如果你已经有一个本地项目,则需要这样托管:

先在本地创建好 Git 的环境:进入项目目录 cd your_project,初始化 Git git init,之后添加项目里的文件到暂存区 git add .. 表示将当前所有文件添加。然后 git commit 提交暂存区的文件。

连接远程仓库(这里假设你已经创建好了一个远程仓库)git remote <shortname> <url><shortname> 是远程仓库的名称,<url> 是远程仓库的地址。

推送内容到远程仓库: git push <shortname> <branch>,推送分支 <branch> 到远程仓库 shortname

到这里你其实已经实现了一个基本的流程:创建 Git 库,添加暂存,提交,建立连接,推送。之后当你每次做了修改,都可以 git add 添加到暂存区后,git commit 提交,再推送给某个远程仓库 git push

posted @ 2022-03-29 16:49  piukaty  阅读(52)  评论(0编辑  收藏  举报