比较 Git 中四种切换分支的方法的优缺点。

所有大量使用 Git 的人都会用到某种形式的上下文切换。有时这只会给你的工作流程增加少量的开销，但有时，这可能是一段痛苦的经历。

让我们用以下这个例子来讨论一些常见的上下文切换策略的优缺点：

假设你在一个名为 feature-X 的分支中工作。你刚刚发现你需要解决一个无关的问题。这不能在 feature-X 分支中完成。你需要在一个新的分支 feature-Y 中完成这项工作。

方案 1：暂存 + 分支

解决此问题最常见的工作流程可能如下所示：

1. 停止分支 feature-X 上的工作
2. git stash
3. git checkout -b feature-Y origin/main
4. 一顿鼓捣，解决 feature-Y 的问题
5. git checkout feature-X 或 git switch -
6. git stash pop
7. 继续在 feature-X 中工作

优点： 这种方法的优点在于，对于简单的更改，这是一个相当简单的工作流程。它可以很好地工作，特别是对于小型仓库。

缺点： 使用此工作流程时，一次只能有一个工作区。另外，根据你的仓库的状态，使用暂存是一个麻烦的环节。

方案 2：WIP 提交 + 分支

这个解决方案和前一个非常相似，但是它使用 WIP（ 正在进行的工作 Work in Progress ）提交而不是暂存。当你准备好切换回来，而不是弹出暂存时，git reset HEAD~1 会展开 WIP 提交，你可以自由地继续，就像之前的方案一样，但不会触及暂存。

1. 停止分支 feature-X 上的工作
2. git add -u（仅仅添加修改和删除的文件）
3. git commit -m "WIP"
4. git checkout -b feature-Y origin/master
5. 一顿鼓捣，解决 feature-Y 的问题
6. git checkout feature-X 或 git switch -
7. git reset HEAD~1

优点： 对于简单的更改，这是一个简单的工作流，也适合于小型仓库。你不需要使用暂存。

缺点： 任何时候都只能有一个工作区。此外，如果你或你的代码审阅者不够谨慎，WIP 提交可能会合并到最终产品。

使用此工作流时，你永远不要想着将 --hard 添加到 git reset。如果你不小心这样做了，你应该能够使用 git reflog 恢复提交，但是你最好完全避免这种情况发生，否则你会听到心碎的声音。

方案 3：克隆一个新仓库

在这个解决方案中，不是创建新的分支，而是为每个新的功能分支创建存储库的新克隆。

优点： 你可以同时在多个工作区中工作。你不需要 git stash 或者是 WIP 提交。

缺点： 需要考虑仓库的大小，因为这可能会占用大量磁盘空间（浅层克隆可以帮助解决这种情况，但它们可能并不总是很合适。）此外，你的仓库克隆将互不可知。因为他们不能互相追踪，所以你必须手动追踪你的克隆的源仓库。如果需要 git 钩子，则需要为每个新克隆设置它们。

方案 4：git 工作树

要使用此解决方案，你可能需要了解 git add worktree。如果你不熟悉 Git 中的工作树，请不要难过。许多人多年来都对这个概念一无所知。

什么是工作树？

将工作树视为仓库中属于项目的文件。本质上，这是一种工作区。你可能没有意识到你已经在使用工作树了。开始使用 Git 时，你将自动获得第一个工作树。

$ mkdir /tmp/foo && cd /tmp/foo
$ git init
$ git worktree list
/tmp  0000000 [master]

你可以在以上代码看到，甚至在第一次提交前你就有了一个工作树。接下来去尝试再添加一个工作树到你的项目中吧。

添加一个工作树

想要添加一个新的工作树你需要提供:

1. 硬盘上的一个位置
2. 一个分支名
3. 添加哪些分支

$ git clone https://github.com/oalders/http-browserdetect.git
$ cd http-browserdetect/
$ git worktree list
/Users/olaf/http-browserdetect  90772ae [master]

$ git worktree add ~/trees/oalders/feature-X -b oalders/feature-X origin/master
$ git worktree add ~/trees/oalders/feature-Y -b oalders/feature-Y e9df3c555e96b3f1

$ git worktree list
/Users/olaf/http-browserdetect       90772ae [master]
/Users/olaf/trees/oalders/feature-X  90772ae [oalders/feature-X]
/Users/olaf/trees/oalders/feature-Y  e9df3c5 [oalders/feature-Y]

与大多数其他 Git 命令一样，你需要在仓库路径下使用此命令。一旦创建了工作树，就有了隔离的工作环境。Git 仓库会跟踪工作树在磁盘上的位置。如果 Git 钩子已经在父仓库中设置好了，那么它们也可以在工作树中使用。

请注意到，每个工作树只使用父仓库磁盘空间的一小部分。在这种情况下，工作树需要只大约三分之一的原始磁盘空间。这这非常适合进行扩展。如果你的仓库达到了千兆字节的级别，你就会真正体会到工作树对硬盘空间的节省。

$ du -sh /Users/olaf/http-browserdetect
2.9M

$ du -sh /Users/olaf/trees/oalders/feature-X
1.0M

