Git是一个由林纳斯·托瓦兹为了更好地管理linux内核开发而创立的分布式版本控制／软件配置管理软件。需要注意的是和GNU Interactive Tools，一个类似Norton Commander界面的文件管理器相区分。



要删除 Git 中的 submodule，你需要按照以下步骤操作：这包括从工作区、暂存区和 `.gitmodules` 文件中移除 submodule，以及清理相应的配置。

1. **删除 submodule 目录**：
   进入到包含 submodule 的 Git 仓库根目录，然后使用命令删除 submodule 目录。
   ```bash
   git rm -f path/to/submodule
   ```
   这一步将 submodule 从工作区和暂存区（index）中删除。

2. **编辑 `.gitmodules` 文件**：
   打开 `.gitmodules` 文件，找到并删除相关 submodule 的配置部分。这通常包含 `path`、`url` 和 `branch` 等信息。
   例如：
   ```ini
   [submodule "path/to/submodule"]
       path = path/to/submodule
       url = https://github.com/example/submodule.git
   ```
   将上述部分完全删除。

3. **编辑 `.git/config` 文件**：
   打开 `.git/config` 文件，在其中找到 submodule 的相关配置并删除。这与 `.gitmodules` 文件中的内容相似。

4. **删除 submodule 的数据**：
   submodule 的数据存储在 `.git/modules` 下的对应子目录中。需要手动删除这个目录以清理残留的 submodule 数据。
   ```bash
   rm -rf .git/modules/path/to/submodule
   ```

5. **提交更改**：
   提交上述所有更改到你的仓库。
   ```bash
   git commit -am "Remove submodule"
   ```

6. **推送更改到远端仓库**：
   如果你的本地仓库关联了远端仓库，执行下面的命令将更改推送到远端。
   ```bash
   git push
   ```

以上步骤可以确保 submodule 被完全从你的 Git 仓库中删除，包括它的历史记录和配置信息。这样做可以让你的项目结构更干净，也避免了将来的混淆和错误。

How do I remove a submodule in git

在使用Git进行版本控制时，向远程仓库推送更改可能会遇到引用错误（ref errors）。这通常发生在尝试将本地的更改推送到远程仓库时，但由于某些原因，操作无法成功完成。以下是一些典型的原因和相应的解决方案：

### 1. 远程分支已更新
错误信息可能会像这样：
```
! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:user/repo.git'
```
这通常意味着你的本地分支落后于远程分支。别人可能已经推送了一些提交，而你的本地分支还没有这些更新。

**解决方法**：
你需要先将远程分支的更改拉取到本地，合并冲突（如果有的话），然后再次尝试推送。

```bash
git fetch origin
git merge origin/master
# 处理可能出现的合并冲突
git push origin master
```

或者使用`git pull`来简化这个过程（`git pull` 实际上是 `git fetch` 和 `git merge` 的组合）。

```bash
git pull origin master
# 处理可能出现的合并冲突
git push origin master
```

如果你想保持提交历史的清晰，可以使用`git pull --rebase`。

```bash
git pull --rebase origin master
# 解决任何出现的冲突
git push origin master
```

### 2. 本地分支和远程分支不匹配
有时，你可能尝试推送一个本地分支到一个不匹配的远程分支。这通常会导致引用错误。

**解决方法**：
确保你推送的分支名称与远程的目标分支相匹配：

```bash
git push origin local-branch-name:remote-branch-name
```

如果远程分支不存在，你可以使用以下命令创建它：

```bash
git push origin local-branch-name
```

### 3. 权限不足
如果你没有权限向远程仓库推送更改，你也会遇到错误。

**解决方法**：
确保你对远程仓库有足够的权限。如果是在团队中工作，可能需要联系仓库管理员来获取必要的权限。

### 4. 强制推送被远程仓库禁止
有时，即使你使用强制推送（`git push -f`），也可能因为远程仓库的配置原因而失败。

**解决方法**：
谨慎使用强制推送，因为这可能会覆盖其他人的更改。如果必须这么做，请先和团队沟通。如果远程仓库禁止了强制推送，你需要联系仓库管理员解决。

### 5. 钩子脚本的问题
在某些情况下，远程仓库可能配置了钩子脚本（hooks），如果推送的提交不符合这些钩子定义的规则，推送将会失败。

**解决方法**：
检查错误信息来确定是否是钩子脚本导致的问题。如果是，根据提示修改你的提交，以满足钩子脚本的要求。

### 总结
处理Git引用错误的关键是仔细阅读错误信息，了解失败的根本原因，并采取适当的措施解决问题。通常，这涉及到更新本地分支、解决合并冲突、检查推送权限以及与团队成员沟通，以确保代码库的一致性和完整性。

(Note:<a href)=“ https://github.blog/changelog/2020-08-26-set-the-default-branch-for-newly-created-repositories/ "Rel=" noreferrer ">Starting October 2020</a>, any new repository is created with the default branch<code>main</code>, not<code>master</code>. And you can<a=" https://github.com/github/renaming "Rel=" noreferrer ">rename existing repository default branch from<code>master</code>to<code>main</code></a>.

If you just used<code>git init</code>and have added your files with<code>git add</ Code>or something similar and have added your remote branch it might be that you just haven't committed (<code>git commit - m'commit message '</code>) anything locally to push to the remote I just had this error and that was my issue

I have the same problem I was getting this problem because I had not made any commitments, not even an initial commitment and still I was trying to push

It has worked for me with this combination of several command lines:

Renaming your branch and then push, e.g.:

