译者注：本文由 SegmentFault 翻译整理，原是 teehan+lax 作者 Ash Furrow 的一篇博文，以下是博文内容翻译。

上周，我在 FITC SCREENS 为设计师们做了一次关于GitHub的演讲，你可以在这里看一下演讲的幻灯片。我觉得把演讲的精华内容放在博客上让大家都能看到，是一件很重要的事，所以这就是你接下来将要看到的。

Git是一个管理和更改文件的工具，GitHub的是建立在Git上的一个Web服务。这篇文章就是准备向你介绍一些Git和GitHub的基础知识，并教你如何使用这些工具与你的团队成员协作。

Git可以管理任何类型的文件，但它通常用于文本文件和图像管理。通常情况下，我们不会用它来存储格式比较复杂的文件，比如PSD文件。

我们使用Git有两个主要原因。其一是它可以帮助我们管理多个团队成员在相同的文件上做的更改 —— 帮助我们跟踪谁在什么时候、做什么样的更改。使用Git的好处是很具体的，但它又有一个陡峭的学习曲线。然而，学习Git是伟大的第一步，它教你学着去改变你已设计的项目。本文也不打算深入到命令行或一个特定的工具，而是教你一些高层次的概念，这将有助于你无视工具的不同（因为它们本质上都是一样的）。

分支(Branches)

分支用来隔离文件更改的。想像一下，你所有的文件复制被到一个新文件夹，所做的任何更改只是在副本操作，在最后你 拉(pull) 这些副本放回到原来的文件夹。

一个分支就是像对你所有的文件做一份复制。

“主”分支(“master” branch) 是一个标准分支 —— 所有新分支都是在主分支上创建的。

当你从主分支创建一个新的分支，就像你为所有的文件创建了一份新副本，这些副本上所做的更改并不会反映回原文件夹（更改新分支内容，主分支不会有变化，除非你 push，接下来会有讲到）。

提交(Commits)

当你操作一个分支时，就像你正在做修改这些文件的副本。当你完成了一个更改，比如增加了一些新的CSS，你应该 提交(Commits) 你的修改。这种“保存”在新目录中的新文件的快照，可以让你随后 恢复(revert) 到该时间点。在你提交之前，没有什么是永久的，所以你可以很容易地做出一些奇怪的、实验性的更改，看它是否还能正常工作。

当你提交时，你只是提交给你的分支，你的分支仍然是那个主分支的一部分，代表的是一系列的提交操作之后的结果。

上图你的分支(Your Branch) 就是有两次提交结果之后的分支，依旧是主分支的一部分。

本地和远程(Local & Remote)

这是让Git变得有点复杂的那部分。主分支和你的分支都存在于 本地(Local)，也有主分支的一个副本在GitHub上，即 远程端(Remote)。这就像在办公室有一个共享文件服务器，它有一个与你保持同步的文件夹。

当你创建一个新的分支，所有的修改都是在本地操作（你电脑的文件夹中）。

同样，你的分支只存在于你的本地计算机上，直到你把它 推到(push) 远程端，这就是接下来要说的。

推送和拉回(Pushing & Pulling)

当你准备向人展示你的更改时，你就应该把你的分支，其中包括变更，都 推送(push) 到GitHub上。这类似于你把自己本地最新版本的文件夹复制到共享的文件服务器。

现在你的最新版本分支在本地和远程端都有了。一旦你把你的更改推送到GitHub上，就需要创建一个 拉回(pull) 的请求（原因往下看），这是一个将你的分支更改拉回到主分支的请求。

一旦这些更改都被拉入远程主分支，你的本地主分支的版本是过时的（记住，此时你的分支上的更改会被暂时孤立），所以现在又需要从远程拉最新的版本来更新您的本地主分支，就像从服务器重新复制原始文件。

现在就令人困惑了，因为我们在两种情况下都使用了“拉”一词。第一次，我们想把我们的分支更改合并到主分支；第二次，我们想把主服务器上的更改拉回到本地以保持最新版。

总之，Git是团队协作时一个非常好用的文件管理工具，不过学起来确实比较复杂。我们都知道要想熟悉它，最好的方式就是不断去用它。

原文 GitHub Fundamentals
翻译整理 SegmentFault