优点： 你可以同时在多个工作区中工作。你不需要使用暂存。Git 会跟踪所有的工作树。你不需要设置 Git 钩子。这也比 git clone 更快，并且可以节省网络流量，因为你可以在飞行模式下执行此操作。你还可以更高效地使用磁盘空间，而无需借助于浅层克隆。

缺点： 这是个需要你额外学习和记忆的新东西，但是如果你能养成使用这个功能的习惯，它会给你丰厚的回报。

额外的小技巧

有很多方式可以清除工作树，最受欢迎的方式是使用 Git 来移除工作树：

git worktree remove /Users/olaf/trees/oalders/feature-X

如果你喜欢 RM 大法，你也可以用 rm -rf 来删除工作树。

rm -rf /Users/olaf/trees/oalders/feature-X

但是，如果执行此操作，则可能需要使用 git worktree prune 清理所有剩余的文件。或者你现在可以跳过清理，这将在将来的某个时候通过 git gc 自行完成。

注意事项

如果你准备尝试 git worktree，请记住以下几点：

• 删除工作树并不会删除该分支。
• 可以在工作树中切换分支。
• 你不能在多个工作树中同时签出同一个分支。
• 像其他命令一样，git worktree 需要从仓库内运行。
• 你可以同时拥有许多工作树。
• 要从同一个本地仓库签出创建工作树，否则它们将互不可知。

git rev-parse

最后一点注意：在使用 git worktree 时，仓库根所在的位置可能取决于上下文。幸运的是，git rev parse 可以让你区分这两者。

• 要查找父仓库的根目录，请执行以下操作：

git rev-parse --git-common-dir

• 要查找你当前所在仓库的根目录，请执行：

git rev-parse --show-toplevel

根据你的需要选择最好的方法

就像很多事情一样，TIMTOWDI（ 条条大道通罗马 there's more than one way to do it ）。重要的是你要找到一个适合你需要的工作流程。你的需求可能因手头的问题而异。也许你偶尔会发现自己将 git worktree 作为版本控制工具箱中的一个方便工具。

via: https://opensource.com/article/21/4/context-switching-git

作者：Olaf Alders 选题：lujun9972 译者：Chao-zhi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这是我怎样设置 Git 来管理我的家目录的方法。

我有好几台电脑。一台笔记本电脑用于工作，一台工作站放在家里，一台树莓派（或四台），一台 Pocket CHIP，一台 运行各种不同的 Linux 的 Chromebook，等等。我曾经在每台计算机上或多或少地按照相同的步骤设置我的用户环境，也经常告诉自己让每台计算机都略有不同。例如，我在工作中比在家里更经常使用 Bash 别名，并且我在家里使用的辅助脚本可能对工作没有用。

这些年来，我对各种设备的期望开始相融，我会忘记我在家用计算机上建立的功能没有移植到我的工作计算机上，诸如此类。我需要一种标准化我的自定义工具包的方法。使我感到意外的答案是 Git。

Git 是版本跟踪软件。它以既可以用在非常大的开源项目也可以用在极小的开源项目而闻名，甚至最大的专有软件公司也在用它。但是它是为源代码设计的，而不是用在一个装满音乐和视频文件、游戏、照片等的家目录。我听说过有人使用 Git 管理其家目录，但我认为这是程序员们进行的一项附带实验，而不是像我这样的现实生活中的用户。

用 Git 管理我的家目录是一个不断发展的过程。随着时间的推移我一直在学习和适应。如果你决定使用 Git 管理家目录，则可能需要记住以下几点。

1、文本和二进制位置

当由 Git 管理时，除了配置文件之外，你的家目录对于所有内容而言都是“无人之地”。这意味着当你打开主目录时，除了可预见的目录的列表之外，你什么都看不到。不应有任何杂乱无章的照片或 LibreOffice 文档，也不应有 “我就在这里放一分钟” 的临时文件。

原因很简单：使用 Git 管理家目录时，家目录中所有 未 提交的内容都会变成噪音。每次执行 git status 时，你都必须翻过去之前 Git 未跟踪的任何文件，因此将这些文件保存在子目录（添加到 .gitignore 文件中）至关重要。

许多 Linux 发行版提供了一组默认目录：

• Documents
• Downloads
• Music
• Photos
• Templates
• Videos

如果需要，你可以创建更多。例如，我把创作的音乐（Music）和购买来聆听的音乐（Albums）区分开来。同样，我的电影（Cinema）目录包含了其他人的电影，而视频（Videos）目录包含我需要编辑的视频文件。换句话说，我的默认目录结构比大多数 Linux 发行版提供的默认设置更详细，但是我认为这样做有好处。如果没有适合你的目录结构，你更会将其存放在家目录中，因为没有更好的存放位置，因此请提前考虑并规划好适合你的工作目录。你以后总是可以添加更多，但是最好先开始擅长的。

2、、设置最优的 .gitignore

清理家目录后，你可以像往常一样将其作为 Git 存储库实例化：

$ cd
$ git init .

你的 Git 仓库中还没有任何内容，你的家目录中的所有内容均未被跟踪。你的第一项工作是筛选未跟踪文件的列表，并确定要保持未跟踪状态的文件。要查看未跟踪的文件：

