使用子模块和子树来帮助你管理多个存储库中共有的子项目。

如果你参与了开源项目的开发，那么你很可能已经用了 Git 来管理你的源码。你可能遇到过有很多依赖和/或子项目的项目。你是如何管理它们的？

对于一个开源组织，要实现社区和产品的单一来源文档和依赖管理比较棘手。文档和项目往往会碎片化和变得冗余，这致使它们很难维护。

必要性

假设你想把单个项目作为一个存储库内的子项目，传统的方法是把该项目复制到父存储库中，但是，如果你想要在多个父项目中使用同一个子项目呢？如果把子项目复制到所有父项目中，当有更新时，你都要在每个父项目中做修改，这是不太可行的。这会导致父项目中的冗余和数据不一致，使更新和维护子项目变得很困难。

Git 子模块和子树

如果你可以用一条命令把一个项目放进另一个项目中，会怎样呢？如果你随时可以把一个项目作为子项目添加到任意数目的项目中，并可以同步更新修改呢？Git 提供了这类问题的解决方案：Git 子模块 submodule 和 Git 子树 subtree 。创建这些工具的目的是以更加模块化的水平来支持共用代码的开发工作流，旨在 Git 存储库 源码管理 source-code management （SCM）与它下面的子树之间架起一座桥梁。

生长在桑树上的樱桃树

下面是本文要详细介绍的概念的一个真实应用场景。如果你已经很熟悉树形结构，这个模型看起来是下面这样：

Git 子模块是什么？

Git 在它默认的包中提供了子模块，子模块可以把 Git 存储库嵌入到其他存储库中。确切地说，Git 子模块指向子树中的某次提交。下面是我 Docs-test GitHub 存储库中的 Git 子模块的样子：

文件夹@提交 Id 格式表明这个存储库是一个子模块，你可以直接点击文件夹进入该子树。名为 .gitmodules 的配置文件包含所有子模块存储库的详细信息。我的存储库的 .gitmodules 文件如下：

你可以用下面的命令在你的存储库中使用 Git 子模块：

克隆一个存储库并加载子模块

克隆一个含有子模块的存储库：

$ git clone --recursive <URL to Git repo>

如果你之前已经克隆了存储库，现在想加载它的子模块：

$ git submodule update --init

如果有嵌套的子模块：

$ git submodule update --init --recursive

下载子模块

串行地连续下载多个子模块是很枯燥的工作，所以 clone 和 submodule update 会支持 --jobs （或 -j）参数：

例如，想一次下载 8 个子模块，使用：

$ git submodule update --init --recursive -j 8
$ git clone --recursive --jobs 8 <URL to Git repo>

拉取子模块

在运行或构建父项目之前，你需要确保依赖的子项目都是最新的。

拉取子模块的所有修改：

$ git submodule update --remote

使用子模块创建存储库：

向一个父存储库添加子树：

$ git submodule add <URL to Git repo>

初始化一个已存在的 Git 子模块：

$ git submodule init

你也可以通过为 submodule update 命令添加 --update 参数在子模块中创建分支和追踪提交：

$ git submodule update --remote

更新子模块的提交

上面提到过，一个子模块就是一个指向子树中某次提交的链接。如果你想更新子模块的提交，不要担心。你不需要显式地指定最新的提交。你只需要使用通用的 submodule update 命令：

$ git submodule update

就像你平时创建父存储库和把父存储库推送到 GitHub 那样添加和提交就可以了。

从一个父存储库中删除一个子模块

仅仅手动删除一个子项目文件夹不会从父项目中移除这个子项目。想要删除名为 childmodule 的子模块，使用：

$ git rm -f childmodule

虽然 Git 子模块看起来很容易上手，但是对于初学者来说，有一定的使用门槛。

Git 子树是什么？

Git 子树 subtree ，是在 Git 1.7.11 引入的，让你可以把任何存储库的副本作为子目录嵌入另一个存储库中。它是 Git 项目可以注入和管理项目依赖的几种方法之一。它在常规的提交中保存了外部依赖信息。Git 子树提供了整洁的集成点，因此很容易复原它们。

