git基础

学习网址

Git教程|菜鸟教程

Pro-Git

 

前言

此处主要是记录一些有用但之前自己所用较少的命令，并不包括一些最基础的命令，入门的话可以去看菜鸟教程的Git教程。

 

记录仓库变动

git rm

要从 Git 中移除一个文件，必须先将其从跟踪文件中移除（更准确地说，是从暂存区域中移除），然后再提交。git rm 命令就能做到这一点，同时还能将文件从工作目录中移除，这样下次提交时就不会看到它是未跟踪文件了。

 

$ git rm PROJECTS.md

rm 'PROJECTS.md'

$ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

 

    deleted: PROJECTS.md

1

2

3

4

5

6

7

8

9

Tips：可认为是rm file + git add file的结合体。

 

$ git rm --cached README

1

git rm --cached命令的功能是将文件从 Git 的暂存区中移除，这样这些文件就不会被包含在下一次的提交中。然而，这些文件仍然会保留在你的工作目录中，这样你就可以继续对它们进行修改，而不会丢失文件的内容。

 

$ git rm log/\*.log

1

注意 * 前面的反斜线 ()，这是通配符的表达方式。这条命令会删除 log/ 目录下所有扩展名为 .log 的文件。

 

git mv

主要用于在仓库中重命名一个已跟踪的文件。

 

git mv file_from file_to

1

等价于下面的代码

 

$ mv file_from file_to

$ git rm file_from

$ git add file_to

1

2

3

查看提交历史

查看每次提交的简短统计信息，可以加上--stat选项；(常用)

 

git log --stat

1

忽略所有merge的log，使用--no-merges选项；(常用)

查看特定路径或者文件的提交log；(常用)

 

git log file_name/location_name

1

还可以使用--pretty=format定制化内容的输出格式；

或者使用--pretty选项搜寻满足特定条件的提交，可以包括对日期，作者，修改文件的约束；

使用--graph选项在日志旁以图形化方式显示分支和合并历史；

 

git reflog

git reflog是 Git 的一个命令，用于查看本地仓库中 HEAD 和分支的移动历史记录。它记录了本地仓库中的引用（reference）的变动情况，包括分支切换、提交、重置等操作，但不包括远程引用的变动。

该命令主要的使用场景有：当你意外地删除分支、回退到错误的提交、或者执行了其他误操作时(如git reset --hard)，可以使用 git reflog 找回之前的引用状态，然后进行恢复操作。通过查看 reflog，你可以找到误操作之前的引用状态，并恢复到正确的状态。

 

撤销动作

git commit --amend

git commit --amend允许你修改最新的提交，举例说明：假设你已经提交了一个修改，但后来发现有些内容遗漏了或者需要进行修正。且你不想创建一个新的提交来修正这些问题，因为这会使你的提交历史变得混乱。这时候，你可以使用git commit --amend命令。

 

git commit -m 'Initial commit'

git add forgotten_file

git commit --amend

1

2

3

这会将Initial commit提交的内容与forgotten_file的commit合并，但提交历史上只保留一条记录。综上，git commit --amend命令允许你修改最新的提交，同时保持提交历史的整洁性。

有了该命令，我们就可以及时将工作区的修改内容进行commit，防止内容的丢失，后面都使用--amend选项保持提交历史的整洁，最后万事俱备再push上库。

 

git reset HEAD <file>

取消暂存区文件的提交，或者使用下面的命令：

 

git restore --staged <file>

1

git checkout <file>

撤销工作区对文件的修改；

也可以使用下面的命令：

 

git restore <file>

1

如此看来git restore命令更加统一好用，同时也会出现在git的提示消息中；

 

撤销commit(慎用)

1.撤销并保留修改：

如果你想保留修改但是撤销最新的提交，可以使用以下命令：

 

git reset --soft HEAD~1

1

这个命令会将 HEAD 移动到上一个提交，并将你的修改保留在工作目录和暂存区中，以便你可以继续修改并重新提交。

2.撤销并丢弃修改：

如果你想完全撤销最新的提交，并且不保留任何修改，可以使用以下命令：

 

git reset --hard HEAD~1

1

这个命令会将 HEAD 移动到上一个提交，并且会丢弃你的修改，恢复到上一个提交的状态。

也可以用具体的提交哈希值来代替 HEAD~1，比如 git reset --soft <commit_hash> 或 git reset --hard <commit_hash>。

需要注意的是，如果你的提交已经被推送到了远程仓库，并且其他人已经基于该提交进行了工作，撤销提交可能会导致一些问题。在这种情况下，最好与团队成员讨论，以确保撤销提交不会对项目产生负面影响。(可以使用后面所说的git revert命令来解决)

