1.一元化は、VSを分散しました
- 集中：CVS、SVNが
遅い、中央リポジトリサーバーで、ネットワークに接続されている必要があり、使用するのは簡単 - 分散型：Gitは
速く、安全なネットワーキングせずに、すべての人のコンピュータには、完全なリポジトリ、変更のすべてを交換するための中央サーバー、強力な支店管理、使用がより複雑に持っています
注：GitHubの：Gitは自由のためのストレージを提供します。提供Gitのリポジトリ、サービスをホスティング自由な交換のための中央サーバーとして動作します。
実際にはローカルおよびリモートの倉庫倉庫何も違う、純粋に24時間365日時間や為替の変化のために
2.バージョンのロールバックと前進
- バージョンロールバック/フォワード（リセットHEADポインタ）は
git reset --hard HEAD~、以前のバージョンにフォールバックするには
git reset --hard 91588fb指定されたバージョンにフォールバックするために
あなたが戻ってバージョンをロールHEADポインタの現在のバージョンにポイントがあるの内側にGitので、ロールバック、非常に高速のGitのバージョン時間は、GitはHEADのバージョンからわずか1ポイントです。
git resetコマンドは、いずれかのロールバックバージョン、また、作業領域にフォールバックするために、一時領域を変更することができます。我々はHEADを使用する場合は、最新バージョンを表します。 - 歴史的な運転記録を見る
git reflogあなたは、将来のバージョンに戻したいかを決定するためにgitのREFLOGビューでコマンド履歴を git log -n 3最新の三つのコミットログを見ます
3.ワークエリア、ステージングエリア
ワークスペースには、隠されたディレクトリがあり.git、これは作業領域ではなく、Gitのリポジトリ。
Gitのバージョンカレーと呼ばれ、最も重要なのは、物事の多くを保存stageステージング領域（またはインデックスと呼ばれる）だけでなく、私たちのGitの最初のブランチは自動的に作成masterと呼ばれる、とのマスターへのポインタHEAD
の前で話しますときに我々はGitのリポジトリにファイルを追加し、2つの手順で実行されます。
-
最初のステップは、
git addファイルが実際にステージング領域を変更するために追加され、ファイルに追加します。 -
第二段階は
git commit、変更をコミットするために、実際には、現在のブランチにステージングエリアのすべての内容を提出することです。
我々はGitリポジトリを作成したときに、Gitは自動的に私たちのためのユニークな作成するためmasterのブランチを、そう、今、git commitそれはmasterブランチへの変更をコミットすることです。
あなたは、単にステージング領域にすべての変更を提出するために必要な書類として理解する、とすることができ、その後、一時領域内のすべての変更のワンタイム提出。
4. [変更管理
Git跟踪并管理的是修改，而非文件。
あなたが求めることができる、変更は何ですか？たとえば、あなたは、変更された行を、追加行を削除、修正され、いくつかの文字を変更し、変更されたいくつかを削除し、いくつかの追加、変更された、あるいは新しいファイルを作成し、も考慮されています変更。
あなたが使用するときにGitの管理が変更されたgit add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。
git diff HEAD -- xx.txt最新のローカルxx.txtファイルと倉庫の間の差を比較しました。
Gitはステージング領域にないgitの追加は、コミットするために添加されない場合、それぞれが、修飾、変更を追跡している、提出プロセスがそうです本地工作区->暂存区stage->版本库
4. [変更の取り消し
git checkout -- readme.txt最後のgitのコミット状態やgitの追加するファイルのバックをしてみましょう（git checkout実際には、リポジトリー・ワークスペースのバージョンのバージョンに置き換えられ、作業エリアが変更または削除されているかどうか、「キーが復元する。」ことができる）
--が非常に重要であり、いいえ--、それは「別のブランチに切り替え」コマンドになりgit reset HEAD xx.txtワークスペースのステージング領域への変更をキャンセルします。
git resetコマンドのいずれかのロールバックバージョンは、また、作業領域にフォールバックするために、一時領域を変更することができます。我々はHEADを使用する場合は、最新バージョンを表し
5.支店の管理
git checkout -b dev私たちは、DEVブランチを作成し、その後のdevのと同等のブランチに切り替えるgit branch devとgit checkout dev二桁git branch現在のブランチを表示するコマンドgit checkout mastermasterブランチに切り替えgit merge dev命令用于合并指定分支到当前分支，dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快git merge --no-ff -m "merged bug fix 101" issue-101通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式--no-ff，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息git branch -d dev就可以放心地删除dev分支了
我们注意到切换分支使用git checkout ，而前面讲过的撤销修改则是git checkout – filename，同一个命令，有两种作用，确实有点令人迷惑
git log --graph --pretty=oneline -abbrev-commit看到分支的合并情况,可以看到分支树结构。
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。git log --graph命令可以看到分支合并图，如下图，内容比较丰富。
- 分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
git stash当前工作现场“储藏”起来，等以后恢复现场后继续工作，之后，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。git stash list查看保存起来的工作现场- 恢复工作现场：
- 用
git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除 - 用
git stash pop，恢复的同时把stash内容也删了 git stash apply stash@{0}有多次stash，选择性恢复
git cherry-pick 4c805e2复制（合并）一个特定的提交内容到当前分支；一般用于bug修复完成后需要把这个改动合并到其他分支。git remoteorgit remote -v查看远程库的信息。你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origingit push origin master把该分支上的所有本地提交推送到远程库git pull获取最新提交
6.标签
发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的.
tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起
git tag v1.0默认标签是打在最新提交的commit上的，默认为HEADgit tag v0.9 f52c633对某次提交打标签git tag查看标签git show tagName查看某个标签的信息git tag -a v0.1 -m "version 0.1 released" 1094adb还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字git tag -d v0.1删除标签git push origin <tagname>推送某个标签到远程git push origin --tags一次性推送全部尚未推送到远程的本地标签- タグは、リモートにプッシュされている場合は、リモートタグは、あなたは少しトラブルを削除する
：削除ローカル開始するためにgit tag -d v0.9
、リモートから削除します。削除コマンドもプッシュしますが、形式は次のとおりです。git push origin :refs/tags/v0.9
特殊なファイルを無視7.
時には、あなたはGitの作業ディレクトリにいくつかのファイルを配置する必要がありますが、そのようなことをパスワードデータベース構成ファイルを保存するように、それらを提出することができない、というように、それぞれの時間git statusが表示されますがUntracked files ...、そこに強迫性障害であり、私の心は確かに不快靴。
幸いなことに、Gitはルートゾーンに特殊なGitの作業ディレクトリを作成するには、この問題を解決するためには非常に単純ですが、アカウントのすべての人の気持ちを考慮して.gitignore塗りつぶしにファイル名を無視し、ファイル、および、Gitは自動的にこれらのファイルを無視します。
GitHubのが私たちのための設定ファイルは、使用できるもののほんの組み合わせの多様性を用意しており、再書き込みにファイルを必要としない.Gitignore。すべての設定ファイルは直接閲覧することができます。https://github.com/github/gitignore
原則わずかファイルは次のとおりです。
- 自動的なサムネイルなどのファイルを、生成されたオペレーティングシステムを無視します。
- コンパイラによって無視さは、生成されたファイルコンパイルされた.class Javaのように、ファイルが自動的に自動的にリポジトリにファイルが生成され、別のファイルによって生成された場合、である必要がないこと、等の中間ファイル、実行可能ファイルを生成します。
- このような構成ファイルに保存されたパスワードなどの機密情報を使用して独自の設定ファイルを、無視します。
8.参照文献
