GitHub入门与实践

1.GitHub入门与实践

参考资料：《GitHub入门与实践》
   声明：本篇博客内容由笔者跟随该书举行现实使用并纪录过程而来，该篇博客内容大部分来自上述提到的书中。
  

下图改编自in/viciloria

1.1 对本土地算机里安装的 Git 举行设置

起首来设置使用 Git 时的姓名和邮箱地点

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

复制代码

1.2 使用github的前期准备

1.2.1 创建账户设置根本信息

1.2.2 设置SSH Key

GitHub 上毗连已有堆栈时的认证，是通过使用了 SSH 的公开密钥认证方式举行的。如今让我们来创建公开密钥认证所需的 SSH Key，并将其添加至 GitHub
运行下面的下令创建 SSH Key

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

复制代码

输入暗码后会出现以下结果

1. Your identification has been saved in /Users/your_user_directory/.ssh/id_rsa.
2. Your public key has been saved in /Users/your_user_directory/.ssh/id_rsa.pub.
3. The key fingerprint is:
4. fingerprint值 your_email@example.com
5. The key's randomart image is:
6. +--[ RSA 2048]----+
7. |.++|
8. |= o O .|

复制代码

id_rsa 文件是私有密钥，id_rsa.pub 是公开密钥
在 GitHub 中添加公开密钥，以后使用私钥举行认证
1.2.2 在github帐号内添加公钥

Title自己取名字，Key type用默认，Key添加之宿世成的公钥

使用以下下令查察公钥，并将该公钥添加到上图中Key的位置

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

复制代码

用手中的私家密钥与 GitHub 举行认证和通讯
输入下令

1. ssh -T git@github.com
2. Enter passphrase for key '~/.ssh/id_rsa': [输入自己github密码]
3. Hi,aaa.You've successfully authenticated,but github does not provide shell access.

复制代码

1.3 创建堆栈

右上角创建新堆栈

README.md
   一样平常在这个文件中标明本堆栈所包罗
（1) 软件的概要
（2) 使用流程
（3) 允许协议
等信息
  .gitignore文件的作用
   .gitignore 文件通过指定忽略规则，资助开发者管理项目中不须要提交的文件，优化项目的存储和协作服从，同时防止敏感信息的不测泄漏。
  

常见允许协议

1.4 公开代码

实行在已有堆栈中添加代码并加以公开
刚刚创建的堆栈的页面

1.4.1 git clone （将github长途堆栈克隆到本地）

起首将已有堆栈 clone 到本地的开发情况中

1. $ git clone git@github.com:irvingwu5/hello_world.git
2. Cloning into 'hello_world'...
3. Enter passphrase for key '/home/.../.ssh/id_rsa': [输入github密码]
4. remote: Enumerating objects: 3, done.
5. remote: Counting objects: 100% (3/3), done.
6. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
7. Receiving objects: 100% (3/3), done.

复制代码

1. cd hello_world/
2. ls
3. README.md

复制代码

1.4.2 coding （本地编写代码）

这里我们编写一个 hello.cpp 文件

1.4.3 git status （查察堆栈状态）

由于 hello.cpp 还没有添加至 Git 堆栈，以是表现为 Untracked files

1. $ git status
2. On branch main
3. Your branch is up to date with 'origin/main'.
5. Untracked files:
6.   (use "git add <file>..." to include in what will be committed)
7.         hello.cpp
9. nothing added to commit but untracked files present (use "git add" to track)

复制代码

1.4.4 git add （添加到暂存区） / git commit（生存堆栈汗青纪录） / git log（查察提交日记）

通过 git add下令将文件参加暂存区 A，再通过 git commit下令提交。添加乐成后，可以通过 git log下令查察提交日记
将 hello.cpp 提交 (commit) 至堆栈。如许一来，这个文件就进入了版本管理体系的管理之下。以后的更改管理都交由 Git 举行

