如果在使用`git reset`时发生了错误，或者后来决定撤销此操作，可以通过以下方法恢复：

1. **使用`reflog`找到之前的HEAD位置：**
   
   在Git中，`reflog`记录了本地仓库头部（HEAD）的变动，包括分支切换和重置操作。首先可以通过`git reflog`查看最近的提交历史和HEAD的变动。

   ```bash
   git reflog
   ```
   
   这将显示一系列的操作，例如：

   ```
   1a410ef HEAD@{0}: reset: moving to HEAD^
   ab1afef HEAD@{1}: commit: a new commit message
   ...
   ```

   在这个例子中，`HEAD@{1}`表示`git reset`操作之前的HEAD位置。

2. **重置到`git reset`操作之前的提交：**
   
   使用`reflog`找到想要恢复的点后，可以通过`git reset`命令将HEAD重置到那个点。如果我们想要恢复到上面例子中的`HEAD@{1}`，可以执行：

   ```bash
   git reset --hard HEAD@{1}
   ```

   这会将当前的HEAD、索引和工作目录重置到`HEAD@{1}`的状态。

请注意，`--hard`选项会使工作目录中的所有未提交的更改丢失。如果想保留这些更改，可以使用`--soft`或者`--mixed`选项，具体选择取决于你想要的更改保留级别：

- `--soft`：重置HEAD到指定提交，但保留暂存区和工作目录。
- `--mixed`（默认）：重置HEAD和暂存区到指定提交，工作目录的更改将保留但不会暂存。

**例子：**

假设我不小心将我的HEAD重置到了两次提交之前，失去了我最近的工作。我可以这样恢复：

1. 查看`reflog`以找到最近的提交记录：

   ```bash
   git reflog
   ```

2. 假设输出显示我想要恢复的提交是`abc1234`，我可以执行：

   ```bash
   git reset --hard abc1234
   ```

   如果我想要保留工作目录中的更改，只恢复索引和HEAD，我可以使用：

   ```bash
   git reset --soft abc1234
   ```

在进行任何可能丢失数据的操作前，最好是先做一个备份，特别是在使用`--hard`选项时。这样可以确保不会无意中丢失工作成果。

### 简短回答：

    git reset 'HEAD@{1}'
    

### 长答案：

Git 保留所有引用更新的日志（例如，签出、重置、提交、合并）。您可以通过输入以下内容来查看它：

    git reflog
    

此列表中的某个位置是您丢失的提交。假设您刚刚输入`git reset HEAD~`并想要撤消它。我的转发日志如下所示：

    $ git reflog
    3f6db14 HEAD@{0}: HEAD~: updating HEAD
    d27924e HEAD@{1}: checkout: moving from d27924e0fe16776f0d0f1ee2933a0334a4787b4c
    [...]
    

第一行表示`HEAD`0个位置之前（换句话说，当前位置）是3f6db14；它是通过重置为 获得的`HEAD~`。第二行表示`HEAD`1 个位置之前（换句话说，重置之前的状态）是 d27924e。它是通过检查特定提交获得的（尽管现在这并不重要）。因此，要撤消重置，请运行`git reset HEAD@{1}`（或`git reset d27924e`）。

另一方面，如果您从那时起运行了一些其他命令来更新 HEAD，那么您想要的提交将不会位于列表的顶部，并且您需要搜索`reflog`.

最后一点：查看要`reflog`取消重置的特定分支（例如 master）可能更容易，而不是`HEAD`：

    $ git reflog show master
    c24138b master@{0}: merge origin/master: Fast-forward
    90a2bf9 master@{1}: merge origin/master: Fast-forward
    [...]
    

这应该比一般的噪音要少`HEAD reflog`。

不过，我会提出另一种选择。

    git reset ORIG_HEAD
    

`ORIG_HEAD`引用之前引用的提交`HEAD`。

我的情况略有不同，我做了`git reset HEAD~`三次。

要撤消它我必须做

    git reset HEAD@{3}
    

所以你应该能够做到

    git reset HEAD@{N}
    

但是如果你已经使用 git Reset 完成了

    git reset HEAD~3
    

你需要做

    git reset HEAD@{1}
    

_{N}_代表 reflog 中的操作数量，正如 Mark 在评论中指出的那样。

1.  用于`git reflog`获取所有参考更新。
    
2.  `git reset <id_of_commit_to_which_you_want_restore>`

答案大多数时候有效

    git reset 'HEAD@{1}'
    

答案每次都有效

    git reset --hard 'HEAD@{1}'
    

where`--hard`使得一切都和以前一样。

Git 如何撤回或者重置某次提交记录？

如果提交发生在过去 90 天内，则按日期执行此操作看起来像这样：

```
git show HEAD@{2013-02-25}:./fileInCurrentDirectory.txt
```

