如何向工具初学者介绍分布式版本控制系统Git.doc

如何向工具初学者介绍分布式版本控制系统Git本文主题是如何向工具初学者介绍分布式版本控制系统 Git。除了了解关于 Git 的基本知识以外，大家还可以学到一些工具学习方面的东西。我发现的问题我的一些职业经历涉及跨职能领域，因此我了解所有同事的工作方式。我记得有一家公司在我加入的几周前才开始使用 Git。我用三步把 post-it 放到屏幕上：第一步是 add，第二步是 commit，第三步是 push。他们不知道为什么要用这三步，他们只知道为了防止发生其他问题，他们应该遵循这三个步骤。但是问题还是频频发生，所以我决定准备一个关于 Git 的讨论会。想法我喜欢在头脑中绘图。我不写思维导图，因为它们是众所周知的图像形式。而我所说的图是一种大脑中的有框架、结构化或其他形式的图像表征。例如，我在头脑中想象骰子来学习加法。所以我准备了一些图。理解这篇文章不一定需要看懂这些图。但出于可访问性，我对每一张图都作出了解释。在这种情况下，词汇的教学就非常重要了。否则他们无法理解来自 Git 的信息。这些图是一种很好地向他们介绍词汇的方式。分布式版本控制系统概括图包括四部分，分别是：开发环境中的：工作区暂存区或索引本地版本库服务器中的：远程版本库到那个时候，你就可以解释分布式版本控制系统的好处了。复制版本库在复制版本库时，远程版本库中的数据要传递到两个区域：工作区本地版本库在工作区中进行更改工作区中有两类文件：追踪文件：Git 知道的文件。未追踪文件：因为尚未添加因此 Git 不知道的文件。更新远程版本库当工作区更改就绪时，必须先把它们添加到暂存区中。当暂存区中有一组特定的更改时，我们就需要在本地库中创建带有这些特定信息的 commit。当本地版本库中有一或多个准备和世界其他地方共享的 commit 时，我们必须把它们 push 到远程版本库中。这时，开发环境中的文件状态已经有所不同了：已修改、已暂存和已提交（modified, staged and committed）。此外，你还可以解释：如何显示工作区的文件更改：git diff如何显示暂存区的文件更改：git diff staged在将文件添加到暂存区后，如何在工作区中更改文件等等更新开发环境抓取（fetch）执行 git fetch 后，远程库中的数据将仅传递到本地库中。Pulling当执行 git pull 后，远程库中的数据会传输到两个区域：本地库：抓取（fetch）工作区：合并（merge）你可以用 git pullrebase 查看 commit 历史。它是由 fetch + rebase 而不是 fetch + merge 组成的。它将会重新执行你的本地提交，而且你无法看到提交历史中已知的 diamond shape。下一步你可以在开发环境中添加另一个区域来解释暂存区：dirty work directory。如果人们将这些概念内化，他们就可以建立坚实的基础，从而更容易地使用分支、提交历史以及衍合（rebasing）等。温馨提示我也曾用过其他版本控制系统（Visual SourceSafe、TFS 和 Subversion），以我的个人经验来讲，缺乏知识对于使用旧工具和新工具而言都有害。我们不仅仅要选择工具，还要掌握工具。