如果你参考 GitHub 提供的子树教程来使用子树，那么无论你什么时候添加子树，在本地都不会看到 .gittrees 配置文件。这让我们很难分辨哪个是子树，因为它们看起来很像普通的文件夹，但是它们却是子树的副本。默认的 Git 包中不提供带 .gittrees 配置文件的 Git 子树版本，因此如果你想要带 .gittrees 配置文件的 git-subtree 命令，必须从 Git 源码存储库的 /contrib/subtree 文件夹 下载 git-subtree。

你可以像克隆其他常规的存储库那样克隆任何含有子树的存储库，但由于在父存储库中有整个子树的副本，因此克隆过程可能会持续很长时间。

你可以用下面的命令在你的存储库中使用 Git 子树。

向父存储库中添加一个子树

想要向父存储库中添加一个子树，首先你需要执行 remote add，之后执行 subtree add 命令：

$ git remote add remote-name <URL to Git repo>
$ git subtree add --prefix=folder/ remote-name <URL to Git repo> subtree-branchname

上面的命令会把整个子项目的提交历史合并到父存储库。

向子树推送修改以及从子树拉取修改

$ git subtree push-all

或者

$ git subtree pull-all

你应该使用哪个？

任何工具都有优缺点。下面是一些可能会帮助你决定哪种最适合你的特性：

• Git 子模块的存储库占用空间更小，因为它们只是指向子项目的某次提交的链接，而 Git 子树保存了整个子项目及其提交历史。
• Git 子模块需要在服务器中可访问，但子树是去中心化的。
• Git 子模块大量用于基于组件的开发，而 Git 子树多用于基于系统的开发。

Git 子树并不是 Git 子模块的直接可替代项。有明确的说明来指导我们该使用哪种。如果有一个归属于你的外部存储库，使用场景是向它回推代码，那么就使用 Git 子模块，因为推送代码更容易。如果你有第三方代码，且不会向它推送代码，那么使用 Git 子树，因为拉取代码更容易。

自己尝试使用 Git 子树和子模块，然后在评论中留下你的使用感想。

via: https://opensource.com/article/20/5/git-submodules-subtrees

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

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

让大家觉得你一次就能写出完美的代码，并让你的补丁更容易审核和合并。

软件开发是混乱的。有很多错误的转折、有需要修复的错别字、有需要修正的错误、有需要稍后纠正的临时和粗陋的代码，还有在以后的开发过程中发现一次又一次的问题。有了版本控制，在创建“完美”的最终产品（即准备提交给上游的补丁）的过程中，你会有一个记录着每一个错误转折和修正的原始记录。就像电影中的花絮一样，它们会让人有点尴尬，有时也会让人觉得好笑。

如果你使用版本控制来定期保存你的工作线索，然后当你准备提交审核的东西时，又可以隐藏所有这些私人草稿工作，并只提交一份单一的、完美的补丁，那不是很好吗？git rebase -i，是重写历史记录的完美方法，可以让大家觉得你一次就写出了完美的代码！

git rebase 的作用是什么？

如果你不熟悉 Git 的复杂性，这里简单介绍一下。在幕后，Git 将项目的不同版本与唯一标识符关联起来，这个标识符由父节点的唯一标识符的哈希以及新版本与其父节点的差异组成。这样就形成了一棵修订树，每个签出项目的人都会得到自己的副本。不同的人可以把项目往不同的方向发展，每个方向都可能从不同的分支点开始。

左边是 origin 版本库中的主分支，右边是你个人副本中的私有分支。

有两种方法可以将你的工作与原始版本库中的主分支整合起来：一种是使用合并：git merge，另一种是使用变基：git rebase。它们的工作方式非常不同。

当你使用 git merge 时，会在主分支（master）上创建一个新的提交，其中包括所有来自原始位置（origin）的修改和所有本地的修改。如果有任何冲突（例如，如果别人修改了你也在修改的文件），则将这些冲突标记出来，并且你有机会在将这个“合并提交”提交到本地版本库之前解决这些冲突。当你将更改推送回父版本库时，所有的本地工作都会以分支的形式出现在 Git 版本库的其他用户面前。