也就是说你可以修改没有push的commit，已经push的commit回退版本时要慎重，最好通过提交新的更改来修复问题，而不是直接撤销提交。这样可以保持提交历史的完整性，同时避免影响其他人的工作。

 

远端仓库相关

git fetch

git fetch 命令用于从远程仓库下载最新的提交和数据到你的本地仓库，但它不会合并这些改变到你的当前工作分支。其作用包括：

 

更新远程跟踪分支： 执行 git fetch 后，Git 会下载远程仓库中的最新提交和数据，并将它们保存在本地仓库中。这些数据包括远程分支（如 origin/master）的引用，它们跟踪了远程仓库的状态。

 

获取最新提交： git fetch 会将远程仓库中的最新提交下载到本地，但不会修改你的工作目录或当前工作分支。这使得你可以查看远程仓库的最新状态，然后决定是否需要合并或拉取这些提交到你的工作分支。

 

设想如下场景，你的同事新建了一分支，名为"branch_a"，并push到远端仓库。这时候你在本地，想直接拉取该分支，使用git pull origin branch_a命令时会报错，因为你没有将远端仓库的提交和数据下载到你的本地仓库，你的本地仓库中并没有“branch_a”的信息。要么你现在当前分支运行git pull命令获取远端仓库的最新提交和数据；要么先运行git fetch的命令，获取“branch_a"的分支信息，再进行后续的分支切换与拉取。

 

git remote rename

给远端仓库重命名：

 

$ git remote rename pb paul

$ git remote

origin

paul

1

2

3

4

取消远端仓库重命名：

 

$ git remote remove paul

$ git remote

origin

1

2

3

标签相关

查看标签

列出仓库中所有的tag，还可以搜索特定pattern的标签：

 

$ git tag -l "v1.8.5*"

v1.8.5

v1.8.5-rc0

v1.8.5-rc1

v1.8.5-rc2

v1.8.5-rc3

v1.8.5.1

v1.8.5.2

1

2

3

4

5

6

7

8

创建标签

Git 支持两种类型的标签：轻量级标签和注释标签。轻量级标签可以理解为给commit的hash值重命名，没有任何额外信息，而注释标签可以保存创建标签的作者，注释和日期等信息；

下面是创建注释标签(Annotated Tags)的示例，在创建tag时需要增加-a的选项：

 

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

$ git tag

v0.1

v1.3

v1.4

1

2

3

4

5

$ git show v1.4

tag v1.4

Tagger: Ben Straub <ben@straub.cc>

Date: Sat May 3 20:19:12 2014 -0700

 

my version 1.4

 

commit ca82a6dff817ec66f44342007202690a93763949

Author: Scott Chacon <schacon@gee-mail.com>

Date: Mon Mar 17 21:52:11 2008 -0700

 

    Change version number

1

2

3

4

5

6

7

8

9

10

11

12

轻量级标签只需要在git tag后添加标签名即可：

 

$ git tag v1.4-lw

$ git tag

v0.1

v1.3

v1.4

v1.4-lw

v1.5

1

2

3

4

5

6

7

$ git show v1.4-lw

commit ca82a6dff817ec66f44342007202690a93763949

Author: Scott Chacon <schacon@gee-mail.com>

Date: Mon Mar 17 21:52:11 2008 -0700

 

    Change version number

1

2

3

4

5

6

如果我们要给之前的某个commit打标签的话，只需要在git tag后加入commit的hash值即可，如：

 

git tag -a v1.2 -m "my version 1.2" 9fceb02

1

推送标签

默认情况下，git push不会将tag信息push上库，除非显式地指定，与分支上库相同，将tag同步到远端仓库的命令为：git push origin <tag_name>

 

$ git push origin v1.5

Counting objects: 14, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (12/12), done.

Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.

Total 14 (delta 3), reused 0 (delta 0)

To git@github.com:schacon/simplegit.git

 * [new tag] v1.5 -> v1.5

1

2

3

4

5

6

7

8

如果有许多tag要推送上库的话，可以使用--tags选项

 

$ git push origin --tags

Counting objects: 1, done.

Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.

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

To git@github.com:schacon/simplegit.git

 * [new tag] v1.4 -> v1.4

 * [new tag] v1.4-lw -> v1.4-lw

1

2

3

4

5

6

7

删除标签

删除标签有如下命令，本地删除tag：

 

$ git tag -d v1.4-lw

Deleted tag 'v1.4-lw' (was e7d5add)

1

2

删除远端仓库的tag：git push origin --delete <tagname>

 

切换标签

