This book is dedicated to the generous people that made the Git community such an awesome environment to work within. You have helped create one of the most useful tools in the tech world. Thank you!
本书献给那些慷慨的人，是他们把Git社区变成如此一个棒的可以工作的环境。在你们的帮助下才创建了科技世界里最有用的工具之一。歇息你们！
目录
Part I: Version Control with Git
Chapter 1: Version Control Systems
What is Version Control?
Why do you need one?
What are the choices?
Local Version Control Systems
Centralized Version Control Systems
Distributed Version Control Systems
What is Git?
What can Git do?
How does Git work?
What is the typical Git workflow?
Summary
Chapter 2: Installation and Setup
Installation
Windows
Mac
Linux
Setting up Git
Summary
Chapter 3: Getting Started
Repositories
Working Directory
Staging Area
Commits
Quick start with Git
Summary
Chapter 4: Diving into Git
Ignoring files
Checking logs and history
Viewing previous versions
Reviewing the current changes
Summary
Chapter 5: Commits
The three states of Git
Navigating between versions
Undo a commit
Modifying a commit
Amending a commit
Summary
Chapter 6: Git Best Practices
Commit messages
Git commit best practices
What to do
What not to do
How Git works (again)
Summary
Chapter 7: Remote Git
Why work on remote
How does it work
The easy way
Summary
Part II: Project Management with GitHub
Chapter 8: GitHub Primer
GitHub overview
GitHub and Open Source
Personal use
GitHub for businesses
Summary
Chapter 9: Quick Start with GitHub
Project management
How remote repositories work
Linking repositories
Pushing to remote repositories
Summary
Chapter 10: Beginning Project Management: Issues
Overview on issues
Creating an Issue
Interacting with an issue
Labels
Assignees
Linking issues with commits 1
Working on the commit
Referencing an issue
Closing an issue using keywords
Summary
Chapter 11: Diving into Project Management: Branches
GitHub workflow
Branches
Creating a branch
Switching to another branch
Deleting a branch
Merging branches
Pushing a branch to remote
Summary
Chapter 12: Better Project Management: Pull Requests
Why use Pull Requests?
Overview on Pull Requests
Pull
What does a PR do
Create a Pull Request
Code Reviews
Give a Code Review
Leave a review comment
Update a Pull Request
Summary
Part III: Teamwork with Git
Chapter 13: Conflicts
How a merge works
Pulling
Fast-forward merge
Merge conflicts
Pulling commits from origin
Resolving merge conflicts
Summary
Chapter 14: More About Conflicts
Pushing after a conflict resolution
Review changes before merge
Check branch location
Review branch diff
Understand Merging
Reducing conflicts
Having a good workflow
Aborting a merge
Using a visual Git tool
Summary
Chapter 15: Git GUI Tools
Default tools
Committing: git-gui
Browsing: gitk
IDE tools
Visual Studio Code
Atom
Specialized tools
GitHub Desktop
GitKraken
Summary
Chapter 16: Advanced Git
Reverting
Stashing
Resetting
Summary
Part IV: Additional Resources
Chapter 17: More with GitHub
Wikis
GitHub Pages
Releases
Project Boards
Summary
Chapter 18: Common Git Problems
Repository
Starting over
Change origin
Working Directory
Git diff is empty
Undo changes to a file
Commits
Error in commit
Undo commits
Branches
Detached HEAD
Worked on wrong branch
Catch up with parent branch
Branches have diverged
Summary
Chapter 19: Git and GitHub Workflow
How to use this workflow
GitHub workflow
Every project starts with a project
Every action starts with an Issue
No direct push to master
Any merge into master needs a PR
Use the wiki to document your code
Git workflow
Always know where you are
Pull remote changes before any action
Take care of your commit message
Don’t rewrite history
Summary
Index
Chapter 1：版本控制系统
顾名思义，版本控制是对一个项目的多个版本的管理。要管理版本，必须跟踪项目中文件的每次更改（添加、编辑或删除）。版本控制记录对一个文件（或一组文件）所做的每个更改，并提供撤消或回滚每个更改的方法。
为了实现有效的版本控制，您必须使用称为版本控制系统的工具。它们可以帮助您在更改之间导航，并在出现问题时让您快速返回到以前的版本。
除此之外，使用版本控制最重要的优点之一是团队合作。当一个项目中有多个人参与时，跟踪更改就变成了一场噩梦，它大大增加了覆盖另一个人更改的可能性。使用版本控制，多个人可以处理他们的项目副本（称为分支），并且只有当他们（或其他团队成员）对工作满意时才能将这些更改合并到主项目中。
注意：这本书是从开发人员的角度写的，但其中的所有内容都适用于任何文本文件，而不仅仅是代码。版本控制系统甚至可以跟踪许多非文本文件（如图像或Photoshop文件）的更改。
回忆一下，您是否曾经处理过一个文本项目或一个需要您回忆对每个文件所做的特定更改的代码？如果是，您是如何管理和控制每个版本的？也许你试着用后缀“review”、“fixed”或“final”来复制和重命名文件？图1-1显示了这种版本控制。
这样做有一个问题，很容易忘记哪个文件是哪个文件以及它们之间发生了什么变化。
另外一个想法是压缩文件并在名称上附加时间戳，以便按创建日期排列版本。图1-2显示了这种对版本的跟踪。
图1-2所示的解决方案似乎是一个完美的系统，直到您意识到即使跟踪版本，也无法知道每个版本的内容和描述。
为了纠正这种情况，一些开发人员使用了如图1-3所示的解决方案，即将每个版本的更改摘要放在一个单独的文件中。
如图1-3所示，项目文件夹附带一个单独的文件，简要描述所做的更改。还要注意包含项目早期版本的许多压缩文件。
应该可以的，对吧？不完全是这样，您仍然需要一种方法来比较每个版本和每个文件更改。在那个系统里没有办法做到这一点，你只需要记住你所做的一切。如果项目越来越大，每个版本的文件夹都会越来越大。
当其他开发人员或编写人员加入您的团队时会发生什么？你会把你编辑的文件或版本发邮件给对方吗？或者在同一个远程文件夹上工作？在最后一个例子中，您如何知道谁在处理哪个文件以及更改了什么？
最后，你有没有觉得有必要在不破坏过程中的一切的情况下，撤销几年前所做的改变？一个无限和全能的ctrl-z？
所有这些问题都通过使用版本控制系统或VCS来解决。VCS跟踪您对项目的每个文件所做的每个更改，并提供一种简单的方法，它可以对比并回滚这些更改。项目的每个版本还附带所做更改的描述以及新文件或已编辑文件的列表。当更多的人加入这个项目时，风投可以准确地显示谁在特定时间编辑了特定的文件。所有这些都让你为你的项目赢得了宝贵的时间，因为你可以专注于写作，而不是花时间跟踪每一个变化。图1-4显示了一个由Git管理的版本化项目。
如图1-4所示，一个版本化项目结合了我们在本章中尝试的所有解决方案。有变更描述、团队合作和编辑日期。
版本控制系统有很多种，每种都有各自的优点和缺点。VCS可以是本地的、集中式的或分布式的。
1. Local Version Control Systems（本地版本控制系统）
这些是为管理源代码而创建的第一个VCS。他们通过跟踪本地存储的单个数据库中对文件所做的更改来工作。这意味着所有的更改都保存在一台计算机中，如果出现问题，所有的工作都将丢失。这也意味着与团队合作是不可能的。
2. Centralized Version Control Systems（集中式版本控制系统）
集中式VCS（centralizedvcs）的工作原理是将更改历史存储在客户机（作者）可以连接的单个服务器上。这提供了一种与团队合作的方法，也提供了一种监控项目总体进度的方法。它们仍然很受欢迎，因为概念非常简单，而且很容易设置。
3. Distributed Version Control Systems（分布式版本控制系统）
分布式VCS的工作原理与集中式VCS几乎相同，但有一个很大的区别：没有主服务器保存所有历史记录。每个客户机都有一个存储库副本（以及更改历史记录），而不是签出单个服务器。
Git能做什么？
首先，它非常适合跟踪更改。你可以
•在版本之间来回切换
•审查这些版本之间的差异
•检查文件的更改历史
•标记特定版本以供快速参考
Git也是团队合作的好工具。你可以
•在存储库之间交换“变更集”
•审查他人所做的更改
Git的一个主要特性是它的分支系统。分支是一个项目的副本，您可以在不影响存储库的情况下处理它。这个概念已经存在了一段时间，但是使用Git，它会更快、更高效。分支还伴随着合并，合并是复制分支中完成的变更集到源数据集的行为。
通常，您创建一个分支来创建或测试一个新特征，并在对工作满意时将该分支合并回来。
还有一个简单的概念，你可能会用到很多：藏匿。隐藏是指安全地将当前编辑内容放在一边，这样您就有了一个干净的环境来处理完全不同的内容。当您在玩或测试一个特性时，您可能希望使用隐藏，但需要优先处理一个新特性。因此，您将更改隐藏起来并开始编写该特性。完成后，您可以将更改恢复并应用到当前的工作环境中。
作为小菜一碟，以下是您将在本书中学习的一些Git命令：
$ git init # Initialize a new git database
$ git clone # Copy an existing database
$ git status # Check the status of the local project
$ git diff # Review the changes done to the project
$ git add # Tell Git to track a changed file
$ git commit # Save the current state of the project to database
$ git push # Copy the local database to a remote server
$ git pull # Copy a remote database to a local machine
$ git log # Check the history of the project
$ git branch # List, create or delete branches
$ git merge # Merge the history of two branches together
$ git stash # Keep the current changes stashed away to be used later正如您所看到的，这些命令是非常不言自明的。不要担心把它们都背下来，当我们开始学习的时候，你会一个一个的记住它们。而且您不会一直使用它们，您将主要使用git add和git commit。您将了解每个命令，但我们将重点介绍您可能在专业环境中使用的命令。但在此之前，让我们看看Git的内部工作
与许多版本控制系统不同，Git使用的是快照，而不是差异。这意味着它不会跟踪文件的两个版本之间的差异，而是拍摄项目的当前状态。
Git的主要特点是它的“三态”系统。状态为工作目录、临时区域和git目录：
•工作目录只是您正在处理的当前快照。
•暂存区是修改后的文件在其当前版本中标记的地方，还没有存储在数据库中。
•git目录是存储历史的数据库
因此，基本上Git的工作原理如下：修改文件，将要包含在快照中的每个文件添加到临时区域（Git add），然后获取快照并将其添加到数据库（Git commit）。对于术语，我们将添加到暂存区域的修改文件称为“staged”，将添加到数据库的文件称为“committed”。因此，文件从“modified”到“staged”再到“committed”
什么是典型的Git工作流？
为了帮助您形象化我们在本节中讨论的所有内容，下面是一个使用Git的典型工作流的小演示。如果你现在什么都不懂，别担心，下一章会帮你准备好的。
这是你上班的第一天。您的任务是将您的姓名添加到现有的项目描述文件中。由于这是您的第一天，一位高级开发人员将在那里检查您的代码。
你应该做的第一件事就是获取项目的源代码。向经理询问存储代码的服务器。对于这个演示，服务器是GitHub，这意味着Git数据库存储在GitHub托管的远程服务器上，您可以通过URL或直接在GitHub网站上访问它。在这里，我们将使用clone命令来获取数据库，但是您也可以从GitHub网站下载项目。您将得到一个zip文件，其中包含项目文件及其所有历史记录。
因此，您可以使用“clone”命令克隆存储库以获取源代码。
git clone https://github.com/mariot/thebestwebsite.git然后，Git下载当前目录下的存储库副本。之后，可以进入新目录并检查其内容，如Figure 1-8中所示
如果要检查最近对项目所做的更改，可以使用“log”命令来显示历史记录。图1-9显示了一个例子。
很好！现在你应该创建一个新的分支来工作，这样你就不会把项目搞砸了。您可以使用“branch”命令创建一个新分支，并使用“checkout”命令将其签出。
git branch add-new-dev-name-to-readme
git checkout add-new-dev-name-to-readme现在创建了新分支，您可以开始修改文件了。你可以使用任何你想要的编辑器；Git将通过校验和跟踪所有的变化。现在您已经做了必要的更改，是时候把它们放到临时区域了。作为提醒，暂存区域是您放置已修改代码的地方，这些代码已准备好进行快照。如果我们修改了“自述文件.md”文件，我们可以使用“add”命令将其添加到临时区域。
git add README.md您不必将修改过的每个文件都添加到临时区域，只需添加希望在快照中记帐的文件即可。既然文件已暂存，现在是“提交”它或将其更改放入数据库的时候了。我们通过使用“commit”命令并附加一点描述来实现这一点。
git commit -m "Add Mariot to the list of developers"就这样！您所做的更改现在已保存在数据库中并安全存储。但只在你的电脑上！其他人看不到您的工作，因为您在自己的存储库和其他分支上工作。要向其他人展示您的工作，您必须将提交推送到远程服务器。但是你必须先向高级开发人员展示代码，然后再进行推送。如果他们同意，您可以将您的分支与项目的主快照（称为主分支）合并。因此，首先必须使用“checkout”命令导航回主分支。
git checkout master您现在位于主分支上，团队的所有工作都存储在这里。但是，当您进行修复时，项目可能已经更改，这意味着团队成员可能已经更改了一些文件。在将自己的更改提交给主服务器之前，应该检索这些更改。这将限制两个或多个贡献者更改同一文件时可能发生的“冲突”风险。要获得更改，必须从远程服务器（也称为源服务器）中提取项目。
git pull origin master即使其他同事更改了与您相同的文件，冲突的风险也很低，因为您只修改了一行。只有当同一行被多人修改时，才会发生冲突。如果你和你的同事改变了文件的不同部分，一切都没问题。
现在我们跟上了项目的当前状态，是时候将我们的版本提交给master了。您可以使用“merge”命令合并分支。
git merge add-new-dev-name-to-readme既然提交已经合并回主服务器，现在是将更改推送到主服务器的时候了。我们通过使用to“push”命令来实现。
git push
就这么简单！再说一次，如果你还不了解所有的事情，不要担心。这只是Git通常是如何使用的一个小演示。这也是不太现实的：没有一个经理会给一个新员工一个像这样的主存储库的访问权限。
Chapter 2：安装和设置
既然您了解了什么是版本控制以及Git是如何工作的，我们将学习如何安装和设置它。与其他章节相比，本章较短，因为设置Git非常容易。
Installation
安装Git所需的文件位于https://git-scm.com/downloads适用于所有系统。只需按照链接选择您的操作系统。
您还可以在图2-1中看到，Git的GUI客户端也在那里可用。在你完成这本书的第三部分，“Git的团队合作”之前，不要去那里。在使用GUI客户机之前，您需要熟悉Git命令；如果不熟悉，您将浪费大量时间来解决一个简单的问题，而使用简单的Git命令需要几秒钟的时间。
在熟悉Git命令之后，您可以查看GUI客户机并亲自查看。在本书的最后一部分有一章是关于GUI客户机的。但在此之前，请不要使用任何GUI客户端；这将大大延长您的学习时间。
在Windows系统上安装Git非常简单。打开链接后(https://gitscm.com/download/win)，下载将自动开始，您将到达如图2-2所示的确认页面。如果没有，只需下载与您的Windows风格相对应的构建。
执行下载exe文件以开始安装。第一个屏幕是概述条款和条件的许可声明；您应该一直读到最后（是的，没错）。单击next，您将进入一个组件选择屏幕，类似于图2-3所示的屏幕。在这里，系统会提示您选择要安装的组件。我建议保留默认选项。
您可以在图2-3中看到，您只需检查组件即可安装它们。保持Windows资源管理器集成处于选中状态是一个好主意；这样您只需右键单击一个文件夹，就可以在默认GUI或上下文菜单中的Bash（命令窗口）中找到启动Git的选项。所有其他的组成部分都是不言自明的，所以决定权在你。
提示：如果您没有安装Windows资源管理器集成，并且希望在文件夹中打开命令窗口，则必须使用shift+右键单击打开扩展上下文菜单。
做出选择后单击next，您将看到默认的编辑器选择，如图2-4所示。Git需要您定义一个默认编辑器，因为您需要一个编辑器来编写提交描述和注释。
如图2-4所示，由于历史原因，Vim是Git的默认编辑器。只需从下拉列表中选择您最喜欢的文本编辑器。前两个，Nano和Vim，在控制台或命令窗口中工作，因此您不必打开另一个程序。在列表中，您可以找到许多流行的编辑器，如Notepad++、Sublime Text、Atom和VisualStudio（VS）代码。如果你的编辑器没有列出，你可以选择最后一个选项，一个新的输入将出现（如图2-5所示），这样你就可以提供一个到编辑器主可执行文件的链接。
一旦你选择了你喜欢的编辑器，你可以进入下一个屏幕，这是路径环境调整，如图2-6所示。PATH环境是一个变量，它包含可执行程序所在的目录列表。它是必需的，这样当您想在控制台中执行一个可执行文件时，就不必键入它的完整路径；只需键入它的名称。例如，要从控制台启动VisualStudio代码，我应该键入C:\ProgramFiles（x86）\Git\bin\Git.exe。但由于我的路径中有C:\ProgramFiles（x86）\Git\bin，所以我只需键入“Git”即可启动它。
如果您不想这样，只想将Git与自己的独立控制台“gitbash”一起使用，请选择第一个选项。因此，要使用Git，您必须从Apps列表或文件夹的上下文菜单启动它（如果您选择安装Windows资源管理器集成）
如果您想在任何地方都能使用Git，请保留默认选项，将其添加到您的路径环境中。这样，其他工具也可以使用Git，您可以在任何命令窗口中工作。我强烈建议这个选择。
最后一个选择是有点侵入性的。它将向您的路径中添加许多Git命令，并将覆盖Windows的一些默认工具。只有在你有正当理由的情况下才选择这个；一般来说，你没有这样的理由。
选择一个如图2-6所示的选项并继续下一步。您将看到一个关于HTTPS连接的屏幕，如图2-7所示。通过HTTPS发送数据时，必须选择要使用的库。在本书的后面部分，您将必须连接到远程服务器（因为Git是一个分布式VCS）才能将您的提交共享给其他人，因此必须对所有这些连接进行加密，以进一步保护您的数据并确保它们不会被窃取
在此之后，转到下一步，这是关于行结束。同样，这是一个选择屏幕，所以您的屏幕应该如图2-8所示。不同的操作系统对文本文件的操作方式不同，特别是在处理行尾时。很可能你的团队会使用不同的操作系统。因此，Git需要在共享提交之前将行尾转换为每个行尾样式
下一步是选择默认的终端（或控制台）仿真器。这是一个简单的选择屏幕，如图2-9所示。gitbash需要一个控制台模拟器才能工作，所以您需要选择一个。默认的模拟器是MinTTY，另一个选项是Windows的默认控制台。
我建议保留默认选项，因为MinTTY可以做Windows控制台窗口所能做的一切，但在各个方面都更好。单击“下一步”继续执行最后一步。
我们现在到了最后一局了！这个安装快结束了。只是一些东西在额外的选项屏幕调整。这个屏幕（如图2-10所示）允许您启用一些额外的特性，这些特性将非常适合您的Git安装。例如，Git凭证管理器将帮助您安全地连接到远程服务器，并与其他Git工具配合使用。
只需保留默认选项，除非你有理由不这样做。之后，只需启动安装并让它完成。就这样！Git已安装在您的Windows系统上。但在使用它之前，请跳到下一节以正确设置它！
Setting up Git
在开始使用Git之前，您需要先进行一些设置。您可能只执行一次，因为所有设置都存储在一个外部全局文件中，这意味着您的所有项目将共享相同的配置。还有一种方法可以一个接一个地配置项目，但我们稍后将看到这一点
由于Git是一个分布式版本控制系统，有朝一日您将需要连接到其他远程存储库。为了避免犯任何身份错误，有必要向Git介绍一下你自己。别担心，它不会问你一些奇怪的问题！
要设置Git，请打开gitbash（对于Windows系统）或默认控制台窗口（对于修改了路径环境的Linux/MacOS或Windows系统）。在命令提示符下，只需告诉Git您的姓名和电子邮件地址：
$ git config --global user.name "Mariot Tsitoara"
$ git config --global user.email "[email protected]请注意“global”参数；这意味着该设置适用于所有将来的Git存储库，因此您以后不必再次设置它。
使用config命令，还可以更改默认编辑器。如果你想改变你的编辑器，因为你发现了一个新的或卸载了你的，config命令可以帮助你。例如，要将默认编辑器更改为Nano，可以键入
$ git config --global core.editor="nano您可以在主文件夹中找到记录Git配置的文件。对于Windows，您可以在C:\Users\YourName\.gitconfig中找到它。对于Linux和Mac OS，您可以在/home/yourname/.gitconfig中找到它，如图2-13所示。
在.gitconfig文件旁边，您可能会找到另一个名为.bash\u history的文件，它记录您在控制台上键入的所有命令。如果要重新检查忘记的命令，可以检查此文档。
CHAPTER 3： 入门
你终于可以开始使用Git了！在本章中，您将学习一些Git术语和任何项目所必需的概念。然后，您的任务是设置一个项目，对其进行更改，检查更改，最后在版本之间导航。我们走！
Repository（仓库）
存储库是保存所有项目和对其所做的所有更改的存储库。您可以将其视为“更改数据库”，但不要担心；它并不是数据库，只是一个普通文件夹，因此很容易操作。
对于要用Git管理的每个项目，必须为其设置一个存储库。设置存储库非常简单。只需导航到您想要跟踪的文件夹，并告诉Git在那里启动一个存储库。
所以对于每个你想开始的项目，你应该
•创建文件夹
•导航到文件夹
•初始化Git存储库
看到了吗？这很简单。让我们把这些语句转换成命令。但是首先，让我们打开一个控制台来输入命令。对于Linux用户，您只需启动您最喜欢的终端（对于类似Debian的发行版，使用Ctrl-Alt-T）。对于MacOS，您只需使用Cmd Space打开Spotlight，在那里您可以搜索终端应用程序。Windows用户可以打开两个控制台：cmd和powershell。Powershell更为现代，并具有类似UNIX的命令。要打开其中一个，请使用Windows-R并键入名称（cmd或powershell）。注意，如果第一次安装Git时打开了这些控制台，则需要重新启动它们。gitforwindows还附带了一个名为gitbash的控制台仿真器，它提供了与Linux和Mac控制台类似的环境。如果你使用Windows，我强烈建议你使用gitbash，这样你就可以和其他使用不同操作系统的人有相同的体验。
$ mkdir mynewproject
$ cd mynewproject/
$ git initmkdir是用于创建目录的命令；它是“make directory”的缩写。cd是用于在目录之间导航的命令；它是“change directory”的缩写。最后，git init是“git initialize”的缩写。
初始化存储库后，Git将告诉您数据库是在哪里创建的，如图3-1所示。
Git将创建一个名为“.Git”的目录，其中包含所有变更集和快照。如果您想签出它，您将不得不显示隐藏的文件从您的文件资源管理器的设置。存储库的目录如图3-2所示。
如果打开.git目录，您将发现更多属于git数据库的项。如图3-3所示。
还记得第一章说Git不跟踪版本之间的更改，而是拍摄快照吗？所有这些快照都存储在“.git”目录中。每个快照都称为“提交”，我们将在本节之后不久对此进行研究。
此“.git”目录中的头文件指向您正在处理的项目的当前“分支”或子版本。默认的分支称为“master”，但它与任何其他分支一样；名称只是一个旧的约定。
您还应该知道，初始化是获取存储库的唯一方法。您可以复制整个存储库及其所有历史记录和快照。它被称为“克隆”，我们将在另一章中看到这一点。
Working Directory（工作目录）
那么“.git”目录外的空白区域呢？它被称为工作目录，您要处理的文件将存储在那里。通常，您的最新版本将在工作目录中。
您处理的每个文件都在工作目录中。这个地方没有什么特别之处，只是你只会直接操作这里的文件。永远不要修改“.git”目录中的文件！
Git将检测到您将要放入工作目录中的任何新文件。使用Git命令“status”检查目录的状态
$ git status例如，如果我们创建一个名为自述文件.md在工作目录中，我们将看到Git将知道项目已经更改。确保将新文件放在.git目录旁边，如图3-4所示，而不是放在其中！
如果我们检查工作目录的状态，就会得到如图3-5所示的结果。
如图3-5所示，我们还没有任何提交；这是因为我们仍然在工作目录中，还没有拍摄任何快照。它还表示我们在“master”分支上；它是存储库初始化时创建的唯一分支的默认名称。然后我们得到未追踪的文件。这些是我们修改过的文件（在本例中是创建的）
基本上，这就是工作目录：您直接与项目文件交互的区域。
Staging Area（暂存区）
暂存区域是拍摄快照之前文件的存放位置。在获取项目当前状态的快照时，不应考虑在工作目录中修改的每个文件。只有放置在临时区域中的文件才会被快照。
因此，在对项目进行快照之前，您可以选择要考虑哪些更改的文件。文件中的更改可以是创建、删除或编辑。
把它想象成指定哪些文件会出现在家庭照片中。要将文件添加到临时区域，我们使用Git命令“add”
$ git add nameofthefile就这么简单。如果我们想上演自述文件.md我们之前创建的，我们将使用“git add自述文件.md或者，如果您创建了多个文件，您可以将它们一个接一个地添加到一起，就像“git add file1 file2 file3”
让我们使用以下命令暂存新文件：
$ git add README.md然后让我们用git status命令检查状态：
$ git status将文件添加到临时区域不会产生任何可见的结果，但是检查状态会得到类似于图3-6的结果。
如果您查看图3-6，您将注意到在暂存文件之后，工作目录再次是干净的。这是因为“git status”只跟踪“unstage”文件（未标记为快照的已编辑文件）。
如图3-6所示，您可以使用Git命令“Git rm”和选项“--cached”来取消文件的暂存。
$ git rm --cached README.md小心不要忘记在取消暂存文件时使用“--cached”选项。如果你忘了它，你可能会丢失你的文件！
在你准备好所有的文件之后，你就可以开始你的第一个快照了！
Commits（提交）
正如我们在本节之前所讨论的，提交只是整个项目在某个特定时间的快照。Git不会记录对文件所做的单个更改；它会拍摄整个项目的照片。
除了快照之外，提交还包含有关内容的“作者”和“提交者”的信息，或者是谁将变更集放入存储库的信息。
由于提交是来自项目状态的快照，因此项目的前一个状态是另一个提交，称为“父级”，第一个提交是在创建存储库时由Git创建的，并且是没有父级的提交。所有未来的提交都通过亲子关系相互链接。这些相互为父的提交的集合称为“分支”
注意：如果提交有两个父级，这意味着它是通过合并两个分支创建的。
提交由其名称标识，这是一个40个字符的字符串，通过对提交进行哈希处理获得。它是一个简单的SHA1散列，因此具有相同信息的多个提交将具有相同的名称。
对特定提交的引用称为“head”，它还有一个名称。您当前正在处理的头部称为“头部”（请参阅上一节）。
我们现在可以提交我们之前提交的文件。在每次提交之前，您应该检查工作目录和临时区域的状态。如果要提交的所有文件都在暂存区域（在短语“要提交的更改”下），则可以提交。如果没有，你就得用“git add”将它们放在舞台上。
为了提交我们所做的所有更改，我们使用“git commit”。这将获取项目当前状态的快照。
$ git commit如果我们执行这个命令，它将打开我们的默认编辑器（如果您想修改您的编辑器，请查看第2章），并向我们请求提交消息。提交消息是对提交中与前一个消息相比发生了哪些变化的简短描述。
我的默认编辑器是Vim，因此如果执行commit命令，我将看到如图3-7所示的屏幕。
您可以在图3-7中看到文件的第一行是空的；这就是您必须编写提交消息的地方。提交消息应该写在一行上，但是您可以添加更多行的注释。注释以“#”开头，被Git忽略；它们只用于完成提交消息，以使其更清晰。还要注意，Git会自动将更改文件的列表放在commit注释中（与您看到的“Git status”文件相同）。
在后面的章节中，您将学习以正确的方式编写提交消息的正确方法。但现在，只需输入一个简单的消息，如“Add自述文件.md如图3-8所示的第一个空行上的“项目”。
在编写了如图3-8所示的提交消息之后，可以关闭编辑器（保存后！）。然后您将得到提交的摘要，如图3-9所示。
提交的摘要将包含大量信息：
•当前分支：主
•上一次提交的名称：根提交，因为这是我们的第一次提交
•提交名称：提交哈希的前七个字母
•提交消息
•更改的文件数：一个文件
•对每个文件执行的操作：创建
我们拍了第一张快照！如果您检查存储库的状态，您可以看到它再次是干净的，除非您留下一些文件未暂存。
Quick start with Git（Git快速入门）
所以，现在您已经熟悉了Git的基本概念，我们将在一个实际的项目中应用它们。假设您希望创建一个文件夹来保存TODO列表，并希望对其进行版本控制，以便检查每个项目何时完成。
为了让您更熟悉Git，您将在没有任何帮助的情况下进行下一个练习。如果你被卡住了，只需检查前面的部分的方向。
只要记住Git的基本原则：
•修改工作目录上的文件。
•将要记录当前状态的文件放在暂存区域。
•您可以通过提交为项目拍摄快照。
在提交之前，不要忘记将您修改的文件放在临时区域，否则它们将不会是快照的一部分。你没有放在暂存区的修改过的文件将一直保留在工作目录中，直到你决定放弃它们或者在将来的提交中包含它们。
让我们开始练习吧！请完成它直到结束，不要进入下一章，直到你清楚地了解Git是如何工作的。
•创建新的存储库。
•创建一个名为tOdO.txt文件在目录中输入一些文本。
•阶段tOdO.txt文件.
•提交项目并发出简短的提交消息。
•创建两个名为完成.txt以及工作.txt.
•暂存并提交这些文件。
•重命名工作.txt加入进度.txt.
•添加一些文本到完成.txt.
•检查目录状态。
•分期付款进度.txt以及完成.txt.
•未分级完成.txt.
•承诺项目。
•检查目录状态
完成这个练习后，合上书，试着用自己的话向自己解释这些事情：
• Working Directory工作目录
• Staging Area暂存区
• Commit提交
CHAPTER 4：深入Git
现在您已经熟悉了Git的基本命令，我们将深入了解它的其他特性。您将在本章中发现我在第1章中向您承诺的功能
Ignoring files
不是工作目录中的所有内容都应该被Git跟踪。有些文件（配置、密码、错误代码）通常不会被作者或开发人员跟踪。
这些文件（或目录）列在一个名为“.gitignore”的简单文件中。注意“gitignore”前面的句点；这很重要。要忽略文件，请创建一个名为.gitignore的文件，并列出其中要忽略的文件或文件夹
让我们回到上一章的存储库，TODO列表。假设您想要包含一个名为专用.txt. 首先必须使用您最喜欢的文本编辑器创建.gitinore文件，然后编写PRIVATE。如图4-1所示。