欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Fork仓库

程序员文章站 2022-05-13 18:54:04
...

在版本控制术语中,如果你 “fork” 一个仓库,则是指复制它。特别是当你 fork 属于别人的仓库时,你将制作他们仓库的完全一样的副本,之后这个副本便变成你的

“fork” 的概念也不同于”克隆”。在克隆仓库时,你也会获得完全一样的仓库副本,但克隆发生在本地计算机上,并且克隆的是远程仓库。当你 fork 仓库时,会创建远程仓库的一份新副本。新副本也是一个远程仓库,但它现在属于你

fork 不在命令行上执行;也不存在 git fork 命令

修改克隆的仓库

当我们尝试通过 git clone 克隆别人的仓库到本地后,修改其中的文件并提交,然后将本地仓库再推送到远程仓库时,会出现类似如下内容:

Fork仓库

由于我不是仓库所有者,所以我没有权限自动向远程仓库添加我的更改。也就是说,如果一个仓库不属于你的帐户,那么你便不具有修改它的权限。

这里 fork 就要派上用场了!你不能直接修改原仓库,但如果你将仓库 fork 到自己的帐户中,便拥有完全控制权了。

Fork仓库

如上图所示,fork 项目后你的 GitHub 配置文件名称旁边会显示新的项目名称。此外名称下面还会说明原始项目所在的位置。现在你可以 fork GitHub 上的任何公共仓库 - 即你可以将仓库复制到自己的帐户中,并对获得的副本拥有完全控制权。

fork 推送/拉取

fork 是一种在托管服务上完成的操作,如 GitHub。fork 仓库会创建与原始仓库完全相同的副本,并将该副本移动到你的帐户。你对 fork 的仓库拥有完全控制权。修改 fork 的仓库不会更改原始仓库。

查看现有工作

我们可以使用非常强大的 git log 命令,查明其他开发者所做工作的详细信息。

使用 git shortlog 按作者对 commit 分组

Fork仓库

它显示了按作者字母顺序排序的人名所有 commit。在上面的截图中,我们可以看到:

  • Abby Armada 在仓库中添加了一个 commit
  • Addy Osmani 添加了八个 commit
  • Adriano Caheté 添加了一个 commit
  • Akshay Iyer 添加了一个 commit

如果我们只想看到每个开发者的 commit 数量,我们可以添加几个选项:用 -s 仅显示 commit 的数量(而不是每个 commit 的消息),以及用 -n 来按数量排序(而不是按作者姓名的字母顺序)。

$ git shortlog -s -n

Fork仓库

如果我们只想看到 Addy Osmani 的这八个 commit 呢?

使用 --author 选项筛选 commit

另一种显示某个作者所有 commit 的方法是使用常规的 git log 命令,但包含 --author 选项来筛选所述作者的 commit 。

$ git log --author="Addy Osmani"

Fork仓库

注意,在上面开发者姓名列表中,我们看到了 “Paul Irish” 和 “Paul Lewis”,如果我们运行下面的命令:

$ git log --author=Paul

这将显示所有姓名以 "Paul" 开头的作者的 commit。所以它将显示 Paul Irish 和 Paul Lewis 的 commit 。

注意上一个命令中使用的引号。如果它不加引号,像 git log --author=Paul Lewis,就无法正常运行。如果不加引号,Git 会认为 Lewis 不是 "author" 选项的一部分,从而导致错误

使用 --grep 选项筛选 commit

在讲解“按搜索内容筛选 commit”这部分之前,我认为我需要强调一下编写好的描述性提交说明的重要性。编写描述性提交说明,会使你之后能很轻松地搜索提交说明,找到你想要的东西。

那么这些详细信息为何重要呢?一方面,你将能更容易地回头查看对仓库所做的更改,其他人也更容易查看更改。另一方面是你将能根据当前说明或描述区域中的信息筛选 commit 。

另外记住,如果提交说明不足以解释 commit 的内容,则你可以在描述区域中提供关于该 commit 用途的详细说明。

我们可以使用 --grep 选项筛选 commit 。以筛选提到 “bug” 一词的 commit :

$ git log --grep=bug
$ git log --grep bug