如果你想切换标签，可以使用git checkout <tag_name>即可。需要注意的是，在 "分离 HEAD "状态下，如果你做了修改，然后又创建了一个提交，tag将保持不变，但你的新提交将不属于任何分支，而且除了通过准确的提交哈希值访问外，将无法访问。因此，如果你需要进行修改，比如修复旧版本上的一个 bug，一般会先基于tag创建一个分支。

 

$ git checkout -b version2 v2.0.0

Switched to a new branch 'version2'

1

2

上述命令是基于tag v2.0.0创建分支version2并切换到version2分支，这样的话我们可以基于v2.0.0继续开发。

 

分支相关

将本地分支与远端分支相关联，下面的示例代码是将当前的工作分支与远端的serverfix相关联；

 

git checkout --track origin/serverfix

1

新建分支并与远端分支相关联：

 

git checkout -b <branch> <remote>/<branch>

1

Tips：有上述命令的快捷方式，较为常用。如果你要检出的分支名称（a）不存在，（b）只与一个远程上的名称完全匹配，同时满足a和b条件的话，Git会自动帮你创建一个跟踪分支。

 

查看已设置的跟踪分支，并列出本地分支的各种信息，包括跟踪的远端分支名，是ahead or behind；

 

git branch -vv

1

删除远端分支：

 

$ git push origin --delete serverfix

To https://github.com/schacon/simplegit

 - [deleted] serverfix

1

2

3

git rebase

git rebase功能与git merge类似，区别在于log比较干净。适用于在推送之前进行rebase，确保log干净后再push上库，而不要对已推送的库上的内容进行rebase。

 

git rebase <base_branch> <topic_branch>

1

一. 进行分支合并

git rebase 主要用于将一个分支的提交移动到另一个分支上，常用于将一个分支的提交合并到另一个分支上。相较于git merge的优点在于commit log里没有"merge xxx into xxx"的日志，看着比较舒服。下面示例将演示如何使用 git rebase 将一个分支的提交合并到另一个分支上。

 

假设我们有两个分支：feature 和 master。我们想要将 feature 分支上的提交合并到 master 分支上。

 

首先，我们需要切换到 feature 分支：

git checkout feature

1

然后，我们运行 git rebase 命令来将 master 分支上的提交移动到 feature 分支上，可以执行以下命令：

git rebase -i master

1

在执行上述命令后，Git 会将 master 分支上的提交逐个应用到 feature 分支上。如果在此过程中出现冲突，需要解决冲突并继续 rebase 过程。可以使用 git status 命令查看冲突的文件，并手动解决冲突。

 

解决完冲突后，使用以下命令继续 rebase 过程：

 

git add <conflicted_file>

git rebase --continue

1

2

重复步骤 3 和步骤 4，合并后进行merge完成feature的合并。

git checkout master

git merge feature

1

2

通过以上步骤，我们使用 git rebase 将 feature 分支上的提交合并到了 master 分支上。这种方式可以使得提交历史保持线性，并且可以减少不必要的合并提交。使用rebase命令时一定切记，我们是否会修改其他同事也能看到的已经存在的commit内容，如果是，则不要使用rebase，尽量使用merge。

 

如果远端仓库的分支名为master，在我们想push修改时，其他同事也在master上有修改，我们可以使用git pull --rebase，commit log是线性的，在rebase后再进行git push操作。需要注意的是使用git pull --rebase时，仓库内不能有modified的文件，我们可以在pull之前使用git stash命令。

参考资料：

git pull --rebase的正确使用

merging vs. rebasing

 

二. 进行多次commit的合并

设想我们在新分支上进行了对同一文件进行了多次commit，有较多的历史信息，为了log的整洁性，我们希望把这多次commit进行整合，合并为一次commit，并修改提交信息。比如我们希望将最近的三次commit修改为一次commit，依次进行下面操作。

要使用 Git rebase 将最近的三个 commit 合并为一个 commit 并修改 commit 信息，你可以按照以下步骤进行操作：

 

执行 git rebase -i HEAD~3 命令来启动交互式 rebase。这将打开一个文本编辑器，列出了最近的三个 commit。

在编辑器中，你会看到一个包含了最近三个 commit 的列表，每个 commit 都有一个前缀为 “pick” 的行。将除了第一个 commit 之外的所有 “pick” 行的前缀改为 “squash” 或 “s”（表示合并），这样 Git 将会将它们合并到第一个 commit 中。

保存并关闭编辑器。Git 将会继续 rebase 操作，并在需要的时候打开另一个编辑器，以便你编辑合并后的 commit 信息。

在新的编辑器中，修改合并后的 commit 信息，以反映你所做的更改。保存并关闭编辑器。