1. $ git add hello.cpp
3. $ git commit -m "Add hello script by cpp"
4. [main 5f4b9e4] Add hello script by cpp
5. 1 file changed, 28 insertions(+)
6. create mode 100644 hello.cpp
8. $ git log
9. commit ........ (HEAD -> main)
10. Author: Wu Irving <....@....com>
11. Date:   Fri Oct 4 16:35:20 2024 +0800
13.     Add hello script by cpp
15. commit ........ (origin/main, origin/HEAD)
16. Author: Wu Xiang Yu <124986252+irvingwu5@users.noreply.github.com>
17. Date:   Fri Oct 4 16:12:46 2024 +0800
19.     Initial commit

复制代码

1.4.5 git push （代码推送回github长途堆栈）

1. $ git push
2. Enter passphrase for key '/home/.../.ssh/id_rsa': [输入github密码]
3. Enumerating objects: 4, done.
4. Counting objects: 100% (4/4), done.
5. Delta compression using up to 16 threads
6. Compressing objects: 100% (3/3), done.
7. Writing objects: 100% (3/3), 718 bytes | 718.00 KiB/s, done.
8. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
9. To github.com:irvingwu5/hello_world.git
10.    f68e6e2..5f4b9e4  main -> main

复制代码

1.5 根本使用

1.5.1 git init （初始化堆栈）

要使用 Git 举行版本管理，必须先初始化堆栈。Git 是使用 git init下令举行初始化的。请现实创建一个目次并初始化堆栈
本地终端输入下令，创建空目次，进入目次，举行初始化使用

1. $ mkdir git-tutorial
2. $ cd git-tutorial/
3. $ git init
4. hint: Using 'master' as the name for the initial branch. This default branch name
5. hint: is subject to change. To configure the initial branch name to use in all
6. hint: of your new repositories, which will suppress this warning, call:
7. hint:
8. hint:         git config --global init.defaultBranch <name>
9. hint:
10. hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
11. hint: 'development'. The just-created branch can be renamed via this command:
12. hint:
13. hint:         git branch -m <name>
14. Initialized empty Git repository in /home/.../Documents/CppProjects/git-tutorial/.git/

复制代码

git init 是一个 Git 下令，用于初始化一个新的 Git 堆栈。它的作用紧张包罗：
   1.创建版本控制情况：git init 下令会在当前目次下创建一个新的 .git 子目次，这个子目次包罗了 Git 版本控制所需的全部文件和布局。
2.开始跟踪文件：通过实行 git init，你可以开始将当前目次中的文件纳入版本控制。这意味着你可以使用其他 Git 下令（如 git add 和 git commit）来跟踪和管理文件的更改。
3.准备项目举行协作：假如你操持将这个项目与他人共享或将其推送到长途堆栈（如 GitHub），那么 git init 是第一步。
  在 Git 中，我们将这个目次（.git）的内容称为“附属于该堆栈的工作树”。
文件的编辑等使用在工作树中举行，然跋文录到堆栈中，以此管理文件的汗青快照。
假如想将文件规复到原先的状态，可以从堆栈中调取之前的快照，在工作树中打开。开发者可以通过这种方式获取以往的文件。

.git下各个目次和文件的寄义

1.5.2 git status（查察堆栈的状态）

工作树和堆栈在被使用的过程中，状态会不绝发生变革。在 Git 使用过程中时常用 git status下令查察当前状态
   工作树与 .git 目次的关系
工作树：你直接使用和编辑的文件。这些文件可以是源代码、文档、图像等，属于项目的现实内容。
.git 目次：用于存储与版本控制干系的元数据和对象。它管理版本汗青、索引、设置和其他版本控制信息。
  工作树表现图：

1. $ git status
2. On branch master
4. No commits yet
6. nothing to commit (create/copy files and use "git add" to track)

复制代码

on branch master表明我们当前正处在master分支下
提交（Commit），是指“纪录工作树中全部文件的当前状态”。“No commits yet” 尚没有可提交的内容，就是说当前我们创建的这个堆栈中还没有纪录任何文件的任何状态。
这里，我们创建 README.md 文件作为管理对象，为第一次提交做前期准备