但是 git rebase 的工作方式不同。它会回滚你的提交，并从主分支（master）的顶端再次重放这些提交。这导致了两个主要的变化。首先，由于你的提交现在从一个不同的父节点分支出来，它们的哈希值会被重新计算，并且任何克隆了你的版本库的人都可能得到该版本库的一个残破副本。第二，你没有“合并提交”，所以在将更改重放到主分支上时会识别出任何合并冲突，因此，你需要在进行 变基 rebase 之前先修复它们。现在，当你现在推送你的修改时，你的工作不会出现在分支上，并且看起来像是你是在主分支的最新的提交上写入了所有的修改。

合并提交（左）保留了历史，而变基（右）重写历史。

然而，这两种方式都有一个缺点：在你准备好分享代码之前，每个人都可以看到你在本地处理问题时的所有涂鸦和编辑。这就是 git rebase 的 --interactive（或简写 -i）标志发挥作用的地方。

git rebase -i 登场

git rebase 的最大优点是它可以重写历史。但是，为什么仅止于假装你从后面的点分支出来呢？有一种更进一步方法可以重写你是如何准备就绪这些代码的：git rebase -i，即交互式的 git rebase。

这个功能就是 Git 中的 “魔术时光机” 功能。这个标志允许你在做变基时对修订历史记录进行复杂的修改。你可以隐藏你的错误! 将许多小的修改合并到一个崭新的功能补丁中! 重新排列修改历史记录中的显示顺序！

当你运行 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 选题：lujun9972 译者：wxy 校对：wxy

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

Git Extras 版本库包含了 60 多个脚本，它们是 Git 基本功能的补充。以下是如何安装、使用和贡献的方法。

2005 年，Linus Torvalds 创建了 Git，以取代他之前用于维护 Linux 内核的分布式源码控制管理的专有解决方案。从那时起，Git 已经成为开源和云原生开发团队的主流版本控制解决方案。

但即使是像 Git 这样功能丰富的应用程序，也没有人们想要或需要的每个功能，所以会有人花大力气去创建这些缺少的功能。就 Git 而言，这个人就是 TJ Holowaychuk。他的 Git Extras 项目承载了 60 多个“附加功能”，这些功能扩展了 Git 的基本功能。

使用 Git 附加功能

下面介绍一下如何使用四种最受欢迎的 Git 附加功能。

git-ignore

git ignore 是一个方便的附加功能，它可以让你手动添加文件类型和注释到 .git-ignore 文件中，而不需要打开文本编辑器。它可以操作你的个人用户帐户的全局忽略文件和单独用于你正在工作的版本库中的忽略文件。

在不提供参数的情况下执行 git ignore 会先列出全局忽略文件，然后是本地的忽略文件。

$ git ignore
Global gitignore: /home/alice/.gitignore
# Numerous always-ignore extensions
*.diff
*.err
*.orig
*.rej
*.swo
*.swp
*.vi
*~
*.sass-cache

# OS or Editor folders
Thumbs.db
---------------------------------
Local gitignore: .gitignore
nbproject

git-info

git info 可以检索你所需要的所有信息，以获取你正在使用的版本库的上下文信息。它包括远程 URL、远程分支、本地分支、配置信息和最后一次的提交信息。

$ git info

## Remote URLs:

origin      [email protected]:sampleAuthor/git-extras.git (fetch)
origin      [email protected]:sampleAuthor/git-extras.git (push)

## Remote Branches:

origin/HEAD -> origin/master
origin/myBranch

## Local Branches:

myBranch
* master

## Most Recent Commit:

commit e3952df2c172c6f3eb533d8d0b1a6c77250769a7
Author: Sample Author <[email protected]>

Added git-info command.

Type ´git log´ for more commits, or ´git show <commit id>´ for full commit details.

## Configuration (.git/config):

color.diff=auto
color.status=auto
color.branch=auto
user.name=Sample Author
[email protected]
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
[email protected]:mub/git-extras.git
branch.master.remote=origin
branch.master.merge=refs/heads/master

git-mr 和 git-pr

这些附加功能的作用类似，工作方式也基本相同。

• git mr 检出来自 GitLab 的合并请求。
• git pr 检出来自 GitHub 的拉取请求。

无论是哪种情况，你只需要合并请求号/拉取请求号或完整的 URL，它就会抓取远程引用，检出分支，并调整配置，这样 Git 就知道要替换哪个分支了。