$ git status
  .AndroidStudio3.2/
  .FBReader/
  .ICEauthority
  .Xauthority
  .Xdefaults
  .android/
  .arduino15/
  .ash_history
[...]

根据你使用家目录的时间长短，此列表可能很长。简单的是你在上一步中确定的目录。通过将它们添加到名为 .gitignore 的隐藏文件中，你告诉 Git 停止将它们列为未跟踪文件，并且永远不对其进行跟踪：

$ \ls -lg | grep ^d | awk '{print $8}' >> ~/.gitignore

完成后，浏览 git status 所示的其余未跟踪文件，并确定是否有其他文件需要排除。这个过程帮助我发现了几个陈旧的配置文件和目录，这些文件和目录最终被我全部丢弃了，而且还发现了一些特定于一台计算机的文件和目录。我在这里非常严格，因为许多配置文件在自动生成时会表现得更好。例如，我从不提交我的 KDE 配置文件，因为许多文件包含了诸如最新文档之类的信息以及其他机器上不存在的其他元素。

我会跟踪我的个性化配置文件、脚本和实用程序、配置文件和 Bash 配置，以及速查表和我经常引用的其他文本片段。如果有软件主要负责维护的文件，则将其忽略。当对一个文件不确定时，我将其忽略。你以后总是可以取消忽略它（通过从 .gitignore 文件中删除它）。

3、了解你的数据

我使用的是 KDE，因此我使用开源扫描程序 Filelight 来了解我的数据概况。Filelight 为你提供了一个图表，可让你查看每个目录的大小。你可以浏览每个目录以查看占用了空间的内容，然后回溯调查其他地方。这是一个令人着迷的系统视图，它使你可以以全新的方式看待你的文件。

使用 Filelight 或类似的实用程序查找不需要提交的意外数据缓存。例如，KDE 文件索引器（Baloo）生成了大量特定于其主机的数据，我绝对不希望将其传输到另一台计算机。

4、不要忽略你的 .gitignore 文件

在某些项目中，我告诉 Git 忽略我的 .gitignore 文件，因为有时我要忽略的内容特定于我的工作目录，并且我不认为同一项目中的其他开发人员需要我告诉他们 .gitignore 文件应该是什么样子。因为我的家目录仅供我使用，所以我 不 会忽略我的家目录的 .gitignore 文件。我将其与其他重要文件一起提交，因此它已在我的所有系统中被继承。当然，从家目录的角度来看，我所有的系统都是相同的：它们具有一组相同的默认文件夹和许多相同的隐藏配置文件。

5、不要担心二进制文件

我对我的系统进行了数周的严格测试，确信将二进制文件提交到 Git 绝对不是明智之举。我试过 GPG 加密的密码文件、试过 LibreOffice 文档、JPEG、PNG 等等。我甚至有一个脚本，可以在将 LibreOffice 文件添加到 Git 之前先解压缩，提取其中的 XML，以便仅提交 XML，然后重新构建 LibreOffice 文件，以便可以在 LibreOffice 中继续工作。我的理论是，提交 XML 会比使用 ZIP 文件（LibreOffice 文档实际上就是一个 ZIP 文件）会让 Git 存储库更小一些。

令我惊讶的是，我发现偶尔提交一些二进制文件并没有大幅增加我的 Git 存储库的大小。我使用 Git 已经很长时间了，我知道如果我要提交几千兆的二进制数据，我的存储库将会受到影响，但是偶尔提交几个二进制文件也不是不惜一切代价要避免的紧急情况。

有了这种信心，我将字体 OTF 和 TTF 文件添加到我的标准主存储库，以及 GDM 的 .face 文件以及其他偶尔小型二进制 Blob 文件。不要想太多，不要浪费时间去避免它。只需提交即可。

6、使用私有存储库

即使托管方提供了私人帐户，也不要将你的主目录提交到公共 Git 存储库。如果你像我一样，拥有 SSH 密钥、GPG 密钥链和 GPG 加密的文件，这些文件不应该出现在任何人的服务器上，而应该出现在我自己的服务器上。

我在树莓派上 运行本地 Git 服务器（这比你想象的要容易），因此我可以在家里时随时更新任何一台计算机。我是一名远程工作者，所以通常情况下就足够了，但是我也可以在旅行时通过 虚拟私人网络 访问我的计算机。

7、要记得推送

Git 的特点是，只有当你告诉它要推送改动时，它才会把改动推送到你的服务器上。如果你是 Git 的老用户，则此过程可能对你很自然。对于可能习惯于 Nextcloud 或 Syncthing 自动同步的新用户，这可能需要一些时间来适应。

Git 家目录

使用 Git 管理我的常用文件，不仅使我在不同设备上的生活更加便利。我知道我拥有所有配置和实用程序脚本的完整历史记录，这会鼓励我尝试新的想法，因为如果结果变得 很糟糕，则很容易回滚我的更改。Git 曾将我从在 .bashrc 文件中一个欠考虑的 umask 设置中解救出来、从深夜对包管理脚本的拙劣添加中解救出来、从当时看似很酷的 rxvt 配色方案的修改中解救出来，也许还有其他一些错误。在家目录中尝试 Git 吧，因为这些提交会让家目录融合在一起。

