使用Git入门(Subversion对比和Git的优点)来自Subversion的转变
由于Git经常被讨论，所以我创建了一份资料，尽管有点长，但是为了希望能简单理解概念的人。
我个人认为，导致Git如此广泛的原因不仅仅是Git本身，还有GitHub及其克隆版本所拥有的Pull Request机制的影响。但首先，我想简单概括一下Git是什么。
-
- どうしてGitなのか、Gitのメリット
-
- SubversionとGitの違い
-
- ローカルでGitを使ってみる
- Gitサーバーのある構成管理
为什么选择Git？Git有哪些优点？
让我们首先明确Git的优点。Git经常被称为一种分布式的配置管理系统。我认为，理解”分布式”和”配置管理”的意义对于使用Git来讲是最重要的一点。
我認為閱讀這篇文章的人可能已經在使用版本控制工具，像是Subversion等等，而Git的優點在於它是一個「分散式」的系統。請看以下的解釋，透過這種「分散式」的方式，開發者可以隨心所欲地對源代碼樹進行修改，這就是我認為使用Git進行分散式版本控制的優勢。
Git以前的传统配置管理是集中式的。它将配置管理的代码库存储在服务器上，并将其传输到开发者的环境中。 开发者会在本地环境中进行试验和开发，并将结果再次提交到服务器中。
这种传统的方法在[开发者手中拥有源代码的期间]存在问题。在这段时间内，很多任务都需要由本地文件管理完成，而且无法完全对配置进行管理，导致开发者在尝试和错误中获得的结果可能会丢失。
在一方面，Git在获取服务器上的配置管理源代码方面与之前相同。然而，之后它并不是从配置管理中解除，而是转移到开发者的个人电脑上。由开发者的个人电脑上的Git进行配置管理。因为配置管理的主体不仅限于服务器，还可以在开发者的个人电脑上进行，所以它变成了分布式的配置管理。
只要在开发者端进行管理，即使不与服务器同步，也可以在开发者的个人电脑中进行稳定的配置管理，因此无论是进行修正还是添加新功能，开发者都可以充分修改源代码。修改完成后，将开发者个人电脑的配置管理内容反映到服务器端的配置管理中，并更新主要的源代码树。
在Git中，操作将按照上述步骤进行。通过将配置管理的责任转移给开发者，开发者可以轻松进行独立的工作，无需担心主代码库。这使得开发者的挑战变得容易。这就是Git分布式配置管理的关键，它使得开发者能够快速进行“尽情开发”。
2. Git 与 Subversion 的区别
我打算在后半部分看一下Git的使用示例，但是要注意事先确认一下，因为它与Subversion等工具在分布式配置管理方面存在一些不同。
2.1. 存在于演练状态中
Git有一个特点，即从配置管理获取的文件在编辑并提交之间有一个中间的暂存状态。可以形象地表示如下：
将手边的文件-(添加命令)->暂存状态-(提交命令)->配置管理状态
推动/拉动
在Subversion等版本控制系统中，提交(commit)指的是将修改同步到服务器上。然而，在本地配置管理中，提交(commit)指的是将修改保存到本地，因此转移到远程服务器需要额外的命令。这就是push和pull的用途。
2.3版本的识别不是连续编号
版本是一个用于识别版本的字符串，需要注意的是它不是连续编号的。（因为它是分散式的，那边的版本号Rev.1234可能与这边的Rev.1234并不相同，无法确认它们是否相等。无法进行连续编号。）
在本地尝试使用Git。
最终我们将使用服务器进行配置管理，但首先让我们先在本地环境中使用Git进行配置管理，并逐渐学习一些命令。
3.1. 起始化
在执行编辑操作的目录中，输入以下命令。
>git init
请在接下来的时间里继续在这个目录下进行编辑。
添加文件的一系列步骤为3.2
在Git中，与Subversion不同的是有一个分阶段的状态。当编辑文件时，可以将编辑过的文件设为分阶段状态，然后再进行提交。提交命令中的-m选项用于指定提交时的消息。
>touch hello.txt (ファイルの追加）
>git add hello.txt （ステージングへの追加）
>git commit -m "add hello.txt" （ステージングからのコミット）
3.3. 编辑文件的一系列步骤（需要添加到暂存区）
在编写时同样需要使用add命令。
>vi hello.txt (ファイルの編集）
>git add hello.txt （ステージングへの追加）
>git commit -m "modify hello.txt" （ステージングからのコミット）
3.4. 分支操作
在Git中，有一个名为”master”的主要分支，通常会在该分支上创建一个新的分支来进行常规的功能添加等操作，然后再将更改合并到主分支上。
如果要查看分支状态，可以按照以下方式获取分支列表和当前所在的分支名称。在下面的例子中，有两个分支，并且可以确定当前位于主分支。
>git branch
如果要创建一个分支的话
>git branch (ブランチ名)
移动分支的步骤如下所示。
>git checkout (ブランチ名)
查看提交日志。
要查看提交的内容，请查看提交日志。
>git log
commit 70175e9fd9a36f7aea8af73f18778b7f472a3277
Author: xxxx <xxxx>
Date: Sat Jan 3 10:53:06 2015 +0900
modify hello.txt
commit 195066c3c0668ef6629defb2eaef36b2d051cd76
Author: xxxx<xxxx>
Date: Sat Jan 3 10:50:51 2015 +0900
add hello.txt
如果你希望将提交的内容精简成一行，并以分支树状图形式进行查看，
>git log --oneline --graph
获取特定版本
>git checkout 19506
commit 70175e9fd9a36f7aea8af73f18778b7f472a3277
Author: xxxx <xxxx>
Date: Sat Jan 3 10:53:06 2015 +0900
modify hello.txt
4. 有Git服务器的配置管理
如果使用遠程工作，將採取以下操作步驟。如前所述，使用Subversion進行提交，即相當於將更新推送到伺服器。
-
- 克隆存储库并获取源代码树。(通常创建分支并切换到该分支。)
-
- 编辑存储库。
-
- 将更改暂存。
-
- 提交更改。
-
- 推送更改。
- (回到状态1)
要获取由其他人进行的对树的更改，请执行拉取操作。
以太网pull远程作出的更改到刚提到的1状态。
请看下面的一些命令。
4.1 通过克隆获取源代码树
如果进行克隆，将记录获取树的信息作为”origin”。
>git clone http://*********.git
4.2. 进行更改并推送。
当向服务器发送更改时，我们使用push。
由于origin被记录为克隆的来源，因此在下面，origin和master分支将自动填充。
>git push
如果在分支上进行开发，将分支推送到origin的方法如下：
>git push origin (ブランチ名)
4.3. 拉取更改。
如果要获取更改，可以使用 pull。
>git pull
5.总结
我尽可能地总结了关于Git的概念，不知道您觉得怎么样？如果有时间，我还想总结一下GitHub（拉取请求）的相关内容。
