Git基本操作

● git init——初始化仓库

要使用Git进行版本管理，必须先初始化仓库。Git是使用git init命令进行初始化的。请实际建立一个目录并初始化仓库。

$ mkdir gitlianxi

$ cd git-lianxi

$ git init

Initialized empty Git repository in E:/gitlianxi/.git/

如果初始化成功，执行了 git init命令的目录下就会生成 .git 目 录。这个 .git 目录里存储着管理当前目录内容所需的仓库数据。 在 Git中，我们将这个目录的内容称为“附属于该仓库的工作树”。 文件的编辑等操作在工作树中进行，然后记录到仓库中，以此管理文件 的历史快照。如果想将文件恢复到原先的状态，可以从仓库中调取之前 的快照，在工作树中打开。开发者可以通过这种方式获取以往的文件。

mkdir——创建文件夹（不能对文件夹里面进行修改）

cd——进入文件夹的路径

● git status——查看仓库的状态 

git status命令用于显示 Git 仓库的状态。这是一个十分常用的 命令，请务必牢记。 工作树和仓库在被操作的过程中，状态会不断发生变化。在Git操 作过程中时常用 git status命令查看当前状态，可谓基本中的基本。 下面，就让我们来实际查看一下当前状态。

$ git status

# On branch master

#

# Initial commit

#

nothing to commit (create/copy files and use "git add" to track)

结果显示了我们当前正处于 master分支下，还显示了没有可提交的内容。所谓提交 （Commit），是指“记录工作树中所有文件的当前状态”。 尚没有可提交的内容，就是说当前我们建立的这个仓库中还没有记 录任何文件的任何状态。这里，我们建立 README.md文件作为管理对 象，为第一次提交做前期准备。

$ git status

On branch master

No commits yet

Untracked files: (use "git add ..." to include in what will be committed) README.md nothing added to commit but untracked files present (use "git add" to track)

可以看到在 Untracked files中显示了 README.md文件。类似地， 只要对 Git 的工作树或仓库进行操作，git status命令的显示结果就 会发生变化。

touch——在文件夹里面进行创建

● git add——向暂存区中添加文件

如果只是用Git仓库的工作树创建了文件，那么该文件并不会被记 入 Git仓库的版本管理对象当中。因此我们用 git status命令查看 README.md 文件时，它会显示在 Untracked files里。 要想让文件成为 Git仓库的管理对象，就需要用 git add命令将其 加入暂存区（Stage 或者 Index）中。暂存区是提交之前的一个临时区域。

$ git add README.md

$ git status

On branch master

No commits yet Changes to be committed: (use "git rm --cached ..." to unstage)

new file: README.md 

将 README.md文件加入暂存区后，git status命令的显示结 果发生了变化。可以看到，README.md文件显示在Changes to be committed中了。

● git commit——保存仓库的历史记录

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

 记述一行提交信息

我们来实际运行一下 git commit命令。

$ git commit -m "First commit"

[master (root-commit) 4bd9108] First commit

1 file changed, 0 insertions(+), 0 deletions(-)

create mode 100644 README.md

-m 参数后的 "First commit"称作提交信息，是对这个提交的 概述。

 记述详细提交信息

刚才我们只简洁地记述了一行提交信息，如果想要记述得更加详 细，请不加 -m，直接执行 git 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命令后再来查看当前状态

$ git status

On branch master

nothing to commit, working tree clean

当前工作树处于刚刚完成提交的最新状态，所以结果显示没有更改。

● git log——查看提交日志

git log命令可以查看以往仓库中提交的日志。包括可以查看什么人在什么时候进行了提交或合并，以及操作前后有怎样的差别。关于 合并我们会在后面解说。 我们先来看看刚才的 git commit命令是否被记录了.

$ git log

commit 4bd9108cbe43b490eae000dd97bb3923787724fa (HEAD -> master)

Author: PhyllisWang666 <15346878235@163.com>

Date: Wed Feb 27 11:18:26 2019 +0800

First commit

如上图所示，屏幕显示了刚刚的提交操作。commit栏旁边显示的 “4bd9108……”是指向这个提交的哈希值。Git的其他命令中，在指向提 交时会用到这个哈希值。 Author栏中显示我们给 Git设置的用户名和邮箱地址。Date栏中显 示提交执行的日期和时间。再往下就是该提交的提交信息。

 只显示提交信息的第一行