via: https://opensource.com/article/21/4/git-home

作者：Seth Kenlon 选题：lujun9972 译者：stevenzdg988 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

“遴选”可以解决 Git 仓库中的很多问题。以下是用 git cherry-pick 修复错误的三种方法。

在版本控制系统中摸索前进是一件很棘手的事情。对于一个新手来说，这可能是非常难以应付的，但熟悉版本控制系统（如 Git）的术语和基础知识是开始为开源贡献的第一步。

熟悉 Git 也能帮助你在开源之路上走出困境。Git 功能强大，让你感觉自己在掌控之中 —— 没有哪一种方法会让你无法恢复到工作版本。

这里有一个例子可以帮助你理解“ 遴选 cherry-pick ”的重要性。假设你已经在一个分支上做了好几个提交，但你意识到这是个错误的分支！你现在该怎么办？你现在要做什么？要么在正确的分支上重复所有的变更，然后重新提交，要么把这个分支合并到正确的分支上。等一下，前者太过繁琐，而你可能不想做后者。那么，还有没有办法呢？有的，Git 已经为你准备好了。这就是“遴选”的作用。顾名思义，你可以用它从一个分支中手工遴选一个提交，然后转移到另一个分支。

使用遴选的原因有很多。以下是其中的三个原因。

避免重复性工作

如果你可以直接将相同的提交复制到另一个分支，就没有必要在不同的分支中重做相同的变更。请注意，遴选出来的提交会在另一个分支中创建带有新哈希的新提交，所以如果你看到不同的提交哈希，请不要感到困惑。

如果您想知道什么是提交的哈希，以及它是如何生成的，这里有一个说明可以帮助你。提交哈希是用 SHA-1 算法生成的字符串。SHA-1 算法接收一个输入，然后输出一个唯一的 40 个字符的哈希值。如果你使用的是 POSIX 系统，请尝试在您的终端上运行这个命令：

$ echo -n "commit" | openssl sha1

这将输出一个唯一的 40 个字符的哈希值 4015b57a143aec5156fd1444a017a32137a3fd0f。这个哈希代表了字符串 commit。

Git 在提交时生成的 SHA-1 哈希值不仅仅代表一个字符串。它代表的是：

sha1(
    meta data
        commit message
        committer
        commit date
        author
        authoring date
    Hash of the entire tree object
)

这就解释了为什么你对代码所做的任何细微改动都会得到一个独特的提交哈希值。哪怕是一个微小的改动都会被发现。这是因为 Git 具有完整性。

撤销/恢复丢失的更改

当你想恢复到工作版本时，遴选就很方便。当多个开发人员在同一个代码库上工作时，很可能会丢失更改，最新的版本会被转移到一个陈旧的或非工作版本上。这时，遴选提交到工作版本就可以成为救星。

它是如何工作的？

假设有两个分支：feature1 和 feature2，你想把 feature1 中的提交应用到 feature2。

在 feature1 分支上，运行 git log 命令，复制你想遴选的提交哈希值。你可以看到一系列类似于下面代码示例的提交。commit 后面的字母数字代码就是你需要复制的提交哈希。为了方便起见，您可以选择复制前六个字符（本例中为 966cf3）。

commit 966cf3d08b09a2da3f2f58c0818baa37184c9778 (HEAD -> master)
Author: manaswinidas <[email protected]>
Date:   Mon Mar 8 09:20:21 2021 +1300

   add instructions

然后切换到 feature2 分支，在刚刚从日志中得到的哈希值上运行 git cherry-pick：

$ git checkout feature2
$ git cherry-pick 966cf3.

如果该分支不存在，使用 git checkout -b feature2 来创建它。

这里有一个问题。你可能会遇到下面这种情况：

$ git cherry-pick 966cf3
On branch feature2
You are currently cherry-picking commit 966cf3d.

nothing to commit, working tree clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

   git commit --allow-empty

Otherwise, please use 'git reset'

不要惊慌。只要按照建议运行 git commit --allow-empty：

$ git commit --allow-empty
[feature2 afb6fcb] add instructions
Date: Mon Mar 8 09:20:21 2021 +1300

这将打开你的默认编辑器，允许你编辑提交信息。如果你没有什么要补充的，可以保存现有的信息。

就这样，你完成了你的第一次遴选。如上所述，如果你在分支 feature2 上运行 git log，你会看到一个不同的提交哈希。下面是一个例子：

commit afb6fcb87083c8f41089cad58deb97a5380cb2c2 (HEAD -> feature2)
Author: manaswinidas <[[email protected]][4]>
Date:   Mon Mar 8 09:20:21 2021 +1300
   add instructions

不要对不同的提交哈希感到困惑。这只是区分 feature1 和 feature2 的提交。

遴选多个提交

但如果你想遴选多个提交的内容呢？你可以使用：

git cherry-pick <commit-hash1> <commit-hash2>... <commit-hashn>

请注意，你不必使用整个提交的哈希值，你可以使用前五到六个字符。

同样，这也是很繁琐的。如果你想遴选的提交是一系列的连续提交呢？这种方法太费劲了。别担心，有一个更简单的方法。

假设你有两个分支：