注意,空格在这里也是一个问题。如果你尝试搜索包含多个词且单词之间有空格的内容,则需要将空格也包含在引号内。例如,要搜索 unit tests,你需要使用以下命令 git log --grep="unit tests"

Fork仓库

Grep 是一个模式匹配工具,如果你运行 git log --grep "fort",那么 Git 将显示顺序包含字符 fort 的 commit 。

有关 Grep 的更多信息

确定任务

假设你正在使用某个第三方库构建一个项目。如果在使用此第三方库时遇到 bug 或拼写错误,该怎么办?

通过向原项目的维护者发送一个请求,将你的代码更改包含在其中,请求维护者将这些更改拉取到原项目中。这种请求称为“拉取请求”(Pull Request)。

但是,你如何以原项目维护者能接受的方式实际对项目做出贡献,并使他最终合并你的更改?记住,你要做的第一件事,是在项目中寻找一个名为 CONTRIBUTING.md 的文件。

CONTRIBUTING.md 文件

CONTRIBUTING.md 文件的名称特别采用全大写,以方便查找。此文件列出了你要为项目做出贡献时所应遵循的信息。在开始任何开发工作之前,应先找到此文件。

Fork仓库

GitHub Issues

Fork仓库

注意,这里说的”Issues(问题)”并不代表实际存在错误,它可以是需要对项目进行的任何改变。GitHub 的问题跟踪器相当高级。每个问题都可以:

  • 应用一个或多个标签
  • 被分配给个人
  • 确定一个里程碑(例如问题将由下一个主要版本解决)

但问题跟踪器最重要的一个方面在于,每个问题都可以有自己的评论区,使开发者围绕这个问题展开对话。

Fork仓库

Issue 的另一个很棒的功能在于:

  • 你可以订阅(Subscribe)某个 Issue ,这样你便会获得新评论和代码更改的通知
  • 你可以就具体变更与项目维护者持续交流

在向某个文件贡献任何内容之前,请查看 CONTRIBUTING.md 中的说明。然后查看项目的 Issue,看是否有哪些与你要贡献的内容类似。如果有,则订阅该 Issue 并阅读现有的对话,看你是否可以提供帮助。如果你查看了 Issues 列表,没有看到与你要做的事情类似的内容,那么你可以创建自己的新 Issue(New issue)。

New Issue 页

新建问题页好的一点在于,如果项目有 CONTRIBUTING.md 文件,它会在页面顶部显示一个提醒,要求你查看有关如何为项目做贡献的准则。点击”guidelines for contributing”链接,可以转至 CONTRIBUTING.md 文件。

Fork仓库

与编写描述性的提交说明一样,你在创建问题时,要给它一个信息丰富的标题,简要说明你想要做的事情。然后,在评论部分,提供大量关于此更改的详细信息,可以是你为什么认为此更改有必要,也可以是它如何改进项目。

特性分支

组织你想贡献给项目的一系列 commit 或更改的最佳方法,是将它们全部放在一个特性分支上。我说的特性分支是什么意思呢?与主分支不同,主分支是保存整个项目的所有 commit 的默认分支,而特性分支仅保存单个概念或单个更改区域的 commit

例如,如果登录某个网站的登录表单有问题,则解决此特定问题的分支名称可以叫做:

  • login
  • login-bug
  • signup-bug
  • login-form-bug
  • 等等。

要记住的一点是,有时项目会对特性分支的命名有特定要求。例如,如果一个分支将要解决错误修复,那么许多项目会要求添加一个 bugfix- 前缀。回到我们处理登录表单错误的分支,它得被命名为 bugfix-login-form。所以一定要阅读 CONTRIBUTING.md 文件,确定项目是否对特性分支的命名提供了特别说明。

一般实践

编写清晰、描述性的提交说明。你的分支名称和提交说明描述得越清楚,项目维护者用于询问你的代码的用途,或者自己去深入了解代码的时间就越少。项目维护者需要做的工作越少,将你的更改纳入项目的速度就越快。

使用短小而明确的 commit。不要进行大量 commit,记录 10 多个文件和数百行代码的更改。最好频繁多次地进行小的 commit,只记录很少数量的文件和代码更改

更新 README,如果你添加的任何代码更改会使项目发生极大的变化,则应更新 README 文件以向其他人说明此更改。

相关标签: Git命令