【读书笔记】Git使用
阅读原文时间:2023年07月11日阅读:2

初始设置本地Git

首先来设置使用 Git 时的姓名和邮箱地址。名字请用英文输入。

$ git config --global user.name "Firstname Lastname"
$ git config --global user.email "your_email@example.com"

这个命令,会在“~/.gitconfig”中以如下形式输出设置文件。

[user]
  name = Firstname Lastname
  email = your_email@example.com

想更改这些信息时,可以直接编辑这个设置文件。这里设置的姓名和邮箱地址会用在 Git 的 提交日志中。由于在 GitHub 上公开仓库时,这里的姓名和邮箱地址也会随着提交日志一同被公开,所以请不要使用不便公开的隐私信息。

将 color.ui 设置为 auto 可以让命令的输出拥有更高的可读性。

$ git config --global color.ui auto

“~/.gitconfig”中会增加下面一行。

[color]
  ui = auto

这样一来,各种命令的输出就会变得更容易分辨。

注意:下面大多数命令是在Win下 git bash 中使用,当然,linux终端也可以使用。

申请GitHub账号及相关设置

GitHub 上连接已有仓库时的认证,是通过使用了 SSH 的公开密钥认证方式进行的。现在让我们来创建公开密钥认证所需的 SSH Key,并将其添加至 GitHub。

在 Git bash 运行下面的命令创建 SSH Key。

$ ssh-keygen -t rsa -C "your_email@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key
(/Users/your_user_directory/.ssh/id_rsa): 按回车键
Enter passphrase (empty for no passphrase): 输入密码
Enter same passphrase again: 再次输入密码

your_email@example.com的部分请改成您在创建账户时用的邮箱地址。密码需要在认证时输入,请选择复杂度高并且容易记忆的组合。输入密码后会出现提示已经创建密匙的提示,并告诉存储位置以及相关信息。其中,id_rsa 文件是私有密钥,id_rsa.pub 是公开密钥

在 GitHub 中添加公开密钥(Add SSH Key),今后就可以用私有密钥进行认证了。

在 Title 中输入适当的密钥名称。Key 部分使用 id_rsa.pub 文件里的内容。id_rsa.pub 的内容可以用如下方法查看。

$ cat ~/.ssh/id_rsa.pub
ssh-rsa 公开密钥的内容 your_email@example.com

添加后,账户邮箱会收到邮件提示。可以使用如下命令测试用手中的私人密钥与 GitHub 进行认证和

通信。

$ ssh -T git@github.com

若是出现

The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is fingerprint值 .
Are you sure you want to continue connecting (yes/no)? 输入yes

出现如下结果即为成功。

Hi hirocastest! You've successfully authenticated, but GitHub does not provide shell access.
  • Initialize this repository with a README

在 Initialize this repository with a README 选项上打钩,随后GitHub 会自动初始化仓库并设置 README 文件,让用户可以立刻clone 这个仓库。如果想向 GitHub 添加手中已有的 Git 仓库,建议不要勾选,直接手动 push。

是刚刚创建的仓库的页面。

  • .gitignore

正如其名,这个设定会帮我们把不需要在Git仓库中进行版本管理的文件记录在 .gitignore 文件中,省去了每次根据框架进行设置的麻烦。

  • GitHub Flavored Markdown

在 GitHub 上进行交流时用到的 Issue、评论、Wiki,都可以用 Markdown 语法表述,从而进行标记。准确地说应该是 GitHub Flavored Markdown(GFM)语法。该语法虽然是 GitHub 在 Markdown 语法基础上扩充而来的,但一般情况下只要按照原本的 Markdown 语法进行描述就可以。

简单试验对已有仓库的操作

将代码下载到了本地以仓库名作为文件夹名的文件夹中,但是与直接下载不同。

$ git clone git@github.com:hirocastest/Hello-World.git
Cloning into 'Hello-World'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
$ cd Hello-World