$ git mr 51
From gitlab.com:owner/repository
 * [new ref]         refs/merge-requests/51/head -> mr/51
Switched to branch 'mr/51'

git-release

通过将 commit、tag 和 push 合并到一个命令中，git release 可以节省大量的按键来执行这三个命令，而这三个命令往往是依次运行的。

要用特定的 <tagname> 和自定义消息提交：

$ git release 0.1.0 -m <+ powerful feature added>

其他附加功能

这只是该版本库中 60 多个 Git 附加功能中的四个命令。要访问 Git Extras 中的全部命令，请查看该源代码库中的 Commands.md 文件，或者在安装 Git Extras 后运行以下命令。

$ git extras --help

安装 Git 附加功能

使用 Git 附加功能的主要前提是安装了 Git 的命令行版本。如果你打算从源码中构建，还需要有额外的工具（例如：make）。

如果你使用的是最新版本的 macOS，那么 Git 附加功能的安装最好使用 Homebrew（和大多数开源工具一样）。

$ brew install git-extras

在 Linux 上，每个平台原生的包管理器中都包含有 Git Extras。有时，你需要启用额外的仓库，比如在 CentOS 上的 EPEL，然后运行一条命令。

$ sudo yum install git-extras

其他 Linux 发行版、BSD 和其他平台的完整安装说明可以在该版本库的 Installation.md 文件中找到。

贡献

你是否认为 Git 中有缺少的功能，并且已经构建了一个脚本来处理它？为什么不把它作为 Git Extras 发布版的一部分，与全世界分享呢？

要做到这一点，请将该功能贡献到 Git Extras 仓库中。更多具体细节请参见仓库中的 CONTRIBUTING.md 文件，但基本的操作方法很简单：

1. 创建一个处理该功能的 Bash 脚本。
2. 创建一个基本的 man 文件，让大家知道如何使用它。
3. 更新命令列表和补完脚本，让人们知道这个功能的存在。
4. 运行完整性检查，确保你没有破坏任何东西。
5. 为你的功能创建一个拉取请求。

向 Git Extras 贡献贡献，会让你的 Git 用户的生活更轻松一些。你可以在项目的 README 中了解更多。

via: https://opensource.com/article/20/4/git-extras

作者：Vince Power 选题：lujun9972 译者：wxy 校对：wxy

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

GTWS 是一系列脚本，它使我们在开发环境中管理不同的项目和项目的各个版本变得很容易。

Great Teeming Workspaces（GTWS）是一个 Git 的复杂工作空间管理工具包，它使我们在开发环境中管理不同的项目和项目的各个版本变得很容易。

有点像 Python 的 venv，但不是为 Python 语言准备的。GTWS 用来管理多个项目的多个版本的工作空间。你可以很容易地创建、更新、进入和离开工作空间，每个项目或版本的组合（最多）有一个本地的 origin，用来与 upstream 同步 — 其余的所有工作空间都从本地的 origin 更新。

部署

${GTWS_ORIGIN}/<project>/<repo>[/<version>]
${GTWS_BASE_SRCDIR}/<project>/<version>/<workspacename>/{<repo>[,<repo>...]}

源代码目录的每一级（包括全局的家目录）可以包含一个 .gtwsrc 文件，这个文件中维护与当前级相关的设置和 bash 代码。每一级的配置会覆盖上一级。

安装

用下面的命令检出 GTWS：

git clone https://github.com/dang/gtws.git

配置你的 ${HOME}/.gtwsrc。它应该包含 GTWS_ORIGIN，也可以再包含 GTWS_SETPROMPT。

把仓库目录加到环境变量中：

export PATH="${PATH}:/path/to/gtws

配置

通过级联 .gtwsrc 文件来进行配置。它从根目录向下遍历，会执行在每级目录中找到的 .gtwsrc 文件。下级目录的文件会覆盖上一级。

在你最上层的文件 ~/.gtws/.gtwsrc 中进行如下设置：