1. $ touch README.md
2. $ git status
3. On branch master
5. No commits yet
7. Untracked files:
8.   (use "git add <file>..." to include in what will be committed)
9.         README.md
11. nothing added to commit but untracked files present (use "git add" to track)

复制代码

1.5.3 git add（向暂存区中添加文件）

假如只是用 Git 堆栈的工作树创建了文件 (touch README.md)，那么该文件并不会被记入 Git 堆栈的版本管理对象当中。因此我们用 git status下令查察README.md 文件时，它会表现在 Untracked files 里
要想让文件成为 Git 堆栈的管理对象，就须要用 git add下令将其参加暂存区（Stage 大概 Index）中。暂存区是提交之前的一个临时地区

1. $ git add README.md
2. $ git status
3. On branch master
5. No commits yet
7. Changes to be committed:
8.   (use "git rm --cached <file>..." to unstage)
9.         new file:   README.md

复制代码

将 README.md 文件参加暂存区后，git status下令的表现结果发生了变革。 可以看到，README.md 文件表现在 Changes to be committed 中了
1.5.4 git commit（生存堆栈的汗青纪录）

git commit下令可以将当前暂存区中的文件现实生存到堆栈的汗青纪录中。通过这些纪录，我们就可以在工作树中复原文件。
记述一行提交信息

1. $ git commit -m "First Commit" #加-m参数，则输入一行提交信息
2. [master (root-commit) db370d2] First Commit
3. 1 file changed, 0 insertions(+), 0 deletions(-)
4. create mode 100644 README.md

复制代码

提交信息表现图：（当堆栈被push到github上才气在页面看到）

记述详细提交信息

1. $ touch hello.cpp
2. $ git add hello.cpp
3. $ git status
4. On branch master
5. Changes to be committed:
6.   (use "git restore --staged <file>..." to unstage)
7.         new file:   hello.cpp
9. $ git commit #不加-m参数，则输入详细提交信息
10. # Please enter the commit message for your changes. Lines starting （第一行）
11. # with '#' will be ignored, and an empty message aborts the commit.
12. #（空行）
13. # On branch master（第三行以后）
14. # Changes to be committed: （可以查看本次提交中包含的文件）
15. #       new file:   hello.cpp
16. no add anything

复制代码

第一行：用一行笔墨简述提交的更改内容
第二行：空行
第三行以后：记述更改的缘故原由和详细内容
查察当前状态

1. $ git status
2. On branch master
3. nothing to commit, working tree clean

复制代码

当前工作树处于刚刚完成提交的最新状态，以是结果表现没有更改
1.5.5 git log（查察提交日记）

git log下令可以查察以往堆栈中提交的日记。包罗可以查察什么人在什么时间举行了提交或归并，以及使用前后有怎样的差别。
来看看刚才的 git commit下令是否被纪录了

1. $ git log
2. commit 1cbd40573990df40f6e7f55bcc58a5c182917d67 (HEAD -> master)
3. Author: Wu Irving <...@....com>
4. Date:   Fri Oct 4 18:14:40 2024 +0800
6.     no add anything
8. commit db370d29535422a4a44630ee0a8af9f52ee3569b #指向这个提交的哈希值,Git的其他命令中，在指向提交时会用到这个哈希值
9. Author: Wu Irving <...@.....com>
10. Date:   Fri Oct 4 17:59:57 2024 +0800
12.     First Commit

复制代码

只表现提交信息的第一行
假如只想让步伐表现第一行简述信息，可以在 git log下令后加上 --pretty=short。如许一来开发职员就可以大概更轻松地把握多个提交

1. $ git log --pretty=short
2. commit 1cbd40573990df40f6e7f55bcc58a5c182917d67 (HEAD -> master)
3. Author: Wu Irving <....@.....com>
5.     no add anything
7. commit db370d29535422a4a44630ee0a8af9f52ee3569b
8. Author: Wu Irving <....@.....com>
10.     First Commit

复制代码

只表现指定目次、文件的日记
只要在 git log下令后加上目次名，便会只表现该目次下的日记
假如加的是文件名，就会只表现与该文件干系的日记