这里会要求输入 GitHub 上设置的公开密钥的密码。认证成功后,仓库便会被 clone 至仓库名后的目录中。将想要公开的代码提交至这个仓库再 push 到 GitHub 的仓库中,代码便会被公开。

如果之前并未设置密码,那么这里也就不用输入。

本地文件想要加入,需要先加到本地仓库。只有添加到其中,才能实现跟踪管理。

这里我们编写一个 hello_world.php 文件,用来输出“Hello World!”。

由于 hello_word.php 还没有添加至 Git 仓库,所以显示为 Untracked

files。

$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# hello_world.php
nothing added to commit but untracked files present (use "git add" to track)

添加到本地仓库,这样一来,这个文件就进入了版本管理系统的管理之下。今后的更改管理都交由 Git 进行。通过 git add命令将文件加入暂存区,再通过 git commit 命令附加信息并提交。

$ git add hello_world.php
$ git commit -m "Add hello world script by php"
[master d23b909] Add hello world script by php
1 file changed, 3 insertions(+)
create mode 100644 hello_world.php

添加成功后,可以通过 git log 命令查看提交日志。

$ git log
commit d23b909caad5d49a281480e6683ce3855087a5da
Author: 你的信息
Date: 你的时间
Add hello world script by php

关于许可:实际使用时,只需将 LICENSE 文件加入仓库,并在README.md 文件中声明使用了何种许可协议即可。使用没有声明许可协议的软件时,以防万一最好直接联系著作者。

之后只要执行 push,GitHub 上的仓库就会被更新。

$ git push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 328 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:hirocastest/Hello-World.git
46ff713..d23b909 master -> master

本地新仓库推送远程

要使用 Git 进行版本管理,必须先初始化仓库。

在包含所有要上传的文件的目录级别下:

$ git init

如果初始化成功,执行了 git init 命令的目录下就会生成 .git 目录。这个 .git 目录里存储着管理当前目录内容所需的仓库数据。在 Git 中,我们将这个目录的内容称为“附属于该仓库的工作树”。文件的编辑等操作在工作树中进行,然后记录到仓库中,以此管理文件的历史快照。

工作树和仓库在被操作的过程中,状态会不断发生变化。

$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

结果显示了我们当前正处于 master 分支下。接着还显示了没有可提交的内容。所谓提交(Commit),是指“记录工作树中所有文件的当前状态”。

要想让文件成为 Git 仓库的管理对象,就需要用 git add 命令将其加入暂存区(Stage 或者 Index)中。暂存区是提交之前的一个临时区域。

$ git add README.md
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: README.md
#

可见,新建的文件被加到了暂存区(注意关注输出内容中括号中的内容,会有一些功能性的建议)

可以将当前暂存区中的文件实际保存到仓库的历史记录中。通过这些记录,我们就可以在工作树中复原文件。

$ git commit -m "First commit"
[master (root-commit) 9f129ba] First commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md

-m 参数后的 "First commit"称作提交信息,是对这个提交的概述。若是不加 -m,直接执行 git commit 命令。执行后编辑器就会启动,并显示如下结果。

git commit -am "..." 命令一次完成 add,commit。

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: README.md
#

在编辑器中记述提交信息的格式如下。

* 第一行:用一行文字简述提交的更改内容
* 第二行:空行
* 第三行以后:记述更改的原因和详细内容

只要按照上面的格式输入,今后便可以通过确认日志的命令或工具看到这些记录。

在以 #(井号)标为注释的 Changes to be committed(要提交的更改)栏中,可以查看本次提交中包含的文件。将提交信息按格式记述完毕后,请保存并关闭编辑器,以 #(井号)标为注释的行不必删除。随后,刚才记述的提交信息就会被提交。

如果在编辑器启动后想中止提交,请将提交信息留空并直接关闭编辑器,随后提交就会被中止。

提交之后,工作树状态会提示没有更改,因为处于最新状态。

