Git

最初，Linux Kernel 的社群采用压缩档或是补丁的方式进行维护工作。一直到 2002 年，开发 BitKeeper 的商业公司与社群合作，让 Linux Kernel 社群改用 BitKeeper 这套分散式的版本控制系统进行维护工作。

这份合作关系一直持续到西元 2005 年，因为一起与逆向工程有关的争议结束。这也迫使了社群以及 Linus Torvalds 需要一套可靠的解决方案。因此，Linux kernel 的主要贡献者 - Linus Torvalds 吸收了使用 BitKeeper 时得到的经验，打造了一套能使用於社群的版本控制系统，也就是当今广为人知的 Git。

The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):

• random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
• "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
• stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.

关於 Linus 的故事，可以参考他在 Ted 中的演讲： Linus Torvalds: The mind behind Linux | TED Talk。

Git 的资料流与储存层

图片取自维基百科。

• 本地仓储

  • 工作目录
    一般来说，工作目录就是指你的专案资料夹，假设专案尚未使用 Git 进行版本控制，我们可以在安装 Git 以後使用以下命令进行初始化：

    git init
    

  • 索引
    在专案资料夹中进行初始化後，Git 会在工作目录中担任观察者的角色 (观察每个档案的整体性是否有改变)，不过，在预设情况下，Git 是不会留意这些档案的。
    因此，若要针对部分档案进行版本控制，我们需要将目标档案做索引，索引档案的命令如下：

    git add index.py
    

    当然，我们也可以一次索引多个档案：

    git add .
    

    索引後，我们可以利用 git status 查看专案的当前状态，Git 便会告诉我们档案已经从 Untracked files 变成 Changes to be committed (可以提交至仓储的状态了)。
  • 仓储
    将档案进行索引後，如果我们觉得目前专案已经到达了某个段落，我们可以使用 git commit 将专案提交至仓储，成为专案的第一个版本。
    不只如此，好的工程师会留下一些资讯供其他开发者参考，我们可以在提交时使用 -m 参数补充提交讯息：

    git commit -m "我完成了 index.py 啦 QWQ"
    

• 远端仓储
  既然专案开发都会是多人协作的，我们就会需要有一个地方能够存放整个专案的仓储，现今较为热门的远端仓储服务有两个选项：

  • GitHub
  • GitLab

  如果要将本地仓储推至远端仓储，需要使用 git push 命令，在 push 之前，还需要先让 Git 知道这些资料要推到哪个远端节点上：

  git remote add origin xxx.xxx.git
  

  新增远端节点 origin 以後，我们就可以将本地资料推至远端仓储啦～

  git push origin master
  

  上面的命令代表： 将 master 分支送至远端仓储 origin 节点的 master 分支，如果远端不存在 origin 分支，你就自动帮我建立一个吧！

  • master 是 Git 本地仓储预设的分支名称，至於分支是什麽，可以在本文的後半部看到。
  • 顾及族群和身份认同的平权，GitHub 已经将预设的分支名称改为 main。

多人协作的世界

分支的概念

在文章的上半部有提到，master 是 Git 的预设分支名称，那为什麽 Git 会需要分支呢？
试想，我们开发了一个部落格系统，但我们希望为他增加文章分类功能，在我们完成新功能并通过测试之前，势必会提交多个 Commit。
在这个情况中，如果我们都只在 master 分支做开发，就会没办法区隔目前稳定工作的版本是那一个 commit，一般来说，我们会针对新功能的开发设立一个新的分支。

根据上图，我们可以知道目前 head 与 master 都指向 e137e9b 这一个 commit。
接着，笔者在 master 分支提交了一个新的 commit (7036d33):

为了增加部落格的分类功能，需要建立一个 feat/sort 分支:

git branch feat/sort

这样一来，就成功建立新分支啦！

建立新分支以後，我们要把 head 指向 feat/sort，这样子之後提交的程序码才会送至 feat/sort 分支：

git checkout feat/sort

Git 练习场的功能好像不够完整，当我把分支命名为 feat/sort 时会 head 会无法顺利切换，所以我在这边以 feat-sort 代替 feat/sort。

切换到 feat/sort 分支後，开发团队用了 2 次 commit 将新功能完成了，这时，我们需要将 head 切换回 master 分支并将 feat/sort 分支合并：

git checkout master
git merge feat/sort

PR 是什麽？能吃吗？

Pull request (PR) 是在软件开发上常见的协作方式，当你在 GitHub 上看到有趣的专案并想为它增加新功能时，可以使用网站上的 fork 按钮复制一份专案到自己的帐号底下。
开发完成後，我们可以在自己的 GitHub 的复制专案中看到 Create a pull request，提交拉取请求後，如果原作者喜欢你新增的功能他就会将你的分支合并回他的专案中。

更多资讯可以参考 与其它开发者的互动 - 使用 Pull Request。

常见的开发流程

• Git flow
• GitHub flow

Reference

• 连猴子都能懂的 Git 入门指南
• git
• Getting Started - A Short History of Git
• 为你自己学 Git