Vince Power 发布的文章

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

通过将 committagpush 合并到一个命令中,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中国 荣誉推出

系统管理员和网站可靠性工程师(SRE,下同)对于任何组织来讲都很重要。本篇将介绍下两者的不同之处。

在 IT 行业,成为多面手或是专家的争议一直存在。99% 的传统系统管理员都被归到了多面手这类。 网站可靠性工程师 site reliability engineer (SRE)的角色则更加专精,并且在如 Google 般有着一定规模的头部公司中对其的需求不断增加。但总的来说这两者对于跑着应用的基础设施有着同样的目标:为应用的消费者提供良好的体验。然而两者的出发点却截然不同。

系统管理员:中立善良的化身

系统管理员一般都是从基础的桌面或网络支持成长过来的,并一路习得大多数系统管理员都会掌握的广泛的技能。此时这些系统管理员会对他们所负责的系统和应用了如指掌。他们会知道一号服务器上的应用每隔一个星期二就需要重启一次,或是九号服务器周三会静默的崩溃。他们会对服务器的监视作出微调以忽略无关紧要的信息,尽管那个被标记为 致命 fatal 的错误信息每个月第三个周日都会显示。

总的来讲,系统管理员了解如何照料那些跑着你核心业务的服务器。这些系统管理员已经成长到开始使用自动化工具去处理所有归他们管的服务器上的例行任务。他们虽然喜欢使用模板、 黄金镜像 golden images 、以及标准,但同时也有着足够的灵活度去修改一个服务器上的参数以解决错误,并注释为什么那个服务器的配置与众不同。

尽管系统管理员很伟大,但他们也有着一些怪癖。其中一项就是没有他们神圣的授权你永远也获取不了系统的 root 访问权限,另一项则是任何不是出于他们的主意的变更都要在文档中被记录为应用提供方的要求,并仍然需要再次核对。

他们所管理的服务器是他们的地盘,没有人可以随意干涉。

SRE:灭霸将为之自豪

与成为系统管理员的道路相反,从开发背景和从系统管理员背景成长为 SRE 的可能性相近。SRE 的职位出现的时长与应用开发环境的生命周期相近。

随着一个组织的发展而引入的类似于持续集成持续发布 (CI/CD) 的 DevOps 概念,通常会出现技能空缺,以让这些 不可变 immutable 的应用部署到多个环境并随着业务需求进行扩展。这将是 SRE 的舞台。的确,一个系统管理员可以学习额外的工具,但大体上成为一个全职的职位更容易跟的上发展。一个专精的专家更有意义。

SRE 使用如 代码即基础设施 infrastructure-as-code 的概念去制作模板,然后调用它们来部署用以运行应用的环境,并以使用一键完整重现每个应用和它们的环境作为目标。因此会出现这样的情况:测试环境中一号服务器里的一号应用的二进制文件与生产环境中十五号服务器的完全一致,仅环境相关的变量如密码和数据库链接字串有所不同。

SRE 也会在配置发生改变时完全销毁一个环境并重新构建它。对于任何系统他们都不带一点感情。每个系统只是个被打了标记和安排了生命周期的数字而已,甚至连例行的对服务器打补丁也要重新部署整个 应用栈 application stack

总结

对于一些情况,尤其是运维一些大型的基于 DevOps 的环境时,一个 SRE 所能提供的用于处理各种规模的业务的专业技能当然更具优势。但每次他们在运气不好走入死胡同时都会去寻求他的系统管理员友人或是 来自地狱的混蛋运维(BOFH) ,得到他那身经百战的故障排除技能,和那些用于给组织提供价值的丰富经验的帮助。


via: https://opensource.com/article/19/7/sysadmins-vs-sres

作者:Vince Power 选题:lujun9972 译者:vizv 校对:wxy

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