1. $ git log README.md
2. commit db370d29535422a4a44630ee0a8af9f52ee3569b
3. Author: Wu Irving <....@.....com>
4. Date:   Fri Oct 4 17:59:57 2024 +0800
6.     First Commit

复制代码

表现文件的改动
假如想查察提交所带来的改动，可以加上 - p参数，文件的前后差别就会表现在提交信息之后

1. $ git log -p
2. commit 1cbd40573990df40f6e7f55bcc58a5c182917d67 (HEAD -> master)
3. Author: Wu Irving <....@.....com>
4. Date:   Fri Oct 4 18:14:40 2024 +0800
6.     no add anything
8. diff --git a/hello.cpp b/hello.cpp
9. new file mode 100644
10. index 0000000..e69de29
12. commit db370d29535422a4a44630ee0a8af9f52ee3569b
13. Author: Wu Irving <....@.....com>
14. Date:   Fri Oct 4 17:59:57 2024 +0800
16.     First Commit
18. diff --git a/README.md b/README.md
19. new file mode 100644
20. index 0000000..e69de29

复制代码

只查察 README.md 文件的提交日记以及提交前后的差别

1. $ git log -p README.md
2. commit db370d29535422a4a44630ee0a8af9f52ee3569b
3. Author: Wu Irving <....@.....com>
4. Date:   Fri Oct 4 17:59:57 2024 +0800
6.     First Commit
8. diff --git a/README.md b/README.md
9. new file mode 100644
10. index 0000000..e69de29

复制代码

1.5.6 git diff（查察更改前后的差别）

git diff下令可以查察工作树、暂存区、最新提交之间的差别。
在README.md文件中添加笔墨，查察更改前后差别
查察工作树和暂存区的差别

1. $ git diff
2. diff --git a/README.md b/README.md
3. index e69de29..6e35e14 100644
4. --- a/README.md
5. +++ b/README.md
6. @@ -0,0 +1 @@
7. +#git tutorial
8. #“+”号标出的是新添加的行，被删除的行则用“-”号标出

复制代码

由于我们尚未用 git add下令向暂存区添加任何东西，以是步伐只会表现工作树与最新提交状态之间的差别
用 git add下令将 README.md 文件参加暂存区

1. $ git add README.md

复制代码

假如如今实行 git diff下令，由于工作树和暂存区的状态并无差别，结果什么都不会表现
要查察与最新提交的差别使用下令 git diff HEAD

1. $ git diff HEAD
2. diff --git a/README.md b/README.md
3. index e69de29..6e35e14 100644
4. --- a/README.md
5. +++ b/README.md
6. @@ -0,0 +1 @@
7. +#git tutorial

复制代码

风俗养成：在实行 git commit下令之前先实行git diff HEAD下令，查察本次提交与前次提交之间有什么差别，等确认完毕后再举行提交。（这里的 HEAD 是指向当前分支中最新一次提交的指针）
使用git commit将刚刚修改过的文件生存到堆栈的汗青纪录中

1. $ git commit -m "Add function"
2. [master d16037b] Add function
3. 1 file changed, 1 insertion(+)

复制代码

查察日记，确认是否提交乐成

1. $ git log
2. commit d16037ba205b79554d772ce8bed20c7b13731760 (HEAD -> master)
3. Author: Wu Irving <....@.....com>
4. Date:   Fri Oct 4 18:47:02 2024 +0800
6.     Add function
8. commit 1cbd40573990df40f6e7f55bcc58a5c182917d67
9. Author: Wu Irving <....@.....com>
10. Date:   Fri Oct 4 18:14:40 2024 +0800
12.     no add anything
14. commit db370d29535422a4a44630ee0a8af9f52ee3569b
15. Author: Wu Irving <....@.....com>
16. Date:   Fri Oct 4 17:59:57 2024 +0800
18.     First Commit

复制代码

1.6 分支使用

1.6.1 git branch（表现分支一览表）

git branch下令可以将分支名列表表现，同时可以确认当前地点分支

1. $ git branch
2. * master #星号表示当前所在分支

复制代码

1.6.2 git checkout -b（创建、切换分支）