如果只想让程序显示第一行简述信息，可以在 git log命令后加 上 --pretty=short。这样一来开发人员就能够更轻松地把握多个 提交

$ git log --pretty=short

commit 4bd9108cbe43b490eae000dd97bb3923787724fa (HEAD -> master)

Author: PhyllisWang666 <15346878235@163.com>

First commit

 只显示指定目录、文件的日志

只要在 git log命令后加上目录名，便会只显示该目录下的日志。 如果加的是文件名，就会只显示与该文件相关的日志。

$ git log README.md

 显示文件的改动

如果想查看提交所带来的改动，可以加上 -p参数，文件的前后差 别就会显示在提交信息之后。

$ git log -p

比如，执行下面的命令，就可以只查看 README.md文件的提交日 志以及提交前后的差别。

$ git log -p README.md

如上所述，git log命令可以利用多种参数帮助开发者把握以往 提交的内容。不必勉强自己一次记下全部参数，每当有想查看的日志就 积极去查，慢慢就能得心应手了。

 ● git diff——查看更改前后的差别

git diff命令可以查看工作树、暂存区、最新提交之间的差别。 单从字面上可能很难理解，各位不妨跟着笔者的解说亲手试一试。 我们在刚刚提交的 README.md 中写点东西。

#git教程

##git基本操作

#######移动

这里用 Markdown 语法写下了一行题目。

 查看工作树和暂存区的差别

执行 git diff命令，查看当前工作树与暂存区的差别。

$ git diff

diff --git a/README.md b/README.md

index e69de29..0f63f31 100644

--- a/README.md

+++ b/README.md

@@ -0,0 +1,3 @@

+#git教程

+##git基本操作

+#######移动

\ No newline at end of file

由于我们尚未用 git add命令向暂存区添加任何东西，所以程序 只会显示工作树与最新提交状态之间的差别。

这里解释一下显示的内容。“+”号标出的是新添加的行，被删除的 行则用“-”号标出。我们可以看到，这次只添加了一行。 用 git add命令将 README.md 文件加入暂存区。

$ git add README.md

 查看工作树和最新提交的差别

如果现在执行 git diff命令，由于工作树和暂存区的状态并无 差别，结果什么都不会显示。要查看与最新提交的差别，请执行以下 命令。

$ git diff HEAD

diff --git a/README.md b/README.md

index e69de29..0f63f31 100644

--- a/README.md

+++ b/README.md

@@ -0,0 +1,3 @@

+#git教程

+##git基本操作

+#######移动

\ No newline at end of file

养成一个好习惯：在执行 git commit命令之前先执行 git diff HEAD命令，查看本次提交与上次提交之间有什么差别，等 确认完毕后再进行提交。这里的 HEAD是指向当前分支中最新一次提交 的指针。 由于我们刚刚确认过两个提交之间的差别，所以直接运行git commit命令。

$ git commit -m

"Add index" [master 5716572] Add index

1 file changed, 3 insertions(+)

保险起见，我们查看一下提交日志，确认提交是否成功

$ git log commit

57165726eb158c4c0e6a32b15ccf972ba6fb087c (HEAD -> master)

Author: PhyllisWang666 <15346878235@163.com>

Date: Wed Feb 27 11:48:06 2019 +0800

Add index

commit4bd9108cbe43b490eae000dd97bb3923787724fa

Author: PhyllisWang666 <15346878235@163.com>

Date: Wed Feb 27 11:18:26 2019 +0800

First commit

成功查到了第二个提交。

分支的操作

在进行多个并行作业时，我们会用到分支。在这类并行开发的过程 中，往往同时存在多个最新代码状态。如图 所示，从master分支创 建 feature-A分支和fix-B分支后，每个分支中都拥有自己的最新代码。 master分支是Git默认创建的分支，因此基本上所有开发都是以这个分 支为中心进行的。

从 master 分支创建 feature-A 分支和 fix-B 分支

不同分支中，可以同时进行完全不同的作业。等该分支的作业完成 之后再与 master分支合并。比如 feature-A分支的作业结束后与 master 合并，如图下所示。 通过灵活运用分支，可以让多人同时高效地进行并行开发。

feature-A 分支作业结束后的状态