• feature1 包括你想复制的提交（从更早的 commitA 到 commitB）。
• feature2 是你想把提交从 feature1 转移到的分支。

然后：

1. 输入 git checkout <feature1>。
2. 获取 commitA 和 commitB 的哈希值。
3. 输入 git checkout <branchB>。
4. 输入 git cherry-pick <commitA>^..<commitB> （请注意，这包括 commitA 和 commitB）。
5. 如果遇到合并冲突，像往常一样解决，然后输入 git cherry-pick --continue 恢复遴选过程。

重要的遴选选项

以下是 Git 文档 中的一些有用的选项，你可以在 cherry-pick 命令中使用。

• -e、--edit：用这个选项，git cherry-pick 可以让你在提交前编辑提交信息。
• -s、--signoff：在提交信息的结尾添加 Signed-off by 行。更多信息请参见 git-commit(1) 中的 signoff 选项。
• -S[<keyid>]、--pgg-sign[=<keyid>]：这些是 GPG 签名的提交。keyid 参数是可选的，默认为提交者身份；如果指定了，则必须嵌在选项中，不加空格。
• --ff：如果当前 HEAD 与遴选的提交的父级提交相同，则会对该提交进行快进操作。

下面是除了 --continue 外的一些其他的后继操作子命令：

• --quit：你可以忘记当前正在进行的操作。这可以用来清除遴选或撤销失败后的后继操作状态。
• --abort：取消操作并返回到操作序列前状态。

下面是一些关于遴选的例子：

• git cherry-pick master：应用 master 分支顶端的提交所引入的变更，并创建一个包含该变更的新提交。
• git cherry-pick master~4 master~2'：应用master` 指向的第五个和第三个最新提交所带来的变化，并根据这些变化创建两个新的提交。

感到不知所措？你不需要记住所有的命令。你可以随时在你的终端输入 git cherry-pick --help 查看更多选项或帮助。

via: https://opensource.com/article/21/3/git-cherry-pick

作者：Manaswini Das 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

获得自由尝试的权利，同时在你的实验出错时可以安全地拥有一个新的、链接的克隆存储库。

Git 的设计部分是为了进行实验。如果你知道你的工作会被安全地跟踪，并且在出现严重错误时有安全状态存在，你就不会害怕尝试新的想法。不过，创新的部分代价是，你很可能会在这个过程中弄得一团糟。文件会被重新命名、移动、删除、更改、切割成碎片；新的文件被引入；你不打算跟踪的临时文件会在你的工作目录中占据一席之地等等。

简而言之，你的工作空间变成了纸牌屋，在“快好了！”和“哦，不，我做了什么？”之间岌岌可危地平衡着。那么，当你需要把仓库恢复到下午的一个已知状态，以便完成一些真正的工作时，该怎么办？我立刻想到了 git branch 和 git stash 这两个经典命令，但这两个命令都不是用来处理未被跟踪的文件的，而且文件路径的改变和其他重大的转变也会让人困惑，它们只能把工作暂存（stash）起来以备后用。解决这个需求的答案是 Git 工作树。

什么是 Git 工作树

Git 工作树 worktree 是 Git 仓库的一个链接副本，允许你同时签出多个分支。工作树与主工作副本的路径是分开的，它可以处于不同的状态和不同的分支上。在 Git 中新建工作树的好处是，你可以在不干扰当前工作环境的情况下，做出与当前任务无关的修改、提交修改，然后在以后合并。

直接从 git-worktree 手册中找到了一个典型的例子：当你正在为一个项目做一个令人兴奋的新功能时，你的项目经理告诉你有一个紧急的修复工作。问题是你的工作仓库（你的“工作树”）处于混乱状态，因为你正在开发一个重要的新功能。你不想在当前的冲刺中“偷偷地”进行修复，而且你也不愿意把变更暂存起来，为修复创建一个新的分支。相反，你决定创建一个新的工作树，这样你就可以在那里进行修复：

$ git branch | tee
* dev
trunk
$ git worktree add -b hotfix ~/code/hotfix trunk
Preparing ../hotfix (identifier hotfix)
HEAD is now at 62a2daf commit

在你的 code 目录中，你现在有一个新的目录叫做 hotfix，它是一个与你的主项目仓库相连的 Git 工作树，它的 HEAD 停在叫做 trunk 的分支上。现在你可以把这个工作树当作你的主工作区来对待。你可以把目录切换到它里面，进行紧急修复、提交、并最终删除这个工作树：

$ cd ~/code/hotfix
$ sed -i 's/teh/the/' hello.txt
$ git commit --all --message 'urgent hot fix'

一旦你完成了你的紧急工作，你就可以回到你之前的任务。你可以控制你的热修复何时被集成到主项目中。例如，你可以直接将变更从其工作树推送到项目的远程存储库中：

$ git push origin HEAD
$ cd ~/code/myproject

或者你可以将工作树存档为 TAR 或 ZIP 文件：

$ cd ~/code/myproject
$ git archive --format tar --output hotfix.tar master

或者你可以从单独的工作树中获取本地的变化：

$ git worktree list
/home/seth/code/myproject  15fca84 [dev]
/home/seth/code/hotfix     09e585d [master]

从那里，你可以使用任何最适合你和你的团队的策略合并你的变化。