请注意，这 `HEAD@{2013-02-25}`意味着此存储库中的“HEAD 位于 2013-02-25”（使用[reflog](http://git-scm.com/docs/git-reflog)），而不是“历史记录中此分支中 2013-02-25 之前的最后一次提交”。

这意味着，默认情况下，此方法仅适用于过去 90 天内的历史记录。否则，您需要执行以下操作：

```
git show $(git rev-list -1 --before="2013-02-26" HEAD):./fileInCurrentDirectory.txt
```

您可以使用 `git show`存储库根目录的路径（`./`或 `../`相对路径）：

```
$ git show REVISION:path/to/file
```

替换 `REVISION`为您的实际修订（Git 提交 SHA、标记名称、分支名称、相对提交名称或在 Git 中标识提交的任何其他方式）。

`<repository-root>/src/main.c`例如，要查看4 次提交前的文件版本，请使用：

```
$ git show HEAD~4:src/main.c
```

即使在相对于当前目录的路径中，Windows 版 Git 也需要_正斜杠。

如果你喜欢 GUI，你可以使用 gitk：

1.  启动 gitk：
    
        gitk /path/to/file
        
    
2.  在屏幕顶部选择修订版本，例如按说明或日期。默认情况下，屏幕的下部显示该修订版的差异（对应于“补丁”单选按钮）。
    
3.  要查看所选版本的文件：
    
    *   单击“树”单选按钮。这将显示该修订版文件树的根。
    *   深入查看您的文件。

您还可以使用[命令](https://git-scm.com/docs/git-show)`commit hash`指定 a （通常也称为`commit ID`）。[`git show`](https://git-scm.com/docs/git-show)

* * *

### 简而言之

`git show <commitHash>:/path/to/file`

* * *

### 一步步

1.  显示给定文件的所有更改日志[`git log /path/to/file`](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History)
2.  在显示的更改列表中，它显示了诸如`commit hash`（`commit 06c98...`06c98...是提交哈希）
3.  复制`commit hash`
4.  `git show <commitHash>:/path/to/file`使用`commit hash`步骤 3 和`path/to/file`步骤 1运行命令。

**注意：**`./`指定相对路径时添加似乎很重要，即`git show b2f8be577166577c59b55e11cfff1404baf63a84:./flight-simulation/src/main/components/nav-horiz.html`。

**_要快速查看文件与旧版本的差异：_**

> `git show -1 filename.txt`\> 与文件的最新版本进行比较
> 
> `git show -2 filename.txt`\> 与最后第二个修订版进行比较
> 
> `git show -3 fielname.txt` > 与最后第三次修订进行比较

Git 如何查看旧版本的文件？

Git 有一个配置设置，告诉它是否需要区分大小写或不敏感的文件系统：`core.ignorecase`。要告诉 Git 区分大小写，只需将此设置设置为 `false`。

```
git config core.ignorecase false
```

请注意，在不区分大小写的文件系统上将此选项设置为 false 通常不是一个好主意。这样做会导致奇怪的错误。例如，以仅更改字母大小写的方式重命名文件将导致 git 报告虚假冲突或创建重复文件

### 文档

从[`git config`文档](http://jk.gs/git-config.html)中：

> `core.ignorecase`
>
> 如果为 true，此选项将启用各种解决方法，使 git 能够在不区分大小写的文件系统（例如 FAT）上更好地工作。例如，如果目录列表 `makefile`在 git 期望时找到 `Makefile`，git 将假定它实际上是同一个文件，并继续将其记住为 `Makefile`.
>
> 默认值为 false，但[git-clone(1)](http://jk.gs/git-clone.html)或[git-init(1)](http://jk.gs/git-init.html)`core.ignorecase`将在创建存储库时进行探测并设置true（如果适用）。

只要您只是重命名一个文件_，而不是一个文件夹_，您就可以使用[git mv](http://git-scm.com/docs/git-mv)：

```
git mv -f yOuRfIlEnAmE yourfilename
```

修复整个存储库上的 git 文件名大小写：
-------------------------------------

（`.`仅替换部分存储库的（子）文件夹名称）

```
git rm -r --cached .
git add --all .

git status ##Review that **only** changes staged are renames

## Commit your changes after reviewing:
git commit -a -m "Fixing file name casing"
git push origin main
```

使用 SourceTree，我可以从 UI 完成这一切

1.  **重命名** `FILE.ext`为`whatever.ext`
2.  **暂存**该文件
3.  现在**重命名** `whatever.ext`为`file.ext`
4.  **再次暂存**该文件

这有点乏味，但是如果您只需要对几个文件执行此操作，那么速度很快

这是我在 OS X 上所做的：

    git mv File file.tmp
    git mv file.tmp file
    

两个步骤，否则我会收到“文件存在”错误。`--cached`也许可以通过添加等一步完成。

Git 如何区分提交文件名的大小写的更改？

通常添加到我不想隐藏的索引更改，然后使用 `--keep-index`选项进行隐藏。

```ba
git add app/controllers/cart_controller.php
git stash --keep-index
git reset
```

最后一步是可选的，但通常是您需要的。它从索引中删除更改。

---

**警告** 

`git stash --keep-index`将所有内容推送到存储中，包括暂存的和未暂存的。`--keep-index`存储完成后，只保留索引。当您稍后弹出存储时，这可能会导致合并冲突。

**编辑：**从 git 2.13 开始，有一个命令可以将特定路径保存到 stash: `git stash push <path>`。例如：

    git stash push -m welcome_cart app/views/cart/welcome.thtml
    

**旧答案：**

您可以使用`git stash --patch`(或`git stash -p`) 来完成此操作 - 您将进入交互模式，在该模式中您将看到每个已更改的块。`n`当您遇到要隐藏的文件时，用于`y`跳过您不想隐藏的文件，并`q`退出并保留剩余的文件。 `a`将把显示的帅哥和其余的帅哥藏在该文件中。

这不是最用户友好的方法，但如果您确实需要它，它可以完成工作。

对于隐藏一个文件：

    git stash -- filename.txt
    

要在命令中给出消息而不是在提示时输入消息，请在文件部分之前添加 -m，例如`git stash -m "stash-message" -- filename1.txt`

对于存储多个文件：

    git stash -m "stash-message" -- filename1.txt filename2.txt…

要添加到 svick 的答案中，该`-m`选项只是将一条消息添加到您的存储中，并且完全是可选的。因此，命令

    git stash push [paths you wish to stash]
    

是完全有效的。例如，如果我只想将更改存储在`src/`目录中，我可以运行

    git stash push src/

如果您使用 Visual Studio 代码，则有一种更简单的方法来存储选定的文件。

1.  确保您已经在 VSCode 中安装了[GitLens](https://gitlens.amod.io/)扩展
2.  转到源代码管理选项卡
3.  选择您想要隐藏的文件
4.  右键点击它，你会看到很多选项。单击**“隐藏更改”**

[![在此输入图像描述](https://i.stack.imgur.com/WyLoP.png)](https://i.stack.imgur.com/WyLoP.png)

4.  现在它会要求您添加一些隐藏消息。添加易于理解的消息并按 Enter 键。

[![在此输入图像描述](https://i.stack.imgur.com/miXZb.png)](https://i.stack.imgur.com/miXZb.png)

Git 如何隐藏特定的文件？

`Git rebase` 和 `Git merge` 都是Git中用于合并不同分支上的更改的命令，但它们以不同的方式处理合并操作。

**Git merge:**
- `merge` 命令通常用于将两个不同的分支合并到一起。
- 当你执行 `git merge` 时，Git会创建一个新的“合并提交”（merge commit），该提交具有两个父提交：一个是当前分支的最后一个提交（HEAD），另一个是被合并分支的最后一个提交。
- 合并提交的出现保留了项目历史的真实性，显示了一个分支合并到另一个分支的时间点。
- 合并是一个非破坏性操作，即它不会改变已有分支的历史。

**Git rebase:**
- `rebase` 命令用于将一个分支的更改重新应用于另一个分支上。
- 当你执行 `git rebase` 时，Git会将你正在工作的分支的提交“转移”到目标分支的顶端。
- 这种操作会改写历史，因为它实际上是重新创建了那些提交，就好像你是在目标分支的当前状态下重新做了那些工作。
- `rebase` 可以创造出一条更干净、线性的历史，这样当查看项目历史的时候，就像是按照时间顺序一步步地发生的。

**例子:**
假设你在 `feature` 分支上工作，并且需要将 `master` 分支的最新更改集成到你的 `feature` 分支中。你可以选择 `merge` 或 `rebase` 来实现这个目的。

如果你选择 `merge`，那么Git会创建一个新的合并提交，使得 `feature` 分支包含了 `master` 分支的所有更改。这个合并提交会有两个父提交，一个指向 `feature` 分支的最后一个提交，另一个指向 `master` 分支的最后一个提交。

如果你选择 `rebase`，Git会将你 `feature` 分支上的每个提交重新应用到 `master` 分支的最新提交之上。结果是你的 `feature` 分支看起来就像是在 `master` 分支的最新提交之后才开始的，这就创造了一条干净的、没有分叉的历史线。但是需要注意的是，如果 `feature` 分支上的更改与 `master` 分支上的更改有冲突，你需要在 `rebase` 过程中手动解决这些冲突。

简洁版本
----

*   合并将一个分支中的所有更改合并到一次提交中的另一个分支中。
*   Rebase 说我希望我分支的点移动到一个新的起点

那么什么时候使用其中任何一个呢？

### 合并

*   假设您为了开发单个功能而创建了一个分支。当您想将这些更改带回 master 时，您可能需要**merge**。

### 变基

*   第二种情况是，如果您开始进行一些开发，然后另一个开发人员进行了不相关的更改。您可能想要拉取然后**重新设置**基础以从存储库中的当前版本进行更改。

**挤压**：在两种情况下都会保留所有提交（例如：“添加功能”，然后“拼写错误”，然后“哎呀再次拼写错误”...）。可以通过压缩将提交合并为单个提交。挤压可以作为合并或变基操作的一部分来完成（--squash 标志），在这种情况下，它通常称为挤压合并或挤压变基。

**Pull 请求**：流行的 git 服务器（Bitbucket、GitLab、GitHub 等）允许配置如何在每个存储库的基础上合并 Pull 请求。按照惯例，UI 可能会显示“合并”按钮，但该按钮可以使用任何标志执行任何操作（关键字：合并、变基、挤压、快进）。

这很简单。通过变基，您可以使用另一个分支作为您工作的新**基础**。

例如，如果你有一个分支`master`，你创建一个分支来实现一个新功能，并说你给它命名`cool-feature`，当然，主分支是你新功能的基础。

现在，在某个时刻，您想要添加在`master`分支中实现的新功能。您可以切换到`master`并合并`cool-feature`分支：

    $ git checkout master
    $ git merge cool-feature
    

但这样就添加了一个新的虚拟提交。如果你想避免意大利面条历史，你可以**rebase**：

    $ git checkout cool-feature
    $ git rebase master
    

然后将其合并到`master`：

    $ git checkout master
    $ git merge cool-feature
    

这次，由于主题分支具有与 master 相同的提交以及具有新功能的提交，因此合并将只是快进。

长话短说
====

如果您有任何疑问，请使用合并。

简答
--

变基和合并之间的唯一区别是：

*   历史记录的结果树结构（通常仅在查看提交图时才明显）是不同的（一个有分支，另一个没有）。
*   合并通常会创建一个额外的提交（例如树中的节点）。
*   合并和变基将以不同的方式处理冲突。Rebase 会一次呈现一个提交的冲突，而合并会一次呈现所有冲突。

因此，简短的答案是_根据您希望的历史记录选择变基或合并_。

长答案
---

选择使用哪种操作时应考虑几个因素。

### 您正在获取更改的分支是否与团队外部的其他开发人员共享（例如开源、公共）？

如果是这样，请不要变基。Rebase 会破坏分支，那些开发人员将拥有损坏/不一致的存储库，除非他们使用`git pull --rebase`. 这是快速让其他开发人员感到不安的好方法。

### 您的开发团队技术如何？

Rebase 是一种破坏性操作。这意味着，如果您没有正确应用它，**您可能会丢失已提交的工作和/或破坏其他开发人员存储库的一致性。**

我曾工作过的团队中，开发人员都来自公司有能力聘请专门人员来处理分支和合并的时代。那些开发人员对 Git 不太了解，也不想了解太多。在这些团队中，我不会出于任何原因冒险推荐变基。

### 分支本身是否代表有用的信息

一些团队使用每个功能分支模型，其中每个分支代表一个功能（或错误修复，或子功能等）。在此模型中，分支有助于识别相关提交集。例如，可以通过恢复该分支的合并来快速恢复某个功能（公平地说，这是一种罕见的操作）。或者通过比较两个分支来区分特征（更常见）。变基会破坏分支，这并不简单。

我还曾在使用每个开发人员分支模型的团队中工作过（我们都经历过）。在这种情况下，分支本身不传达任何附加信息（提交已经有作者）。重新设定基准不会有什么坏处。

### 您可能出于某种原因想要恢复合并吗？

与恢复合并相比，恢复（如撤消）变基相当困难和/或不可能（如果变基有冲突）。如果您认为有可能想要恢复，请使用合并。

### 你在团队中工作吗？如果是这样，您愿意在这个分支上采取全有或全无的方法吗？

Rebase 操作需要使用相应的`git pull --rebase`. 如果您自己工作，您也许能够记住应该在适当的时间使用哪个。如果你在一个团队中工作，这将很难协调。`git pull --rebase`这就是为什么大多数变基工作流程建议对所有合并（以及所有拉取）使用变基。

常见的误区
-----

### 合并会破坏历史（压缩提交）

假设您有以下合并：

        B -- C
       /      \
      A--------D
    

有些人会说合并“破坏”了提交历史记录，因为如果您只查看主分支（A - D）的日志，您将错过 B 和 C 中包含的重要提交消息。

如果这是真的，我们就不会有[这样的问题](https://stackoverflow.com/questions/15875253/git-log-to-return-only-the-commits-made-to-the-master-branch)了。基本上，您会看到 B 和 C，除非您明确要求不要看到它们（使用 --first-parent）。这很容易自己尝试。

### Rebase 允许更安全/更简单的合并

这两种方法的合并方式不同，但尚不清楚一种方法总是优于另一种方法，这可能取决于开发人员的工作流程。例如，如果开发人员倾向于定期提交（例如，当他们从工作地点转移到家庭时，他们可能每天提交两次），那么对于给定分支可能会有大量提交。其中许多提交可能看起来与最终产品完全不同（我倾向于对每个功能重构我的方法一次或两次）。如果其他人正在处理相关的代码区域，并且他们试图重新调整我的更改，那么这可能是一个相当乏味的操作。

### Rebase 更酷/更性感/更专业

如果您喜欢使用别名`rm`来`rm -rf`“节省时间”，那么也许 rebase 适合您。

我的两分钱
=====

我总是认为有一天我会遇到一个场景，Git rebase 是解决问题的很棒的工具。就像我认为我会遇到这样一个场景：Git reflog 是一个很棒的工具，可以解决我的问题。我使用 Git 已有五年多了。这还没有发生。

混乱的历史对我来说从来都不是问题。我从来不会像读一本令人兴奋的小说那样阅读我的提交历史。大多数时候我需要历史记录，无论如何我都会使用 Git Blame 或 Git Bisect。在这种情况下，合并提交实际上对我来说很有用，因为如果合并引入了问题，那对我来说就是有意义的信息。

更新（4/2017）
==========

我觉得有必要提一下，尽管我的一般建议仍然有效，但我个人对使用 rebase 已经软化了。[我最近与Angular 2 Material](https://github.com/angular/material2)项目进行了很多互动。他们使用 rebase 来保持非常干净的提交历史记录。这使我能够非常轻松地查看哪些提交修复了给定的缺陷以及该提交是否包含在版本中。它是正确使用 rebase 的一个很好的例子。

我刚刚用我自己的话为我的团队创建了一个常见问题解答来回答这个问题。让我分享一下：

什么是`merge`?
-----------

一次提交，将不同分支的所有更改合并到当前分支中。

什么是`rebase`?
------------

将当前分支的所有提交重新提交到不同的基础提交上。

`merge`和 之间的主要区别是什么`rebase`？
----------------------------

1.  `merge`仅执行**一次**新提交。`rebase`通常执行**多个**（当前分支中的提交次数）。
2.  `merge`产生一个**新的**生成提交（所谓的合并提交）。`rebase`只移动**现有的**提交。

在什么情况下我们应该使用`merge`?
--------------------

`merge`每当您想要将分支分支的更改添加**回**基本分支时即可使用。

通常，您可以通过单击拉取/合并请求（例如 GitHub 上的）上的“合并”按钮来执行此操作。

在什么情况下我们应该使用`rebase`?
---------------------

`rebase`每当您想要将**基础分支的更改**添加回分支分支时即可使用。

通常，`feature`只要分支发生更改，您就可以在分支中执行此操作`main`。

为什么不使用`merge`将基础分支的更改合并到功能分支中？
------------------------------

1.  git 历史记录将包含许多**不必要的合并提交**。如果一个功能分支中需要多次合并，那么该功能分支甚至可能容纳比实际提交更多的合并提交！
    
2.  这会创建一个循环，**破坏 Git 设计的思维模型，从而**导致 Git 历史记录的任何可视化出现问题。
    
    想象有一条河（例如“尼罗河”）。水朝一个方向流动（Git 历史上的时间方向）。时不时地，想象那条河有一条分支，并假设大部分分支又汇回到河流中。这就是河流自然流动的样子。这说得通。
    
    但想象一下那条河有一个小支流。然后，由于某种原因，**河流汇入支流**，支流从那里继续。从技术上讲，这条河现在已经消失了，它现在处于支流中。但后来，不知何故，那根树枝神奇地又融入了河流。你问哪条河？我不知道。河流现在实际上应该在分支中，但不知何故它仍然继续存在，我可以将分支合并回河流中。所以说，河就是河。有点没有道理。
    
    这正是当您将`merge`基础分支合并到一个`feature`分支中，然后当`feature`分支完成时，您再次将其合并回基础分支时所发生的情况。心智模式被打破了。因此，您最终得到的分支可视化效果并不是很有帮助。
    

使用时的 Git 历史记录示例`merge`：
-----------------------

[![使用合并时的 Git 历史记录示例](https://i.stack.imgur.com/Oqqmm.png)](https://i.stack.imgur.com/Oqqmm.png)

请注意许多以`Merge branch 'main' into ...`. 如果您变基，它们甚至不存在（在那里，您将只有拉取请求合并提交）。还有许多视觉分支合并循环（`main`into `feature`into `main`）。

使用时的 Git 历史记录示例`rebase`：
------------------------

[![使用 rebase 时的 Git 历史记录示例](https://i.stack.imgur.com/0ZVla.png)](https://i.stack.imgur.com/0ZVla.png)

更干净的 Git 历史记录，更少的合并提交，并且没有任何混乱的可视分支合并循环。

有什么缺点/陷阱吗`rebase`？
------------------

是的：

1.  因为`rebase`移动提交（技术上重新执行它们），所以所有移动提交的提交日期将是变基时间，并且**git 历史记录可能看起来丢失了初始提交时间**。因此，如果由于某种原因所有工具都需要提交的确切日期，那么这`merge`是更好的选择。但通常情况下，干净的 git 历史记录比确切的提交日期有用得多。并且[作者日期](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/troubleshooting-commits-on-your-timeline#how-github-uses-the-git-author-date-and-commit-date)字段将在需要时继续保留原始提交日期。
    
2.  如果变基分支有多个提交更改了同一行，并且该行也在基础分支中进行了更改，则您可能需要多次解决同一行的合并冲突，而合并时则不需要这样做。因此，平均而言，需要解决更多的合并冲突。
    

请注意，有一个常见的误解，即即使**未**多次编辑`rebase`同一行，也会导致更多合并冲突。这是因为执行了多个提交，因此，例如，在单个提交中出现的 10 个冲突会分布在这些多个提交中。因此，您会更频繁地收到 Git 客户端的“存在合并冲突”消息，但冲突总数仍然相同（除非您在分支中多次更改同一行）。`merge`

使用时减少合并冲突的提示`rebase`：
---------------------

1.  **经常变基**。我通常建议每天至少进行一次。
2.  尝试将同一行上的**更改**尽可能压缩到一次提交中。

为了补充[TSamper](https://stackoverflow.com/questions/804115/git-rebase-vs-git-merge/804119#804119)提到的[我自己的答案](https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions)，[](https://stackoverflow.com/questions/804115/git-rebase-vs-git-merge/804119#804119)

*   在合并之前进行变基通常是一个好主意，因为这个想法是将要合并的分支`Y`的工作集成到您的分支`B`中。  
    但同样，在合并之前，您需要解决分支中的任何冲突_（_即：“rebase”，如“从分支的最近点开始重播我的分支中的工作`B`）。  
    如果操作正确，后续从分支合并到分支`B`可以快进。
    
*   合并直接影响目标分支`B`，这意味着合并最好是微不足道的，否则该分支`B`可能需要很长时间才能恢复到稳定状态（解决所有冲突的时间）
    

* * *

> 变基后合并的点是什么？

在我描述的情况下，我重新定位`B`到我的分支，只是为了有机会从最近的点重播我的工作`B`，但同时留在我的分支中。  
在这种情况下，仍然需要合并才能将我的“重播”工作带到`B`.

另一种情况（例如，[在 Git Ready 中描述](http://www.gitready.com/intermediate/2009/01/31/intro-to-rebase.html)`B`）是通过变基直接引入您的工作（这确实保留了所有好的提交，甚至让您有机会通过交互式变基重新排序它们）。  
在这种情况下（在 B 分支中进行变基），你是对的：不需要进一步合并：

**当我们没有合并或重新建立基础时，默认的 Git 树**

![变基1](https://i.stack.imgur.com/7vsGZ.png)

**我们通过变基得到：**

![变基3](https://i.stack.imgur.com/yCxOO.png)

第二个场景是关于：如何将新功能返回到 master 中。

我的观点是，通过描述第一个 rebase 场景，提醒大家，rebase 也可以用作实现此目的的初步步骤（即“将新功能恢复到 master 中”）。  
您可以使用 rebase 首先将 master “引入”新功能分支：rebase 将重播来自 的新功能提交`HEAD master`，但仍在新功能分支中，从而有效地将分支起点从旧的 master 提交移动到`HEAD-master`。  
这允许您解决分支中的任何冲突_（_意味着，单独地，同时如果您的冲突解决阶段花费太长时间，则允许 master 继续并行发展）。  
然后，您可以切换到 master 并合并`new-feature`（或者如果您想保留分支中完成的提交，则重新建立`new-feature`基础）。`master``new-feature`

所以：

*   “变基与合并”可以被视为导入作品的两种方式，例如，`master`.
*   但“变基然后合并”可以是一个有效的工作流程，首先单独解决冲突，然后恢复工作。

Git  rebase 和 Git merge 之间的区别是什么？

您可以使用 `git config`在 Git 中启用凭据存储。

```
git config --global credential.helper store
```

运行此命令时，第一次从远程存储库拉取或推送时，系统会询问您用户名和密码。

之后，为了与远程存储库进行后续通信，您不必提供用户名和密码。

存储格式是 `.git-credentials`文件，以明文形式存储。

此外，您还可以使用其他帮助程序 `git config credential.helper`，即内存缓存：

```
git config credential.helper 'cache --timeout=<timeout>'
```

它需要一个可选的 `timeout parameter`，确定凭证将在内存中保留多长时间。使用帮助程序，凭据将永远不会接触磁盘，并将在指定的超时后被删除。该 `default`值为900 秒（15 分钟）。

---

**警告**：如果您使用此方法，您的 Git 帐户密码将以_明文_格式保存在 中 `global .gitconfig file`，例如在 Linux 中将是 `/home/[username]/.gitconfig`.

如果您不希望这样做，请改用 `ssh key`您的帐户。

**注意：此方法将以****明文形式**将凭据保存在您的 PC 磁盘上。您计算机上的每个人都可以访问它，例如恶意 NPM 模块。

跑步

    git config --global credential.helper store
    

然后

    git pull
    

提供用户名和密码，稍后将记住这些详细信息。凭证存储在磁盘上的文件中，磁盘权限为“仅用户可读/可写”，但仍为明文形式。

如果您想稍后更改密码

    git pull
    

会失败，因为密码不正确，git然后从`~/.git-credentials`文件中删除有问题的用户+密码，所以现在重新运行

    git pull
    

提供一个新密码，以便它像以前一样工作。

### 推荐且安全的方法：SSH

按照以下步骤生成密钥：[更多详细信息](https://docs.github.com/en/github-ae@latest/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)

    $ssh-keygen -t rsa -b 4096 -C "yourEmail@something.com"
    

设置保护密钥的密码并将其存储在本地

将 id\_rsa.pub 文件的内容复制到剪贴板以进行下一步

    $ clip < ~/.ssh/id_rsa.pub
    

转到[github.com](https://www.github.com) →_设置_→ _SSH 和 GPG 密钥_→_新 SSH 密钥_。粘贴密钥并保存

如果私钥在_~/.ssh/目录中保存为__id\_rsa_，我们将其添加用于身份验证，如下所示：

    ssh-add -K ~/.ssh/id_rsa
    

### 更安全的方法：缓存

我们可以使用[_git-credential-cache_](https://git-scm.com/docs/git-credential-cache)将我们的用户名和密码缓存一段时间。只需在 CLI（终端或命令提示符）中输入以下内容：

    git config --global credential.helper cache
    

您还可以设置超时时间（以秒为单位），如下所示：

    git config --global credential.helper 'cache --timeout=3600'

### 打开凭据助手，以便 Git 会将您的密码在内存中保存一段时间：

在终端中，输入以下内容：

    # Set Git to use the credential memory cache
    git config --global credential.helper cache
    

默认情况下，Git 会将您的密码缓存 15 分钟。

要更改默认密码缓存超时，请输入以下内容：

    # Set the cache to timeout after 1 hour (setting is in seconds)
    git config --global credential.helper 'cache --timeout=3600'
    

来自[GitHub 帮助](https://help.github.com/articles/caching-your-github-password-in-git/)。

您可以编辑该`~/.gitconfig`文件来**存储**您的**凭据**：

    nano ~/.gitconfig
    

哪个应该已经有

    [user]
            email = your@email.com
            user = gitUSER
    

您应该在此文件的底部添加以下内容。

    [credential]
            helper = store
    

我推荐此选项的原因是因为它是全局的，如果您在任何时候需要删除该选项，您知道该去哪里更改它。

_**仅在您的个人计算机上使用此选项。**_

然后当你拉| 克隆| 输入你的Git密码，一般情况下，密码会以`~/.git-credentials`以下格式保存

    https://gituser:gitpassword@domain.xxx
    

_**其中 DOMAIN.XXX 可以是 github.com、bitbucket.org 或其他**_

请参阅[文档](https://git-scm.com/docs/git-credential-store)。

### _重新启动您的终端。_

Git 如何保存用户名和密码？

文件`.gitignore`用于告诉 Git 应忽略哪些文件和文件夹。通常，这些文件是构建工件、临时文件或不属于存储库的其他类型的文件。Git 将忽略符合文件中模式的任何目录或文件`.gitignore`。

例子：

    # Ignore .DS_Store files
    .DS_Store
    
    # Ignore build artifacts
    build/
    
    # Ignore log files
    *.log
    

* * *

相反， `.gitkeep`Git 中使用文件来维护否则为空的目录。默认情况下，Git 不会跟踪空文件夹，因此`.gitkeep`如果您希望将文件保留在存储库中，则必须将文件添加到该目录。文件名比文件的实际内容更重要。

`.gitkeep`文件示例

    # This file is used to keep the directory empty in Git
    

* * *

总之。该`.gitignore`命令用于告诉 Git 要忽略哪些文件和文件夹。要维护一个否则为空的 Git 目录，请使用`.gitkeep`. 它们彼此不同并且具有不同的功能。

`.gitkeep`没有记录，因为它不是 Git 的功能。

Git[无法添加完全空的目录](https://git.wiki.kernel.org/index.php/Git_FAQ#Can_I_add_empty_directories.3F)。想要在 Git 中跟踪空目录的人已经创建了将调用的文件放入`.gitkeep`这些目录中的约定。该文件可以被命名为任何名称；Git 没有赋予这个名称特殊的意义。

有一个相互竞争的约定，`.gitignore`即向空目录添加文件以跟踪它们，但有些人认为这令人困惑，因为目标是保留空目录，而不是忽略它们；`.gitignore`还用于列出在查找未跟踪的文件时应被 Git 忽略的文件。

`.gitkeep`只是一个占位符。一个虚拟文件，因此 Git 不会忘记该目录，因为 Git 只跟踪文件。

---

如果您想要一个空目录并确保它对于 Git 保持“干净”，请创建一个 `.gitignore`包含以下行的目录：

```
# .gitignore sample
# Ignore all files in this dir...
*

# ... except for this one.
!.gitignore
```

如果您希望只有一种类型的文件对 Git 可见，下面是如何过滤除所有文件之外的 `.gitignore`所有内容的示例 `.txt`：

```
# .gitignore to keep just .txt files
# Filter everything...
*

# ... except the .gitignore...
!.gitignore

# ... and all text files.
!*.txt
```

.gitignore
    

是一个文本文件，包含目录中 git 将忽略或不在存储库中添加/更新的文件列表。

    .gitkeep
    

由于 Git 删除或不向存储库添加空目录，因此 .gitkeep 是一种在存储库中保留空目录的 hack（我不认为它被正式命名为 Git 的一部分）。

只需执行 a`touch /path/to/emptydirectory/.gitkeep`添加文件，Git 现在就可以在存储库中维护此目录。

许多人更喜欢使用，只是`.keep`因为该约定与 git 无关。

Gitignore 和 gitkeep 之间有什么区别

要更改某次提交记录的提交作者，可以使用`git commit --amend`命令来修改最近的提交，或者如果需要更改更早的提交，则可以使用`git rebase`命令。下面我会详细解释这两种情况的操作步骤。

### 使用`git commit --amend`

如果你要更改的是最近的提交，可以使用`git commit --amend`选项来重新指定提交作者。以下是操作步骤：

1. 打开命令行或终端。
2. 切换到需要更改提交作者的仓库目录。
3. 执行以下命令来更改最近一次提交的作者信息：

   ```sh
   git commit --amend --author="新作者名 <新作者邮箱>"
   ```
   
   例如，如果我要将作者更改为“John Doe”和他的邮箱“johndoe@example.com”，命令将是：

   ```sh
   git commit --amend --author="John Doe <johndoe@example.com>"
   ```

4. 这会打开一个文本编辑器，允许你修改提交信息。保存并关闭编辑器后，提交的作者信息将被更新。

请注意，这种方式会修改最后一次提交并创建一个新的提交哈希，所以如果您已经将提交推送到远程仓库，之后必须使用`git push --force`来覆盖远程仓库上的提交记录。

### 使用`git rebase`

如果需要更改较早的提交记录的作者，可以使用`git rebase`命令。这里是一个简化的例子：

1. 打开命令行或终端。
2. 切换到你的仓库目录。
3. 找出需要修改作者的提交的哈希值。可以使用`git log`查看提交历史。
4. 运行`git rebase`命令开始交互式变基操作：

   ```sh
   git rebase -i <哈希值的前一次提交>
   ```
   
   例如，如果哈希值是`abcd1234`，则命令将是：
   
   ```sh
   git rebase -i abcd1234^
   ```

5. 在打开的文本编辑器中，将要更改的提交前面的`pick`改为`edit`。
6. 保存并关闭编辑器。
7. 当rebasing到指定的提交时，执行以下命令来更改作者信息：

   ```sh
   git commit --amend --author="新作者名 <新作者邮箱>"
   ```

   使用相同的例子，“John Doe”的命令将是：

   ```sh
   git commit --amend --author="John Doe <johndoe@example.com>"
   ```

8. 完成作者信息的修改后，继续rebase进程：

   ```sh
   git rebase --continue
   ```

9. 如果有冲突，解决它们并使用`git add`将更改的文件标记为已解决。
10. 重新运行`git rebase --continue`直到rebase完成。

由于这将改变历史中每个后续提交的哈希值，如果这些提交已经被推送到远程仓库，你可能需要使用`git push --force`来更新远程仓库。

在执行这些操作时，请务必意识到，修改公共历史是一个危险的行为，因为它可以对其他协作者造成混淆和额外的工作。因此，这些操作应该只在确实必要，且仓库的其他协作者都同意的情况下进行。

从历史记录中比您需要修改的提交更早的点进行交互式变基 ( `git rebase -i <earliercommit>`)。在要重新设置基准的提交列表中，将文本从`pick`更改`edit`为要修改的哈希值旁边的文本。然后当 git 提示您更改提交时，请使用以下命令：

    git commit --amend --author="Author Name <email@address.com>" --no-edit
    

* * *

例如，如果您的提交历史记录是as `A-B-C-D-E-F`，并且您想更改和的作者，那么您会...`F``HEAD``C``D`

1.  指定`git rebase -i B`（这是执行[命令](https://help.github.com/articles/about-git-rebase/#an-example-of-using-git-rebase)[后您将看到的示例`git rebase -i B`](https://help.github.com/articles/about-git-rebase/#an-example-of-using-git-rebase)）
    *   如果您需要编辑`A`，请使用`git rebase -i --root`
2.  `C`将和`D`from`pick`的行更改为`edit`
3.  退出编辑器（对于 vim，这将是按 Esc，然后键入`:wq`）。
4.  一旦变基开始，它首先会暂停在`C`
5.  你会`git commit --amend --author="Author Name <email@address.com>"`
6.  然后`git rebase --continue`
7.  它会再次暂停在`D`
8.  然后你`git commit --amend --author="Author Name <email@address.com>"`又会
9.  `git rebase --continue`
10.  变基将完成。
11.  用于使用`git push -f`更新的提交来更新您的源。

这个问题的[公认答案](https://stackoverflow.com/a/3042512/3357935)是交互式变基的巧妙使用，但不幸的是，如果我们试图更改作者的提交曾经位于随后合并的分支上，那么它会出现冲突。更一般地说，它不起作用当处理混乱的历史记录时。

由于我担心运行依赖于设置和取消设置环境变量来重写 git 历史记录的脚本，因此我正在根据[这篇文章编写一个新答案，该答案与](https://help.github.com/articles/changing-author-info/)[此答案](https://stackoverflow.com/a/3404304/391161)类似，但更完整。

与链接的答案不同，以下内容经过测试并有效。为了清楚地说明起见，假设`03f482d6`我们正在尝试替换其作者的提交，并且`42627abe`是新作者的提交。

1.  检查我们正在尝试修改的提交：
    
         git checkout 03f482d6
        
    
2.  让作者改变：
    
         git commit --amend --author "New Author Name <New Author Email>"
        
    
    现在我们有了一个新的提交，哈希值假设为`42627abe`。
    
3.  查看原来的分支。
    
4.  在本地用新提交替换旧提交：
    
         git replace 03f482d6 42627abe
        
    
5.  根据替换重写所有未来的提交：
    
         git filter-branch -- --all
        
    
6.  取下替换件以保持清洁：
    
         git replace -d 03f482d6
        
    
7.  推新历史：
    
         git push --force-with-lease
        
    
    （仅在后者失败时使用`--force`，`--force-with-lease`并且仅在使用`git log`and/or进行健全性检查后使用`git diff`。）
    

您可以直接 rebase 到新的提交，而不是执行步骤 4-5：

    git rebase -i 42627abe

如果您只想更改**上次提交**的作者，您可以这样做：

*   重置当前存储库的作者：
    
    `git config --local user.name "Alex Smith"`
    
    `git config --local user.email alex@email.com`
    
*   现在重置提交的作者，无需编辑：
    
    `git commit --amend --reset-author --no-edit`
    
*   强制推送您的更改而不覆盖其他任何人的提交：
    
    `git push --force-with-lease`
    

请注意，这也会更改作者时间戳。

要对**最后 N 次提交**执行此操作：

`git rebase --onto HEAD~N --exec "git commit --amend --reset-author --no-edit" HEAD~N`

Github 文档包含[一个脚本，用于替换分支中所有提交的提交者信息](https://help.github.com/articles/changing-author-info/)（现在无法检索，这是[最后一个快照](https://web.archive.org/web/20200823163529/https://docs.github.com/en/github/using-git/changing-author-info#changing-the-git-history-of-your-repository-using-a-script)）。

更改变量值后从终端运行以下脚本

    #!/bin/sh
     
    git filter-branch --env-filter '
     
    OLD_EMAIL="your-old-email@example.com"
    CORRECT_NAME="Your Correct Name"
    CORRECT_EMAIL="your-correct-email@example.com"
    
    if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
    then
        export GIT_COMMITTER_NAME="$CORRECT_NAME"
        export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
    fi
    if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
    then
        export GIT_AUTHOR_NAME="$CORRECT_NAME"
        export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
    fi
    ' --tag-name-filter cat -- --branches --tags
    

将更正后的历史记录推送到 GitHub：

    git push --force --tags origin 'refs/heads/*'
    

或者，如果您想推送分支的选定引用，则使用

    git push --force --tags origin 'refs/heads/develop'

您可以使用以下命令更改上次提交的作者。

`git commit --amend --author="Author Name <email@address.com>"`

然而，如果你想更改多个提交的作者姓名，那就有点棘手了。您需要启动交互式变基，然后将提交标记为编辑，然后一一修改并完成。

1.  开始变基`git rebase -i`。
    
2.  `pick`将关键字更改`edit`为要更改作者姓名的提交。
    
3.  然后关闭编辑器。对于初学者，请点击`Escape`然后输入`:wq`并点击`Enter`。
    

然后你会看到你的终端就像什么都没发生一样。实际上，您正处于交互式变基过程中。现在是时候使用上面的命令修改提交的作者姓名了。它将再次打开编辑器。退出并继续使用 进行变基`git rebase --continue`。对要编辑的提交计数重复相同的操作。当您收到消息时，您可以确保交互式变基已完成`No rebase in progress?`。

在Git中，如果你想要更改单个提交的提交作者，你可以使用`git commit --amend --author="Author Name <email@example.com>"` 命令。但这只会影响最新的提交。如果你需要更改历史中特定的一个旧的提交，你可以使用`git rebase -i` 命令，然后选择要修改的提交，并使用`rebase`期间的`edit`功能。

下面是详细的步骤来更改一个旧的提交的作者：

1. 使用`git log`找到你想要更改的提交的哈希值。

2. 启动交互式变基操作，选择要修改的提交之前的一个提交作为基础。例如，如果你想要修改的提交哈希是`abc123`，则执行：

   ```sh
   git rebase -i abc123^
   ```

   注意：`^`表示选择这个哈希之前的提交，因为我们需要对这个特定的提交作出修改。

3. 在弹出的编辑器中，你会看到一系列提交列表。找到你想要修改的提交，将它前面的`pick`改为`edit`。

4. 保存并退出编辑器。Git现在将会暂停变基操作，并允许你修改那个特定的提交。

5. 现在你可以使用以下命令来更改提交的作者：

   ```sh
   git commit --amend --author="New Author Name <newauthor@example.com>" --no-edit
   ```

   `--no-edit`参数表示保持提交信息不变。如果你也想要编辑提交信息，可以省略这个参数。

6. 一旦完成，继续变基进程：

   ```sh
   git rebase --continue
   ```

   如果有冲突，解决冲突后需要用`git add`将文件标记为已解决，然后再次运行`git rebase --continue`。

7. 完成变基后，如果你更改的是已经推送到远程仓库的提交，你需要强制推送你的更改：

   ```sh
   git push origin branch_name --force
   ```

   或者，如果你是在共享分支上工作，可能更喜欢使用：

   ```sh
   git push origin branch_name --force-with-lease
   ```

   这种方法更安全一些，因为它会在远程分支有你本地不知道的新提交时防止推送。

请注意，更改历史提交，并且强制推送到远程仓库会重写共享的分支历史，这可能会对其他协作者造成影响。在进行这类操作前，最好和你的团队沟通，并确认这是一个可接受的操作。

Git 如何更改某一次提交的提交作者？

当您想要修改特定的提交时，Git 提供了一些工具来帮助您实现这个目的。以下是几种常见的方法：

### 1. `git commit --amend`
如果您刚刚做了一个提交，并且想要修改它（例如，修复一个打字错误、忘记添加一个文件、或者想要更改提交信息），您可以使用 `git commit --amend` 命令。这将打开一个编辑器，让您可以修改当前提交的信息，或者添加忘记的更改。

**例子**:
```bash
git commit --amend -m "新的提交信息"
```

### 2. `git rebase -i`
对于较早的提交，如果需要修改，您可以使用交互式变基(`git rebase -i`)。这会打开一个TODO列表，让您可以选择需要修改的提交。

**例子**:
```bash
git rebase -i HEAD~3  # 查看最近三个提交并选择编辑
```

在打开的编辑器中，将您想要修改的提交前面的 `pick` 改为 `edit`，然后保存退出。Git 将会停在您选择的那个提交，允许您做出修改。

```bash
# 修改文件并将它们添加到暂存区
git add .

# 使用 --amend 选项来修改提交
git commit --amend

# 继续变基过程
git rebase --continue
```

### 3. `git filter-branch`
如果需要修改很早以前的提交，或者做一些复杂的历史修改，可以使用 `git filter-branch` 命令。这是一个强大但复杂的工具，可以对历史中的多个提交进行修改。

**例子**:
```bash
git filter-branch --env-filter '
OLD_EMAIL="your-old-email@example.com"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="your-correct-email@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags
```

### 警告
修改已经提交到公共仓库的历史是一个危险的操作，因为它会改变历史中的提交ID（SHA-1哈希）。如果其他人已经基于这些提交做了工作，他们将不得不处理合并冲突或重新基于新的历史。因此，在修改公共仓库的历史之前，请确保这是必要的，并且您已经通知了所有相关的合作伙伴。

在每一种情况下，都要确保您对 Git 有足够的了解，以避免数据丢失。在执行任何修改历史的操作之前，最好是先备份您的仓库。

使用[`git rebase`](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)。例如，要修改 commit `bbc643cd`，请运行：

    git rebase --interactive bbc643cd~
    

`~`请注意命令末尾的波形符，因为您需要在上一次提交的基础上重新应用提交`bbc643cd`（即`bbc643cd~`）。

在默认编辑器中，在提到 的行中修改`pick`为。`edit``bbc643cd`

保存文件并退出。git 会解释并自动执行文件中的命令。您会发现自己处于刚刚创建 commit 的先前情况`bbc643cd`。

此时，`bbc643cd`这是您的最后一次提交，您可以[轻松修改它](https://www.atlassian.com/git/tutorials/rewriting-history#git-commit--amend)。进行更改，然后使用以下命令提交它们：

    git commit --all --amend --no-edit
    

之后，使用以下命令返回到之前的 HEAD 提交：

    git rebase --continue
    

**警告：请注意，这将更改该提交****以及所有子**提交的 SHA-1——换句话说，这将重写从该点开始的历史记录。如果使用命令进行推送，则[可以中断存储库执行此操作](https://stackoverflow.com/a/3926832/1269037)`git push --force`。

使用很棒的交互式变基：
-----------

    git rebase -i    # Show your commits in a text editor
    

找到所需的提交，更改`pick`为`e`( `edit`)，然后保存并关闭文件。Git 将回退到该提交，允许您：

*   用于`git commit --amend`进行更改，或
*   用于`git reset @~`放弃最后一次提交，但不放弃对文件的更改（即带您到编辑文件但尚未提交时所在的位置）。

后者对于执行更复杂的操作（例如拆分为多个提交）很有用。

然后，运行`git rebase --continue`，Git 将在修改后的提交之上重播后续更改。可能会要求您修复一些合并冲突。

_注意：`@`是 的简写`HEAD`，`~`是指定提交之前的提交。_

_在 Git 文档中阅读有关[重写历史的更多信息。](https://git-scm.herokuapp.com/book/en/v2/Git-Tools-Rewriting-History)_

  

不要害怕重新建立基础
----------

专业提示™：不要害怕尝试重写历史记录的“危险”命令\* — 默认情况下，Git 在 90 天内不会删除您的提交；你可以在转发日志中找到它们：

    $ git reset @~3   # go back 3 commits
    $ git reflog
    c4f708b HEAD@{0}: reset: moving to @~3
    2c52489 HEAD@{1}: commit: more changes
    4a5246d HEAD@{2}: commit: make important changes
    e8571e4 HEAD@{3}: commit: make some changes
    ... earlier commits ...
    $ git reset 2c52489
    ... and you're back where you started
    

\*_注意诸如`--hard`和`--force`等选项 - 它们可能会丢弃数据。_  
\* _另外，不要重写您正在协作的任何分支上的历史记录。_

  

* * *

在许多系统上，`git rebase -i`会默认打开 Vim。Vim 的工作方式与大多数现代文本编辑器不同，因此请了解[如何使用 Vim 进行变基](https://stackoverflow.com/a/28421811/405550)。如果您想使用其他编辑器，请将其更改为`git config --global core.editor your-favorite-text-editor`.

当我需要更深入地修复历史记录中的先前提交时，我经常使用交互式[变基](http://git-scm.com/docs/git-rebase)。`--autosquash`它本质上加速了 ZelluX 的答案所说明的过程，并且当您需要编辑多个提交时特别方便。

从文档中：

> `--autosquash`
> 
> 当提交日志消息以“squash！…​”（或“fixup！…​”）开头，并且存在标题以相同…​开头的提交时，自动修改rebase -i的todo列表，以便该提交标记为压缩发生在要修改的提交之后

假设您有这样的历史记录：

    $ git log --graph --oneline
    * b42d293 Commit3
    * e8adec4 Commit2
    * faaf19f Commit1
    

并且您有想要修改为 Commit2 的更改，然后使用以下命令提交更改

    $ git commit -m "fixup! Commit2"
    

或者，您可以使用 commit-sha 代替提交消息，甚至`"fixup! e8adec4`只是提交消息的前缀。

然后在之前的提交上启动交互式变基

    $ git rebase e8adec4^ -i --autosquash
    

您的编辑器将打开并显示已正确排序的提交

    pick e8adec4 Commit2
    fixup 54e1a99 fixup! Commit2
    pick b42d293 Commit3
    

您所需要做的就是保存并退出

基于[文档](https://help.github.com/articles/changing-a-commit-message/)

**修改较旧的消息或多个提交消息**

    git rebase -i HEAD~3 
    

上面显示了当前分支上最近 3 次提交的列表，如果需要更多，请将 3 更改为其他内容。该列表将类似于以下内容：

    pick e499d89 Delete CNAME
    pick 0c39034 Better README
    pick f7fde4a Change the commit message but push the same commit.
    

在要更改的每个提交消息之前将**pick**替换为**reword 。**假设您更改列表中的第二个提交，您的文件将如下所示：

    pick e499d89 Delete CNAME
    reword 0c39034 Better README
    pick f7fde4a Change the commit message but push the same commit.
    

保存并关闭提交列表文件，这将弹出一个新的编辑器供您更改提交消息，更改提交消息并保存。

最后，强制推送修改后的提交。

    git push --force

### 修改特定提交的步骤

1. **定位提交**: 首先，我们需要找到要修改的提交。可以通过 `git log`命令查看提交历史，确定要修改的提交的哈希值。
2. **交互式变基**: 使用 `git rebase -i`命令进行交互式变基。该命令将打开一个文本编辑器，列出待选的提交列表。这需要指定基底提交的哈希值或使用 `HEAD`的相对引用，例如 `HEAD~3`表示当前分支最后三个提交。
3. **挑选提交**: 在交互式变基的列表中，找到要修改的提交，并将该行前的命令从 `pick`改为 `edit`。然后保存并退出编辑器，Git将暂停在那个提交上，允许你进行更改。
4. **修改提交**: 在此步骤中，可以进行所需的文件更改。完成后，使用 `git add`命令将这些更改加入暂存区。
5. **应用修改**: 使用 `git commit --amend`命令来修改那个提交。可以在此时修改提交信息，或者保留原始提交信息。
6. **继续变基操作**: 更改完成并提交后，使用 `git rebase --continue`来继续之前的变基操作。Git将应用剩余的提交。
7. **处理冲突**: 如果在变基过程中遇到冲突，需要手动解决冲突，然后使用 `git add`命令标记为已解决。之后再次使用 `git rebase --continue`。
8. **完成变基**: 一旦所有的冲突都解决了，且所有的提交都被顺利地应用，变基操作就完成了。

### 注意事项

- **不要在公共分支上修改历史**：修改已经推送到远程且被他人使用的分支的提交历史是非常危险的做法，因为它会改变历史，需要其他人进行强制拉取（`git pull --force`）。
- **备份分支**：在进行变基之前，建议创建一个备份分支，以便发生错误时可以恢复到原始状态。

### 实战示例

假如我在工作中修复了一个bug，并提交了这个更改。但之后我发现提交消息写错了，或者我忘记了把一些重要的改动加入到提交中，我就需要对这个提交进行修改。以下是我具体操作的一个例子：

```shell
# 查看提交历史，找到要修改的提交的哈希值
git log

# 假设要修改的提交是3个提交前的那个
git rebase -i HEAD~3

# 这会打开一个文本编辑器，我会将要修改的提交行前的指令从'pick'改为'edit'
# 保存退出编辑器之后，Git会停在那个提交上

# 做必要的文件修改
# ...

# 把更改添加到暂存区
git add .

# 修改提交信息或者保留原来的提交信息
git commit --amend

# 继续变基过程
git rebase --continue

# 解决可能出现的任何冲突，并继续
# ...

# 变基完成
```

通过这样的步骤，我可以修改特定的提交，并确保项目的历史保持清晰和有序。

Git 如何修改特定的提交

当在 Git 中遇到合并冲突时，如果您决定不继续完成合并过程，并希望中止合并，您可以使用以下命令来重置合并状态：

```bash
git merge --abort
```

或者，在某些旧版本的 Git 中，您可能需要使用:

```bash
git reset --merge
```

使用 `git merge --abort` 命令将会恢复到合并操作之前的状态，并尝试重建合并操作开始前的文件和索引的状态。

如果合并之前您的工作目录是干净的（没有未提交的改动），那么 `git merge --abort` 就会让您的工作目录回到合并操作之前完全一样的状态。如果合并操作之前有未提交的改动，那些改动依然会保留在工作目录中，但可能需要手动解决任何因合并操作引入的冲突。

例如，假设我在 `feature` 分支上开发了一项新功能，现在我想将这些改动合并到 `master` 分支。当我运行 `git merge feature` 时，我遇到了冲突。我意识到现在不是解决这些冲突的好时机，或者我决定采取不同的策略来整合这些变更，因此我决定中止合并。我就会运行 `git merge --abort`，这样我就可以回到合并之前的状态，重新考虑我的合并策略。

由于您`pull`不成功，那么`HEAD`(not `HEAD^`) 是您分支上的最后一个“有效”提交：

    git reset --hard HEAD
    

您想要的另一部分是让他们的更改覆盖您的更改。

旧版本的 git 允许您使用“他们的”合并策略：

    git pull --strategy=theirs remote_branch
    

[但正如Junio Hamano](http://marc.info/?l=git&m=121637513604413&w=2)（Git 维护者）在本消息中所解释的那样，此内容已被删除。[正如链接](http://marc.info/?l=git&m=121637513604413&w=2)中所述，您可以这样做：

    git fetch origin
    git reset --hard origin

如果您的 git 版本 >= 1.6.1，则可以使用`git reset --merge`.

另外，正如 @Michael Johnson 提到的，如果你的 git 版本 >= 1.7.4，你也可以使用`git merge --abort`.

与往常一样，请确保在开始合并之前没有未提交的更改。

来自[git merge 手册页](https://www.kernel.org/pub/software/scm/git/docs/git-merge.html)

`git merge --abort`相当于`git reset --merge`何时`MERGE_HEAD`存在。

`MERGE_HEAD`当合并正在进行时出现。

另外，关于开始合并时未提交的更改：

如果您不想在开始合并之前提交更改，只需`git stash`在合并之前以及`git stash pop`完成合并或中止合并之后提交即可。

git merge --abort
    

> 中止当前的冲突解决过程，并尝试重建合并前的状态。
> 
> 如果合并开始时存在未提交的工作树更改，`git merge --abort`则在某些情况下将无法重建这些更改。因此，建议在运行 git merge 之前始终提交或存储更改。
> 
> `git merge --abort`相当于`git reset --merge`何时 `MERGE_HEAD`存在。

[http://www.git-scm.com/docs/git-merge](http://www.git-scm.com/docs/git-merge)

我想这是`git reset`你需要的。

请注意，这`git revert`意味着非常不同的东西，例如，`svn revert`在 Subversion 中，恢复将丢弃您的（未提交的）更改，将文件从存储库返回到当前版本，而`git revert`“撤消”提交。

`git reset`应该做相当于 的事情`svn revert`，即放弃不需要的更改。

对于 git >= 1.6.1：

    git merge --abort
    

对于旧版本的 git，这可以完成工作：

    git reset --merge
    

或者

    git reset --hard

Git 合并冲突过程中如何中止合并进度？

`git add -A` 和 `git add .` 在许多情况下的表现是相似的，但它们在某些特定的git版本和情境下会有不同的行为。下面是它们的主要区别：

- `git add -A`：这个命令是 `git add --all` 的缩写，它会添加所有在工作目录中的变更到暂存区（staging area），包括文件的添加、修改和删除。这个操作会影响整个仓库。

- `git add .`：这个命令只会添加当前目录及其子目录中的新文件和修改过的文件到暂存区，并不会添加删除的文件。这个操作只影响当前目录和子目录。

在较新的Git版本中（比如从2.0版本开始），`git add .` 和 `git add -A` 在执行时几乎是等效的，因为 `git add .` 也会包括删除的文件。但是，`git add .` 的作用范围仅限于当前目录，而 `git add -A` 可以在仓库中任何位置执行，它会影响整个仓库。

简而言之，如果你想确保包括所有类型的变更（添加、修改、删除）并且希望这种添加操作适用于整个仓库，使用 `git add -A` 是比较安全的选择。如果你只关心当前目录及其子目录的变更，可以使用 `git add .`。在使用时，确保理解你正在使用的Git版本的行为，因为这可能影响命令的准确行为。

_此答案仅适用于**Git 版本 1.x**。对于 Git 版本 2.x，请参阅其他答案。_

* * *

**概括：**

*   `git add -A`阶段**所有变化**
    
*   `git add .`暂存新文件和修改，**但不删除**（在当前目录及其子目录上）。
    
*   `git add -u`阶段修改和删除，**无需新文件**
    

* * *

**细节：**

`git add -A`相当于 `git add .; git add -u`.

重要的一点`git add .`是，它会查看工作树，并将所有这些路径添加到暂存的更改（如果它们已更改或是新的且未被忽略），它不会暂存任何“rm”操作。

`git add -u`查看所有_已_跟踪的文件，如果这些文件不同或已被删除，则暂存对这些文件的更改。它不会添加任何新文件，它只会暂存对已跟踪文件的更改。

`git add -A`是执行这两项操作的便捷捷径。

您可以使用类似以下内容测试差异（请注意，对于 Git 版本 2.x，您的输出`git add .` `git status` **将**有所不同）：

    git init
    echo Change me > change-me
    echo Delete me > delete-me
    git add change-me delete-me
    git commit -m initial
    
    echo OK >> change-me
    rm delete-me
    echo Add me > add-me
    
    git status
    # Changed but not updated:
    #   modified:   change-me
    #   deleted:    delete-me
    # Untracked files:
    #   add-me
    
    git add .
    git status
    
    # Changes to be committed:
    #   new file:   add-me
    #   modified:   change-me
    # Changed but not updated:
    #   deleted:    delete-me
    
    git reset
    
    git add -u
    git status
    
    # Changes to be committed:
    #   modified:   change-me
    #   deleted:    delete-me
    # Untracked files:
    #   add-me
    
    git reset
    
    git add -A
    git status
    
    # Changes to be committed:
    #   new file:   add-me
    #   modified:   change-me
    #   deleted:    delete-me

### Git 版本 1.x

命令

新文件

修改文件

已删除的文件

描述

`git add -A`

✔️

✔️

✔️

暂存所有（新的、修改的、删除的）文件

`git add .`

✔️

✔️

❌

仅在当前文件夹中暂存新文件和修改后的文件

`git add -u`

❌

✔️

✔️

仅阶段修改和删除的文件

### Git 版本 2.x

命令

新文件

修改文件

已删除的文件

描述

`git add -A`

✔️

✔️

✔️

暂存所有（新的、修改的、删除的）文件

`git add .`

✔️

✔️

✔️

暂存当前文件夹中的所有（新的、修改的、删除的）文件

`git add --ignore-removal .`

✔️

✔️

❌

仅暂存新文件和修改后的文件

`git add -u`

❌

✔️

✔️

仅阶段修改和删除的文件

### 长格式标志：

*   `git add -A`相当于`git add --all`
*   `git add -u`相当于`git add --update`

### 进一步阅读：

*   [Git 初学者：权威的实用指南](https://stackoverflow.com/q/315911/12860895)
*   [学习 Git 的资源](https://try.github.io)
*   [学习 Git 分支](https://learngitbranching.js.org)
*   [用 D3 解释 Git](https://onlywei.github.io/explain-git-with-d3)

对于[**Git 2.0，`git add -A`默认值是：`git add .`equals`git add -A .`**](https://github.com/git/git/blob/f99a38c0121456822f8a9dfb7928eefceaa98201/Documentation/RelNotes/2.0.0.txt#L32-L36)。

> `git add <path>`与现在的“ ”相同`git add -A <path>`，这样“ `git add dir/`”就会注意到您从目录中删除的路径并记录删除情况。  
> 在旧版本的 Git 中，“ `git add <path>`”忽略了删除。
> 
> 如果您确实愿意，可以说“ `git add --ignore-removal <path>`”仅在 中添加添加或修改的路径。`<path>`

`git add -A`就像`git add :/`（[添加顶部 git repo 文件夹中的所有内容](https://stackoverflow.com/a/31951899/6309)）。  
请注意，git 2.7（2015 年 11 月）将允许您添加名为“ `:`”的文件夹！  
请参阅[Junio C Hamano (](https://github.com/gitster) [)的](https://github.com/gitster)[提交 29abb33](https://github.com/git/git/commit/29abb33978f713cd0a5cc3687bf61077b0928840)（2015 年 10 月 25 日）。 [`gitster`](https://github.com/gitster)

* * *

请注意，[从 git 2.0（2014 年第一季度或第二季度）开始](https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.3.txt#L19-L30)，在谈论**`git add .`**（工作树中的当前路径）时，您也必须`.`在其他命令中使用“” 。`git add`

这意味着：

> “ `git add -A .`”相当于“ `git add .; git add -u .`”

（注意和的额外“ `.`” ）`git add -A``git add -u`

因为`git add -A`or会在**整个工作树上**`git add -u`操作（仅从 git 2.0 开始），而不仅仅是在当前路径上。

> 这些命令将对**Git 2.0 中的整个树进行操作，以与“ `git commit -a`”和其他命令**保持一致。因为没有机制可以使“ `git add -u`”表现得像“ `git add -u .`”，所以对于那些习惯“ `git add -u`”（没有路径规范）仅更新当前子目录中路径的索引的人来说，开始训练他们的手指明确地说“是很重要的” `git add -u .`“在 Git 2.0 到来之前他们就是这么想的。
> 
> **当这些命令在没有路径规范的情况下运行以及在当前目录之外进行本地更改时，会发出警告，**因为在这种情况下，Git 2.0 中的行为将与今天的版本不同。

根据[查尔斯的指示](https://stackoverflow.com/questions/572549/difference-between-git-add-a-and-git-add/572660#572660)，经过测试，我提出的理解如下：

    # For the next commit
    $ git add .   # Add only files created/modified to the index and not those deleted
    $ git add -u  # Add only files deleted/modified to the index and not those created
    $ git add -A  # Do both operations at once, add to all files to the index
    

这篇博文也可能有助于了解在什么情况下可以应用这些命令：_[从 Git 工作目录中删除已删除的文件](http://www.geekgumbo.com/2010/05/16/removing-deleted-files-from-your-git-working-directory/)_。

_在 2.0 中不再如此。`add .`等于`add -A`同一路径，唯一的区别是树的其他路径中是否有新文件_

`git add -A` 和 `git add .` 在许多情况下的表现是相似的，但它们在某些特定的git版本和情境下会有不同的行为。下面是它们的主要区别：

* `git add -A`：这个命令是 `git add --all` 的缩写，它会添加所有在工作目录中的变更到暂存区（staging area），包括文件的添加、修改和删除。这个操作会影响整个仓库。
* `git add .`：这个命令只会添加当前目录及其子目录中的新文件和修改过的文件到暂存区，并不会添加删除的文件。这个操作只影响当前目录和子目录。

在较新的Git版本中（比如从2.0版本开始），`git add .` 和 `git add -A` 在执行时几乎是等效的，因为 `git add .` 也会包括删除的文件。但是，`git add .` 的作用范围仅限于当前目录，而 `git add -A` 可以在仓库中任何位置执行，它会影响整个仓库。

简而言之，如果你想确保包括所有类型的变更（添加、修改、删除）并且希望这种添加操作适用于整个仓库，使用 `git add -A` 是比较安全的选择。如果你只关心当前目录及其子目录的变更，可以使用 `git add .`。在使用时，确保理解你正在使用的Git版本的行为，因为这可能影响命令的准确行为。

Git add a 和 git add 有什么区别？

当您想要将本地的 Git 标签（tag）推送到远程仓库时，您可以使用 `git push` 命令来完成这个操作。这里有两种主要的情况：一种是推送单个标签，另一种是推送多个标签。下面我会详细解释这两种情况的操作方法。

### 推送单个标签到远程仓库

假设您已经创建了一个本地标签 `v1.0`，如果要将这个标签推送到远程仓库，您可以使用以下命令：

```shell
git push origin v1.0
```

这里，`origin` 是远程仓库的默认名称，`v1.0` 是您要推送的标签名称。执行这个命令后，标签 `v1.0` 就会被推送到远程仓库中。

### 推送所有本地新建的标签到远程仓库

如果您想要一次性推送所有本地新建的标签到远程仓库，可以使用：

```shell
git push origin --tags
```

这条命令会推送所有本地新建的标签到 `origin` 远程仓库。需要注意的是，这个命令不会推送已经删除的标签。

### 示例

假设您正在进行一个项目的版本发布，您创建了一个名为 `v2.0` 的标签来标记这个发布版本：

```shell
git tag v2.0
```

创建标签后，您确认这个标签可以被推送到远程仓库与团队共享：

```shell
git push origin v2.0
```

这样，您的团队成员就可以通过拉取远程标签来获取这个特定的项目快照了。

如果您的团队采取了版本号策略，并且您有一系列的标签（比如 `v1.1`, `v1.2`, `v2.0` 等）需要一起推送，那么您可能会选择推送所有标签：

```shell
git push origin --tags
```

以上就是如何将 Git 标签推送到远程存储库的方法


推送**单个**标签：

    git push origin <tag_name>
    

以下命令应推送**所有**标签（**不推荐**）：

    # not recommended
    git push --tags

**`git push --follow-tags`**

这是 Git 1.8.3 中引入的一个明智的选项：

    git push --follow-tags
    

它推送两个提交，并且仅推送同时满足以下条件的标签：

*   带注释的
*   从推送的提交中可以到达（祖先）

这是明智的，因为：

*   您应该只将带注释的标签推送到远程，并保留轻量级标签用于本地开发，以避免标签冲突。另请参阅：[带注释的标签和未注释的标签有什么区别？](https://stackoverflow.com/questions/11514075)
*   它不会将带注释的标签推送到不相关的分支上

正是出于这些原因，`--tags`应该避免。

Git 2.4[添加了](https://github.com/git/git/commit/61ca378275e83c48343c74a849ff0dcdef9abc91)`push.followTags`默认打开该标志的选项，您可以使用以下命令进行设置：

    git config --global push.followTags true
    

或者添加`followTags = true`到文件`[push]`的部分`~/.gitconfig`。

### 视觉工作室代码

`"git.followTagsWhenSync": true`要在 Visual Studio Code 中激活此功能，请根据用户或工作区设置变量。[GitHub](https://github.com/microsoft/vscode/issues/103281)

要推送特定内容，一个标签执行以下操作 `git push origin tag_name`

为了扩展[Trevor 的答案](https://stackoverflow.com/a/5195913/456814)，您可以一次推送单个标签或所有标签。

推送单个标签
------

    git push <remote> <tag>
    

[这是解释这一点的相关文档](https://www.kernel.org/pub/software/scm/git/docs/git-push.html)的摘要（为简洁起见，省略了一些命令选项）：

>     git push [[<repository> [<refspec>…]]
>     
>     <refspec>...
>     
> 
> 参数的格式`<refspec>`是...源 ref `<src>`，后跟冒号`:`，然后是目标 ref `<dst>`...
> 
> 告诉`<dst>`远程端的哪个引用通过此推送进行更新...如果`:<dst>`省略，`<src>`则将更新相同的引用...
> 
> 标签的`<tag>`含义与 相同`refs/tags/<tag>:refs/tags/<tag>`。

一次推送所有标签
--------

    git push --tags <remote>
    # Or
    git push <remote> --tags
    

[以下是相关文档](https://www.kernel.org/pub/software/scm/git/docs/git-push.html)的摘要（为简洁起见，省略了一些命令选项）：

>     git push [--all | --mirror | --tags] [<repository> [<refspec>…]]
>     
>     --tags
>     
> 
> `refs/tags`除了命令行上明确列出的参考规范之外，所有参考文献都会被推送。

在当前分支中添加标签。如果您想为您的 master 创建标签，请首先签出 master。

    git tag tag_name
    

检查是否创建

    git tag
    

推入您的远程源

    git push origin tag_name

Git 如何将 tag 推送到远程存储库？

如何列出提交中的所有文件？,要列出一个 Git 提交中的所有文件，你可以使用 `git show` 命令结合 `--name-only` 或者 `--name-status` 选项。这里是如何操作的：

1. 使用 `--name-only` 选项：

```sh
git show --name-only <commit-hash>
```

`<commit-hash>` 是你想要查看的提交的哈希值。这个命令会列出那个提交中更改（包括添加和删除）的所有文件名。

2. 使用 `--name-status` 选项：

```sh
git show --name-status <commit-hash>
```

这个命令不仅会列出文件名，还会显示每个文件的状态，比如 `M` 代表修改（Modified），`A` 代表添加（Added），`D` 代表删除（Deleted）。

如果你只是想要获得文件列表，而不想看到提交的其他信息（比如 diff 或者提交信息），你可以使用 `--pretty=format:` 来避免打印提交的其他信息：

```sh
git show --pretty=format: --name-only <commit-hash>
```

或者：

```sh
git show --pretty=format: --name-status <commit-hash>
```

如果你不知道提交的哈希值，但是知道是最近的提交，你可以使用 `HEAD` 指向最新的提交，或者使用 `HEAD~1` 来表示最新提交的前一个提交，以此类推。例如，列出最近提交中的所有文件：

```sh
git show --pretty=format: --name-only HEAD
```

此外，如果你想要查看某个特定分支或标签中最后一次提交修改了哪些文件，你可以将分支名或标签名替换 `HEAD`。例如，查看名为 `feature-branch` 的分支的最后一次提交：

```sh
git show --pretty=format: --name-only feature-branch
```

使用这些方法，你可以很容易地查看 Git 提交中包含的所有文件。

**首选方式**（因为它是一个_管道_命令；旨在编程）：

    $ git diff-tree --no-commit-id --name-only bd61ad98 -r
    index.html
    javascript/application.js
    javascript/ie6.js
    

**另一种方式**（对于脚本来说不太受欢迎，因为它是一个_瓷器_命令；意味着面向用户）

    $ git show --pretty="" --name-only bd61ad98    
    index.html
    javascript/application.js
    javascript/ie6.js
    

* * *

*   抑制`--no-commit-id`提交 ID 输出。
*   该`--pretty`参数指定一个空格式字符串以避免开头出现混乱。
*   该`--name-only`参数仅显示受影响的文件名（感谢 Hank）。`--name-status`如果您想查看每个文件发生了什么（**删除**、**修改**、**添加**） ，请改为使用
*   参数`-r`是递归到子树

如果你想获取已更改文件的列表：

    git diff-tree --no-commit-id --name-only -r <commit-ish>
    

如果你想获取一次提交中所有文件的列表，你可以使用

    git ls-tree --name-only -r <commit-ish>

我只是假设这[`gitk`](https://git-scm.com/docs/gitk)不是我们所希望的。在这种情况下，请尝试`git show --name-only <sha>`。

**我个人将--stat**和**\--oneline**与**show**命令结合使用：

    git show --stat --oneline HEAD
    git show --stat --oneline b24f5fb
    git show --stat --oneline HEAD^^..HEAD
    

如果您不喜欢/想要添加/删除统计信息，可以将**\--stat**替换为**\--name-only**

    git show --name-only --oneline HEAD
    git show --name-only --oneline b24f5fb
    git show --name-only --oneline HEAD^^..HEAD

你也可以做

    git log --name-only
    

您可以浏览各种提交、提交消息和更改的文件。

输入 q 即可恢复提示。

Git 如何列出提交中的所有文件？

当您在Git中工作时，有时会发现自己在错误的分支上进行了一些更改，或者决定您的修改应该在新的分支上进行，以保持主分支的清洁或为了其他原因。幸运的是，Git提供了灵活性，允许您将尚未提交的更改移至新的分支。以下是步骤：

1. **检查当前更改**：
   在移动更改之前，您应该查看当前工作目录和暂存区的状态。可以使用以下命令：
   ```
   git status
   ```
   这将显示当前更改的状态，无论是已经暂存(staged)还是尚未暂存(unstaged)。

2. **创建并切换到新分支**：
   如果您已经暂存了更改，首先应该将这些更改取消暂存（如果您希望这些更改也被移动到新分支）。然后，创建并切换到新分支，可以使用以下命令：
   ```
   git checkout -b new-branch-name
   ```
   这个命令会创建一个名为 `new-branch-name` 的新分支，并切换到那个分支。

3. **添加和提交更改**：
   现在您已经在新分支上，可以添加并提交您的更改。使用以下命令来添加所有更改到暂存区：
   ```
   git add .
   ```
   或者，如果您想要添加特定文件，可以使用：
   ```
   git add <file-path>
   ```
   接下来，将更改提交到您的新分支：
   ```
   git commit -m "Commit message explaining the changes"
   ```

4. **（可选）保持主分支清洁**：
   如果您刚才从主分支（比如说 `main` 或 `master`）上创建了新分支，并且不想让这些更改出现在主分支上，您可以切回主分支并撤消这些更改。首先，切换回主分支：
   ``` 
   git checkout main
   ```
   然后，使用以下命令来撤销未提交的更改：
   ```
   git reset --hard
   ```
   这将重置主分支，将其恢复到最后一次提交的状态，丢弃所有未提交的更改。请注意，这是一个危险的操作，因为它会丢弃所有未提交的更改。在使用 `git reset --hard` 之前，请确保您不需要这些未提交的更改。

这就是将未提交的工作移动到新分支的基本过程。 让我们看一个具体的例子：

假设您正在主分支 `main` 上工作，并且进行了一些更改，现在您想要将这些更改移到一个新的分支 `feature-x`。

1. 检查更改:
   ```sh
   git status
   ```
2. 创建并切换到新分支 `feature-x`:
   ```sh
   git checkout -b feature-x
   ```
3. 添加所有更改并提交它们到新分支:
   ```sh
   git add .
   git commit -m "Start working on feature X"
   ```
4. 如果需要，切换回 `main` 分支并撤销更改:
   ```sh
   git checkout main
   git reset --hard
   ```

现在，新分支 `feature-x` 包含了之前未提交的工作，而 `main` 分支保持不变。

### 2020 更新/Git 2.23

Git 2.23 添加了新的[`switch`](https://git-scm.com/docs/git-switch)子命令，试图消除由于超载使用[`checkout`](https://git-scm.com/docs/git-checkout)（切换分支、恢复文件、分离 HEAD 等）而产生的一些混乱。

从此版本的 Git 开始，将 checkout 命令替换为：

    git switch -c <new-branch>
    

行为是相同的并且保持不变。

* * *

### 2020 年更新之前/Git 2.23

使用以下内容：

    git checkout -b <new-branch>
    

这将使您当前的分支保持原样，创建并签出一个新分支并保留所有更改。然后，您可以暂存要提交的文件中的更改：

    git add <files>
    

并承诺您的_新分支_：

    git commit -m "<Brief description of this commit>"
    

工作目录中的更改和索引中暂存的更改_尚不属于任何分支_。这会更改这些修改结束的分支。

您无需_重置_原始分支，它会保持原样。最后一次提交`<old-branch>`仍然是相同的。因此你`checkout -b`然后承诺。

将当前更改保存到临时存储中：

1. `$ git stash`
2. 基于此存储创建一个新分支，并切换到新分支：

   `$ git stash branch <new-branch> stash@{0}`

提示：使用 Tab 键来减少输入存储名称。

**如果您在编码时一直**在主分支上进行提交，但现在想要将这些提交移动到不同的分支，这是一种快速方法：

1.  将当前历史记录复制到新分支，同时也带来所有未提交的更改：
    
         git checkout -b <new-feature-branch>
        
    
2.  现在强制原来的“混乱”分支回滚：（不切换到它）
    
         git branch -f <previous-branch> <earlier-commit-id>
        
    
    例如：
    
         git branch -f master origin/master
        
    
    或者如果您已进行 4 次提交：
    
         git branch -f master HEAD~4
        
    

_**警告：**_ `git branch -f master origin/master`将_重置该分支的跟踪信息_。因此，如果您将`master`分支配置为推送到其他地方，`origin/master`那么该配置将会丢失。

_**警告：**_如果在分支后进行变基，则存在某些提交可能会丢失的危险，如此处[所述](https://stackoverflow.com/a/36463546/99777)。避免这种情况的唯一方法是使用cherry-pick 创建新的历史记录。该链接描述了最安全、万无一失的方法，尽管不太方便。（如果您有未提交的更改，则可能需要`git stash`在开始和`git stash pop`结束时进行更改。）

常见的情况如下：我忘记为新功能创建新分支，并在旧功能分支中完成所有工作。我已将所有“旧”工作提交给 master 分支，并且我希望我的新分支从“master”中成长。我还没有对我的新工作做出任何承诺。这是分支结构：“master”->“Old\_feature”

    git stash 
    git checkout master
    git checkout -b "New_branch"
    git stash apply

如果您提交它，您还可以选择单个提交 ID。当我开始在 master 中工作，然后想在推送到我的 origin/ 之前创建一个本地分支时，我经常这样做。

    git cherry-pick <commitID>
    

[正如此处](https://git-scm.com/docs/git-cherry-pick)所述，您可以使用cherry-pick做很多事情，但这可能是您的一个用例。

Git 如何将现有的未提交工作转移到新分支？

首先，创建一个新的本地分支并检查它：

    git checkout -b <branch-name>
    

当您将其推送到远程服务器时，会自动创建远程分支：

    git push <remote-name> <branch-name> 
    

`<remote-name>`通常是`origin`，这是 git 为您克隆的远程服务器提供的名称。然后，您的同事可以简单地拉动该分支。

但请注意，形式上，格式为：

    git push <remote-name> <local-branch-name>:<remote-branch-name>
    

但是当您省略一个时，它会假设两个分支名称相同。话虽如此，但请**注意**，不要犯仅指定`:<remote-branch-name>`（使用冒号）的严重错误，否则远程分支将被删除！

* * *

为了让后续的人`git pull`知道该怎么做，您可能想使用：

    git push --set-upstream <remote-name> <local-branch-name> 
    

如下所述，该`--set-upstream`选项设置上游分支：

> 对于每个最新或成功推送的分支，添加上游（跟踪）引用，由无参数 git-pull(1) 和其他命令使用。

首先，您必须在本地创建分支

    git checkout -b your_branch
    

之后，您可以在本地分支中工作，当您准备好共享分支时，推送它。下一个命令将分支推送到远程存储库原点并跟踪它

    git push -u origin your_branch
    

队友可以通过以下方式到达您的分支机构：

    git fetch
    git checkout origin/your_branch
    

您可以继续在分支中工作并在需要时推送，而无需向 git Push 传递参数（无参数 git Push 会将 master 推送到远程 master，将本地 your\_branch 推送到远程 your\_branch，等等...）

    git push
    

队友可以通过提交来推送到您的分支，然后显式推送

    # ... work ...
    git commit
    # ... work ...
    git commit
    git push origin HEAD:refs/heads/your_branch
    

或者跟踪分支以避免 git push 的参数

    git checkout --track -b your_branch origin/your_branch
    # ... work ...
    git commit
    # ... work ...
    git commit
    git push

简单的 Git 2.0+ 解决方案：
------------------

从 Git 2.0开始**，行为变得更加简单**：

您可以配置 git**`push.default = current`**让生活更轻松：

我添加了这个，所以现在我可以将一个新分支推向上游

    $ git push -u
    

`-u`将跟踪同名的远程分支。现在通过此配置，您将自动猜测对 git Push 的远程引用。来自[git.config 文档](http://git-scm.com/docs/git-config)：

> **默认推送**
> 
> 定义在没有明确给出 refspec 的情况下 git push 应采取的操作。
> 
> **`push.default = current`**\- 推送当前分支以更新接收端同名分支。适用于中央和非中央工作流程。

对我来说，这很好地简化了我的日常 Git 工作流程。配置设置负责“通常”的用例，即您在本地添加分支并希望远程创建它。`git co remote_branch_name`另外，我可以通过执行操作（而不是使用`--set-upstream-to`标志）轻松地从远程创建本地分支。

我知道这个问题和接受的答案相当旧，但行为已经改变，因此现在存在配置选项以使您的工作流程更简单。

要添加到全局 Git 配置，请在命令行上运行：

    $ git config --global push.default current

正如前面的答案中所说，

    git push <remote-name> <local-branch-name>:<remote-branch-name>
    

足以推动当地分支机构。

您的同事可以使用以下命令拉取所有远程分支（包括新分支）：

    git remote update
    

然后，要在分支上进行更改，通常的流程是：

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

基于当前分支在本地创建一个新分支：

    git checkout -b newbranch
    

像平常一样进行任何更改。然后，将其推向上游：

    git push -u origin HEAD
    

这是将当前分支推送到同名分支并跟踪它的快捷方式，以便您将来`origin`不需要指定。`origin HEAD`

Git 如何创建远程分支？

git branch
    

应该显示您的存储库的所有本地分支。带星号的分支是您当前的分支。

* * *

要仅检索您所在分支的名称：

    git rev-parse --abbrev-ref HEAD
    

2.22 版本添加了[_“打印当前分支的名称”_](https://www.git-scm.com/docs/git-branch#Documentation/git-branch.txt---show-current)`--show-current`选项。该组合也适用于第一次提交之前新初始化的存储库：[](https://www.git-scm.com/docs/git-branch#Documentation/git-branch.txt---show-current)

    git branch --show-current

要仅显示您所在的当前分支的名称：

```
git rev-parse --abbrev-ref HEAD
```

参考：[仅显示 Git 中的当前分支](https://stackoverflow.com/a/1418022/367456)

您还可以`git symbolic-ref HEAD`显示完整的参考规范。

仅显示 Git v1.8 及更高版本中的分支名称（感谢 Greg 指出这一点）：

    git symbolic-ref --short HEAD
    

在 Git v1.7+ 上您还可以执行以下操作：

    git rev-parse --abbrev-ref HEAD
    

如果您在一个分支上，则两者应该给出相同的分支名称。如果你有超然的头脑，答案就会有所不同。

> _**笔记：**_
> 
> 在早期的客户端上，这似乎有效：
> 
>     git symbolic-ref HEAD | sed -e "s/^refs\/heads\///"
>     
> 
> – _达里恩 2014 年 3 月 26 日_

为了我自己的参考（但可能对其他人有用），我概述了该线程中提到的大多数（基本命令行）技术，每个技术都应用于多个用例： HEAD 是（指向）：

*   本地分支（主）
*   远程跟踪分支，与本地分支同步（origin/master 与 master 相同提交）
*   远程跟踪分支，与本地分支不同步（origin/feature-foo）
*   标签（v1.2.3）
*   子模块（在子模块目录内运行）
*   一般独立头（以上都不是）

结果：

*   `git branch | sed -n '/\* /s///p'`
    *   当地分行：`master`
    *   远程跟踪分支（同步）：`(detached from origin/master)`
    *   远程跟踪分支（不同步）：`(detached from origin/feature-foo)`
    *   标签：`(detached from v1.2.3)`
    *   子模块：`(HEAD detached at 285f294)`
    *   一般独立头：`(detached from 285f294)`
*   `git status | head -1`
    *   当地分行：`# On branch master`
    *   远程跟踪分支（同步）：`# HEAD detached at origin/master`
    *   远程跟踪分支（不同步）：`# HEAD detached at origin/feature-foo`
    *   标签：`# HEAD detached at v1.2.3`
    *   子模块：`# HEAD detached at 285f294`
    *   一般独立头：`# HEAD detached at 285f294`
*   `git describe --all`
    *   当地分行：`heads/master`
    *   远程跟踪分支（同步）：（`heads/master`注意：_不是_ `remotes/origin/master`）
    *   远程跟踪分支（不同步）：`remotes/origin/feature-foo`
    *   标签：`v1.2.3`
    *   子模块：`remotes/origin/HEAD`
    *   一般独立头：`v1.0.6-5-g2393761`
*   `cat .git/HEAD`:
    *   当地分行：`ref: refs/heads/master`
    *   子模块：`cat: .git/HEAD: Not a directory`
    *   所有其他用例：相应提交的 SHA
*   `git rev-parse --abbrev-ref HEAD`
    *   当地分行：`master`
    *   所有其他用例：`HEAD`
*   `git symbolic-ref --short HEAD`
    *   当地分行：`master`
    *   所有其他用例：`fatal: ref HEAD is not a symbolic ref`

（仅供参考，这是使用 git 版本 1.8.3.1 完成的）

从 git 2.22 版本开始，你可以使用：

    git branch --show-current
    

根据手册页：

> 打印当前分支的名称。在分离头状态下，不打印任何内容。

在 Git 中，有几种方法可以获取当前分支的名称，这里将介绍两种常用的方法：

### 1. 使用 `git branch` 命令

运行 `git branch` 命令时，它会列出仓库中的所有分支。当前分支会以一个星号 (*) 标记显示在列表中。例如：

```bash
$ git branch
  main
* develop
  feature-xyz
```

在这个例子中，当前分支是 `develop`。

### 2. 使用 `git rev-parse` 命令

如果需要在脚本中使用或者想要直接获取当前分支的名称，可以使用 `git rev-parse` 命令。这种方式会直接输出当前分支的名称，而不会显示其他分支信息。命令如下：

```bash
$ git rev-parse --abbrev-ref HEAD
```

这条命令会输出当前分支的名称。例如，如果当前分支是 `develop`，则输出会是：

```
develop
```

这个方法很适合自动化脚本中，因为它直接返回当前分支的名称，而不包含其他额外信息。

### 示例使用场景

假设我在一个软件开发项目中工作，项目采用 Git 进行版本控制。我需要确保我正在 `feature-new-ui` 分支上开发新的用户界面功能。为了验证我当前的工作环境，我可以使用以下命令：

```bash
$ git rev-parse --abbrev-ref HEAD
```

如果返回的分支名称是 `feature-new-ui`，那么我可以安心地继续我的开发任务；如果不是，我需要切换到正确的分支上。

这样的命令使用可以有效避免在错误的分支上进行开发，减少将来可能出现的合并冲突或错误。

Git 如何获取当前分支名称？

首先，当您克隆一个Git仓库时，默认情况下，`git clone` 命令将克隆远程仓库中的所有分支，但是在本地只会创建一个跟踪远程仓库`origin/master`分支的分支，即`master`分支。这意味着您的本地仓库中已经包含了远程仓库中所有分支的信息，但是为了切换到这些远程分支，您需要在本地创建相对应的跟踪分支。

如果您需要在本地显式地创建并切换到所有远程分支的跟踪分支，可以按照以下步骤操作：

1. 首先克隆远程仓库：
   ```shell
   git clone [remote-url]
   ```
   这样操作会创建所有远程分支的引用，在`.git/refs/remotes/origin/`目录下。

2. 接下来，您可以使用`git branch -a` 查看所有分支，包括远程分支。

3. 然后，对于每个远程分支，您可以使用以下命令创建本地分支并建立跟踪关系：
   ```shell
   git checkout -b [branch-name] origin/[branch-name]
   ```
   这个命令会创建一个新的本地分支`[branch-name]`，并设置它跟踪对应的远程分支。

例如，如果远程仓库有一个名为`feature`的分支，我想要在本地创建并切换到这个分支，我将会执行：
```shell
git checkout -b feature origin/feature
```

如果您希望自动化这个过程，可以使用下面的脚本在克隆后创建并切换到所有远程分支的本地跟踪分支：
```shell
# 克隆仓库
git clone [remote-url]

# 进入仓库目录
cd [repository-name]

# 遍历所有远程分支并创建本地跟踪分支
for branch in `git branch -r | grep -v '\->'`; do
    if [ "origin/HEAD" != "$branch" ]; then
        git checkout -b `echo $branch | sed 's/origin\///'` $branch
    fi
done

# 切换回主分支
git checkout master
```

这段脚本会克隆远程仓库，并为除了HEAD以外的所有远程分支创建本地分支，然后切换回主分支。注意，您需要替换`[remote-url]`和`[repository-name]`为实际的远程仓库URL和仓库名称。

首先，克隆一个远程[Git](http://en.wikipedia.org/wiki/Git_%28software%29)存储库并[`cd`](http://en.wikipedia.org/wiki/Cd_%28command%29)进入其中：

    $ git clone git://example.com/myproject
    $ cd myproject
    

接下来，查看存储库中的本地分支：

    $ git branch
    * master
    

但是您的存储库中还隐藏着其他分支！使用`-a`标志查看这些：

    $ git branch -a
    * master
      remotes/origin/HEAD
      remotes/origin/master
      remotes/origin/v1.0-stable
      remotes/origin/experimental
    

要快速浏览上游分支，请直接查看：

    $ git checkout origin/experimental
    

要处理该分支，请创建一个本地跟踪分支，这是通过以下方式自动完成的：

    $ git checkout experimental
    
    Branch experimental set up to track remote branch experimental from origin.
    Switched to a new branch 'experimental'
    

这里，“新分支”仅意味着从索引中获取分支并在本地为您创建。正如_上_一行告诉您的，正在设置分支来跟踪远程分支，这通常意味着 origin/branch\_name 分支。

您的本地分支机构现在应该显示：

    $ git branch
    * experimental
      master
    

您可以使用以下命令跟踪多个远程存储库`git remote`：

    $ git remote add win32 git://example.com/users/joe/myproject-win32-port
    $ git branch -a
    * master
      remotes/origin/HEAD
      remotes/origin/master
      remotes/origin/v1.0-stable
      remotes/origin/experimental
      remotes/win32/master
      remotes/win32/new-widgets
    

此时，事情变得非常疯狂，所以运行`gitk`看看发生了什么：

    $ gitk --all &

如果想一次获取许多远程分支，请执行以下操作：

```
git pull --all
```

现在，您可以根据需要签出任何分支，而无需访问远程存储库。

这个[Bash](http://en.wikipedia.org/wiki/Bash_%28Unix_shell%29)脚本帮助了我：

    #!/bin/bash
    for branch in $(git branch --all | grep '^\s*remotes' | egrep --invert-match '(:?HEAD|master)$'); do
        git branch --track "${branch##*/}" "$branch"
    done
    

它将为所有远程分支创建跟踪分支，但 master 除外（您可能从原始克隆命令中获得）。我想你可能还需要做一个

    git fetch --all
    git pull --all
    

为了确定。

> **一行**：`git branch -a | grep -v HEAD | perl -ne 'chomp($_); s|^\*?\s*||; if (m|(.+)/(.+)| && not $d{$2}) {print qq(git branch --track $2 $1/$2\n)} else {$d{$_}=1}' | csh -xfs`  
> 像往常一样：在复制我们所知的 rm -rf Universe 之前测试您的设置
> 
> _一行的积分归用户 cfi_

使用该`--mirror`选项似乎可以正确复制`remote`跟踪分支。但是，它将存储库设置为裸存储库，因此您必须随后将其恢复为普通存储库。

    git clone --mirror path/to/original path/to/dest/.git
    cd path/to/dest
    git config --bool core.bare false
    git checkout anybranch
    

参考：[Git 常见问题解答：如何克隆包含所有远程跟踪分支的存储库？](https://git.wiki.kernel.org/index.php/Git_FAQ#How_do_I_clone_a_repository_with_all_remotely_tracked_branches.3F)

您可以轻松切换到分支，而无需使用花哨的“git checkout -b somebranch origin/somebranch”语法。你可以做：

    git checkout somebranch
    

Git 会自动做正确的事情：

    $ git checkout somebranch
    Branch somebranch set up to track remote branch somebranch from origin.
    Switched to a new branch 'somebranch'
    

Git 会检查一个远程分支中是否存在同名分支，如果存在，它会以与您明确指定它是远程分支相同的方式进行跟踪。来自 Git 1.8.2.1 的 git-checkout 手册页：

> 如果未找到 <branch>，但在一个远程（称为 <remote>）中确实存在具有匹配名称的跟踪分支，则视为等同于
> 
>     $ git checkout -b <branch> --track <remote>/<branch>
>

Git 如何克隆所有远程分支?

在Git中，空目录本身不会被包含在版本控制中。这是因为Git跟踪文件的变化，而不是目录。但是，常见的做法是在需要跟踪的空目录里添加一个名为 `.gitignore` 的文件。

以下是将空目录添加到Git存储库的步骤：

1. 在你的本地文件系统中创建你想要跟踪的空目录。例如，你想跟踪名为 `empty-folder` 的目录：

   ```bash
   mkdir empty-folder
   ```

2. 在这个空目录中创建一个 `.gitignore` 文件。这个文件可以包含一些规则来告诉Git忽略哪些文件，但在这种情况下，我们只是用它来保持目录的存在。打开文本编辑器，创建一个名为 `.gitignore` 的文件，并写入以下内容：

   ```
   # Ignore everything in this directory
   *
   # Except this file
   !.gitignore
   ```

3. 这样，`.gitignore` 文件会告诉Git忽略该目录下的所有文件（`*` 表示所有文件），但不包括 `.gitignore` 文件自身（`!.gitignore`）。

4. 将新建的 `.gitignore` 文件添加到版本控制中：

   ```bash
   git add empty-folder/.gitignore
   ```

5. 提交更改到你的Git存储库：

   ```bash
   git commit -m "Add empty-folder with .gitignore"
   ```

6. 将更改推送到远程仓库（如果有的话）：

   ```bash
   git push
   ```

使用这种方法，虽然目录是空的，但其中的 `.gitignore` 文件确保了Git将目录包含在版本控制中。这是在Git中处理空目录的常见方式。

使目录（在存储库中）保持（几乎）为空的另一种方法是`.gitignore`在该目录中创建一个包含以下四行的文件：

    # Ignore everything in this directory
    *
    # Except this file
    !.gitignore
    

那么您就不必像 m104 的解决[方案](https://stackoverflow.com/a/180917/32453)中那样正确地获得订单。

这还有一个好处，即当您执行 git status 时，该目录中的文件不会显示为“未跟踪”。

使[@GreenAsJade](https://stackoverflow.com/users/554807/greenasjade)的评论持久化：

> 我认为值得注意的是，这个解决方案恰好满足了问题的要求，但可能不是许多查看这个问题的人所寻求的。此解决方案保证目录保持为空。它说“我真的不想在这里签入文件”。与“我这里还没有任何文件要签入，但我需要这里的目录，文件可能稍后会出现”相反。

你不能。请参阅[Git 常见问题解答](https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F)。

> 目前 git 索引（暂存区域）的设计仅允许列出文件，并且没有人有足够的能力进行更改以允许空目录，并且足够关心这种情况并进行补救。
> 
> 在目录中添加文件时会自动添加目录。也就是说，目录永远不需要添加到存储库中，并且不会自行跟踪。
> 
> 你可以说“ `git add <dir>`”，它就会在其中添加文件。
> 
> 如果您确实需要在结账中存在一个目录，您应该在其中创建一个文件。.gitignore 非常适合此目的；您可以将其留空，或填写您希望在目录中显示的文件的名称。

`.gitkeep`在目录中创建一个名为的空文件，然后`git add`将其命名为.

默认情况下，这将是类 Unix 系统上的隐藏文件，但它会强制 Git 承认该目录的存在，因为它现在有内容。

另请注意，该文件的名称没有什么特别之处。您可以将其命名为您想要的任何名称。Git 关心的只是文件夹中有东西。

您始终可以在该目录中放置一个自述文件，并解释为什么您希望在存储库中使用此目录（否则为空目录）。

touch .placeholder
    

在 Linux 上，这会创建一个名为 的空文件`.placeholder`。就其价值而言，这个名称与 git 无关，并且这种方法用于系统中的其他各个地方，例如`/etc/cron.d/.placeholder`. 其次，正如另一位用户所指出的，`.git`可以为 Git 本身用于配置目的的文件和目录保留前缀约定。

或者，正如另一个[答案](https://stackoverflow.com/a/5305908/)中所述，**该目录可以包含一个描述性[`README.md`文件](https://stackoverflow.com/questions/8655937/github-readme-and-readme-md)**。

无论哪种方式，这都要求文件的存在不会导致您的应用程序崩溃。

Git 如何将空目录添加到存储库？

要删除远程仓库中的标签（Tag），您可以使用 `git push` 命令结合 `--delete` 选项。这里有一个步骤说明和示例：

**步骤 1:** 首先，您需要确定要删除的远程标签的名称。您可以通过以下命令查看所有远程标签：

```sh
git fetch --tags
git tag -l
```

假设您要删除的远程标签名称为 `v1.0`。

**步骤 2:** 接下来，您可以使用以下命令删除远程标签：

```sh
git push --delete origin v1.0
```

这里，`origin` 是您要删除标签的远程仓库的名称（通常情况下远程仓库默认叫做 `origin`），`v1.0` 是要删除的标签名称。

**示例:**

假设我有一个远程仓库，在这个仓库中有一个标签 `v1.0`，现在我需要删除它。我会这样操作：

1. 首先，我确认标签存在：

    ```sh
    git fetch --tags
    git tag -l
    ```
   
    这会列出所有的标签，确认 `v1.0` 在列表中。

2. 然后，我使用命令删除远程标签：

    ```sh
    git push --delete origin v1.0
    ```
   
    这个命令告诉 Git 我要推送一个删除操作到远程仓库 `origin`，目标是删除 `v1.0` 标签。

执行这个命令后，远程仓库中的 `v1.0` 标签将被删除。也可以使用 `:refs/tags/v1.0` 这样的语法来指定要删除的标签，但是上面提到的 `--delete` 选项更加直观易懂。

此外，在进行此类操作之前，通常需要确认您有足够的权限删除远程仓库中的标签，因为在多人协作的项目中，这可能会影响其他人的工作。

您可以将“空”引用推送到远程标记名称：

    git push origin :tagname
    

或者，更具体地说，使用该`--delete`选项（或者`-d`如果您的 git 版本早于 1.8.0）：

    git push --delete origin tagname
    

请注意，git 具有标签命名空间和分支命名空间，因此您可以对分支和标签使用相同的名称。如果你想确保不会意外删除分支而不是标签，你可以指定 full ref ，它永远不会删除分支：

    git push origin :refs/tags/tagname
    

如果还需要删除本地标签，请使用：

    git tag --delete tagname
    

* * *

### 背景

将分支、标签或其他引用推送到远程存储库涉及指定“哪个存储库、什么源、什么目的地？”

    git push remote-repo source-ref:destination-ref
    

将主分支推送到源的主分支的真实示例是：

    git push origin refs/heads/master:refs/heads/master
    

由于默认路径，可以缩短为：

    git push origin master:master
    

标签的工作方式相同：

    git push origin refs/tags/release-1.0:refs/tags/release-1.0
    

也可以缩短为：

    git push origin release-1.0:release-1.0
    

通过省略源引用（冒号之前的部分），您可以将“无内容”推送到目标，从而删除远程端的引用。

直接的方法：

```
git push --delete origin YOUR_TAG_NAME
```

如果您有要删除的远程标签`v0.1.0`，并且您的远程是`origin`，那么只需：

    git push origin :refs/tags/v0.1.0
    

如果还需要在本地删除标签：

    git tag -d v0.1.0
    

请参阅[**Adam Franco**的回答](https://stackoverflow.com/a/5480292/535871)`:`，了解 Git 不寻常的删除语法的解释。

**删除所有本地标签并获取远程标签列表**：

    git tag -l | xargs git tag -d
    git fetch
    

**删除所有远程标签**

    git tag -l | xargs -n 1 git push --delete origin
    

**清理本地标签**

    git tag -l | xargs git tag -d

`git push --delete origin $TAGNAME`是正确的方法（除了本地删除）。

但是：请确保使用 Git 2.31+（2021 年第一季度）。

“ [`git push $there --delete`](https://github.com/git/git/blob/140045821aa78da3a80a7d7c8f707b955e1ab40d/Documentation/git-push.txt)” ( [man](https://git-scm.com/docs/git-push) )应该被诊断为错误，但却变成了匹配的推送，并已在 Git 2.31 (Q1 2021) 中得到纠正。

请参阅[Junio C Hamano (](https://github.com/gitster) [)的](https://github.com/gitster)[提交 20e4164](https://github.com/git/git/commit/20e416409fc2bc260faf65a0fc74927ed0d3ca12)（2021 年 2 月 23 日）。（由[Junio C Hamano 合并 --](https://github.com/gitster) [\--](https://github.com/gitster)在[提交 1400458](https://github.com/git/git/commit/140045821aa78da3a80a7d7c8f707b955e1ab40d)中，2021 年 2 月 25 日）[`gitster`](https://github.com/gitster)  
[`gitster`](https://github.com/gitster)[](https://github.com/git/git/commit/140045821aa78da3a80a7d7c8f707b955e1ab40d)

> [`push`](https://github.com/git/git/commit/20e416409fc2bc260faf65a0fc74927ed0d3ca12): 不变成`--delete ''`匹配推送
> ----------------------------------------------------------------------------------------------------------
> 
> 关注者：蒂尔曼·沃格尔

> 当我们将语法糖“ [`git push remote --delete`](https://github.com/git/git/blob/20e416409fc2bc260faf65a0fc74927ed0d3ca12/Documentation/git-push.txt#L182)” （[man](https://git-scm.com/docs/git-push#Documentation/git-push.txt---delete)） `<ref>`添加到“ [`git push`](https://github.com/git/git/blob/20e416409fc2bc260faf65a0fc74927ed0d3ca12/Documentation/git-push.txt)” （[man](https://git-scm.com/docs/git-push)）作为规范（[man](https://git-scm.com/docs/git-push#Documentation/git-push.txt-remoterejected)）的同义词时： [f517f1f](https://github.com/git/git/commit/f517f1f2e9c9e3abe0fde1b3c9a7bb20fdb5ba55)处的语法（“ ：（[man](https://git-scm.com/docs/git-add)）作为：foo的语法糖”，2009-12-30， Git v1.7.0-rc0 -- [merge](https://github.com/git/git/commit/84d52cabe7044786b5cc448ffeb97b7c1e667156)），我们不够仔细以确保它不为空。[`git push remote`](https://github.com/git/git/blob/20e416409fc2bc260faf65a0fc74927ed0d3ca12/Documentation/git-push.txt#L453)[](https://git-scm.com/docs/git-push#Documentation/git-push.txt-remoterejected)[](https://github.com/git/git/commit/f517f1f2e9c9e3abe0fde1b3c9a7bb20fdb5ba55)`builtin-push`[`add`](https://github.com/git/git/blob/f517f1f2e9c9e3abe0fde1b3c9a7bb20fdb5ba55/Documentation/git-add.txt)[](https://git-scm.com/docs/git-add) `--delete`[](https://github.com/git/git/commit/84d52cabe7044786b5cc448ffeb97b7c1e667156)`<ref>`
> 
> 盲目地将“”重写`--delete <ref>`为“ `:<ref>`”意味着空字符串`<ref>`会导致refspec“ `:`”，这是要求“匹配”推送的语法，不会删除任何内容。
> 
> 更糟糕的是，如果有可以快进的匹配参考，它们就会过早地发布，即使用户觉得它们还没有准备好被推出，这将是一场真正的灾难。

假设您想要的提交的哈希值是`c5f567`：

    git checkout c5f567 -- file1/to/restore file2/to/restore
    

git [checkout](https://git-scm.com/docs/git-checkout)手册页提供了更多信息。

如果您想恢复到之前的提交`c5f567`，请追加`~1`（其中 1 是您要返回的提交数，可以是任何值）：

    git checkout c5f567~1 -- file1/to/restore file2/to/restore
    

附带说明一下，我一直对这个命令感到不舒服，因为它既用于普通的事情（在分支之间进行更改），也用于不寻常的破坏性事情（丢弃工作目录中的更改）。

`--`命令中的含义可以参考[在Git中，`--`(dash dash) 是什么意思？](https://stackoverflow.com/questions/22750028/in-git-what-does-dash-dash-mean)

* * *

还有一个新[`git restore`](https://git-scm.com/docs/git-restore)命令专门用于恢复已修改的工作副本文件。如果你的 git 足够新，你可以使用这个命令，但文档附带一个警告：

> 该命令是实验性的。行为可能会改变。

因为`git restore`它是实验性的，所以还不应该被推广为这个问题的主要答案。当该命令不再标记为“实验性”时，则可以修改此答案以推广`git restore`. \[在撰写本文时，该`git restore`命令已被标记为“实验”至少四年。\]

您可以使用 diff 命令快速查看对文件所做的更改：

    git diff <commit hash> <filename>
    

然后要将特定文件恢复到该提交，请使用重置命令：

    git reset <commit hash> <filename>
    

`--hard`如果您有本地修改，您可能需要使用该选项。

管理航路点的一个好的工作流程是使用标签在时间轴中清晰地标记点。我不太明白你的最后一句话，但你可能想要的是从之前的时间点分出一个分支。为此，请使用方便的结帐命令：

    git checkout <commit hash>
    git checkout -b <new branch name>
    

当您准备好合并这些更改时，您可以根据主线重新调整基础：

    git checkout <my branch>
    git rebase master
    git checkout master
    git merge <my branch>

您可以使用对 git 提交的任何引用，包括 SHA-1（如果最方便的话）。重点是该命令如下所示：

`git checkout [commit-ref] -- [filename]`

git checkout -- foo
    

这将重置`foo`为 HEAD。你也可以：

    git checkout HEAD^ foo
    

进行一次修订等

从 git v2.23.0 开始，有一个新的[git Restore](https://git-scm.com/docs/git-restore/2.23.0)方法，该方法应该承担部分`git checkout`责任（即使接受的答案也提到这`git checkout`非常令人困惑）。[请参阅github 博客](https://github.blog/2019-08-16-highlights-from-git-2-23/)上的更改要点。

`source`此命令的默认行为是使用来自参数的内容（在您的情况下将是提交哈希）恢复工作树的状态。

因此，根据 Greg Hewgill 的回答（假设提交哈希为`c5f567`），命令将如下所示：

    git restore --source=c5f567 file1/to/restore file2/to/restore
    

或者如果你想恢复到c5f567之前一次提交的内容：

    git restore --source=c5f567~1 file1/to/restore file2/to/restore

所有问题