● git branch——显示分支一览表

git branch命令可以将分支名列表显示，同时可以确认当前所在 分支。让我们来实际运行 git branch命令。

$ git branch

* master

可以看到master分支左侧标有“*”（星号），表示这是我们当前所 在的分支。也就是说，我们正在 master分支下进行开发。结果中没有显 示其他分支名，表示本地仓库中只存在 master 一个分支。

 ● git checkout -b——创建、切换分支 

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

 ● 切换到 feature-A 分支并进行提交

执行下面的命令，创建名为 feature-A 的分支。

$ 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 branch

* feature-A

master

feature-A分支左侧标有“*”，表示当前分支为 feature-A。在这个状 态下像正常开发那样修改代码、执行 git add命令并进行提交的话， 代码就会提交至feature-A分支。像这样不断对一个分支（例如 feature-A）进行提交的操作，我们称为“培育分支”。

下面来实际操作一下。在 README.md 文件中添加一行。

# Git教程

  - feature-A

这里我们添加了 feature-A 这样一行字母，然后进行提交。

$ git add README.md

$ git commit -m "Add feature-A"

[feature-A 8a6c8b9] Add feature-A

1 file changed, 2 insertions(+)

于是，这一行就添加到 feature-A 分支中了。

 ●  切换到 master 分支

现在我们再来看一看master分支有没有受到影响。首先切换至 master 分支。

$ git checkout master Switched to branch 'master'

然后查看 README.md文件，会发现 README.md文件仍然保持 原先的状态，并没有被添加文字。feature-A分支的更改不会影响到 master分支，这正是在开发中创建分支的优点。只要创建多个分支，就可以在不互相影响的情况下同时进行多个功能的开发。

 ●  切换回上一个分支

现在，我们再切换回 feature-A 分支。

$ git checkout

Switched to branch 'feature-A'

像上面这样用“-”（连字符）代替分支名，就可以切换至上一个分 支。当然，将“-”替换成 feature-A 同样可以切换到 feature-A 分支。

 ● 特性分支 

Git 与 Subversion（SVN）等集中型版本管理系统不同，创建分支时 不需要连接中央仓库，所以能够相对轻松地创建分支。因此，当今大部 分工作流程中都用到了特性（Topic）分支。 特性分支顾名思义，是集中实现单一特性（主题），除此之外不进 行任何作业的分支。在日常开发中，往往会创建数个特性分支，同时在 此之外再保留一个随时可以发布软件的稳定分支。稳定分支的角色通常 由 master 分支担当。

特性分支的概念

之前我们创建了feature-A分支，这一分支主要实现feature-A，除 feature-A的实现之外不进行任何作业。即便在开发过程中发现了 BUG， 也需要再创建新的分支，在新分支中进行修正。基于特定主题的作业在特性分支中进行，主题完成后再与 master分 支合并。只要保持这样一个开发流程，就能保证 master分支可以随时供 人查看。这样一来，其他开发者也可以放心大胆地从 master分支创建新 的特性分支。

 ● 主干分支

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

 ● git merge——合并分支 

接下来，我们假设 feature-A 已经实现完毕，想要将它合并到主干分 支 master 中。首先切换到 master 分支。

$ git checkout master

Switched to branch 'master'

然后合并 feature-A 分支。为了在历史记录中明确记录下本次分支合 并，我们需要创建合并提交。因此，在合并时加上 --no-ff参数。

$ git merge --no-ff feature-A

随后编辑器会启动，用于录入合并提交的信息。

Merge branch 'feature-A'

# Please enter a commit message to explain why this merge is necessary,

# especially if it merges an updated upstream into a topic branch.

#

# Lines starting with '#' will be ignored, and an empty message aborts

# the commit.

默认信息中已经包含了是从 feature-A 分支合并过来的相关内容，所 以可不必做任何更改。将编辑器中显示的内容保存，关闭编辑器，然后就会看到下面的结果。

Merge made by the 'recursive' strategy.

README.md | 2 ++

1 file changed,2 insertions(+)

这样一来，feature-A 分支的内容就合并到 master 分支中了。

 ● git log --graph——以图表形式查看分支

用 git log --graph命令进行查看的话，能很清楚地看到特性 分支（feature-A）提交的内容已被合并。除此以外，特性分支的创建以 及合并也都清楚明了。