列出活动工作树

你可以使用 git worktree list 命令获得工作树的列表，并查看每个工作树签出的分支：

$ git worktree list
/home/seth/code/myproject  15fca84 [dev]
/home/seth/code/hotfix     09e585d [master]

你可以在任何一个工作树中使用这个功能。工作树始终是连接的（除非你手动移动它们，破坏 Git 定位工作树的能力，从而切断连接）。

移动工作树

Git 会跟踪项目 .git 目录下工作树的位置和状态：

$ cat ~/code/myproject/.git/worktrees/hotfix/gitdir
/home/seth/code/hotfix/.git

如果你需要重定位一个工作树，必须使用 git worktree move；否则，当 Git 试图更新工作树的状态时，就会失败：

$ mkdir ~/Temp
$ git worktree move hotfix ~/Temp
$ git worktree list
/home/seth/code/myproject  15fca84 [dev]
/home/seth/Temp/hotfix     09e585d [master]

移除工作树

当你完成你的工作时，你可以用 remove 子命令删除它：

$ git worktree remove hotfix
$ git worktree list
/home/seth/code/myproject  15fca84 [dev]

为了确保你的 .git 目录是干净的，在删除工作树后使用 prune 子命令：

$ git worktree remove prune

何时使用工作树

与许多选项一样，无论是标签还是书签还是自动备份，都要靠你来跟踪你产生的数据，否则可能会变得不堪重负。不要经常使用工作树，要不你最终会有 20 份存储库的副本，每份副本的状态都略有不同。我发现最好是创建一个工作树，做需要它的任务，提交工作，然后删除树。保持简单和专注。

重要的是，工作树为你管理 Git 存储库的方式提供了更好的灵活性。在需要的时候使用它们，再也不用为了检查另一个分支上的内容而争先恐后地保存工作状态了。

via: https://opensource.com/article/21/4/git-worktree

作者：Seth Kenlon 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

了解 git cherry-pick 命令是什么，为什么用以及如何使用。

当你和一群程序员一起工作时，无论项目大小，处理多个 Git 分支之间的变更都会变得很困难。有时，你不想将整个 Git 分支合并到另一个分支，而是想选择并移动几个特定的提交。这个过程被称为 “ 遴选 cherry-pick ”。

本文将介绍“遴选”是什么、为何使用以及如何使用。

那么让我们开始吧。

什么是遴选？

使用遴选（cherry-pick）命令，Git 可以让你将任何分支中的个别提交合并到你当前的 Git HEAD 分支中。

当执行 git merge 或者 git rebase 时，一个分支的所有提交都会被合并。cherry-pick 命令允许你选择单个提交进行整合。

遴选的好处

下面的情况可能会让你更容易理解遴选功能。

想象一下，你正在为即将到来的每周冲刺实现新功能。当你的代码准备好了，你会把它推送到远程分支，准备进行测试。

然而，客户并不是对所有修改都满意，要求你只呈现某些修改。因为客户还没有批准下次发布的所有修改，所以 git rebase 不会有预期的结果。为什么会这样？因为 git rebase 或者 git merge 会把上一个冲刺的每一个调整都纳入其中。

遴选就是答案！因为它只关注在提交中添加的变更，所以遴选只会带入批准的变更，而不添加其他的提交。

还有其他几个原因可以使用遴选：

• 这对于 bug 修复是必不可少的，因为 bug 是出现在开发分支中对应的提交的。
• 你可以通过使用 git cherry-pick 来避免不必要的工作，而不用使用其他选项例如 git diff 来应用特定变更。
• 如果因为不同 Git 分支的版本不兼容而无法将整个分支联合起来，那么它是一个很有用的工具。

使用 cherry-pick 命令

在 cherry-pick 命令的最简单形式中，你只需使用 SHA 标识符来表示你想整合到当前 HEAD 分支的提交。

要获得提交的哈希值，可以使用 git log 命令：

$ git log --oneline

当你知道了提交的哈希值后，你就可以使用 cherry-pick 命令。

语法是：

$ git cherry-pick <commit sha>

例如：

$ git cherry-pick 65be1e5

这将会把指定的修改合并到当前已签出的分支上。

如果你想做进一步的修改，也可以让 Git 将提交的变更内容添加到你的工作副本中。

语法是：

$ git cherry-pick <commit sha> --no-commit

例如：

$ git cherry-pick 65be1e5 --no-commit

如果你想同时选择多个提交，请将它们的提交哈希值用空格隔开：

$ git cherry-pick hash1 hash3

当遴选提交时，你不能使用 git pull 命令，因为它能获取一个仓库的提交并自动合并到另一个仓库。cherry-pick 是一个专门不这么做的工具；另一方面，你可以使用 git fetch，它可以获取提交，但不应用它们。毫无疑问，git pull 很方便，但它不精确。

自己尝试

要尝试这个过程，启动终端并生成一个示例项目：

$ mkdir fruit.git
$ cd fruit.git
$ git init .

创建一些数据并提交：

$ echo "Kiwifruit" > fruit.txt
$ git add fruit.txt
$ git commit -m 'First commit'

现在，通过创建一个项目的复刻来代表一个远程开发者：