• GTWS_BASE_SRCDIR：所有项目源文件目录树的基目录。默认为 $HOME/src。
• GTWS_ORIGIN： 指定 origin git 目录树的路径。默认为 $HOME/origin。
• GTWS_SETPROMPT： 可选配置。如果配置了这个参数，shell 提示符会有工作空间的名字。
• GTWS_DEFAULT_PROJECT： 不指定项目或项目未知时默认的项目名。如果不指定，使用命令行时必须指明项目。
• GTWS_DEFAULT_PROJECT_VERSION： 检出的默认版本。默认为 master。

在每个项目的根目录进行以下设置：

• GTWS_PROJECT： 项目的名字（和基目录）。
• gtws_project_clone： 这个函数用于克隆一个项目的指定版本。如果未定义，它会假定项目的 origin 对每一个版本都有一个单独的目录，这样会导致克隆一堆 Git 仓库。
• gtws_project_setup： 在克隆完所有的仓库后，可以选择是否调用这个函数，调用后可以对项目进行必要的配置，如在 IDE 中配置工作空间。

在项目版本级进行以下设置：

• GTWS_PROJECT_VERSION： 项目的版本。用于正确地从 origin 拉取代码。类似 Git 中的分支名字。

下面这些参数可以在目录树的任意地方进行配置，如果能生效，它们可以被重写多次：

• GTWS_PATH_EXTRA： 这些是工作空间中加到路径后的额外的路径元素。
• GTWS_FILES_EXTRA： 这些是不在版本控制内，但应该在工作空间中被检出的额外的文件。这些文件包括 .git/info/exclude，每个文件都与仓库的基目录相关联。

origin 目录

GTWS_ORIGIN （大部分脚本中）指向拉取和推送的原始 Git 检出目录。

${GTWS_ORIGIN} 部署：

• /<project>

  • 这是一个项目的仓库的基目录。
  • 如果指定了 gtws_project_clone，你可以配置任意的部署路径。
  • 如果没有指定 gtws_project_clone，这个路径下必须有个名为 git 的子目录，且 git 目录下有一系列用来克隆的裸 Git 仓库。

工作流示例

假设你有一个项目名为 Foo，它的 upstream 为 github.com/foo/foo.git。这个仓库有个名为 bar 的子模块，它的 upstream 是 github.com/bar/bar.git。Foo 项目在 master 分支开发，使用稳定版本的分支。

为了能在 Foo 中使用 GTWS，你首先要配置目录结构。本例中假设你使用默认的目录结构。

• 配置你最上层的 .gtwsrc：

  • cp ${GTWS_LOC}/examples/gtwsrc.top ~/.gtwsrc
  • 根据需要修改 ~/.gtwsrc。

• 创建顶级目录：

  • mkdir -p ~/origin ~/src
• 创建并配置项目目录：

+ `mkdir -p ~/src/foo`


`cp ${GTWS_LOC}/examples/gtwsrc.project ~/src/foo/.gtwsrc`
+ 根据需要修改 `~/src/foo/.gtwsrc`。

• 创建并配置 master 版本目录：

+ `mkdir -p ~/src/foo/master`


`cp ${GTWS_LOC}/examples/gtwsrc.version ~/src/foo/master/.gtwsrc`
+ 根据需要修改 `~/src/foo/master/.gtwsrc`。

• 进入版本目录并创建一个临时工作空间来配置镜像：

+ `mkdir -p ~/src/foo/master/tmp`


`cd ~/src/foo/master/tmp`


`git clone --recurse-submodules git://github.com/foo/foo.git`


`cd foo`


`gtws-mirror -o ~/origin -p foo`（译注：这个地方原文有误，不加 `-s` 参数会报错）
+ 上面命令会创建 `~/origin/foo/git/foo.git` 和 `~/origin/foo/submodule/bar.git`。
+ 以后的克隆操作会从这些 origin 而不是 upstream 克隆。
+ 现在可以删除工作空间了。

到现在为止，Foo 的 master 分支的工作可以结束了。假设你现在想修复一个 bug，名为 bug1234。你可以脱离你当前的工作空间为修复这个 bug 单独创建一个工作空间，之后在新创建的工作空间中开发。

• 进入版本目录，创建一个新的工作空间：

+ `cd ~/src/foo/master`


`mkws bug1234`
+ 上面的命令创建了 `bug1234/`，在这个目录下检出了 Foo（和它的子模块 `bar`），并创建了 `build/foo` 来构建它。