完成 rebase 操作后，你可能需要解决任何可能出现的合并冲突。Git 会提示你在 rebase 过程中遇到的任何冲突，并提供解决冲突的指导。

最后，使用 git log 确认你的 commit 已经合并并修改成功。

以下是一个简单的示例：

 

git rebase -i HEAD~3

1

编辑器中的内容：(其中git会提供较多的选项，我们按需选择就行)

 

pick 1234567 Commit message 1

squash abcdefg Commit message 2

squash hijklmn Commit message 3

1

2

3

编辑器中的内容：

 

# This is a combination of 3 commits.

# This is the new commit message.

1

2

保存并关闭编辑器，然后解决可能出现的冲突，最后确认合并结果。

 

工作流程

空白行track

在git commit之前，运行下面命令检查是否track了空白行：

 

git diff --check

1

将开发分支合并到主分支上时，可以使用git merge --squash命令，它是 Git 中用于合并分支并压缩提交历史的命令。它的作用是将一个分支上的所有提交压缩成一个提交，并将这个提交合并到当前分支上，适用于需要保持提交历史清晰、整洁的情况。

 

三点语法

查看分支上(contrib)相对于主分支(master)的所有改动情况，可以使用git diff master...contrib来查看，该命令只显示当前主题分支与主分支的共同节点之后引入的工作。

 

离线归档

准备release版本时，可以使用git archive命令创建一个zip的归档文件，供那些不使用git的人查看或进行代码备份。

使用git log --no-merges master --not v1.0查看master分支自tag v1.0后的所有改动，不包括merge的变动，可以整理查看所有的改动情况。

 

两点语法

设想如下场景，你的主分支名字叫master，为新开发特性，新建分支featureA，随后master和featureA分支各自并行进行。最后featureA开发完毕，准备合并进入master时，你想看一下哪些commit是仅在featureA上而不在master上(因为我们是基于master新建的分支featureA，所以它也继承了之前master分支上的log)，你可以使用下面命令：git log master..featureA。

同理，想将本地push到远程，并查看有什么新的commit时，可以使用如下命令：git log origin/master..HEAD。其中下面两种写法与两点的语法同理：

 

git log ^master featureA

git log featureA --not master

1

2

通过上面的语法，我们可以更进一步：

 

git log refA refB ^refC

git log refA refB --not refC

1

2

如果我们在一个文件中一次修改多个bug，但想分段进行commit，也就是分不同的修改部分进行commit，这时我们可以使用git add -p选项进行修改内容的选择跟踪。

 

git stash

使用场景：当你正在进行一些修改，但需要切换到其他分支或者处理其他任务时，可以使用 git stash 临时保存当前工作目录的修改。这样可以避免将未完成的工作提交到版本库，保持工作目录的干净和整洁。使用git stash或者git stash push命令。使用git stash list查看stash列表，使用git stash apply将存储的状态取出来(取出来但还不会在list中删除，如果想取出随后就删除，请使用git stash pop命令)，默认取出的stash是最新压栈的。

当你只想保存工作目录中的部分修改，而不是全部修改时，可以先将需要提交的修改添加到暂存区中，然后运行git stash --keep-index命令保存工作目录的修改。这样可以确保保存的修改不包含已经暂存的部分。

git stash -u是 Git 中 git stash 命令的一个选项，它用于将当前工作目录的修改临时保存到存储中，并且包括未跟踪的文件。

最后，如果我们增加“–patch”选项，git会交互式地与你确认哪些修改需要进行stash，而哪些不需要。

 

git clean

如果我们想直接删除工作目录中untrack的文件，而不是把它压栈，可以使用git clean命令，为了安全起见，最好加上“-i”选项进行交互式删除。加上"-d"选项会自动删除untrack的空文件夹。

 

git搜寻

使用下面命令查看特定字符串的提交或修改记录，其中ZLIB_BUF_MAX为我们想搜寻的字符，--oneline是输出的选项，以简易形式输出。

 

git log -S ZLIB_BUF_MAX --oneline

1

使用git blame file查看file中每一行的最近改动，可以查看是谁引入了相关问题(所以是blame选项，找背锅的，哈哈哈)。git blame -L 11,22 file仅限查看file中11到22行的最近改动。

 

查看特定文件中某一函数的改动情况，可以使用如下的命令：

 

git log -L :git_deflate_bound:zlib.c

1

如果我们想查看 zlib.c 文件中函数 git_deflate_bound 的每一次修改，可以运行上述命令，这将尝试找出该函数的边界，然后查看历史记录，以一系列补丁的形式向我们展示函数的每一次修改，直至函数首次创建。或者就在-L后面给出行数范围也可以。可以使用git log --h