$ mkdir ~/fruit.fork
$ cd !$
$ echo "Strawberry" >> fruit.txt
$ git add fruit.txt
$ git commit -m 'Added a fruit"

这是一个有效的提交。现在，创建一个不好的提交，代表你不想合并到你的项目中的东西：

$ echo "Rhubarb" >> fruit.txt
$ git add fruit.txt
$ git commit -m 'Added a vegetable that tastes like a fruit"

返回你的仓库，从你的假想的开发者那里获取提交的内容：

$ cd ~/fruit.git
$ git remote add dev ~/fruit.fork
$ git fetch dev
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done...

$ git log –oneline dev/master
e858ab2 Added a vegetable that tastes like a fruit
0664292 Added a fruit
b56e0f8 First commit

你已经从你想象中的开发者那里获取了提交的内容，但你还没有将它们合并到你的版本库中。你想接受第二个提交，但不想接受第三个提交，所以使用 cherry-pick。

$ git cherry-pick 0664292

第二次提交现在在你的仓库里了：

$ cat fruit.txt
Kiwifruit
Strawberry

将你的更改推送到远程服务器上，这就完成了！

避免使用遴选的原因

在开发者社区中，通常不鼓励所以遴选。主要原因是它会造成重复提交，而你也失去了跟踪你的提交历史的能力。

如果你不按顺序地遴选了大量的提交，这些提交会被记录在你的分支中，这可能会在 Git 分支中导致不理想的结果。

遴选是一个强大的命令，如果没有正确理解可能发生的情况，它可能会导致问题。不过，当你搞砸了，提交到错误的分支时，它可能会救你一命（至少是你当天的工作）。

via: https://opensource.com/article/21/4/cherry-picking-git

作者：Rajeev Bera 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

学习如何使用 git stash 命令，以及何时应该使用它。

版本控制是软件开发人员日常生活中不可分割的一部分。很难想象有哪个团队在开发软件时不使用版本控制工具。同样也很难想象有哪个开发者没有使用过（或没有听说过）Git。在 2018 年 Stackoverflow 开发者调查中，74298 名参与者中有 87.2% 的人 使用 Git 进行版本控制。

Linus Torvalds 在 2005 年创建了 Git 用于开发 Linux 内核。本文将介绍 git stash 命令，并探讨一些有用的暂存变更的选项。本文假定你对 Git 概念 有基本的了解，并对工作树、暂存区和相关命令有良好的理解。

为什么 git stash 很重要？

首先要明白为什么在 Git 中暂存变更很重要。假设 Git 没有暂存变更的命令。当你正在一个有两个分支（A 和 B）的仓库上工作时，这两个分支已经分叉了一段时间，并且有不同的头。当你正在处理 A 分支的一些文件时，你的团队要求你修复 B 分支的一个错误。你迅速将你的修改保存到 A 分支（但没有提交），并尝试用 git checkout B 来签出 B 分支。Git 会立即中止了这个操作，并抛出错误：“你对以下文件的本地修改会被该签出覆盖……请在切换分支之前提交你的修改或将它们暂存起来。”

在这种情况下，有几种方法可以启用分支切换：

• 在分支 A 中创建一个提交，提交并推送你的修改，以修复 B 中的错误，然后再次签出 A，并运行 git reset HEAD^ 来恢复你的修改。
• 手动保留不被 Git 跟踪的文件中的改动。

第二种方法是个馊主意。第一种方法虽然看起来很传统，但却不太灵活，因为保存未完成工作的修改会被当作一个检查点，而不是一个仍在进行中的补丁。这正是设计 git stash 的场景。

git stash 将未提交的改动保存在本地，让你可以进行修改、切换分支以及其他 Git 操作。然后，当你需要的时候，你可以重新应用这些存储的改动。暂存是本地范围的，不会被 git push 推送到远程。

如何使用 git stash

下面是使用 git stash 时要遵循的顺序：

1. 将修改保存到分支 A。
2. 运行 git stash。
3. 签出分支 B。
4. 修正 B 分支的错误。
5. 提交并（可选）推送到远程。
6. 查看分支 A
7. 运行 git stash pop 来取回你的暂存的改动。

git stash 将你对工作目录的修改存储在本地（在你的项目的 .git 目录内，准确的说是 /.git/refs/stash），并允许你在需要时检索这些修改。当你需要在不同的上下文之间切换时，它很方便。它允许你保存以后可能需要的更改，是让你的工作目录干净同时保持更改完整的最快方法。

如何创建一个暂存

暂存你的变化的最简单的命令是 git stash：

$ git stash
Saved working directory and index state WIP on master; d7435644 Feat: configure graphql endpoint

默认情况下，git stash 存储（或称之为“暂存”）未提交的更改（已暂存和未暂存的文件），并忽略未跟踪和忽略的文件。通常情况下，你不需要暂存未跟踪和忽略的文件，但有时它们可能会干扰你在代码库中要做的其他事情。

你可以使用附加选项让 git stash 来处理未跟踪和忽略的文件：

• git stash -u 或 git stash --includ-untracked 储存未追踪的文件。
• git stash -a 或 git stash --all 储存未跟踪的文件和忽略的文件。