git log --graph

git log --graph命令可以用图表形式输出提交日志，非常直 观，请大家务必记住。

● git reset——回溯历史版本

Git的另一特征便是可以灵活操作历史版本。借助分散仓库的优势， 可以在不影响其他仓库的前提下对历史版本进行操作。 在这里，为了让各位熟悉对历史版本的操作，我们先回溯历史版 本，创建一个名为 fix-B 的特性分支。

回溯历史，创建 fix-B 分支

  回溯到创建 feature-A 分支前

让我们先回溯到上一节feature-A分支创建之前，创建一个名为 fix-B 的特性分支。 要让仓库的HEAD、暂存区、当前工作树回溯到指定状态，需要用 到 git reset --hard命令。只要提供目标时间点的哈希值 ，就可以完全恢复至该时间点的状态。事不宜迟，让我们执行下面的命令。

$ git reset --hard 4bd9108cbe43b490eae000dd97bb3923787724fa

HEAD is now at fd0cbf0 Add index

我们已经成功回溯到特性分支（feature-A）创建之前的状态。由于 所有文件都回溯到了指定哈希值对应的时间点上，README.md文件的 内容也恢复到了当时的状态。

哈希值在每个环境中各不相同，读者请查看自身当前环境中Add index 的哈希值， 进行替换。

创建 fix-B 分支

现在我们来创建特性分支（fix-B）。

$ git checkout -b fix-B

Switched to a new branch 'fix-B'

作为这个主题的作业内容，我们在README.md文件中添加一行 文字。

# Git教程

  - fix-B

然后直接提交 README.md 文件。

$ git add README.md

$ git commit -m "Fix B"

[fix-B 4096d9e] Fix B

1 file changed, 2 insertions(+)

现在的状态如图所示。接下来我们的目标是图4.6 中所示的状 态，即主干分支合并 feature-A 分支的修改后，又合并了 fix-B 的修改

当前 fix-B 分支的状 fix-B 分支的下一步目标

 推进至 feature-A 分支合并后的状态

首先恢复到 feature-A 分支合并后的状态。不妨称这一操作为“推进 历史”。 git log命令只能查看以当前状态为终点的历史日志。所以这里 要使用 git reflog命令，查看当前仓库的操作日志。在日志中找出 回溯历史之前的哈希值，通过 git reset --hard命令恢复到回溯历 史前的状态。 首先执行 git reflog 命令，查看当前仓库执行过的操作的日志。

在日志中，我们可以看到 commit、checkout、reset、merge等 Git命 令的执行记录。只要不进行 Git 的 GC（Garbage Collection，垃圾回收）， 就可以通过日志随意调取近期的历史状态，就像给时间机器指定一个时 间点，在过去未来中自由穿梭一般。即便开发者错误执行了Git操作， 基本也都可以利用 git reflog命令恢复到原先的状态。

之前我们使用 git reset --hard命令回溯了历史，这里又再次 通过它恢复到了回溯前的历史状态。

恢复历史后的状态

● 消除冲突 

现在只要合并fix-B分支，就可以得到我们想要的状态。让我们赶 快进行合并操作。

这时，系统告诉我们 README.md文件发生了冲突（Conflict）。系 统在合并 README.md 文件时，feature-A分支更改的部分与本次想要合 并的 fix-B 分支更改的部分发生了冲突。 不解决冲突就无法完成合并，所以我们打开 README.md文件，解 决这个冲突。

 查看冲突部分并将其解决

用编辑器打开 README.md文件，就会发现其内容变成了下面这个 样子。

# Git教程

<<<<<<< HEAD 

- feature-A ======= 

- fix-B

>>>>>>> fix-B

=======以上的部分是当前HEAD的内容，以下的部分是要合并 的 fix-B 分支中的内容。我们在编辑器中将其改成想要的样子。

# Git教程

  - feature-A  - fix-B

如上所示，本次修正让feature-A与 fix-B的内容并存于文件之中。 但是在实际的软件开发中，往往需要删除其中之一，所以各位在处理冲 突时，务必要仔细分析冲突部分的内容后再行修改。

 提交解决后的结果

冲突解决后，执行 git add命令与 git commit命令。

由于本次更改解决了冲突，所以提交信息记为 "Fix conflict"。

 ● git commit --amend——修改提交信息