I found the solution to this problem in GitHub help (<a href=“ https://help.github.com/articles/dealing-with-non-fast-forward-errors/ Dealing with non fast forward errors</a>:

I followed the following steps and it worked for me

I have faced the same problem and fixed it with the below steps

Git error failed to push some refs to remote?

在`pnpm`环境中，确实可以使用相似于`npm`中`npx`命令的功能。`npx`是`npm`的一个工具，允许用户运行在没有全局安装的情况下的包。`pnpm`有一个类似的命令叫`pnpx`，但从`pnpm`版本6开始，`pnpx`被标记为废弃，转而推荐直接使用`pnpm dlx`。

`pnpm dlx`命令的作用类似于`npx`，它允许你执行一个在本地未安装的npm包。这样你可以临时运行一个命令，而不需要将其添加到项目的依赖中。举个例子，如果你希望运行`create-react-app`来初始化一个新的React项目，你可以使用下面的命令：

```sh
pnpm dlx create-react-app my-app
```

这条命令将会临时安装`create-react-app`并立刻在`my-app`目录下创建一个新的React应用，而无需将`create-react-app`作为全局或项目的依赖。

使用`pnpm dlx`的好处之一是，它会使用`pnpm`的存储方式，即使是临时安装，也会利用`pnpm`的缓存和存储机制，有效地节省磁盘空间并加快后续的执行速度。

The are are two key uses of `npx`.

**Running executables inside your downloaded dependencies**

For example `npx jest`.

The pnpm equivalent is `pnpm exec jest`.

**Running executable commands in packages you want to download transiently**

For example `npx create-react-app my-app`.

The pnpm equivalent of this is `pnpm dlx create-react-app my-app`.

Note: There used to be a `pnpx` command, but it has been [deprecated](https://web.archive.org/web/20230202163724/https://pnpm.io/6.x/pnpx-cli).

Based on [PNPM Feature Comparison](https://pnpm.io/feature-comparison) the alternative to **NPX** in **PNPM** should `pnpm dlx`

Comment from the [addition of dlx](https://github.com/pnpm/pnpm/pull/3652):

> npx is also kind of deprecated and replaced by `npm exec`.

Which probably refers to npx being [deprecated as standalone package](https://github.com/npm/npx/commit/34660901133c8e890c1076d11b744ea20d9511c2#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R1) and [inclusion into npm itself by use of `npm exec`](https://docs.npmjs.com/cli/v7/commands/npx#compatibility-with-older-npx-versions) . The [main difference](https://docs.npmjs.com/cli/v7/commands/npx#npx-vs-npm-exec) is now that

**`npm exec` supports `--` to end argument parsing** for itself and count following args to the package to be run.

Whereas **npx** requires all **args to itself** to be given **before the package** to be run and couts all following arguments to the latter.

Short answer yes. `npx create-next-app@latest --use-pnpm`

Can I use npx with pnpm?

`cherry-pick` 是 Git 版本控制系统中的一个功能，它的作用是允许用户选择一个或多个其他分支上的提交（commits），并将这些提交复制到当前分支上。这样做的主要原因通常是因为这些提交包含了对特定问题的修复或者是某个特定功能的实现，而这些是当前分支所需要的。

使用 `cherry-pick` 的情况通常包括：

1. **修复紧急问题**：当在一个分支上发现了一个紧急问题并且此问题已经在另一个分支上被解决了，可以使用 `cherry-pick` 将这个修复迅速应用到当前分支上，而不必合并整个分支的所有更改。

2. **代码回滚**：在某些情况下，如果一次提交导致了问题，而这个问题在后续的提交中得到了解决，可以使用 `cherry-pick` 来选择性地将修复的提交应用到当前分支上。

3. **功能挑选**：在开发过程中，可能某个功能先在一个分支上实现，但是需要将其应用到另一个分支上。如果这两个分支不方便直接合并，可以使用 `cherry-pick` 来单独挑选该功能的提交。

4. **代码整理**：有时在多个分支上可能有很多临时或实验性的提交，当需要清理历史或重新组织提交时，可以使用 `cherry-pick` 来选择性地将有效的提交整合到一个新的分支上。

使用 `cherry-pick` 的命令格式如下：

```bash
git cherry-pick <commit-hash>
```

其中 `<commit-hash>` 是想要复制的提交的哈希值。

这里有一个具体的例子：假设我们有两个分支，`main` 和 `feature`。在 `feature` 分支上有一个提交（假设哈希值是 `abc1234`），这个提交修复了一个严重的 bug。现在，我们希望将这个修复迅速应用到 `main` 分支上，但我们不想合并整个 `feature` 分支的所有更改。我们可以在 `main` 分支上执行以下命令：

```bash
git checkout main
git cherry-pick abc1234
```

这样，`abc1234` 这个提交就被复制到了 `main` 分支上，而 `main` 分支上的其他代码保持不变。这是一个高效且精确地管理代码更改的方式。然而，需要注意的是，如果在不同分支之间 `cherry-pick` 被复制的提交，可能会遇到冲突，这时就需要手动解决这些冲突。

Cherry-picking in Git means choosing a commit from one branch and applying it to another.

This contrasts with other ways such as `merge` and `rebase` which normally apply many commits to another branch.

It's also possible to [cherry-pick multiple commits](https://stackoverflow.com/questions/1670970/how-to-cherry-pick-multiple-commits) but `merge` is the preferred way over cherry-picking.

1. Make sure you are on the branch you want to apply the commit to.
 
 git switch master
 
 
2. Execute the following:
 
 git cherry-pick <commit-hash>
 
 

N.B.:

1. If you cherry-pick from a public branch, you should consider using
 
 git cherry-pick -x <commit-hash>
 
 
 This will generate a standardized commit message. This way, you (and your co-workers) can still keep track of the origin of the commit and may avoid merge conflicts in the future.
 
2. If you have notes attached to the commit they do not follow the cherry-pick. To bring them over as well, You have to use:
 
 git notes copy <from> <to>
 
 

Additional links:

* [git official guide page](http://git-scm.com/docs/git-cherry-pick)
* [git cherry-pick guide](https://acompiler.com/git-cherry-pick/)

This quote is taken from: [Version Control with Git](https://rads.stackoverflow.com/amzn/click/com/1449316387)

> Using git cherry-pick The command git cherry-pick commit applies the changes introduced by the named commit on the current branch. It will introduce a new, distinct commit. **Strictly speaking, using git cherry-pick doesn’t alter the existing history within a repository; instead, it adds to the history. As with other Git operations that introduce changes via the process of applying a diff, you may need to resolve conflicts to fully apply the changes from the given commit** . The command git cherry-pick is typically used to introduce particular commits from one branch within a repository onto a different branch. A common use is to forward- or back-port commits from a maintenance branch to a development branch.

    $ git checkout rel_2.3
    $ git cherry-pick dev~2 # commit F, below
    

before: ![before](https://i.stack.imgur.com/R4nfN.png)

after: ![after](https://i.stack.imgur.com/23fCh.png)

Also, here is a very nice in action video tutorial about it: [Youtube: Introduction to Git cherry-pick](https://www.youtube.com/watch?v=-ndmel-4wsk)

Cherry picking in Git is designed to apply some commit from one branch into another branch. It can be done if you eg. made a mistake and committed a change into wrong branch, but do not want to merge the whole branch. You can just eg. revert the commit and cherry-pick it on another branch.

To use it, you just need `git cherry-pick hash`, where `hash` is a commit hash from other branch.

For full procedure see: [http://technosophos.com/2009/12/04/git-cherry-picking-move-small-code-patches-across-branches.html](http://technosophos.com/2009/12/04/git-cherry-picking-move-small-code-patches-across-branches.html)

I prepared step-by-step illustrations what _cherry-pick_ does — and an _animation of these illustrations_ (near the end).

1.  Before cherry-picking  
    (we are going to do a _cherry-pick_ of the commit `L` from the branch `feature`): [![An image showing the state of a Git repository before cherry-picking. On the master branch, there are five commits, A through E. A second branch, labeled 'feature', contains four commits and diverges at commit B. The 'feature' commits are labeled K through N, with L in the middle.](https://i.stack.imgur.com/x1R6o.jpg)](https://i.stack.imgur.com/x1R6o.jpg)

* * *

2.  Starting the command `git cherry-pick feature~2`  
    (`feature~2` is the 2nd commit before  
    `feature`, i.e. the commit `L`): [![This image shows the result of a cherry-pick operation taking the L commit out of the feature branch, and placing it after the E commit on the master branch.](https://i.stack.imgur.com/H1NDD.jpg)](https://i.stack.imgur.com/H1NDD.jpg)

* * *

3.  After performing the command (`git cherry-pick feature~2`): [![The master branch now contains a commit, called L', or L-prime. The feature branch is unchanged.](https://i.stack.imgur.com/LpDH8.jpg)](https://i.stack.imgur.com/LpDH8.jpg)

* * *

The same animated: [![An animation of the above steps.](https://i.stack.imgur.com/j2D9C.gif)](https://i.stack.imgur.com/j2D9C.gif)

* * *

_Note:_

The commit `L'` is _from the user's point of view (commit = snapshot)_ the exact copy of the commit `L`.

Technically (internally), it's a _new, different_ commit (because e.g. `L` contains a pointer to `K` (as its parent), while `L'` contains a pointer to `E`).

**Short example of situation, when you need cherry pick**

> Consider following scenario. You have two branches.
> 
> a) **release1** - This branch is going to your customer, but there are still some bugs to be fixed.
> 
> b) **master** - Classic master branch, where you can for example add functionality for release2.

**NOW**: You fix something in **release1**. Of course you need this fix also in **master**. And that is a typical use-case for cherry picking. So cherry pick in this scenario means that you take a commit from **release1** branch and include it into the **master** branch.

What does cherry picking a commit with git mean

`HEAD`在Git中是一个引用（reference），它指向当前工作目录中的最新提交。简单来说，它代表了你最后一次提交的结果，或者说是当前工作的快照。在Git中，`HEAD`通常用来表示当前的工作分支的尖端。

例如，如果你在`master`分支上工作，并做了一些提交，`HEAD`将会指向`master`分支的最新提交。如果你切换到另一个分支，比如`feature`，那么`HEAD`就会更新，以指向`feature`分支的最新提交。

在Git中，`HEAD`可以是附着的（attached）状态或游离的（detached）状态。当它处于附着状态时，它指向当前分支的最新提交。当处于游离状态时，它直接指向一个提交，而不是某个分支的尖端。这种情况通常发生在你检出一个特定的提交而不是分支时。

此外，`HEAD`还可以与其他引用一起使用，比如`HEAD~1`可以用来引用当前提交的父提交，`HEAD~2`用来引用父提交的父提交，依此类推。

一个实际的例子是，如果我想查看当前分支的历史中的上一个提交，我可以使用命令`git show HEAD~1`。如果我想将当前分支重置到这个上一个提交的状态，我可以使用命令`git reset --hard HEAD~1`。这将会使当前分支的`HEAD`指向那个提交，并且将工作目录的内容更新为那个提交的内容。

您可以将 HEAD 视为“当前分支”。当您使用 切换分支时`git checkout`，HEAD 修订版本会更改为指向新分支的尖端。

您可以通过执行以下操作来查看 HEAD 指向的内容：

    cat .git/HEAD
    

就我而言，输出是：

    $ cat .git/HEAD
    ref: refs/heads/master
    

HEAD 可以引用与分支名称不相关的特定修订版。这种情况称为[detached HEAD](http://git-scm.com/docs/git-checkout#_detached_head)。

引用[别人的话](http://www.eecs.harvard.edu/%7Ecduan/technical/git/git-1.shtml#heads)：

> 头只是对提交对象的引用。每个头都有一个名称（分支名称或标签名称等）。默认情况下，每个存储库中都有一个名为 master 的头。存储库可以包含任意数量的头。在任何给定时间，都会选择一个头作为“当前头”。该头是 HEAD 的别名，始终大写”。
> 
> 请注意这一区别：“head”（小写）指的是存储库中的任何一个命名头；“HEAD”（大写）专门指当前活动的头。这种区别在 Git 文档中经常使用。

[可以在这里](http://eagain.net/articles/git-for-computer-scientists/)找到另一个快速介绍 git 内部工作原理（从而更好地理解 head/HEAD）的好资源。引用 (ref:) 或标题或分支可以被视为粘贴在提交历史记录中的提交上的便利贴。[`git checkout`](http://linux.die.net/man/1/git-checkout)通常它们指向一系列提交的尖端，但它们可以通过或[`git reset`](https://www.kernel.org/pub/software/scm/git/docs/git-reset.html)等移动。

这些答案中可能存在一个微妙但重要的误解。我想我应该添加我的答案来澄清它。

> 什么是`HEAD`？

### 头就是你

`HEAD`是一个符号引用，指向您在提交历史记录中的任何位置。无论你走到哪里，无论你做什么，它都会像影子一样跟随你。如果你做出承诺，`HEAD`就会移动。如果你结账了一些东西，`HEAD`就会搬家。无论你做什么，如果你在提交历史中移动到了新的地方，`HEAD`它就会随着你一起移动。为了解决一个常见的误解：你无法将自己与`HEAD`. 这不是分离的 HEAD 状态。如果你发现自己在想：“哦不，我处于分离的头脑状态！我失去了我的头脑！” 记住，这是你的头。头就是你。你还没有脱离头脑，你和你的头脑已经脱离了其他东西。

### HEAD 可以连接什么？

`HEAD`可以指向提交，是的，但通常不会。让我再说一遍。_通常`HEAD`不指向提交。_它指向一个分支引用。它_附加_到该分支，当您执行某些操作（例如`commit`或[`reset`](https://stackoverflow.com/a/54934887/7936744)）时，附加的分支将随着 一起移动`HEAD`。您可以通过查看引擎盖下面的内容来了解​​它所指向的内容。

    cat .git/HEAD
    

通常你会得到这样的结果：

    ref: refs/heads/master
    

有时你会得到这样的信息：

    a3c485d9688e3c6bc14b06ca1529f0e78edd3f86
    

`HEAD`这就是当直接指向提交时会发生的情况。这称为分离头，因为`HEAD`它指向分支引用之外的其他内容。如果您在此状态下进行提交，`master`则不再附加到`HEAD`，将不再与您一起移动。该提交在哪里并不重要。**您可以与主分支位于同一提交上，但如果`HEAD`指向该提交而不是分支，则它会被分离，并且新的提交将不会与分支引用关联。**

如果您尝试以下练习，您可以以图形方式查看此内容。从 git 存储库运行此命令。你会得到一些稍微不同的东西，但它们的关键部分会在那里。当需要直接检查提交时，只需使用从第一个输出中获得的任何缩写哈希（此处是`a3c485d`）。

    git checkout master
    git log --pretty=format:"%h:  %d" -1
    # a3c485d:   (HEAD -> master)
    
    git checkout a3c485d -q # (-q is for dramatic effect)
    git log --pretty=format:"%h:  %d" -1   
    # a3c485d:   (HEAD, master)
    

好的，所以这里的输出有一点小小的差异。直接检查提交（而不是分支）给我们一个逗号而不是箭头。你怎么看，我们是否处于分离的 HEAD 状态？HEAD 仍然指与分支名称关联的特定修订版。我们仍然_在_master 分支上，不是吗？

现在尝试：

    git status
    # HEAD detached at a3c485d
    

没有。我们处于“分离头”状态。

`(HEAD -> branch)`您可以看到与 的`(HEAD, branch)`相同表示`git log -1`。

### 综上所述

`HEAD`是你。它指向您查看的任何内容，无论您身在何处。通常这不是提交，而是分支。如果`HEAD` _确实_指向提交（或标记），即使它与分支也指向相同的提交（或标记），您（和`HEAD`）也已与该分支分离。由于您没有附加分支，因此当您进行新提交时，分支不会跟随您。`HEAD`不过，会的。

HEAD 只是一个特殊的指针，指向您当前所在的本地分支。

来自[Pro Git](https://git-scm.com/book/en/v2)书籍，第[3.1 章 Git 分支 - 简而言之分支，在](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)**创建新分支**部分：

> 如果创建一个新分支会发生什么？好吧，这样做会创建一个新的指针供您移动。假设您创建一个名为测试的新分支。您可以使用 gitbranch 命令执行此操作：
> 
>     $ git branch testing 
>     
> 
> 这会在您当前所在的同一提交处创建一个新指针
> 
> ![在此输入图像描述](https://i.stack.imgur.com/VBCtE.png)
> 
> Git 如何知道你当前所在的分支？它保留一个称为 HEAD 的特殊指针。请注意，这与您可能习惯的其他 VCS（例如 Subversion 或 CVS）中的 HEAD 概念有很大不同。在 Git 中，这是指向您当前所在的本地分支的指针。在这种情况下，你仍然是master。gitbranch 命令只创建了一个新分支——它并没有切换到该分支。
> 
> ![在此输入图像描述](https://i.stack.imgur.com/eAo7u.png)

我推荐 github 开发者 Scott Chacon 的这个定义 \[[视频参考](http://www.youtube.com/watch?feature=player_detailpage&v=ZDR433b0HJY#t=2791s)\]：

> Head 是您当前的分支。这是一个象征性的参考。它是对分支的引用。你总是有 HEAD，但 HEAD 将指向其他指针之一，指向你所在的分支之一。它是您下一次提交的父级。它应该是上次签出到您的工作目录中的内容...这是您的工作目录的最后一个已知状态。

整个视频将公正地介绍整个 git 系统，因此我也建议您如果有时间的话可以全部观看。

Git 中的 `HEAD` 是一个引用（reference），指向当前工作目录中所检出（checked out）的最新提交（commit）。换句话说，`HEAD` 指向当前分支的最新的本地提交，并且它会随着新的提交而移动。

当你切换分支时，`HEAD` 也会随之切换到新分支的最新提交。在多数情况下，`HEAD` 会指向一个分支名，比如 `master` 或 `main`，这被称为“依附的 HEAD”（attached HEAD）。这意味着你正处在正常的开发过程中，你的 `HEAD` 正依附于一个特定的分支上。

然而，也可以在没有依附任何分支的情况下检出某个特定的提交，这被称作“分离的 HEAD”（detached HEAD）。在这种模式下，你可以查看历史中的代码，或者进行实验性的提交，但要注意，如果你在分离的 HEAD 状态下创建了新的提交，那么，当你切换回一个正常的分支时，这些提交可能会丢失，除非你特别地创建一个新分支来保存这些变化。

你可以通过 `git log` 查看 `HEAD` 的指向，或者使用 `git show-ref --heads` 查看所有分支的当前提交。在 Git 的实现里，`HEAD` 通常是一个包含指向当前提交 SHA-1 值的文件，位于 `.git/` 目录中。

What is head in git?

全局的 Git 配置数据存储在用户的主目录下的 `.gitconfig` 文件中。当您在命令行使用 `git config --global` 命令设置配置时，它会将这些配置添加到这个文件中。

例如，如果我想设置我的全局用户名和电子邮件，我会在终端中使用以下命令：

```bash
git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"
```

执行这些命令后，`.gitconfig` 文件将包含以下内容：

```ini
[user]
    name = Your Name
    email = your_email@example.com
```

这个文件是针对每个用户的，影响该用户在该系统上进行的所有 Git 操作。这与仓库级别的配置是分开的，仓库级别的配置存储在每个 Git 仓库的根目录下的 `.git/config` 文件中。

可以简单地使用：

```bash
git config --list --show-origin
```

使用 Git 2.26，您可以[添加一个 `--show-scope`选项](https://stackoverflow.com/a/60286340/6309)

```bash
git config --list --show-origin --show-scope
```

您将看到哪个配置设置在哪里。
请参阅“[我的 Git 配置中的设置来自哪里？](https://stackoverflow.com/a/35670933/6309) ”

我也在我的 Windows 电脑上寻找全局 `.gitconfig`文件，并使用 git 发现了这个巧妙的技巧。

执行以下操作：

```bash
git config --global -e
```

然后，如果幸运的话，您将打开一个加载了全局 `.gitconfig`文件的文本编辑器。然后只需从那里执行查找文件夹命令即可

在 \*nixes 上，它位于`~/.gitconfig`. 你家里有对应的文件吗？

在 Windows 上，您可以在[Git Bash](https://superuser.com/questions/1053633/what-is-git-bash-for-windows-anyway)中输入以下内容：

    notepad ~/.gitconfig

msygit 的路径是：

**Windows Vista+** `C:\Users\<user_name>\.gitconfig`

在 Windows MsysGit 上，全局位置是使用 HOMEDRIVE 和 HOMEPATH 环境变量导出的，除非您定义了 HOME 环境变量。“配置文件”脚本中有详细说明。

在我的公司环境中，HOMEDRIVE 是 H:，然后将其映射到网络 URL \\\\share\\$。然后，所有内容都会映射到“我的文档”，这不是其他人所期望的。驱动器到 URL 重新映射可能存在一些其他问题。无论如何，我什至无法调整 HOMEDRIVE 或 HOMEPATH 变量。

就我而言，我定义了一个个人 HOME 环境变量并将其指向 D:\\git\\GitHOME 并将所有这些 GIT 文件（没有扩展名）复制到 GitHOME 目录以安全保存。

可以通过“我的电脑”属性对话框中的“高级”选项卡设置 Windows 环境变量。

Where is the global git config data stored?

如果错误地命名了分支并将其推送到远程存储库，请按照以下步骤重命名该分支

1. **重命名您的本地分支：**

   * 如果在要重命名的分支上：
   * ```bash
     git branch -m new-name
     ```
   * 如果在不同的分支：
   * ```bash
     git branch -m old-name new-name
     ```
2. **删除 `old-name`远程分支并推送 `new-name`本地分支**：`git push origin :old-name new-name`
3. **重置新名称本地分支的上游分支**：
   切换到该分支，然后：
   `git push origin -u new-name`

[![示意图，可爱的 git 远程图](https://i.stack.imgur.com/YeBYR.jpg)](https://i.stack.imgur.com/YeBYR.jpg)

* * *

有几种方法可以实现这一点：

1. 更改您的本地分支，然后推送您的更改
2. 使用新名称将分支推送到远程，同时在本地保留原始名称

### 重命名本地和远程

 # Rename the local branch to the new name
 git branch -m <old_name> <new_name>
 
 # Delete the old branch on remote - where <remote> is, for example, origin
 git push <remote> --delete <old_name>
 
 # Or shorter way to delete remote branch [:]
 git push <remote> :<old_name>
 
 # Prevent git from using the old name when pushing in the next step.
 # Otherwise, git will use the old upstream name instead of <new_name>.
 git branch --unset-upstream <new_name>
 
 # Push the new branch to remote
 git push <remote> <new_name>
 
 # Reset the upstream branch for the new_name local branch
 git push <remote> -u <new_name>
 

[![控制台截图](https://i.stack.imgur.com/YOHON.png)](https://i.stack.imgur.com/YOHON.png)

* * *

### 仅重命名远程分支

信用：[ptim](https://stackoverflow.com/questions/30590083/how-do-i-rename-both-a-git-local-and-remote-branch-name/30590238#42173564)

 # In this option, we will push the branch to the remote with the new name
 # While keeping the local name as is
 git push <remote> <remote>/<old_name>:refs/heads/<new_name> :<old_name>
 

* * *

### 重要的提示：

当您使用`git branch -m`（移动）时，Git 也会使用新名称**更新您的跟踪分支。**

> `git remote rename legacy legacy`

`git remote rename`正在尝试更新配置文件中的远程部分。它将使用给定名称的遥控器重命名为新名称，但在您的情况下，它没有找到任何名称，因此重命名失败。

**但**它不会按照你的想法去做；它将重命名您的**本地**配置远程名称而**不是**远程分支。 

* * *

**注意** Git 服务器可能允许您使用 Web 界面或外部程序（如 Sourcetree 等）重命名 Git 分支，但您必须记住，在 Git 中所有工作都是在本地完成的，因此建议使用上述命令去工作。

查询正在使用的分支

```
git branch -a 
```

切换到要重命名的分支

```bash
git checkout branch_to_rename
```

使用重命名分支

```bash
git branch -m new_name
```

推动更改

```bash
git push origin :old_name new_name
```

*   **重命名您的本地分支机构**。

如果您在要重命名的分支上：

    git branch -m new-name
    

如果您当前住在不同的分支机构：

    git branch -m old-name new-name
    

*   **删除旧名称的远程分支并推送新名称的本地分支。**

留在目标分支上并且：

    git push origin :old-name new-name
    

*   **重置新名称本地分支的上游分支。**

切换到目标分支然后：

    git push origin -u new-name

看来有一个直接的办法：

> 如果您真的只想远程重命名分支（而不同时重命名任何本地分支），您可以使用单个命令来完成此操作，例如
> 
> `git push <remote> <remote>/<old_name>:refs/heads/<new_name> :<old_name>`
> 
> _[在 Git 中远程重命名分支](https://stackoverflow.com/questions/4753888/renaming-branches-remotely-in-git/21302474#21302474)_

有关更多详细信息，请参阅原始答案。

How do i rename both a git local and remote branch name?

在使用Git进行版本控制时，`cherry-pick` 是一项功能，它允许开发者选择一个或多个提交(commit)从一个分支复制到当前所在的分支。当你想要将指定的提交应用到你的分支，而不是合并整个分支的内容时，这非常有用。

要逐个挑选多个提交记录，你可以重复使用 `git cherry-pick` 命令，后面跟着你想要挑选的提交的哈希值（commit hash）。例如：

```sh
git cherry-pick commit_hash1
git cherry-pick commit_hash2
git cherry-pick commit_hash3
```

每执行一次 `cherry-pick`，就会将指定的提交应用到当前分支上。

如果你想一次挑选一系列连续的提交，你可以使用如下命令：

```sh
git cherry-pick commit_hash1^..commit_hash3
```

在这个例子中，`commit_hash1^` 表示 `commit_hash1` 的父提交，而 `commit_hash3` 是你想要挑选的最后一个提交。上面的命令将会挑选 `commit_hash1` 到 `commit_hash3` 之间的所有提交（包括 `commit_hash1` 和 `commit_hash3`）。

如果你想要挑选不连续的多个提交，可以在 `git cherry-pick` 命令中一次性列出所有想要挑选的提交哈希值，每个哈希值之间用空格隔开。例如：

```sh
git cherry-pick commit_hash1 commit_hash3 commit_hash5
```

这将会分别挑选 `commit_hash1`、`commit_hash3` 和 `commit_hash5` 这三个提交。

在执行 `cherry-pick` 操作时，可能会发生冲突。如果发生冲突，Git 会停止应用提交，并让你解决冲突。解决完冲突后，你需要使用 `git add` 命令将冲突文件标记为已解决，然后使用 `git cherry-pick --continue` 继续应用挑选的提交。如果你决定不继续这个 `cherry-pick` 操作，可以使用 `git cherry-pick --abort` 放弃更改，回到操作前的状态。

Git 1.7.2 引入了挑选一系列提交的功能。从[发行说明](https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.2.txt)来看：

> `git cherry-pick`学会了选择一系列提交（例如`cherry-pick A..B`和`cherry-pick --stdin`）， 也是如此`git revert`；`rebase [-i]`不过，这些不支持更好的排序控制。

`A`要从一个提交到另一个提交`B`（其中`A`早于`B`）挑选所有提交，请运行：

    git cherry-pick A^..B
    

如果你想_忽略_A 本身，请运行：

    git cherry-pick A..B
    

评论中的注释：

*   `A`应该早于`B`，或者`A`应该来自另一个分支。
*   在 Windows 上，它应该是`A^^..B`因为插入符号需要转义，或者应该是`"A^..B"`（双引号）。
*   在`zsh`shell 中，它应该是`'A^..B'`（单引号），因为插入符号是一个特殊字符。
*   有关说明，请参阅[Gabriel Staples 的回答](https://stackoverflow.com/a/69472178/4561887)。

_（感谢评论中的 damian、JB Rainsberger、sschaef、Neptilo、Pete 和 TMin。）_

如果您有选择性的修订要合并，例如来自 A、B、C、D、E、F、G、H、I、J 提交的 A、C、F、J，只需使用以下命令：

    git cherry-pick A C F J

最简单的方法是`onto`选择`rebase`. 假设当前结束的分支称为 mybranch，并且这是您要移动到的`a`分支。`c``f`

    # checkout mybranch
    git checkout mybranch
    
    # reset it to f (currently includes a)
    git reset --hard f
    
    # rebase every commit after b and transplant it onto a
    git rebase --onto a b

如何挑选单个提交、多个提交或一系列提交
-------------------

**...到您当前签出的分支：**

1\. 挑选一个名为的_分支_或提交`commit`
--------------------------

    git cherry-pick commit
    

例子：

    git cherry-pick my_branch                                 # by branch name
    git cherry-pick 1e038f108a130831f108329b1083a8139813fabc  # by full hash
    git cherry-pick 1e038f10                                  # by partial hash
    

2\. 挑选_多个_提交
------------

请注意，您可以按您想要的任何顺序一次挑选_任意数量的提交哈希值__。_它们只会按照您指定的顺序一次应用一个。如果出现任何冲突，您必须一次解决一个问题，然后在完成后使用`git add my_file`then`git cherry-pick --continue`继续挑选过程。

    git cherry-pick commit1 commit2 commit3 commit4 commit5
    

3\. 挑选_一系列_提交
-------------

[我最初是从@Eric Darchis 在这里获得最多支持的答案中](https://stackoverflow.com/a/3933416/4561887)学习了这种风格的基础知识。

请注意，要挑选一系列_提交_，您必须指定开始和结束提交哈希，以及`..`它们之间的值。但是，在一系列提交中，不包括开始提交。因此，要包含它，您必须在开始提交_之前_指定提交。_指定前面_提交的语法是在提交_之后_放置`~`、`~1`或 ，如： ，这意味着`^`：“之前的提交”。`beginning_commit~``beginning_commit`

    # A. INCLUDING the beginning_commit
    git cherry-pick beginning_commit~..ending_commit
    # OR (same as above)
    git cherry-pick beginning_commit~1..ending_commit
    # OR (same as above)
    git cherry-pick beginning_commit^..ending_commit 
    
    # B. NOT including the beginning_commit
    git cherry-pick beginning_commit..ending_commit
    

_注意：_ `commit~`、`commit~1`和all 表示“_之前的_`commit^`一次提交”，或者换句话说：“之前的提交”。 `commit``commit`

要指定之前的_两次_`commit`提交，您可以使用如下语法：

    commit~~
    commit~2  # my preferred syntax
    commit^^
    

要指定之前的_三个_`commit`提交，您可以执行以下操作：

    commit~~~  
    commit~3   # my preferred syntax
    commit^^^
    

这不起作用：

    commit^3   # INVALID syntax
    

这_确实_有效，但这是一个非常特殊的情况。另请参阅我的问答：[在`git merge`\-style 工作流程中，仅显示合并之前某人在其 PR（拉取请求）功能分支中拥有的唯一提交](https://stackoverflow.com/q/77617436/4561887)：

    # valid on **merge commits** only
    commit^2   # this is the immediate **right** parent of the two parents 
               # involved in the merge (which made commit `commit`)
    
    # valid on any commits (gets the left parent of a merge commit, or 
    # the only parent of a non-merge commit)
    commit~    # and this is the immediate **left** parent of the two 
               # parents involved in the merge (which made commit `commit`)
    

要自己测试上述“先前提交语法”概念，最简单的方法是使用`git log`命令。前任：

    git log commit
    git log commit~
    git log commit~1
    git log commit^
    git log commit~~
    git log commit~5
    # etc.
    

4\. 挑选一系列同行的提交到您的分支上
--------------------

...当他们的分支`peer_branch`从您的分支的早期版本中分叉出来时`my_branch`。

### 快速总结

    # you cherry-pick all of their extra commits from their `peer_branch` onto 
    # your `my_branch` (note: the 3 dots below are very important!)
    
    git fetch origin peer_branch  # get their latest changes from the remote
    git checkout my_branch        # ensure you're on your branch
    # cherry-pick their range of commits
    git cherry-pick my_branch...origin/peer_branch  
    git log                       # review the commits you just chery-picked
    git push                      # push your changes to the remote
    

提交范围内 2 点和 3 点之间的差异非常显着。`git diff branch1...branch2`相当于`git diff $(git merge-base branch1 branch2) branch2`. `branch2`当您想要查看自 偏离 以来所做的更改`branch1`，而不是两个分支在当前状态下的差异时，这非常有用。请参阅此处和[此处](https://stackoverflow.com/questions/1670970/how-to-cherry-pick-multiple-commits/69472178#comment137438679_3933416)[的评论](https://stackoverflow.com/questions/7251477/what-are-the-differences-between-double-dot-and-triple-dot-in-git-dif/7252067#comment112851552_7252067)以及此处的答案：[What are the Differences between double-dot ".." and Triple-dot "..." in Git diff commit Ranges?](https://stackoverflow.com/q/7251477/4561887)[](https://stackoverflow.com/questions/1670970/how-to-cherry-pick-multiple-commits/69472178#comment137438679_3933416)[](https://stackoverflow.com/q/7251477/4561887)

### 完整的详细信息和工作流程演练

假设您正在开发功能分支`my_branch`，而您的同事希望帮助您进行一些更改以帮助您完成功能。您已经推`my_branch`送到名为 的远程`origin`。因此，他们将获取名为`my_branch`其本地计算机的远程分支，从中分叉出自己的名为 的分支`peer_brach`，然后推送到自己名为 的分支`peer_branch`。一旦他们这样做了，你就可以立即挑选他们添加的所有内容。该过程的第一部分如下所示：

    # **your peer** does this
    
    # peer fetches your branch named `my_branch` and forks their `peer_branch`
    # off of it
    
    # they fetch your latest work from remote `my_branch` into their locally-stored
    # remote-tracking "hidden" branch named `origin/my_branch`
    # (note: you can see all locally-stored remote-tracking "hidden" branches
    # with `git branch -r`)
    git fetch origin my_branch
    # create `peer_branch` as a fork off of `origin/my_branch`, and check it out
    git checkout -b peer_branch origin/my_branch
    
    # Now they can add their changes and commits and `git push` to remote `origin`
    # as their own `peer_branch` when done.
    

现在他们已经将所有更改推送到远程`origin`作为他们自己的名为 的分支`peer_branch`，您可以挑选他们添加到您的工作之上的_所有提交，如下所示：_

    # **you** do this to cherry-pick your peer's helpful changes they added to 
    # your work
    
    # you fetch their latest work from their branch named `peer_branch` on remote
    # `origin` into your locally-stored remote-tracking "hidden" branch named 
    # `origin/peer_branch` 
    # (note: you can see all locally-stored remote-tracking "hidden" branches
    # with `git branch -r`)
    git fetch origin peer_branch
    # ensure you are on `my_branch` (if you aren't already)
    git checkout my_branch
    # you cherry-pick all of their extra commits from their `peer_branch` onto 
    # your `my_branch` (note: the 3 dots here are very important!)
    git cherry-pick my_branch...origin/peer_branch
    
    git log                       # review the commits you just chery-picked
    git push                      # push your changes to the remote
    

为了您的理解，`cherry-pick`上面那个带有 3 个点的命令_完全等同_于这个更长的命令：

    git cherry-pick $(git merge-base my_branch origin/peer_branch)..origin/peer_branch
    

该部分查找branch和branch`git merge-base my_branch origin/peer_branch`之间的公共父提交哈希。这是他们从你的你的. 然后，您当然会挑选从该点到 ( ) 的最终提交_的提交范围_。`my_branch``origin/peer_branch``peer_branch``my_branch``..``origin/peer_branch`

要了解有关 3 点语法的更多信息，请参阅此处：[Git diff 提交范围中双点“..”和三点“...”之间的区别是什么？\[复制\]](https://stackoverflow.com/a/7252067/4561887)。有关 的帮助`git checkout -b new_branch from_branch`，请参阅我的答案：[从另一个分支在 git 中创建分支的各种方法](https://stackoverflow.com/a/63418267/4561887)

官方 Git 文档
---------

1.  [https://git-scm.com/docs/gitrevisions](https://git-scm.com/docs/gitrevisions) - 提到 git commit 3 点 ( `...`) 与 2 点范围语法、`^commit`("not" `commit`)、`commit^`( 的父级`commit`) 等。

更进一步
----

1.  还有一点需要知道： a`git rebase`只是一堆连续的`git cherry-pick`s。请参阅我的其他答案（[根据 Git，谁是“我们”，谁是“他们”？](https://stackoverflow.com/a/63911630/4561887)），其中我展示了我制作的 ASCII 绘图，其中显示了 a 的`git rebase`工作原理及其正在执行的操作。
2.  [Git diff 提交范围中的双点“..”和三点“...”有什么区别？\[复制\]](https://stackoverflow.com/a/7252067/4561887)
3.  [我对从另一个分支在 git 中创建分支的各种方法的](https://stackoverflow.com/a/63418267/4561887)回答[](https://stackoverflow.com/a/63418267/4561887)
4.  我的问答：[在`git merge`风格的工作流程中，仅显示合并之前某人在其 PR（拉取请求）功能分支中的唯一提交](https://stackoverflow.com/q/77617436/4561887)

或者所要求的一行：

    git rebase --onto a b f

How to cherry pick multiple commits

要为特定的 Git 提交生成补丁，你可以使用 `git format-patch` 命令。以下是一些常见的用法：

1. **生成最近的一个提交的补丁：**

 ```sh
 git format-patch -1
 ```

 `-1` 指的是最近的一个提交（HEAD）。这将会生成一个以提交哈希开始，后面跟着提交信息的`.patch`文件。

2. **生成特定提交的补丁：**

 首先，你需要知道提交的哈希值。可以使用 `git log` 查看提交历史并找到你想要生成补丁的特定提交的哈希值。然后使用：

 ```sh
 git format-patch -1 <commit-hash>
 ```

 替换 `<commit-hash>` 为实际的提交哈希值。

3. **生成一系列提交的补丁：**

 如果你想要生成一系列提交（比如说，从某个特定的提交开始到最新的提交），你可以这样做：

 ```sh
 git format-patch <commit-hash>^..
 ```

 这里 `<commit-hash>` 是序列中第一个提交的哈希值，`^` 表示该提交的父提交，两个点 `..` 表示到当前分支的最新提交。

4. **生成一个范围内所有提交的补丁：**

 如果你想要获取两个提交之间的所有补丁，可以使用：

 ```sh
 git format-patch <start-commit-hash>..<end-commit-hash>
 ```

 这会为从 `<start-commit-hash>` 到 `<end-commit-hash>` （不包含 `<start-commit-hash>`）之间的每一个提交生成一个补丁文件。

每个生成的补丁文件将包含一个单独提交的完整内容，这些文件可以应用到另一个仓库中，或者用于代码审查和其他目的。这些文件通常是以邮件的形式发送给其他开发者或者通过某些项目管理工具来共享。

尝试：

 git format-patch -<n> <rev>

例如：

 git format-patch -1 HEAD
 

该`-1`标志指示补丁中应包含多少提交：

> \-<n>
> 
>      从最上面的 <n> 次提交中准备补丁。

* * *

使用以下命令应用补丁：

 git am < file.patch
 

或者，您也可以通过以下方式申请（应该适用于包括 Windows 在内的所有操作系统）：

 git apply --verbose file.patch
 

或将显示失败的内容（如果有）`-v`。`--verbose`为您提供有关如何修复的线索。

用于从特定 SHA-1 哈希的最顶层 <n> 提交生成补丁：

 git format-patch -<n> <SHA-1> --stdout > <name_of_patch_file>.patch
 

单个补丁文件中头部的最后 10 个补丁：

 git format-patch -10 HEAD --stdout > 0001-last-10-commits.patch

假设您在提交 1 之后提交了提交 ID 2，您可以运行：

    git diff 2 1 > mypatch.diff
    

其中 2 和 1 是 SHA-1 哈希值。

这个命令（正如[@ _Naftuli Tzvi Kay_](https://stackoverflow.com/questions/6658313/generate-a-git-patch-for-a-specific-commit#comment21730708_6658352)已经建议的那样），

 git format-patch -1 HEAD
 

替换`HEAD`为特定的哈希或范围。

将为最新提交生成补丁文件，其格式类似于 Unix 邮箱格式。

> `-<n>`\- 从最上面的 <n> 次提交中准备补丁。

然后您可以通过以下方式以邮箱格式重新应用补丁文件：

 git am -3k 001*.patch
 

看：[`man git-format-patch`](http://linux.die.net/man/1/git-format-patch)。

git format-patch commit_Id~1..commit_Id  
    git apply patch-file-name
    

快速而简单的解决方案。

How can i generate a git patch for a specific commit?

当您想要从Git存储库中彻底删除某个目录时，您应该遵循以下步骤：

1. **删除本地目录**：
 首先，在您的本地工作副本中，您需要使用文件系统命令来删除目录。例如，在UNIX系统上，您可以使用`rm -rf`命令：

 ```sh
 rm -rf <directory_name>
 ```

2. **将更改暂存到Git**：
 删除了目录后，您需要告诉Git这个变化。为此，您应该使用`git add`命令将删除操作暂存起来，使用带有`-A`选项，该选项告诉Git考虑所有变化（包括文件删除）：

 ```sh
 git add -A
 ```

 或者，您可以只暂存已删除的目录：

 ```sh
 git add <directory_name>
 ```

3. **提交更改**：
 接下来，您需要提交您的更改。提交时应该提供一个合适的消息，说明您进行了哪些更改：

 ```sh
 git commit -m "Remove <directory_name> from the repository"
 ```

4. **从历史记录中删除**：
 如果目录在之前的历史记录中不存在，直接提交即可。但如果您希望从历史记录中彻底删除目录（例如，它可能包含敏感数据），您将需要使用更高级的工具，比如`git filter-branch`或`BFG Repo-Cleaner`。

 使用`filter-branch`：
 ```sh
 git filter-branch --force --index-filter \
 "git rm --cached --ignore-unmatch -r <directory_name>" \
 --prune-empty --tag-name-filter cat -- --all
 ```

 使用`BFG Repo-Cleaner`（一个更快且更容易使用的工具）：
 ```sh
 bfg --delete-folders <directory_name> --no-blob-protection
 ```

 请注意，这些操作会重写您的Git历史记录，这可能对其他人的存储库副本产生影响。这种操作应该非常小心地进行，并且确保团队中的每个人都了解这一点。

5. **推送更改到远程仓库**：
 一旦您提交了更改（并且如果需要，也清理了历史记录），您需要推送这些更改到远程仓库。如果您修改了历史记录，您可能需要使用`--force`（或者在Git 2.0和以上版本中使用`--force-with-lease`）来推送您的更改：

 ```sh
 git push origin --force --all
 ```

 如果您未修改历史记录，正常的推送命令就足够了：

 ```sh
 git push origin
 ```

请记住，在执行这样的操作时，团队中的每个成员都需要知道变更，因为这将影响他们的本地存储库。如果他们有基于被删除目录的未合并工作，可能会遇到冲突。

#### 从 Git 和本地删除目录

检查两个目录的“master”：

 git rm -r one-of-the-directories // This deletes from filesystem
 git commit . -m "Remove duplicated directory"
 git push origin <your-git-branch> (typically 'master', but not always)
 

#### 从 Git 中删除目录，但不是本地目录

要从 Git 中删除此目录，但不将其从文件系统（本地）中完全删除：

 git rm -r --cached myFolder

### 要仅从 git 存储库而不是从本地删除文件夹/目录，请尝试 3 个简单的命令。

* * *

**删除目录的步骤**

    git rm -r --cached FolderName
    git commit -m "Removed folder from repository"
    git push origin master
    

* * *

**在下次提交中忽略该文件夹的步骤**

> 要在下一次提交中忽略该文件夹，请在根文件夹（初始化 git 的主项目目录）中创建一个名为**.gitignore**的文件 ，并将该文件夹名称放入其中。您可以忽略任意数量的文件/文件夹

**.gitignore**文件将如下所示

    /FolderName
    

* * *

![删除目录](https://i.stack.imgur.com/mJYfF.png)

如果由于某种原因，karmakaze 所说的不起作用，您可以尝试使用文件系统浏览器（例如，在 Windows 文件资源管理器中）删除想要的目录。删除目录后，发出命令：  
`git add -A`  
and then  
`git commit -m 'deleting directory'`  
和 then  
`git push origin master`。

我之前已经提交了该文件夹，并且也想删除历史记录中的目录。

我做了以下事情：

将文件夹添加到`.gitignore`：

    echo Folder_Name/ >> .gitignore
    

从所有提交中删除：

    git filter-branch --index-filter 'git rm -rf --cached --ignore-unmatch Folder_Name/' --prune-empty --tag-name-filter cat -- --all
    

从旧提交中删除引用：

    git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
    

确保所有旧的引用被完全删除

    rm -Rf .git/logs .git/refs/original
    

执行垃圾收集

    git gc --prune=all --aggressive
    

将您的更改推送到在线存储库：

    git push
    

你已经完成了。

但是您可以使用以下命令将所有更改推送到所有分支：但是要小心这个命令！

    git push origin --all --force
    git push origin --tags --force
    

之后该文件夹已从 git 中删除，但并未从本地磁盘中删除。

你可以试试这个： **`git rm -rf <directory_name>`**

它将强制删除该目录。

How do i remove a directory from a git repository

要查看仅包含一个用户提交的git日志，您可以使用`git log`命令，并配合`--author`选项来指定作者名字。这样，Git 将会筛选出所有匹配指定作者名字的提交记录。命令的基本格式如下：

```bash
git log --author="用户名"
```

请将`"用户名"`替换为您想要查看提交记录的用户的真实姓名或邮箱地址的一部分。Git会展示出所有匹配该用户名片段的提交。

例如，如果您想要查看由用户John Doe提交的所有日志，您可以运行：

```bash
git log --author="John Doe"
```

如果您已知用户的电子邮箱，并且想要更精确地过滤，可以这样写：

```bash
git log --author=johndoe@example.com
```

此外，如果你想要的搜索更加精细化，可以使用正则表达式：

```bash
git log --author="^John"
```

上面的命令将会显示所有名字以"John"开头的作者的提交。

**例子：**

假设我参与了一个名为`example-project`的项目，并对这个项目做了很多贡献。项目经理想要查看我所有的提交记录，我的Git用户名是`Alex`。项目经理可以在项目的根目录打开终端或命令提示符，然后输入以下命令：

```bash
git log --author="Alex"
```

这将输出所有我作为作者的提交，包括提交哈希、提交信息、日期和时间等详细信息。项目经理可以通过这些信息来分析我的工作量和贡献内容。

这适用于 gitk `git log`和[gitk——](https://git-scm.com/docs/gitk)查看历史记录的两种最常见的方式。
您不需要使用全名：

```
git log --author="Jon"
```

将匹配“Jonathan Smith”所做的提交

```
git log --author=Jon
```

和

```
git log --author=Smith
```

也会起作用。如果不需要任何空格，引号是可选的。

**`--all`如果您打算搜索存储库中的所有分支而不仅仅是当前提交的祖先，请添加。**

还可以轻松匹配多个作者，因为正则表达式是此过滤器的基础机制。

因此，要列出 Jonathan 或 Adam 的提交，您可以这样做：

```
git log --author="$Adam$\|$Jon$"
```

为了使用[本问题中](https://stackoverflow.com/questions/406230/regular-expression-to-match-string-not-containing-a-word)提到的正则表达式排除特定作者或一组作者的提交，您可以将[负向前瞻](http://www.regular-expressions.info/lookaround.html)与开关结合使用 `--perl-regexp`：

```
git log --author='^(?!Adam|Jon).*$' --perl-regexp
```

或者，您可以通过使用和管道排除 Adam 创作的提交 `bash`：

```
git log --format='%H %an' | 
  grep -v Adam | 
  cut -d ' ' -f1 | 
  xargs -n1 git log -1
```

如果您想排除 Adam 提交的（但不一定是创作的）提交，请替换 `%an`为 `%cn`.

github上还有一个_秘密_方法...

您可以通过附加 param 在提交视图中按作者过滤提交`?author=github_handle`。例如，链接[https://github.com/dynjs/dynjs/commits/master?author=jingweno](https://github.com/dynjs/dynjs/commits/master?author=jingweno)显示了 Dynjs 项目的提交列表

```
git help log
```

显示 git log 的联机帮助页。按 / 搜索“author”，然后输入“author”，然后按 Enter。键入“n”几次即可进入相关部分，其中显示：

```
git log --author="username"
```

请注意，这将为您提供提交的作者，但在 Git 中，作者可以是与提交者不同的人。

```bash
git log --author="username" --pretty=format:"%h - %an, %ar : %s"
```

How can i view a git log of just one users commits?

当您要查询当前计算机上Git的全部全局配置时，您可以使用以下Git命令：

```bash
git config --global --list
```

这个命令会列出所有的全局配置，这些配置位于用户主目录下的`.gitconfig`文件中。例如，它可以显示用户的姓名和邮箱配置、差异检查工具、别名等全局设置。如果您想要看到某个特定的全局配置，可以使用以下命令：

```bash
git config --global user.name
git config --global user.email
```

这些命令分别会显示全局配置中设置的用户姓名和邮箱。

举个例子，如果我在我的机器上进行了一些全局设置，配置了我的用户名和邮箱，并为常用的命令设置了别名，那么执行 `git config --global --list` 命令后可能会得到如下输出：

```plaintext
user.name=John Doe
user.email=johndoe@example.com
alias.st=status
alias.co=checkout
alias.br=branch
alias.ci=commit
```

在这个输出中，我们可以看到用户的姓名是"John Doe"，邮箱是"johndoe@example.com"，并且设置了几个命令别名，比如用`st`代替`status`，用`co`代替`checkout`等。

您可以使用：

    git config --list
    

或者查看你的`~/.gitconfig`文件。本地配置将位于存储库的`.git/config`文件中。

使用：

    git config --list --show-origin
    

查看该设置的定义位置（全局、用户、存储库等...）

最短的，

    git config -l
    

显示所有继承的值：系统、全局和本地

> 如何编辑我的**全局**Git 配置？

简短回答：`git config --edit --global`

* * *

要了解 Git 配置，您应该知道：

> Git 配置变量可以存储在三个不同的级别。每个级别都会覆盖前一个级别的值。
> =====================================

**1.系统级别（适用于系统上的每个用户及其所有存储库）**

*   查看，`git config --list --system`（可能需要`sudo`）
*   设置，`git config --system color.ui true`
*   编辑系统配置文件，`git config --edit --system`

**2\. 全局级别（您（用户）个人特定的值）。**

*   查看，`git config --list --global`
*   设置，`git config --global user.name xyz`
*   编辑全局配置文件，`git config --edit --global`

**3\. 存储库级别（特定于该单个存储库）**

*   查看，`git config --list --local`
*   设置，`git config --local core.ignorecase true`（`--local`可选）
*   编辑存储库配置文件，`git config --edit --local`（`--local`可选）

> 如何查看**所有**设置？
> =============

*   运行`git config --list`，显示**系统**、**全局**和（如果在存储库内）**本地**配置
*   Run `git config --list --show-origin`，还显示每个配置项的原始文件

> 如何读取一项特定配置？
> ===========

*   例如，运行`git config user.name`以获取。`user.name`
*   您还可以指定选项`--system`, `--global`,`--local`来读取特定级别的该值。

* * *

参考：_[1.6 入门 - 首​​次 Git 设置](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup)_

git config --list
    

是一种方法。不过我通常只是敞开心扉`.gitconfig`。

从 Git [2.26.0](https://github.com/git/git/blob/v2.26.0/Documentation/RelNotes/2.26.0.txt)开始，您可以使用[`--show-scope`](https://github.blog/2020-03-22-highlights-from-git-2-26/#some-new-config-tricks)选项：

    git config --list --show-scope
    

输出示例：

    system  rebase.autosquash=true
    system  credential.helper=helper-selector
    global  core.editor='code.cmd' --wait -n
    global  merge.tool=kdiff3
    local   core.symlinks=false
    local   core.ignorecase=true
    

它可以与

*   `--local`用于项目配置、 `--global`用于用户配置、 `--system`用于所有用户配置
*   `--show-origin`显示确切的配置文件位置

How do i show my global git configuration

当您想要在 Git 的代码历史中搜索特定的关键词或模式时，可以使用 `git grep` 配合 `git log` 的一些参数来实现。以下是实现这个目的的一个基本步骤：

1. **使用 `git grep` 搜索工作目录中的内容：**

   若您只是想搜索当前工作目录中的文件，可以直接使用 `git grep` 命令。例如：

   ```shell
   git grep '搜索关键字'
   ```

2. **搜索历史提交中的内容：**

   如果您想搜索历史提交中的内容，可以使用 `git log` 的 `-p` 参数和 `grep` 命令组合起来。例如，搜索历史提交中包含“搜索关键字”的内容：

   ```shell
   git log -p -S'搜索关键字'
   ```

   这里的 `-p` 参数会显示每个提交的差异（即代码更改），而 `-S` 参数用于指定要搜索的字符串。`-S` 会查找添加或删除了指定字符串的那些提交。

3. **结合使用 `git log` 和外部的 `grep` 命令：**

   您也可以通过管道将 `git log` 的输出传递给外部的 `grep` 命令，这样可以利用 `grep` 的强大搜索能力。例如：

   ```shell
   git log -p | grep '搜索关键字'
   ```

   如果您想要更具体的信息，比如显示匹配到关键字的提交哈希，可以通过添加额外的参数来实现。例如：

   ```shell
   git log -p | grep -B 4 '搜索关键字'
   ```

   这里 `-B 4` 表示除了显示匹配行之外，还会显示匹配行之前的四行，这通常包括了提交信息。

4. **使用 `git log -G` 进行正则表达式搜索：**

   如果要进行更复杂的搜索，可以使用 `-G` 参数，后面跟上正则表达式：

   ```shell
   git log -p -G'regex'
   ```

5. **限定搜索的文件范围：**

   如果您只对特定类型的文件或特定的文件路径进行搜索，可以在 `git grep` 命令中指定文件路径或模式。例如，只搜索所有 `.c` 文件：

   ```shell
   git grep '搜索关键字' -- '*.c'
   ```

6. **搜索特定分支或标签中的内容：**

   如果您想搜索特定分支或标签中的内容，可以在 `git grep` 命令中指定分支或标签名。例如，在名为“feature-branch”的分支中搜索：

   ```shell
   git grep '搜索关键字' feature-branch
   ```

通过以上步骤，您可以灵活地搜索 Git 历史中的代码。记得替换 `'搜索关键字'` 和 `'regex'` 为您实际想要搜索的内容。

要搜索提交_内容_（即实际的源代码行，而不是提交消息等），您需要执行以下操作：

 git grep <regexp> $(git rev-list --all)
 

`git rev-list --all | xargs git grep <expression>`如果您遇到“参数列表太长”错误，它将起作用。

如果您想将搜索限制在某个子树（例如“lib/util”），您需要将其传递给子`rev-list`命令，`grep`并且：

 git grep <regexp> $(git rev-list --all -- lib/util) -- lib/util
 

这将 grep 遍历您的所有提交文本`regexp`。

在两个命令中传递路径的原因是因为`rev-list`将返回发生所有更改的修订列表`lib/util`，但您还需要传递 to`grep`以便它只在`lib/util`.

想象一下以下场景：可能会在返回的同一修订版中包含的其他文件上`grep`找到相同的内容（即使该修订版上的该文件没有更改）。`<regexp>``rev-list`

以下是搜索来源的一些其他有用方法：

在工作树中搜索与正则表达式 regexp 匹配的文本：

 git grep <regexp>
 

在工作树中搜索与正则表达式 regexp1 或 regexp2 匹配的文本行：

 git grep -e <regexp1> [--or] -e <regexp2>
 

在工作树中搜索与正则表达式 regexp1 和 regexp2 匹配的文本行，仅报告文件路径：

 git grep -l -e <regexp1> --and -e <regexp2>
 

在工作树中搜索具有与正则表达式 regexp1 匹配的文本行和与正则表达式 regexp2 匹配的文本行的文件：

 git grep -l --all-match -e <regexp1> -e <regexp2>
 

在工作树中搜索已更改的文本匹配模式行：

 git diff --unified=0 | grep <pattern>
 

搜索所有修订版本以查找与正则表达式 regexp 匹配的文本：

 git grep <regexp> $(git rev-list --all)
 

搜索 rev1 和 rev2 之间的所有修订版本以查找与正则表达式 regexp 匹配的文本：

 git grep <regexp> $(git rev-list <rev1>..<rev2>)

您应该使用 的[pickaxe ( `-S`)](https://git-scm.com/docs/git-log#Documentation/git-log.txt--Sltstringgt)选项[`git log`](http://git-scm.com/docs/git-log)。

要搜索`Foo`：

 git log -SFoo -- path_containing_change
 git log -SFoo --since=2009.1.1 --until=2010.1.1 -- path_containing_change
 

有关更多信息，请参阅[Git 历史记录 - 按关键字查找丢失的行。](https://stackoverflow.com/questions/2839253/git-history-find-lost-line-by-keyword/2839319#2839319)

`-S`（名为`pickaxe`）最初来自一个[`git diff`选项](https://github.com/git/git/commit/52e9578985fb636ec1d3f6cf794fdadd5ec896fc)（Git v0.99，2005 年 5 月）。然后`-S`( `pickaxe`)于 2006 年 5 月用 Git 1.4.0-rc1[移植到。`git log`](https://github.com/git/git/commit/582af688157607f05447cefce8d91b26eeaee39d)

* * *

正如[雅库布·纳伦布斯基 (Jakub Narębski)](https://stackoverflow.com/users/46058/jakub-narebski)评论的那样：

* 这**会查找引入或删除 实例的差异`<string>`**。它通常意味着“添加或删除带有‘Foo’的行的修订”。
 
* 该`--pickaxe-regex`选项允许您使用扩展的 POSIX 正则表达式而不是搜索字符串。示例（来自[`git log`](https://git-scm.com/docs/git-log#Documentation/git-log.txt--Gltregexgt)）：`git log -S"frotz\(nitfol" --pickaxe-regex`
 

* * *

正如[Rob](https://stackoverflow.com/users/601626/rob)评论的那样，此搜索区分大小写 - 他提出了有关如何搜索不区分大小写的[后续问题。](https://stackoverflow.com/questions/25384842/case-insensitive-git-pickaxe-search)

* * *

[嗨天使在](https://stackoverflow.com/users/2388257/hi-angel)[评论](https://stackoverflow.com/questions/2928584/how-to-grep-search-committed-code-in-the-git-history/2928721#comment131608633_2928721)中指出：

> 执行 a `git log -G<regexp> --branches --all`（与正则表达式`-G`相同）与[接受的执行](https://stackoverflow.com/a/2929502/6309)( ) 执行相同的操作，但速度快得多！`-S`[](https://stackoverflow.com/a/2929502/6309)`git grep <regexp> $(git rev-list --all)`
> 
> 接受的答案在我运行约 10 分钟后仍在搜索文本，而这个答案在约 4 秒后给出结果🤷‍♂️。这里的输出也更有用

我最喜欢的方法是使用`git log`'s`-G`选项（在版本 1.7.4 中添加）。

 -G<regex>
 Look for differences whose added or removed line matches the given <regex>.
 

`-G`和`-S`选项确定提交是否匹配的方式之间存在细微差别：

* 该`-S`选项本质上是计算提交之前和之后您的搜索在文件中匹配的次数。如果之前和之后的计数不同，则提交会显示在日志中。例如，这不会显示与您的搜索匹配的行被移动的提交。
* 使用该`-G`选项，如果您的搜索与添加、删除或更改的任何行匹配，则提交将显示在日志中。

以这次提交为例：

 diff --git a/test b/test
 index dddc242..60a8ba6 100644
 --- a/test
 +++ b/test
 @@ -1 +1 @@
 -hello hello
 +hello goodbye hello
 

因为在这次提交之前和之后文件中出现“hello”的次数是相同的，所以使用`-Shello`. 但是，由于匹配的行发生了更改`hello`，因此将使用 来显示提交`-Ghello`。

`git log`可以是跨所有分支搜索文本的更有效方法，特别是如果有很多匹配项，并且您希望首先查看更新的（相关）更改。

    git log -p --all -S 'search string'
    git log -p --all -G 'match regular expression'
    

这些日志命令列出添加或删除给定搜索字符串/正则表达式的提交，（通常）首先是最近的。该`-p`选项会导致在添加或删除模式的位置显示相关差异，以便您可以在上下文中查看它。

找到添加您要查找的文本的相关提交（例如 8beeff00d）后，找到包含该提交的分支：

    git branch -a --contains 8beeff00d

如果您想浏览代码更改（查看整个历史记录中给定单词实际更改的内容），请选择`patch`模式 - 我发现了一个非常有用的组合：

    git log -p
    # Hit '/' for search mode.
    # Type in the word you are searching.
    # If the first search is not relevant, hit 'n' for next (like in Vim ;) )

Git 的代码历史中搜索特定的关键词或模式时，可以使用 `git grep` 配合 `git log` 的一些参数来实现。以下是实现这个目的的一个基本步骤： 

1. **使用 `git grep` 搜索工作目录中的内容：**

   若您只是想搜索当前工作目录中的文件，可以直接使用 `git grep` 命令。例如：

   ```shell
   git grep '搜索关键字'
   ```
2. **搜索历史提交中的内容：**

   如果您想搜索历史提交中的内容，可以使用 `git log` 的 `-p` 参数和 `grep` 命令组合起来。例如，搜索历史提交中包含“搜索关键字”的内容：

   ```shell
   git log -p -S'搜索关键字'
   ```

   这里的 `-p` 参数会显示每个提交的差异（即代码更改），而 `-S` 参数用于指定要搜索的字符串。`-S` 会查找添加或删除了指定字符串的那些提交。
3. **结合使用 `git log` 和外部的 `grep` 命令：**

   您也可以通过管道将 `git log` 的输出传递给外部的 `grep` 命令，这样可以利用 `grep` 的强大搜索能力。例如：

   ```shell
   git log -p | grep '搜索关键字'
   ```

   如果您想要更具体的信息，比如显示匹配到关键字的提交哈希，可以通过添加额外的参数来实现。例如：

   ```shell
   git log -p | grep -B 4 '搜索关键字'
   ```

   这里 `-B 4` 表示除了显示匹配行之外，还会显示匹配行之前的四行，这通常包括了提交信息。
4. **使用 `git log -G` 进行正则表达式搜索：**

   如果要进行更复杂的搜索，可以使用 `-G` 参数，后面跟上正则表达式：

   ```shell
   git log -p -G'regex'
   ```
5. **限定搜索的文件范围：**

   如果您只对特定类型的文件或特定的文件路径进行搜索，可以在 `git grep` 命令中指定文件路径或模式。例如，只搜索所有 `.c` 文件：

   ```shell
   git grep '搜索关键字' -- '*.c'
   ```
6. **搜索特定分支或标签中的内容：**

   如果您想搜索特定分支或标签中的内容，可以在 `git grep` 命令中指定分支或标签名。例如，在名为“feature-branch”的分支中搜索：

   ```shell
   git grep '搜索关键字' feature-branch
   ```

通过以上步骤，您可以灵活地搜索 Git 历史中的代码。记得替换 `'搜索关键字'` 和 `'regex'` 为您实际想要搜索的内容。

How to grep search through committed code in the git history

在Git中，我们可以通过在命令行使用`git log`命令的不同参数来打印一个漂亮的分支图。这里有几种方法：

### 基本分支图

最简单的分支图可以使用如下命令生成：

```sh
git log --graph --oneline --all
```

- `--graph` 参数会显示ASCII图形表示的分支图。
- `--oneline` 参数将每个提交放在一行显示，这样的输出更为紧凑。
- `--all` 参数显示所有的分支，而不只是当前分支。

### 带有更多信息的分支图

如果你希望在分支图中显示更多信息，比如提交者的名字和提交的日期，可以使用：

```sh
git log --graph --oneline --all --decorate
```

- `--decorate` 参数会添加指向分支名、标签等的指针。

### 定制化的分支图

你还可以使用`--pretty=format:`来定制输出格式。例如：

```sh
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --all
```

- 格式字符串可以定制颜色、提交哈希、分支名、提交信息、提交日期和作者等信息的显示方式。
- `%Cred`, `%Creset`, `%C(yellow)`, 等命令用于定制颜色。
- `%h` 显示缩略的提交哈希。
- `%d` 显示装饰器（分支名、标签）。
- `%s` 显示提交信息。
- `%cr` 显示相对时间（比如，“3 days ago”）。
- `%an` 显示作者名字。
- `--abbrev-commit` 缩短哈希长度。

### 使用别名

因为这些命令可能会变得很长，所以你可能想要在Git中为它们设置别名。例如，设置一个叫做`graph`的别名：

```sh
git config --global alias.graph "log --graph --oneline --all --decorate"
```

这样，以后你就可以简单地使用`git graph`来打印漂亮的分支图了。

### 示例

下面是一个直观的例子，展示了当你在具有几个分支的仓库中使用命令`git log --graph --oneline --all --decorate`时，可能会得到的输出：

```sh
* e2a6f7b (HEAD -> master, origin/master, origin/HEAD) Merge pull request #2 from feature/xyz
|\ 
| * 4e5c111 (feature/xyz) Added XYZ feature
| * 5f4e3d2 Improved XYZ feature
* | 9c0f3f9 Modified README
|/ 
* c1f2e9e Initial commit
```

这是一个简单的树形结构，它将显示提交的顺序和分支之间的关系。每个`*`和`|`字符构成ASCII艺术，代表提交和分支。最左边的线表示当前分支的直接历史，而右边的线则代表其他分支的提交。

_更新：我已经针对_[Git](https://stackoverflow.com/questions/1838873/visualizing-branch-topology-in-git/34467298#34467298)_问题中的可视化分支拓扑发布了此答案的改进版本，因为它在那里更合适。出于历史（和代表，我承认）原因留下这个答案，尽管我真的很想删除它。_

**我的两分钱**：我通常在`~/.gitconfig`文件中放入两个别名：

    [alias]
    lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(auto)%d%C(reset)' --all
    lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(auto)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'
    lg = lg1
    

`git lg`/`git lg1`看起来像这样： ![git lg1](https://i.stack.imgur.com/K6RFN.png)

看起来`git lg2`像这样： ![git LG2](https://i.stack.imgur.com/39dMf.png)

* * *

（注意：这个问题现在有更多适用的答案，例如[fracz](https://stackoverflow.com/questions/1057564/pretty-git-branch-graphs/9074343#24107223)、[Jubos](https://stackoverflow.com/questions/1057564/pretty-git-branch-graphs/9074343#25468472)或[Harry Lee](https://stackoverflow.com/questions/1057564/pretty-git-branch-graphs/9074343#21116867)！）

这里的许多答案都很好，但对于那些只想要一个简单的一行到点答案而无需设置别名或任何额外内容的人来说，这里是：

    git log --all --decorate --oneline --graph
    

不是每个人都会`git log`一直这样做，但是当你需要它时，请记住：

> “**一只狗**” = git log -- **a** ll -- **d** ecorate -- **o** neline -- **graph**

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

如果您输入

    git config --global alias.adog "log --all --decorate --oneline --graph"
    

在命令提示符下一次，您可以使用

    git adog
    

即使您关闭并重新打开它，也不会出现该提示。

对于文本输出，您可以尝试：

```
git log --graph --abbrev-commit --decorate --date=relative --all
```

或者：

```
git log --graph --oneline --decorate --all
```

或者：[这是](https://git.wiki.kernel.org/index.php/Aliases#Use_graphviz_for_display)用于绘制[DAG图的](https://en.wikipedia.org/wiki/Directed_acyclic_graph)[Graphviz](https://en.wikipedia.org/wiki/Graphviz)别名。[](https://en.wikipedia.org/wiki/Directed_acyclic_graph)

[Gitgraph.js](https://github.com/nicoespeon/gitgraph.js/)允许在没有存储库的情况下绘制漂亮的 Git 分支。只需编写一段 JavaScript 代码来配置您的分支并提交并在浏览器中呈现它。提供[交互式文档。](https://www.nicoespeon.com/gitgraph.js)

    var gitGraph = new GitGraph({
       template: "blackarrow",
       mode: "compact",
       orientation: "horizontal",
       reverseArrow: true
    });
    
    var master = gitGraph.branch("master").commit().commit();
    var develop = gitGraph.branch("develop").commit();
    master.commit();
    develop.commit().commit();
    develop.merge(master);
    

![使用 Gitgraph.js 生成的示例图](https://i.stack.imgur.com/OLmxz.png)

或者使用`metro`模板：

![GitGraph.js 地铁主题](https://i.stack.imgur.com/eE8dd.png)

或者使用提交消息、作者和标签：

![带有提交消息的 GitGraph](https://i.stack.imgur.com/k5Gdu.png)

[使用JSFiddle](http://jsfiddle.net/fracz/q76vj8ow/)进行测试。

[使用 @bsara 的Git Grapher](http://bsara.github.io/git-grapher/)生成它。

[构建在TikZ 和 PGF](http://www.ctan.org/pkg/pgf)之上，[`gitdags`](https://github.com/Jubobs/gitdags)是一个小型 LaTeX 软件包，可让您轻松生成矢量图形提交图等。

自动生成现有存储库的提交图_不是_目的[`gitdags`](https://github.com/Jubobs/gitdags)；它生成的图表仅用于_教育目的_。

我经常使用它来生成 Git 问题答案的图表，作为 ASCII 提交图的替代方案：

* [如何在 master 上进行错误修复并将其集成到我不太稳定的分支中？](https://stackoverflow.com/questions/25933056/how-can-i-do-a-bugfix-on-master-and-integrate-it-into-my-less-stable-branches/25934341#25934341)
* [git commit --amend 到底是如何工作的？](https://stackoverflow.com/questions/26050327/how-does-git-commit-amend-work-exactly/26050416#26050416)
* [为什么在我运行“git checkout origin/<branch>”后，Git 告诉我“当前不在任何分支上”？](https://stackoverflow.com/questions/25670173/why-does-git-tell-me-not-currently-on-any-branch-after-i-run-git-checkout-ori/25670296#25670296)
* [将master合并到分支和将分支合并到master有什么区别？](https://stackoverflow.com/questions/26384166/what-is-the-difference-between-merging-master-into-branch-and-merging-branch-int/26384695#26384695)
* [Git rebase --preserve-merges 失败](https://stackoverflow.com/questions/25670519/git-rebase-preserve-merges-fails/25671230#25671230)

下面是一个此类图表的示例，展示了简单变基的效果：

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

 \documentclass{article}
 
 \usepackage{subcaption}
 \usepackage{gitdags}
 
 \begin{document}
 
 \begin{figure}
 \begin{subfigure}[b]{\textwidth}
 \centering
 \begin{tikzpicture}
 % Commit DAG
 \gitDAG[grow right sep = 2em]{
 A -- B -- { 
 C,
 D -- E,
 }
 };
 % Tag reference
 \gittag
 [v0p1] % node name
 {v0.1} % node text
 {above=of A} % node placement
 {A} % target
 % Remote branch
 \gitremotebranch
 [origmaster] % node name
 {origin/master} % node text
 {above=of C} % node placement
 {C} % target
 % Branch
 \gitbranch
 {master} % node name and text 
 {above=of E} % node placement
 {E} % target
 % HEAD reference
 \gitHEAD
 {above=of master} % node placement
 {master} % target
 \end{tikzpicture}
 \subcaption{Before\ldots}
 \end{subfigure}
 
 \begin{subfigure}[b]{\textwidth}
 \centering
 \begin{tikzpicture}
 \gitDAG[grow right sep = 2em]{
 A -- B -- { 
 C -- D' -- E',
 {[nodes=unreachable] D -- E },
 }
 };
 % Tag reference
 \gittag
 [v0p1] % node name
 {v0.1} % node text
 {above=of A} % node placement
 {A} % target
 % Remote branch
 \gitremotebranch
 [origmaster] % node name
 {origin/master} % node text
 {above=of C} % node placement
 {C} % target
 % Branch
 \gitbranch
 {master} % node name and text 
 {above=of E'} % node placement
 {E'} % target
 % HEAD reference
 \gitHEAD
 {above=of master} % node placement
 {master} % target
 \end{tikzpicture}
 \subcaption{\ldots{} and after \texttt{git rebase origin/master}}
 \end{subfigure}
 \caption{Demonstrating a typical \texttt{rebase}}
 \end{figure}
 
 \end{document}

How to output pretty git branch graphs?

如果在使用`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`使得一切都和以前一样。

How do i undo git reset?

如果提交发生在过去 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` > 与最后第三次修订进行比较

How can i view an old version of a file with 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`也许可以通过添加等一步完成。

How do i commit case sensitive only filename changes in 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)

How can i git stash a specific file?

`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`.
*   但“变基然后合并”可以是一个有效的工作流程，首先单独解决冲突，然后恢复工作。

When do you use git rebase instead of 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相关问题