要修改上一条提交信息,可以使用 git commit --amend 命令。

可以查看什么人在什么时候进行了提交或合并,以及操作前后有怎样的差别。

针对刚才

$ git log
commit 9f129bae19b2c82fb4e98cde5890e52a6c546922(指向这个提交的哈希值)
Author: ...
Date: ...
First commit(该提交的提交信息。)

如果只想让程序显示第一行简述信息,可以在 git log 命令后加上 --pretty=short

$ git log --pretty=short
commit 9f129bae19b2c82fb4e98cde5890e52a6c546922
Author: ...
First commit

$ git log -p README.md

git log 命令后加上 -p 参数,文件的前后差

别就会显示在提交信息之后。加上目录名,便会只显示该目录下的日志。如果加的是文件名,就会只显示与该文件相关的日志。

git log -- graph ——以图表形式查看分支合并提交等信息。

可以查看 工作树暂存区最新提交之间的差别。显示的内容的内容中,“+”号标出的是新添加的行,被删除的行则用“-”号标出。

要查看与最新提交的差别,请执行以下

命令。

$ git diff HEAD

这里的 HEAD 是指向当前分支中最新一次提交

的指针。

在进行多个并行作业时,我们会用到分支。在这类并行开发的过程中,往往同时存在多个最新代码状态。master 分支是 Git 默认创建的分支,因此基本上所有开发都是以这个分支为中心进行的。不同分支中,可以同时进行完全不同的作业。等该分支的作业完成之后再与 master 分支合并。

git branch 命令可以将分支名列表显示,同时可以确认当前所在分支。

分支左侧标有“*”(星号),表示这是我们当前所

在的分支。结果中没有显示其他分支名,表示本地仓库中只存在 master 一个分支。

如果想以当前的 master 分支为基础创建新的分支,我们需要用到 git checkout -b命令。

$ git checkout -b feature-A
Switched to a new branch 'feature-A'

等同于:

$ git branch feature-A
$ git checkout feature-A

创建 feature-A 分支,并将当前分支切换为 feature-A 分支。这时再来查看分支列表,会显示我们处于 feature-A 分支下。

在这个状态下像正常开发那样修改代码、执行 git add 命令并进行提交的话,代码就会提交至 feature-A 分支。

命令 git checkout - 可以切换回上一个分支,当然指定名字也可以。

主干分支和特性分支

特性分支顾名思义,是集中实现单一特性(主题),除此之外不进行任何作业的分支。在日常开发中,往往会创建数个特性分支,同时在此之外再保留一个随时可以发布软件的稳定分支。稳定分支的角色通常由 master 分支担当。

主干分支是刚才我们讲解的特性分支的原点,同时也是合并的终点。通常人们会用 master 分支作为主干分支。主干分支中并没有开发到一半的代码,可以随时供他人查看。有时我们需要让这个主干分支总是配置在正式环境中,有时又需要用标签 Tag 等创建版本信息,同时管理多个版本发布。拥有多个版本发布时,主干分支也有多个。

接下来,我们假设 feature-A 已经实现完毕,想要将它合并到主干分支 master 中。为了在历史记录中明确记录下本次分支合并,我们需要创建合并提交。因此,在合并时加上 --no-ff 参数,在主干分支中执行

$ git merge --no-ff feature-A

随后编辑器会启动,用于录入合并提交的信息。默认信息中已经包含了是从 feature-A 分支合并过来的相关内容,所以可不必做任何更改。将编辑器中显示的内容保存,关闭编辑器会提示成功合并。

合并时可能发生冲突(Conflict),不解决,无法合并。按提示解决就好。

要让仓库的 HEAD 、暂存区、当前工作树回溯到指定状态,需要用到 git rest --hard 命令。只要提供 目标时间点的哈希值,就可以完全恢复至该时间点的状态。

