mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
386febaae2
@ -0,0 +1,79 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12231-1.html)
|
||||
[#]: subject: (The life-changing magic of git rebase -i)
|
||||
[#]: via: (https://opensource.com/article/20/4/git-rebase-i)
|
||||
[#]: author: (Dave Neary https://opensource.com/users/dneary)
|
||||
|
||||
完美生活：git rebase -i
|
||||
======
|
||||
|
||||
> 让大家觉得你一次就能写出完美的代码，并让你的补丁更容易审核和合并。
|
||||
|
||||
|
||||
|
||||
软件开发是混乱的。有很多错误的转折、有需要修复的错别字、有需要修正的错误、有需要稍后纠正的临时和粗陋的代码，还有在以后的开发过程中发现一次又一次的问题。有了版本控制，在创建“完美”的最终产品（即准备提交给上游的补丁）的过程中，你会有一个记录着每一个错误转折和修正的原始记录。就像电影中的花絮一样，它们会让人有点尴尬，有时也会让人觉得好笑。
|
||||
|
||||
如果你使用版本控制来定期保存你的工作线索，然后当你准备提交审核的东西时，又可以隐藏所有这些私人草稿工作，并只提交一份单一的、完美的补丁，那不是很好吗？`git rebase -i`，是重写历史记录的完美方法，可以让大家觉得你一次就写出了完美的代码！
|
||||
|
||||
### git rebase 的作用是什么？
|
||||
|
||||
如果你不熟悉 Git 的复杂性，这里简单介绍一下。在幕后，Git 将项目的不同版本与唯一标识符关联起来，这个标识符由父节点的唯一标识符的哈希以及新版本与其父节点的差异组成。这样就形成了一棵修订树，每个签出项目的人都会得到自己的副本。不同的人可以把项目往不同的方向发展，每个方向都可能从不同的分支点开始。
|
||||
|
||||
![Master branch vs. private branch][2]
|
||||
|
||||
*左边是 origin 版本库中的主分支，右边是你个人副本中的私有分支。*
|
||||
|
||||
有两种方法可以将你的工作与原始版本库中的主分支整合起来：一种是使用合并：`git merge`，另一种是使用变基：`git rebase`。它们的工作方式非常不同。
|
||||
|
||||
当你使用 `git merge` 时，会在主分支（`master`）上创建一个新的提交，其中包括所有来自原始位置（`origin`）的修改和所有本地的修改。如果有任何冲突（例如，如果别人修改了你也在修改的文件），则将这些冲突标记出来，并且你有机会在将这个“合并提交”提交到本地版本库之前解决这些冲突。当你将更改推送回父版本库时，所有的本地工作都会以分支的形式出现在 Git 版本库的其他用户面前。
|
||||
|
||||
但是 `git rebase` 的工作方式不同。它会回滚你的提交，并从主分支（`master`）的顶端再次重放这些提交。这导致了两个主要的变化。首先，由于你的提交现在从一个不同的父节点分支出来，它们的哈希值会被重新计算，并且任何克隆了你的版本库的人都可能得到该版本库的一个残破副本。第二，你没有“合并提交”，所以在将更改重放到主分支上时会识别出任何合并冲突，因此，你需要在进行<ruby>变基<rt>rebase</rt></ruby>之前先修复它们。现在，当你现在推送你的修改时，你的工作不会出现在分支上，并且看起来像是你是在主分支的最新的提交上写入了所有的修改。
|
||||
|
||||
![Merge commits preserve history, and rebase rewrites history.][3]
|
||||
|
||||
*合并提交（左）保留了历史，而变基（右）重写历史。*
|
||||
|
||||
然而，这两种方式都有一个缺点：在你准备好分享代码之前，每个人都可以看到你在本地处理问题时的所有涂鸦和编辑。这就是 `git rebase` 的 `--interactive`（或简写 `-i`）标志发挥作用的地方。
|
||||
|
||||
### git rebase -i 登场
|
||||
|
||||
`git rebase` 的最大优点是它可以重写历史。但是，为什么仅止于假装你从后面的点分支出来呢？有一种更进一步方法可以重写你是如何准备就绪这些代码的：`git rebase -i`，即交互式的 `git rebase`。
|
||||
|
||||
这个功能就是 Git 中的 “魔术时光机” 功能。这个标志允许你在做变基时对修订历史记录进行复杂的修改。你可以隐藏你的错误! 将许多小的修改合并到一个崭新的功能补丁中! 重新排列修改历史记录中的显示顺序！
|
||||
|
||||
![output of git rebase -i][4]
|
||||
|
||||
当你运行 `git rebase -i` 时，你会进入一个编辑器会话，其中列出了所有正在被变基的提交，以及可以对其执行的操作的多个选项。默认的选择是选择（`Pick`）。
|
||||
|
||||
* `Pick`：会在你的历史记录中保留该提交。
|
||||
* `Reword`：允许你修改提交信息，可能是修复一个错别字或添加其它注释。
|
||||
* `Edit`：允许你在重放分支的过程中对提交进行修改。
|
||||
* `Squash`：可以将多个提交合并为一个。
|
||||
* 你可以通过在文件中移动来重新排序提交。
|
||||
|
||||
当你完成后，只需保存最终结果，变基操作就会执行。在你选择修改提交的每个阶段（无论是用 `reword`、`edit`、`squash` 还是发生冲突时），变基都会停止，并允许你在继续提交之前进行适当的修改。
|
||||
|
||||
上面这个例子的结果是 “One-liner bug fix” 和 “Integate new header everywhere” 被合并到一个提交中，而 “New header for docs website” 和 “D'oh - typo. Fixed” 合并到另一个提交中。就像变魔术一样，其他提交的工作还在你的分支中，但相关的提交已经从你的历史记录中消失了！
|
||||
|
||||
这使得使用 `git send-email` 或者用你新整理好的补丁集在父版本库中创建一个拉取请求，然后来提交一个干净的补丁给上游项目变得很容易。这有很多好处，包括让你的代码更容易审核，更容易接受，也更容易合并。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/4/git-rebase-i
|
||||
|
||||
作者：[Dave Neary][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/dneary
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/programming-code-keyboard-laptop.png?itok=pGfEfu2S (Hands programming)
|
||||
[2]: https://opensource.com/sites/default/files/uploads/master-private-branches.png (Master branch vs. private branch)
|
||||
[3]: https://opensource.com/sites/default/files/uploads/merge-commit-vs-rebase.png (Merge commits preserve history, and rebase rewrites history.)
|
||||
[4]: https://opensource.com/sites/default/files/uploads/git-rebase-i.png (output of git rebase -i)
|
||||
@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-12230-1.html)
|
||||
[#]: subject: (4 cool new projects to try in COPR for May 2020)
|
||||
[#]: via: (https://fedoramagazine.org/4-cool-new-projects-to-try-in-copr-for-april-2020/)
|
||||
[#]: author: (Dominik Turecek https://fedoramagazine.org/author/dturecek/)
|
||||
@ -18,13 +18,13 @@ COPR 是个人软件仓库[集合][2]，它不在 Fedora 中。这是因为某
|
||||
|
||||
### Ytop
|
||||
|
||||
[ytop][4] 是类似于 _htop_ 的命令行系统监视器。它们之间的主要区别是 _ytop_ 在显示进程及 CPU 和内存使用率的顶部，还显示了系统 CPU、内存和网络使用率随时间变化的图表。此外，_ytop_ 显示磁盘使用情况和计算机温度。最后，_ytop_ 支持多种配色方案以及创建新配色的选项。
|
||||
[ytop][4] 是类似于 `htop` 的命令行系统监视器。它们之间的主要区别是，`ytop` 在显示进程及其 CPU 和内存使用率的顶部显示了系统的 CPU、内存和网络使用率随时间变化的图表。此外，`ytop` 还显示磁盘使用情况和计算机温度。最后，`ytop` 支持多种配色方案以及创建新配色的选项。
|
||||
|
||||
![][5]
|
||||
|
||||
#### 安装说明
|
||||
|
||||
[仓库][6]当前为 Fedora 30、31、32 和 Rawhide 以及 EPEL 7 提供 _ytop_。要安装 _ytop_，请[带上 _sudo_][7] 使用以下命令：
|
||||
[该仓库][6]当前为 Fedora 30、31、32 和 Rawhide 以及 EPEL 7 提供了 `ytop`。要安装 `ytop`，请[带上 sudo][7] 使用以下命令：
|
||||
|
||||
```
|
||||
sudo dnf copr enable atim/ytop
|
||||
@ -33,13 +33,13 @@ sudo dnf install ytop
|
||||
|
||||
### Ctop
|
||||
|
||||
[ctop][8] 是另一个命令行系统监视器。但是，与 _htop_ 和 _ytop_ 不同，_ctop_ 专注于显示容器的资源使用情况。_ctop_ 同时显示计算机上运行的所有容器的CPU、内存、网络和磁盘使用情况的概要，以及单个容器的更全面的信息，包括一段时间内资源使用情况的图表。当前，_ctop_ 支持 Docker 和 runc 容器。
|
||||
[ctop][8] 是另一个命令行系统监视器。但是，与 `htop` 和 `ytop` 不同，`ctop` 专注于显示容器的资源使用情况。`ctop` 同时显示计算机上运行的所有容器的 CPU、内存、网络和磁盘使用情况的概要，以及单个容器的更全面的信息，包括一段时间内资源使用情况的图表。当前，`ctop` 支持 Docker 和 runc 容器。
|
||||
|
||||
![][9]
|
||||
|
||||
#### 安装说明
|
||||
|
||||
[仓库][10]当前为 Fedora 31、32 和 Rawhide 以及 EPEL 7 还有其他发行版提供安装包。要安装 _ctop_，请使用以下命令：
|
||||
[该仓库][10]当前为 Fedora 31、32 和 Rawhide 以及 EPEL 7 还有其他发行版提供了安装包。要安装 `ctop`，请使用以下命令：
|
||||
|
||||
```
|
||||
sudo dnf copr enable fuhrmann/ctop
|
||||
@ -48,13 +48,13 @@ sudo dnf install ctop
|
||||
|
||||
### Shortwave
|
||||
|
||||
[shortwave][11] 是用于收听广播电台的程序。shortwave 使用广播电台的社区数据库 [www.radio-browser.info][12]。在此数据库中，你可以发现或搜索广播电台，将它们添加到库中，然后收听。此外，shortwave 还提供有关当前播放歌曲的信息，并且还可以记录这些歌曲。
|
||||
[shortwave][11] 是用于收听广播电台的程序。`shortwave` 使用广播电台的社区数据库 [www.radio-browser.info][12]。在此数据库中，你可以发现或搜索广播电台，将它们添加到库中，然后收听。此外，`shortwave` 还提供有关当前播放歌曲的信息，并且还可以记录这些歌曲。
|
||||
|
||||
![][13]
|
||||
|
||||
#### 安装说明
|
||||
|
||||
[仓库][14] 当前为 Fedora 31、32 和 Rawhide 提供 shortwave。要安装 shortwave，请使用以下命令：
|
||||
[该仓库][14] 当前为 Fedora 31、32 和 Rawhide 提供了 shortwave。要安装 `shortwave`，请使用以下命令：
|
||||
|
||||
```
|
||||
sudo dnf copr enable atim/shortwave
|
||||
@ -63,13 +63,13 @@ sudo dnf install shortwave
|
||||
|
||||
### Setzer
|
||||
|
||||
[setzer][15] 是 LaTeX 编辑器，它可以构建 pdf 文档并查看它们。它提供了各种类型文档（例如文章或幻灯片）的模板。此外，setzer 还有许多特殊符号，数学符号和希腊字母的按钮。
|
||||
[setzer][15] 是 LaTeX 编辑器，它可以构建 pdf 文档并查看它们。它提供了各种类型文档（例如文章或幻灯片）的模板。此外，`setzer` 还有许多特殊符号、数学符号和希腊字母的按钮。
|
||||
|
||||
![][16]
|
||||
|
||||
#### 安装说明
|
||||
|
||||
[仓库][17] 当前为Fedora 30、31、32 和 Rawhide 提供 setzer。要安装 setzer，请使用以下命令：
|
||||
[该仓库][17] 当前为 Fedora 30、31、32 和 Rawhide 提供了 `setzer`。要安装 `setzer`，请使用以下命令：
|
||||
|
||||
```
|
||||
sudo dnf copr enable lyessaadi/setzer
|
||||
@ -83,7 +83,7 @@ via: https://fedoramagazine.org/4-cool-new-projects-to-try-in-copr-for-april-202
|
||||
作者：[Dominik Turecek][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -105,4 +105,4 @@ via: https://fedoramagazine.org/4-cool-new-projects-to-try-in-copr-for-april-202
|
||||
[14]: https://copr.fedorainfracloud.org/coprs/atim/shortwave/
|
||||
[15]: https://www.cvfosammmm.org/setzer/
|
||||
[16]: https://fedoramagazine.org/wp-content/uploads/2020/04/setzer.png
|
||||
[17]: https://copr.fedorainfracloud.org/coprs/lyessaadi/setzer/
|
||||
[17]: https://copr.fedorainfracloud.org/coprs/lyessaadi/setzer/
|
||||
@ -1,30 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How to repeat a Linux command until it succeeds)
|
||||
[#]: via: (https://www.linux.com/news/how-to-repeat-a-linux-command-until-it-succeeds/)
|
||||
[#]: author: (Linux.com Editorial Staff https://www.linux.com/author/linuxdotcom/)
|
||||
|
||||
How to repeat a Linux command until it succeeds
|
||||
======
|
||||
|
||||
If you want to run a command on a Linux system until it succeeds, there are some really easy ways to do it that don’t require you to retype the command repeatedly or sit in front of your screen pressing !! Let’s look at the two options available with bash.
|
||||
|
||||
Read More at [Network World][1]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/how-to-repeat-a-linux-command-until-it-succeeds/
|
||||
|
||||
作者：[Linux.com Editorial Staff][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.linux.com/author/linuxdotcom/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.networkworld.com/article/3541298/how-to-repeat-a-linux-command-until-it-succeeds.html
|
||||
@ -1,79 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (The life-changing magic of git rebase -i)
|
||||
[#]: via: (https://opensource.com/article/20/4/git-rebase-i)
|
||||
[#]: author: (Dave Neary https://opensource.com/users/dneary)
|
||||
|
||||
完美生活：git rebase -i
|
||||
======
|
||||
|
||||
> 让大家觉得你一次就能写出完美的代码，并让你的补丁更容易审核和合并。
|
||||
|
||||
![Hands programming][1]
|
||||
|
||||
软件开发是混乱的。有很多错误的转折、有需要修复的错别字、有需要修正的错误、有需要稍后纠正临时和粗陋的代码，还有在开发过程中以后发现的错位问题。有了版本控制，在创建“完美”的最终产品（即准备提交给上游的补丁）的过程中，你会有一个记录着每一个错误的转折和修正的原始记录。就像电影中的片段一样，它们有些尴尬，有时还很有趣。就像电影中的花絮一样，它们会让人有点尴尬，有时也会让人觉得好笑。
|
||||
|
||||
如果你能使用版本控制来定期保存你的工作线索，然后当你准备提交审核的东西时，可以隐藏所有这些私人草稿工作，只需提交一份单一的、完美的补丁就可以了，那不是很好吗？`git rebase -i`，是重写历史记录的完美方法，可以让大家觉得你一次就写出了完美的代码。
|
||||
|
||||
### git rebase 的作用是什么？
|
||||
|
||||
如果你不熟悉 Git 的复杂性，这里简单介绍一下。在幕后，Git 将项目的不同版本与唯一标识符关联起来，这个标识符由父节点的唯一标识符的哈希以及新版本与其父节点的差异组成。这样就形成了一棵修订树，每个检出项目的人都会得到自己的副本。不同的人可以把项目往不同的方向发展，每个人的出发点都可能是不同的分支点。
|
||||
|
||||
![Master branch vs. private branch][2]
|
||||
|
||||
*左边是 `origin` 版本库中的主分支，右边是你个人副本中的私有分支。*
|
||||
|
||||
有两种方法可以将你的工作与原始版本库中的主分支整合起来：一种是使用 合并：`git merge`，另一种是使用变基：`git rebase`。它们的工作方式非常不同。
|
||||
|
||||
当你使用 `git merge` 时，会在主分支上创建一个新的提交，其中包括所有来自 `origin` 的修改和所有本地的修改。如果有任何冲突（例如，如果别人修改了你也在修改的文件），则将这些冲突标记出来，并且你有机会在将该“合并提交”提交到本地版本库之前解决这些冲突。当你将更改推送回父版本库时，所有的本地工作都会以分支的形式出现在 Git 仓库的其他用户面前。
|
||||
|
||||
但是 `git rebase` 的工作方式不同。它回滚你的提交，并从主分支的顶端再次重放这些提交。这导致了两个主要的变化。首先，由于你的提交现在从一个不同的父节点分支出来，它们的哈希值会被重新计算，并且任何克隆了你的仓库的人都可能会有一个残破的仓库副本。第二，你没有一个合并提交，所以在将更改重放到主分支上时会识别出任何合并冲突，所以任何合并冲突都会被识别出来，因此，你需要在进行<ruby>变基<rt>rebase</rt></ruby>之前修复它们。当你现在推送你的修改时，你的工作不会出现在分支上，并且看起来像是你把所有的修改都写到了主分支的最新的提交上。
|
||||
|
||||
![Merge commits preserve history, and rebase rewrites history.][3]
|
||||
|
||||
*合并提交（左）保留了历史，而变基（右）重写历史。*
|
||||
|
||||
然而，这两种方式都有一个坏处：在你准备好分享代码之前，每个人都可以看到你在本地处理问题时的所有涂鸦和编辑。这就是 `git rebase` 的 `--interactive`（或简写 `-i`）标志的作用。
|
||||
|
||||
### 介绍 git rebase -i
|
||||
|
||||
`git rebase` 的最大优点是它重写了历史。但是，为什么仅止于假装你从后面的点分支出来呢？有一种更进一步方法可以重写你是如何准备就绪这些代码的：`git rebase -i`，交互式的 `git rebase`。
|
||||
|
||||
这个功能就是 Git 中的 "神奇的时间机器” 功能。这个标志允许你在做变基时对修订历史记录进行复杂的修改。你可以隐藏你的错误! 将许多小的修改合并到一个原始的功能补丁中! 重新排序修改历史记录中的内容
|
||||
|
||||
![output of git rebase -i][4]
|
||||
|
||||
当你运行 `git rebase -i` 时，你会得到一个编辑器会话，其中列出了所有正在被变基的提交，并有一些选项可以对它们做什么。默认的选择是 `pick`。
|
||||
|
||||
* `Pick`：会在你的历史记录中保留该提交。
|
||||
* `Reword`：允许你修改提交信息，可能是修复一个错别字或添加额外的注释。
|
||||
* `Edit`：允许你在重放分支的过程中对提交进行修改。
|
||||
* `Squash`：可以将多个提交合并为一个。
|
||||
* 你可以通过移动文件中的提交来重新排序。
|
||||
|
||||
当你完成后，只需保存最终结果，变基就会执行。在每个阶段，当你选择了修改提交（无论是用 `reword`、`edit`、`squash` 还是有冲突时），变基会停止，并允许你在继续提交之前进行适当的修改。
|
||||
|
||||
上面这个例子的结果是 “One-liner bug fix” 和 “Integate new header everywhere” 被合并到一个提交中，而 “New header for docs website” 和 “D'oh - typo. Fixed” 合并到另一个提交中。就像变魔术一样，其他提交的工作还在你的分支中，但相关的提交已经从你的历史记录中消失了！这样一来，你就可以很容易地提交干净的提交。
|
||||
|
||||
这使得使用 `git send-email` 或者用你新整理好的补丁集在父版本库中创建一个拉取请求来提交一个干净的补丁给上游项目变得很容易。这有很多好处，包括让你的代码更容易审核，更容易接受，也更容易合并。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/4/git-rebase-i
|
||||
|
||||
作者：[Dave Neary][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/dneary
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/programming-code-keyboard-laptop.png?itok=pGfEfu2S (Hands programming)
|
||||
[2]: https://opensource.com/sites/default/files/uploads/master-private-branches.png (Master branch vs. private branch)
|
||||
[3]: https://opensource.com/sites/default/files/uploads/merge-commit-vs-rebase.png (Merge commits preserve history, and rebase rewrites history.)
|
||||
[4]: https://opensource.com/sites/default/files/uploads/git-rebase-i.png (output of git rebase -i)
|
||||
Loading…
Reference in New Issue
Block a user