要修改上一条提交信息，可以使用 git commit --amend命令。 我们将上一条提交信息记为了 "Fix conflict"，但它其实是 fix-B分 支的合并，解决合并时发生的冲突只是过程之一，这样标记实在不妥。 于是，我们要修改这条提交信息。

$ git commit --amend

执行上面的命令后，编辑器就会启动。

编辑器中显示的内容如上所示，其中包含之前的提交信息。请将 提交信息的部分修改为 Merge branch 'fix-B'，然后保存文件，关闭编 辑器。

[master 2e7db6f] Merge branch 'fix-B'

随后会显示上面这条结果。现在执行 git log --graph命令， 可以看到提交日志中的相应内容也已经被修改。

1 2

● git rebase -i——压缩历史

在合并特性分支之前，如果发现已提交的内容中有些许拼写错误等， 不妨提交一个修改，然后将这个修改包含到前一个提交之中，压缩成一 个历史记录。这是个会经常用到的技巧，让我们来实际操作体会一下。

 创建 feature-C 分支

首先，新建一个 feature-C特性分支。

$ git checkout -b feature-C

Switched to a new branch 'feature-C'

作为 feature-C的功能实现，我们在 README.md文件中添加一行 文字，并且故意留下拼写错误，以便之后修正。

# Git教程

  - feature-A 

- fix-B 

- faeture-C

提交这部分内容。这个小小的变更就没必要先执行 git add命令 再执行 git commit命令了，我们用 git commit -am命令来一次 完成这两步操作。

$ git commit -am "Add feature-C"

[feature-C 7a34294] Add feature-C

1 file changed, 1 insertion(+)

 修正拼写错误

现在来修正刚才预留的拼写错误。请各位自行修正 README.md文 件的内容，修正后的差别如下所示。

然后进行提交。

$ git commit -am "Fix typo"

[feature-C 6fba227] Fix typo

1 file changed, 1 insertion(+), 1 deletion(-)

错字漏字等失误称作typo，所以我们将提交信息记为 "Fix typo"。

实际上，我们不希望在历史记录中看到这类提交，因为健全的历史记录 并不需要它们。如果能在最初提交之前就发现并修正这些错误，也就不 会出现这类提交了。

更改历史 

因此，我们来更改历史。将 "Fix typo"修正的内容与之前一次的 提交合并，在历史记录中合并为一次完美的提交。为此，我们要用到 git rebase命令。

 $ git rebase -i HEAD~2 

用上述方式执行 git rebase命令，可以选定当前分支中包含 HEAD（最新提交）在内的两个最新历史记录为对象，并在编辑器中 打开。

我们将 6fba227 的Fix typo的历史记录压缩到 7a34294 的Add feature-C 里。按照下图所示，将 6fba227 左侧的 pick 部分删除，改写为 fixup。 

pick 7a34294 Add feature-C 

fixup 6fba227 Fix typo  

保存编辑器里的内容，关闭编辑器。

[detached HEAD 51440c5] Add feature-C

1 file changed, 1 insertion(+)

Successfully rebased and updated refs/heads/feature-C.

系统显示 rebase成功。也就是以下面这两个提交作为对象，将 "Fix typo"的内容合并到了上一个提交 "Add feature-C"中，改写成了一个新 的提交。

● 7a34294 Add feature-C 

● 6fba227 Fix typo

现在再查看提交日志时会发现Add feature-C的哈希值已经不是 7a34294 了，这证明提交已经被更改。

这样一来，Fix typo就从历史中被抹去，也就相当于 Add feature-C 中从来没有出现过拼写错误。这算是一种良性的历史改写。

合并至 master 分支

feature-C分支的使命告一段落，我们将它与 master 分支合并。

$ git checkout master

Switched to branch 'master'

$ git merge --no-ff feature-C

Merge made by the 'recursive' strategy.

README.md| 1 +

1 file changed, 1 insertion(+)

master 分支整合了 feature-C分支。开发进展顺利。

● git remote add——添加远程仓库 

在 GitHub上创建的仓库路径为“git@github.com:用户名 / git-tutorial.git”。现在我们用 git remote add命令将它设置 成本地仓库的远程仓库 A。

$ git remote add origin git@github.com:github-book/git-tutorial.git