git log 命令只能查看以当前状态为终点的历史日志。所以这里要使用 git reflog 命令,查看当前仓库的操作日志。在日志中找出回溯历史之前的哈希值,通过 git reset --hard 命令恢复到回溯历史前的状态。

在日志中,我们可以看到 commit、checkout、reset、merge 等 Git 命令的执行记录。只要不进行 Git 的 GC(Garbage Collection,垃圾回收),就可以通过日志随意调取近期的历史状态。

在合并特性分支之前,如果发现已提交的内容中有些许拼写错误等,不妨提交一个修改,然后将这个修改包含到前一个提交之中,压缩成一个历史记录。

git rebase -i HEAD~2 方式执行 git rebase 命令,可以选定当前分支中包含 HEAD(最新提交)在内的两个最新历史记录为对象,并在编辑器中打开。

出现类似

pick 7a34294 Add feature-C
pick 6fba227 Fix typo

6fba227 左侧的 pick 部分删除,改写为 fixup

pick 7a34294 Add feature-C
fixup 6fba227 Fix typo

保存编辑器里的内容,关闭编辑器。提示 rebase 成功。这样一来,Fix typo 就从历史中被抹去,也就相当于 Add feature-C中从来没有出现过拼写错误。这算是一种良性的历史改写。

在 GitHub 上新建一个仓库。为防止与其他仓库混淆,仓库名请与本地仓库保持一致。创建时请不要勾选 Initialize this repository with a README 选项。因为一旦勾选该选项,GitHub 一侧的仓库就会自动生成 README 文件,从创建之初便与本地仓库失去了整合性。虽然到时也可以强制覆盖,但为防止这一情况发生还是建议不要勾选该选项。

现在我们用 git remote add 命令将github新建仓库设置成本地仓库的远程仓库。

$ git remote add origin 远程仓库路径

按照上述格式执行 git remote add 命令之后,Git 会自动将远程仓库的名称设置为 origin(标识符)。

当前分支下本地仓库内容推送到远程仓库。

假定在 master 分支下工作。

$ git push -u origin master

当前分支的内容就会被推送给远程仓库 originmaster 分支。

-u 参数可以在推送的同时,将 origin 仓库的 master 分支设置为本地仓库当前分支的 upstream(上游)。添加了这个参数,将来运行 git pull 命令从远程仓库获取内容时,本地仓库的这个分支就可以直接从 originmaster 分支获取内容,省去了另外添加参数的麻烦。

对于其他分支,我们在本地仓库中创建了 feature-D 分支,现在将它 push 给远程仓

库并保持分支名称不变。

$ git checkout -b feature-D
$ git push -u origin feature-D

获取远程仓库其他分支开发

不要与之前操作的仓库在同一目录下。执行 git clone 命令后我们会默认处于 master 分支下,同时系统会自动将 origin 设置成该远程仓库的标识符。也就是说,当前本地仓库的 master 分支与 GitHub 端远程仓库(origin)的 master 分支在内容上是完全相同的。

git branch -a命令查看当前分支的相关信息。添加 -a 参数可以同时显示本地仓库和远程仓库的分支信息。

若要获取远程特性分支 feature-D,可以使用如下操作。

$ git checkout -b feature-D origin/feature-D

-b 参数的后面是本地仓库中新建分支的名称。为了便于理解,我们仍将其命名为 feature-D,让它与远程仓库的对应分支保持同名。新建分支名称后面是获取来源的分支名称。

例子中指定了 origin/feature-D,就是说以远程 origin 的仓库的 feature-D 分支作为来源,在本地仓库中创建 feature-D 分支。更改添加提交推送即可。

$ git commit -am "Add feature-D"
$ git push

此时,本地分支中并未有内容,需要使用 pull

$ git pull origin feature-D

如果两人同时修改了同一部分的源代码,push 时就很容易发生冲突。所以多名开发者在同一个分支中进行作业时,为减少冲突情况的发生,建议更频繁地进行 push 和 pull 操作。