1. $ git checkout -b feature-A #创建并切换分支
2. Switched to a new branch 'feature-A'

复制代码

等价于

1. $ git branch feature-A #创建分支
2. $ git checkout feature-A #切换分支

复制代码

查察分支情况

1. $ git branch
2. * feature-A
3.   master

复制代码

feature-A 分支左侧标有“*”，表现当前分支为 feature-A。在这个状态下像正常开发那样修改代码、实行 git add下令并举行提交的话，代码就 会提交至 feature-A 分支。 像如许不绝对一个分支（比方feature-A）举行提交的使用，我们称为 “培养分支”

在README.md中添加一行后举行提交

1. $ nano README.md#git tutorial
3.   -feature-A
4. $ git add README.md
5. $ git commit -m "Add feature-A"[feature-A bd15091] Add feature-A 1 file changed, 1 insertion(+)

复制代码

README.md中这一行内容添加到了feature-A分支中了
如今我们再来看一看 master 分支有没有受到影响。起首切换至master 分支，然后查察 README.md 文件，会发现 README.md 文件仍旧保持原先的状态，并没有被添加笔墨。feature-A 分支的更改不会影响到master 分支，这正是在开发中创建分支的优点。只要创建多个分支，可以在不相互影响的情况下同时举行多个功能的开发。

1. $ git checkout master
2. Switched to branch 'master'
3. $ nano README.md
4. #git tutorial

复制代码

feature-A分支中README.md内容

1. #git tutorial
3.   -feature-A

复制代码

master分支中README.md内容

1. #git tutorial

复制代码

切换回上一个分支
用“-”（连字符）代替分支名，就可以切换至上一个分支

1. $ git checkout -
2. Switched to branch 'feature-A'

复制代码

主干分支、特性分支

1.6.3 git merge（归并分支）

假设 feature-A 已经实现完毕，想要将它归并到主干分支 master 中。起首切换到 master 分支

1. $ git branch
2. * feature-A
3.   master
4.   $ git checkout masterSwitched to branch 'master'$ git branch  feature-A* master

复制代码

归并 feature-A 分支。为了在汗青纪录中明确纪录下本次分支归并，我们须要创建归并提交。因此，在归并时加上 --no-ff参数

1. $ git merge --no-ff feature-A
2. # 随后编辑器会启动，用于录入合并提交的信息
3. Merge branch 'feature-A'
4. # Please enter a commit message to explain why this merge is necessary,
5. # especially if it merges an updated upstream into a topic branch.
6. #
7. # Lines starting with '#' will be ignored, and an empty message aborts
8. # the commit.
10. # 默认信息中已经包含了是从 feature-A 分支合并过来的相关内容，所以可不必做任何更改。将编辑器中显示的内容保存，关闭编辑器，然后就会看到下面的结果。
11. Merge made by the 'ort' strategy.
12. README.md | 1 +
13. 1 file changed, 1 insertion(+)

复制代码

1.6.4 git log --graph（以图心情势查察分支）

用 git log --graph下令举行查察的话，能很清晰地看到特性分支（feature-A）提交的内容已被归并。除此以外，特性分支的创建以及归并也都清晰明确

1. $ git log --graph
2. *   commit 1515c54edfd7ddfaba476e67c0b52bf878c3af78 (HEAD -> master)
3. |\  Merge: d16037b bd15091
4. | | Author: Wu Irving <....@.....com>
5. | | Date:   Fri Oct 4 19:48:23 2024 +0800
6. | |
7. | |     Merge branch 'feature-A'
8. | |
9. | * commit bd15091d17ef71bf63e98e9e501d4b66ba43fe67 (feature-A)
10. |/  Author: Wu Irving <....@.....com>
11. |   Date:   Fri Oct 4 19:17:40 2024 +0800
12. |   
13. |       Add feature-A
14. |
15. * commit d16037ba205b79554d772ce8bed20c7b13731760
16. | Author: Wu Irving <....@.....com>
17. | Date:   Fri Oct 4 18:47:02 2024 +0800
18. |
19. |     Add function
20. |
21. * commit 1cbd40573990df40f6e7f55bcc58a5c182917d67
22. | Author: Wu Irving <....@.....com>
23. | Date:   Fri Oct 4 18:14:40 2024 +0800
24. |
25. ....
26. ....