按照上述格式执行 git remote add命令之后，Git会自动将 git@github.com:github-book/git-tutorial.git远程仓库的 名称设置为 origin（标识符）。

● git push——推送至远程仓库

 推送至 master 分支

如果想将当前分支下本地仓库中的内容推送给远程仓库，需要用到 git push命令。现在假定我们在 master 分支下进行操作。

1

像这样执行 git push命令，当前分支的内容就会被推送给远程仓库 origin的master分支。-u参数可以在推送的同时，将 origin仓库的 master分 支设置为本地仓库当前分支的upstream（上游）。添加了这个参数，将来 运行 git pull命令从远程仓库获取内容时，本地仓库的这个分支就可 以直接从 origin 的 master 分支获取内容，省去了另外添加参数的麻烦。 执行该操作后，当前本地仓库master分支的内容将会被推送到 GitHub的远程仓库中。在 GitHub上也可以确认远程 master分支的内容和本地 master 分支相同。

 推送至 master 以外的分支

除了master分支之外，远程仓库也可以创建其他分支。举个例子，我 们在本地仓库中创建 feature-D 分支，并将它以同名形式 push 至远程仓库。

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

我们在本地仓库中创建了 feature-D分支，现在将它push给远程仓 库并保持分支名称不变。

$ git push -u origin feature-D

Total 0 (delta 0), reused 0 (delta 0)

To git@github.com:github-book/git-tutorial.git

* [new branch]      feature-D -> feature-D

Branch feature-D set up to track remote branch feature-D from origin.

现在，在远程仓库的 GitHub 页面就可以查看到 feature-D 分支了。

● git clone——获取远程仓库

 获取远程仓库

首先我们换到其他目录下，将 GitHub上的仓库 clone到本地。注意不要与之前操作的仓库在同一目录下。

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

$ git branch -a

* master 

remotes/origin/HEAD -> origin/master 

remotes/origin/feature-D 

remotes/origin/master

我们用 git branch -a命令查看当前分支的相关信息。添加 -a 参数可以同时显示本地仓库和远程仓库的分支信息。 结果中显示了 remotes/origin/feature-D，证明我们的远程仓库中已经 有了 feature-D 分支。

 获取远程的 feature-D 分支

我们试着将 feature-D 分支获取至本地仓库。

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

Branch feature-D set up to track remote branch feature-D from origin.

Switched to a new branch 'feature-D'

-b参数的后面是本地仓库中新建分支的名称。为了便于理解，我 们仍将其命名为 feature-D，让它与远程仓库的对应分支保持同名。新建 分支名称后面是获取来源的分支名称。例子中指定了origin/feature-D， 就是说以名为 origin的仓库（这里指 GitHub端的仓库）的 feature-D分 支为来源，在本地仓库中创建 feature-D 分支。

 向本地的 feature-D 分支提交更改

现在假定我们是另一名开发者，要做一个新的提交。在README. md 文件中添加一行文字，查看更改.

按照之前学过的方式提交即可。

$ git commit -am "Add feature-D" [feature-D ed9721e] Add feature-D 1 file changed, 1 insertion(+)

 推送 feature-D 分支

现在来推送 feature-D 分支。

从远程仓库获取feature-D分支，在本地仓库中提交更改，再将 feature-D分支推送回远程仓库，通过这一系列操作，就可以与其他开发 者相互合作，共同培育 feature-D 分支，实现某些功能。

 ● git pull——获取最新的远程仓库分支

现在我们放下刚刚操作的目录，回到原先的那个目录下。这边的本 地仓库中只创建了 feature-D分支，并没有在 feature-D分支中进行任何提交。然而远程仓库的feature-D分支中已经有了我们刚刚推送的提交。 这时我们就可以使用 git pull命令，将本地的 feature-D分支更新到最新 状态。当前分支为 feature-D 分支。

GitHub端远程仓库中的feature-D分支是最新状态，所以本地仓库 中的 feature-D 分支就得到了更新。今后只需要像平常一样在本地进行提 交再push给远程仓库，就可以与其他开发者同时在同一个分支中进行 作业，不断给 feature-D 增加新功能。 如果两人同时修改了同一部分的源代码，push时就很容易发生冲 突。所以多名开发者在同一个分支中进行作业时，为减少冲突情况的发 生，建议更频繁地进行 push 和 pull 操作。