• 有两种方式进入工作空间：

+ `cd ~/src/foo/master/bug1234`


`startws`


或者


`cd ~/src/foo/master/`


`startws bug1234`
+ 上面的命令在 `bug1234` 工作空间中开启了一个子 shell。这个 shell 有 GTWS 的环境和你在各级 `.gtwsrc` 文件中设置的环境。它也把你工作空间的基目录加入到了 CD，因此你可以从 base 路径 `cd` 到相关的目录中。
+ 现在你可以修复 `bug1234` 了，构建、测试、提交你的修改。当你可以把代码推送到 upstream 时，执行下面的命令：


`cd foo`


`wspush`
+ `wspush` 会把代码推送到与你工作空间相关的分支 — 先推送到本地的 origin，再推送到 upstream。
+ 当 upstream 有修改时，你可以用下面的命令同步到本地：


`git sync`
+ 上面的命令调用了 GTWS 的 `git-sync` 脚本，会从本地 origin 更新代码。使用下面的命令来更新本地的 origin：


`git sync -o`
+ 上面的命令会更新你本地的 origin 和子模块的镜像，然后用那些命令来更新你的检出仓库的代码。`git-sync` 也有一些其他的很好的工鞥。
+ 当要结束工作空间中的工作时，直接退出 shell：


`exit`
+ 你可以在任何时间重复进入工作空间，也可以在同一时间在相同的工作空间中开多个 shell。

• 当你不需要某个工作空间时，你可以使用 rmws 来删除它，或者直接删除它的目录树。
• 还有一个脚本 tmws 使用 tmux 进入工作空间，能创建一系列的窗口/窗格，这完美契合我的工作流。你可以根据你自己的需求来修改它。

via: https://opensource.com/article/20/2/git-great-teeming-workspaces

作者：Daniel Gryniewicz 选题：lujun9972 译者：lxbwolf 校对：wxy

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

在 Git 15 周年之际，了解为什么 Git 是保持软件行业运行的重要组成部分。

如果说过去二十年来有什么东西改变了软件，那么 Git 肯定位列榜首。

如果你没有亲自使用过 Git，你可能会认为它只是一种技术时尚，只是因为它是由 Linux 项目的创始人创建的，所以在开发者中只是一个偶然的宠儿。这或许有一定的道理，但 Git 确实取得了一些其他行业所没有的成就。有了 Git，分布在世界各地的开发者们可以在同一时间对同一段代码进行工作，并记录下每一次修改的历史，然后将所有的工作合并到一起，形成一个成品。由于这件事情非常复杂，所以这个工具本身也会变得很复杂，但归根结底，它是维持软件行业运行的重要组成部分。

无论你是否了解 Git，如果你足够深入的研究开源软件，或者进入计算机科学领域，都有可能遇到它。无论你使用 Git 只是为了下载一个安装包，还是每天与它交互来管理代码，了解更多关于它的知识，都会对你有很大的启发和帮助。

Git 术语

与任何专业工具一样，Git 中也有很多行话。像“ 克隆 clone ”、“ 合并 merge ”和“ 变基 rebase ”这样的术语，最起码也是神秘的，而更糟的情况下会令人感到排斥。试图理解这些术语的含义可能会让人不知所措，但如果你从 Matthew Broberg 的优秀文章《Git 术语基础》中得到一点指导，就不会这样了。只需快速阅读一下，你就能真正理解地听懂关于 Git 的对话。

Git 入门

如果你需要知道如何使用 Git，那么我自己的关于使用 Git 的入门文章系列是一个很好的开始。这些文章已经有几年的历史了，但就像许多 Linux 和 UNIX 技术一样，它的界面并没有发生很大的变化，所以这些文章和我写这些文章那时一样，在今天还是很有意义的。这一系列文章向你介绍了 Git 最基本的概念，并带领你完成创建仓库、提交文件、恢复文件、合并分支等过程。

常见的 Git 服务