要存储特定的文件，你可以使用 git stash -p 或 git stash -patch 命令：

$ git stash --patch
diff --git a/.gitignore b/.gitignore
index 32174593..8d81be6e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,6 +3,7 @@
 # dependencies
 node_modules/
 /.pnp
+f,fmfm
 .pnp.js

 # testing
(1/1) Stash this hunk [y,n,q,a,d,e,?]?

列出你的暂存

你可以用 git stash list 命令查看你的暂存。暂存是后进先出（LIFO）方式保存的：

$ git stash list
stash@{0}: WIP on master: d7435644 Feat: configure graphql endpoint

默认情况下，暂存会显示在你创建它的分支和提交的顶部，被标记为 WIP。然而，当你有多个暂存时，这种有限的信息量并没有帮助，因为很难记住或单独检查它们的内容。要为暂存添加描述，可以使用命令 git stash save <description>：

$ git stash save "remove semi-colon from schema"
Saved working directory and index state On master: remove semi-colon from schema

$ git stash list
stash@{0}: On master: remove semi-colon from schema
stash@{1}: WIP on master: d7435644 Feat: configure graphql endpoint

检索暂存起来的变化

你可以用 git stash apply 和 git stash pop 这两个命令来重新应用暂存的变更。这两个命令都会重新应用最新的暂存（即 stash@{0}）中的改动。apply 会重新应用变更；而 pop 则会将暂存的变更重新应用到工作副本中，并从暂存中删除。如果你不需要再次重新应用被暂存的更改，则首选 pop。

你可以通过传递标识符作为最后一个参数来选择你想要弹出或应用的储藏：

$ git stash pop stash@{1}

或

$ git stash apply stash@{1}

清理暂存

删除不再需要的暂存是好的习惯。你必须用以下命令手动完成：

• git stash clear 通过删除所有的暂存库来清空该列表。
• git stash drop <stash_id> 从暂存列表中删除一个特定的暂存。

检查暂存的差异

命令 git stash show <stash_id> 允许你查看一个暂存的差异：

$ git stash show stash@{1}
console/console-init/ui/.graphqlrc.yml        |   4 +-
console/console-init/ui/generated-frontend.ts | 742 +++++++++---------
console/console-init/ui/package.json          |   2 +-

要获得更详细的差异，需要传递 --patch 或 -p 标志：

$ git stash show stash@{0} --patch
diff --git a/console/console-init/ui/package.json b/console/console-init/ui/package.json
index 755912b97..5b5af1bd6 100644
--- a/console/console-init/ui/package.json
+++ b/console/console-init/ui/package.json
@@ -1,5 +1,5 @@
 {
- "name": "my-usepatternfly",
+ "name": "my-usepatternfly-2",
  "version": "0.1.0",
  "private": true,
  "proxy": "http://localhost:4000"
diff --git a/console/console-init/ui/src/AppNavHeader.tsx b/console/console-init/ui/src/AppNavHeader.tsx
index a4764d2f3..da72b7e2b 100644
--- a/console/console-init/ui/src/AppNavHeader.tsx
+++ b/console/console-init/ui/src/AppNavHeader.tsx
@@ -9,8 +9,8 @@ import { css } from "@patternfly/react-styles";

interface IAppNavHeaderProps extends PageHeaderProps {
- toolbar?: React.ReactNode;
- avatar?: React.ReactNode;
+ toolbar?: React.ReactNode;
+ avatar?: React.ReactNode;
}

export class AppNavHeader extends React.Component<IAppNavHeaderProps>{
  render()

签出到新的分支

你可能会遇到这样的情况：一个分支和你的暂存中的变更有分歧，当你试图重新应用暂存时，会造成冲突。一个简单的解决方法是使用 git stash branch <new_branch_name stash_id> 命令，它将根据创建暂存时的提交创建一个新分支，并将暂存中的修改弹出：

$ git stash branch test_2 stash@{0}
Switched to a new branch 'test_2'
On branch test_2
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: .graphqlrc.yml
modified: generated-frontend.ts
modified: package.json
no changes added to commit (use "git add" and/or "git commit -a")
Dropped stash@{0} (fe4bf8f79175b8fbd3df3c4558249834ecb75cd1)

在不打扰暂存参考日志的情况下进行暂存

在极少数情况下，你可能需要创建一个暂存，同时保持暂存参考日志（reflog）的完整性。这些情况可能出现在你需要一个脚本作为一个实现细节来暂存的时候。这可以通过 git stash create 命令来实现；它创建了一个暂存条目，并返回它的对象名，而不将其推送到暂存参考日志中：

$ git stash create "sample stash"
63a711cd3c7f8047662007490723e26ae9d4acf9

有时，你可能会决定将通过 git stash create 创建的暂存条目推送到暂存参考日志：

$ git stash store -m "sample stash testing.." "63a711cd3c7f8047662007490723e26ae9d4acf9"
$ git stash list
stash @{0}: sample stash testing..

结论

我希望你觉得这篇文章很有用，并学到了新的东西。如果我遗漏了任何有用的使用暂存的选项，请在评论中告诉我。

via: https://opensource.com/article/21/4/git-stash

作者：Ramakrishna Pattnaik 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出