复制代码

1.7 更改提交的使用

1.7.1 git reset（回溯汗青版本）

回溯汗青
要让堆栈的 HEAD、暂存区、当前工作树回溯到指定状态，须要用到 git reset --hard下令。只要提供目的时间点的哈希值 A，就可以完全规复至该时间点的状态

1. $ git log --graph
2. *   commit 1515c54edfd7ddfaba476e67c0b52bf878c3af78 (HEAD -> master)
3. |\  Merge: d16037b bd15091
4. | | Author: Wu Irving <....@.....com>
5. | | Date:   Fri Oct 4 19:48:23 2024 +0800
6. | |
7. | |     Merge branch 'feature-A'
8. | |
9. | * commit bd15091d17ef71bf63e98e9e501d4b66ba43fe67 (feature-A)
10. |/  Author: Wu Irving <....@.....com>
11. |   Date:   Fri Oct 4 19:17:40 2024 +0800
12. |   
13. |       Add feature-A
14. |
15. * commit d16037ba205b79554d772ce8bed20c7b13731760
16. | Author: Wu Irving <....@.....com>
17. | Date:   Fri Oct 4 18:47:02 2024 +0800
18. |
19. |     Add function
20. |
21. * commit 1cbd40573990df40f6e7f55bcc58a5c182917d67
22. | Author: Wu Irving <....@.....com>
23. | Date:   Fri Oct 4 18:14:40 2024 +0800
24. |
25. ....
26. ....

复制代码

回溯到特性分支（feature-A）创建之前的状态

1. $ git reset --hard 1515c54edfd7ddfaba476e67c0b52bf878c3af78
2. HEAD is now at bd15091 Add feature-A

复制代码

1. $ git log --graph
2. * commit bd15091d17ef71bf63e98e9e501d4b66ba43fe67 (HEAD -> master)
3. | Author: Wu Irving <....@.....com>
4. | Date:   Fri Oct 4 19:17:40 2024 +0800
5. |
6. |     Add feature-A
7. |
8. * commit d16037ba205b79554d772ce8bed20c7b13731760
9. | Author: Wu Irving <....@.....com>
10. | Date:   Fri Oct 4 18:47:02 2024 +0800
11. |
12. |     Add function
13. |
14. * commit 1cbd40573990df40f6e7f55bcc58a5c182917d67
15. | Author: Wu Irving <....@.....com>
16. | Date:   Fri Oct 4 18:14:40 2024 +0800
17. |
18. |     no add anything
19. |
20. * commit db370d29535422a4a44630ee0a8af9f52ee3569b
21.   Author: Wu Irving <....@.....com>
22.   Date:   Fri Oct 4 17:59:57 2024 +0800
23.   
24.       First Commit

复制代码

1.7.2 git commit --amend（修改提交信息）

要修改上一条提交信息，可以使用 git commit --amend下令

1. $ git commit --amend

复制代码

1.7.3 git rebase -i（压缩汗青）

git rebase -i（交互式 rebase）中的“压缩汗青”指的是将多个提交归并为一个或多个提交，从而精简和整理 Git 提交汗青。这对于整理开发过程中频仍的小提交、归并重复的提交、大概让项目的提交汗青更为清晰整齐非常有效。
假设你有以下的提交汗青：

1. commit 789def4 (HEAD -> feature)
2. Author: You
3. Date:   Fri Oct 1 2024
5.     Fix typo in README
7. commit 456abc7
8. Author: You
9. Date:   Fri Oct 1 2024
11.     Improve README format
13. commit 123abc1
14. Author: You
15. Date:   Fri Oct 1 2024
17.     Add initial README

复制代码

如今，你渴望将这些三个提交压缩成一个提交，整理成一个单一的提交来形貌你对 README 文件的全部修改。这时可以使用 git rebase -i。
步调一：运行 git rebase -i 下令，指定须要举行压缩的范围。比方，你想将末了三次提交归并，可以运行：