Git 最常见的用途之一是公共的 Git 托管服务，比如 GitLab 和 GitHub。Kedar Vijay Kulkarni 在他的《如何在 Git 中克隆、修改、添加和删除文件》一文中，演示了大多数开发者使用 Git 执行的日常任务。这不是非开发者的必读书目，但对于任何想在公共 Git 托管服务上为项目做贡献的人来说，这篇文章是必读的。这篇文章专门针对的是 Github，因为它是当今最常见的平台之一，但其原理也适用于任何 Git 服务的 Web 前端，包括 GitLab、Gogs 和 Gitea 等流行的开源框架。

试试这个 Git 演练

与其漫无目的的探索，你是不是更喜欢在导游的带领下学习？有时候，学习一件事最简单的方法就是模仿别人的准确步骤。你知道最终的结果是肯定成功的，所以你在进行练习的时候会有信心，而你的大脑和手指也会得到重复的好处，从而建立起记忆。如果这是你的学习风格，那就跟着 Alan Formy-Duvall 的《Git 的实用学习练习》，找出成功的 Git 课程的感觉。

Git 应用程序

信不信由你，Git 的界面比你在终端输入的文字更多。显然，在线托管的 Git 有 Web 界面，但是你也可以在计算机上使用 Git 客户端。如果想获得更多的帮助，请阅读 Jesse Duffield 关于 Lazygit 的文章或 Olaf Anders 关于 Tig 的文章。要获得完整的图形应用程序体验，请阅读我有关 Git-cola、Sparkleshare 以及其它应用的文章。是的，甚至还有用于你的移动设备的界面！

了解更多关于 Git 的信息

知识就是力量，所以不要让 Git 对你来说像个谜。无论你是直接使用它，还是只知道它的名字，或者你以前从未听说过它，现在都是了解 Git 的好时机。这里有很多资源可以帮助你了解它的工作原理、工作原理以及人们为什么这么喜欢它。潜入其中，按照自己的节奏来学习，并学会爱上 Git 吧！

via: https://opensource.com/article/20/4/get-started-git

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

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

在 Ubuntu 上安装 Git 非常容易。它存在于 Ubuntu 的主仓库中，你可以像这样使用 apt 命令安装它：

sudo apt install git

很简单？是不是？

只有一点点小问题（这可能根本不是问题），就是它安装的 Git 版本。

在 LTS 系统上，软件稳定性至关重要，这就是为什么 Ubuntu 18.04 和其他发行版经常提供较旧但稳定的软件版本的原因，它们都经过发行版的良好测试。

这就是为什么当你检查 Git 版本时，会看到安装的版本会比 Git 网站上当前最新 Git 版本旧：

$ git --version
git version 2.17.1

在编写本教程时，网站上提供的版本为 2.25。那么，如何在 Ubuntu 上安装最新的 Git？

在基于 Ubuntu 的 Linux 发行版上安装最新的 Git

一种方法是从源代码安装。这种很酷又老派的方法不适合所有人。值得庆幸的是，Ubuntu Git 维护团队提供了 PPA，莫可以使用它轻松地安装最新的稳定 Git 版本。

sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git

即使你以前使用 apt 安装了 Git，它也将更新为最新的稳定版本。

$ git --version
git version 2.25.0

使用PPA 的好处在于，如果发布了新的 Git 稳定版本，那么就可以通过系统更新获得它。仅更新 Ubuntu 来获取最新的 Git 稳定版本。

配置 Git （推荐给开发者）

如果你出于开发目的安装了 Git，你会很快开始克隆仓库，进行更改并提交更改。

如果你尝试提交代码，那么你可能会看到 “Please tell me who you are” 这样的错误：

$ git commit -m "update readme"

*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'abhishek@itsfoss.(none)')

这是因为你还没配置必要的个人信息。

正如错误已经暗示的那样，你可以像这样设置全局 Git 配置：

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

你可以使用以下命令检查 Git 配置：

git config --list

它应该显示如下输出：

[email protected]
user.name=Your Name

配置保存在 ~/.gitconfig 中。你可以手动修改配置。

结尾

我希望这个小教程可以帮助你在 Ubuntu 上安装 Git。使用 PPA，你可以轻松获得最新的 Git 版本。

如果你有任何疑问或建议，请随时在评论部分提问。也欢迎直接写“谢谢” :)

via: https://itsfoss.com/install-git-ubuntu/

作者：Abhishek Prakash 选题：lujun9972 译者：geekpi 校对：wxy

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