1. git rebase -i HEAD~3

复制代码

步调二：实行下令后，Git 会打开一个文本编辑器，表现雷同如下的界面：

1. pick 123abc1 Add initial README
2. pick 456abc7 Improve README format
3. pick 789def4 Fix typo in README

复制代码

此中，每个 pick 表现一个提交。默认情况下，Git 会按汗青序次保存这些提交。
步调三：为了将这些提交压缩为一个，你可以将第二和第三个 pick 修改为 squash 或 s，像如许：

1. pick 123abc1 Add initial README # pick：保留提交。
2. squash 456abc7 Improve README format # squash：将该提交的更改压缩（合并）到前一个提交中。
3. squash 789def4 Fix typo in README

复制代码

步调四：生存并退出编辑器后，Git 会集并这些提交，并打开另一个编辑器，让你修改新的提交信息。你可以选择保存各个提交的原始消息，大概编写一个新的提交消息。好比：

1. Add initial README and improvements
3. - Add initial README
4. - Improve README format
5. - Fix typo in README

复制代码

步调五：生存提交消息后，Git 会完成压缩使用。终极，提交汗青会酿成如下所示：

1. commit 9abcdef (HEAD -> feature)
2. Author: You
3. Date:   Fri Oct 1 2024
5.     Add initial README and improvements

复制代码

颠末 git rebase -i 压缩后，原来的三个提交被归并为一个提交，整个汗青变得更加轻巧，提交信息更具代表性，克制了过于细碎的提交。
1.8 推送至长途堆栈

1.8.1 git remote add（添加长途堆栈）

在 GitHub 上创建的堆栈路径为“git@github.com :用户名/git-tutorial.git”。如今我们用 git remote add下令将它设置成本地堆栈的长途堆栈

1. $ 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（标识符）
1.8.2 git push（推送至长途堆栈）

推送到master分支
假如想将当前分支下本地堆栈中的内容推送给长途堆栈，须要用到git push下令。如今假定我们在 master 分支下举行使用。

1. $ git push -u origin master
2. Counting objects: 20, done.
3. Delta compression using up to 8 threads.
4. Compressing objects: 100% (10/10), done.
5. Writing objects: 100% (20/20), 1.60 KiB, done.
6. Total 20 (delta 3), reused 0 (delta 0)
7. To git@github.com:github-book/git-tutorial.git
8. * [new branch]
9. master -> master
10. Branch master set up to track remote branch master from origin.

复制代码

像如许实行 git push下令，当前分支的内容就会被推送给长途堆栈origin 的 master 分支

推送到master以外的分支
除了 master 分支之外，长途堆栈也可以创建其他分支。举个例子，我们在本地堆栈中创建 feature-D 分支，并将它以同名情势 push 至长途堆栈

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

复制代码

我们在本地堆栈中创建了 feature-D 分支，如今将它 push 给长途堆栈并保持分支名称稳定

1. $ git push -u origin feature-D
2. Total 0 (delta 0), reused 0 (delta 0)
3. To git@github.com:github-book/git-tutorial.git
4. * [new branch]
5. feature-D -> feature-D
6. Branch feature-D set up to track remote branch feature-D from origin.

复制代码

如今，在长途堆栈的 GitHub 页面就可以查察到 feature-D 分支了
1.9 从长途堆栈获取

1.9.1 git clone（获取长途堆栈）

获取长途堆栈

1. $ git clone git@github.com:github-book/git-tutorial.git
2. Cloning into 'git-tutorial'...
3. remote: Counting objects: 20, done.
4. remote: Compressing objects: 100% (7/7), done.
5. remote: Total 20 (delta 3), reused 20 (delta 3)
6. Receiving objects: 100% (20/20), done.
7. Resolving deltas: 100% (3/3), done.
8. $ cd git-tutorial

复制代码

实行 git clone下令后我们会默认处于 master 分支下，同时体系会主动将 origin 设置成该长途堆栈的标识符。也就是说，当前本地堆栈的 master 分支与 GitHub 端长途堆栈（origin）的 master 分支在内容上是完全雷同的

1. $ git branch -a
2. * master #本地仓库
3. remotes/origin/HEAD -> origin/master #远程仓库
4. remotes/origin/feature-D
5. remotes/origin/master

复制代码

我们用 git branch -a下令查察当前分支的干系信息。添加 -a参数可以同时表现本地堆栈和长途堆栈的分支信息。结果中表现了 remotes/origin/feature-D，证明我们的长途堆栈中已经有了 feature-D 分支
获取长途的 feature-D 分支

1. $ git checkout -b feature-D origin/feature-D #- b 参数的后面是本地仓库中新建分支的名称 紧接着为远程仓库分支名称
2. Branch feature-D set up to track remote branch feature-D from origin.
3. Switched to a new branch 'feature-D'

复制代码

修改后将本地的 feature-D 分支提交更改
先实行 git add下令，再实行 git commit下令 等价于 git commit -am “提交信息”

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

复制代码

推送 feature-D 分支

1. $ git push
2. Counting objects: 5, done.
3. Delta compression using up to 8 threads.
4. Compressing objects: 100% (2/2), done.
5. Writing objects: 100% (3/3), 281 bytes, done.
6. Total 3 (delta 1), reused 0 (delta 0)
7. To git@github.com:github-book/git-tutorial.git
8. ca0f98b..ed9721e feature-D -> feature-D

复制代码

从长途堆栈获取 feature-D 分支，在本地堆栈中提交更改，再将feature-D 分支推送回长途堆栈，通过这一系列使用，就可以与其他开发者相互互助，共同培养 feature-D 分支，实现某些功能
1.9.2 git pull （获取最新的长途堆栈分支）

长途堆栈的 feature-D 分支中更新了内容，将本地的 feature-D 分支更新到最新状态

1. $ git pull origin feature-D
2. remote: Counting objects: 5, done.
3. remote: Compressing objects: 100% (1/1), done.
4. remote: Total 3 (delta 1), reused 3 (delta 1)
5. Unpacking objects: 100% (3/3), done.
6. From github.com:github-book/git-tutorial
7. * branch
8. feature-D -> FETCH_HEAD
9. First, rewinding head to replay your work on top of it...
10. Fast-forwarded feature-D to ed9721e686f8c588e55ec6b8071b669f411486b8.

复制代码

1.10 实行Pull Request

Pull Request 是自己修改源代码后，哀求对方堆栈采取该修改时接纳的一种活动
如今假设我们在使用 GitHub 上的一款开源软件。在使用这款软件的过程中，我们偶尔间发现了 BUG。为了继续使用软件，我们手动修复了这个 BUG。假如我们修改的这段代码能被该软件的开发堆栈采取，以后与我们同样使用这款软件的人就不会再遇到这个 BUG。为此，我们要第一时间发送 Pull Request
在 GitHub 上发送 Pull Request 后，汲取方的堆栈会创建一个附带源代码的 Issue，我们在这个 Issue 中纪录详细内容。这就是 Pull Request.Pull Request 在网络上也常常被简称为 PR
发送已往的 Pull Request 是否被采取，要由汲取方堆栈的管理者举行判断。一样平常只要代码没有标题，对方都会采取。假如有标题，我们会收到批评。只要 Pull Request 被顺遂采取，我们就会成为这个项目的 Contributor（贡献者），我们编写的这段代码也将被全天下的人使用

不举行 Fork 直接从分支发送 Pull Request
一样平常说来，在 GitHub 上修改对方的代码时，须要先将堆栈 Fork 到本地，然后再修改代码，发送 Pull Request。但是，假如用户对该堆栈有编辑权限，则可以直接创建分支，从分支发送 Pull Request。使用这一计划，团队开发时不妨为每一名成员赋予编辑权限，免除 Fork 堆栈的贫苦。如许，成员在有须要时就可以创建自己的分支，然后直接向 master分支等发送 Pull Request
堆栈的维护

1.11 汲取Pull Request

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金