プロジェクト開発では、svn や Git などのバージョン管理ツールが必ず使われます。Git の発展に伴い、ますます多くの人に使われるようになり、svn の地位を徐々に取って代わりつつあります。以下では、Git リポジトリの作成、Git のよく使う基本コマンド、Git のブランチ管理、Git のコミット履歴の確認、Git タグ、Git リモートリポジトリという観点から Git の使い方を紹介します。もちろん、以下で扱うコマンドはすべて Git bash 上での操作なので、まず Git をインストールする必要があります。Git のインストール方法についてはここでは説明しません。ネット上にインストール手順はたくさんあります。
Git リポジトリの作成
git リポジトリを作成するには、次のようないくつかの方法があります：
- git init：git リポジトリを初期化する
- git clone：git リポジトリを clone する
以下ではこれらの方法を詳しく紹介します：
1. git init
Git は git init コマンドを使って Git リポジトリを初期化します。git init コマンドを実行すると .git ディレクトリが生成されます。このディレクトリにはリソースデータが含まれ、リポジトリのルートディレクトリにのみ生成されます。
現在のディレクトリを Git リポジトリとして使う場合は、次のコマンドを実行するだけで済みます：
git init実行結果は次のとおりです：
このコマンドを実行すると、現在のディレクトリに .init フォルダが生成され、デフォルトで master ブランチも生成されます。
指定したディレクトリにリポジトリを生成する場合は、次のコマンドになります：
git init newDirnewDir はリポジトリのパスです。実行が完了すると、newDir ディレクトリの下に .git ディレクトリが生成されます。具体的な実行結果は次のとおりです：
このコマンドを実行すると、現在のディレクトリに newtest フォルダが生成され、そのフォルダの下に .init フォルダが生成されます。
2. git clone
git clone コマンドを使うと Git リポジトリからプロジェクトをコピーできます。SVN の svn checkout に似ており、コマンドの形式は次のとおりです：
git clone <url> [directory]url は git リポジトリのアドレス、directory はローカルディレクトリです。たとえば、ある Git コードリポジトリをクローンするには、次のコマンドを使います：
git clone git://github.com/schacon/grit.git実行が完了すると現在のディレクトリにリポジトリが生成されます。指定したディレクトリに生成したい場合は、後ろに具体的なパスを追加します。たとえば：
git clone git://github.com/schacon/grit.git newgit以下はリポジトリを clone したときの実行結果です：
git clone では、ssh、git、https などさまざまなプロトコルを使えます。中でも最もよく使われるのは ssh です。速度が速く、公開鍵を設定すればパスワード入力も不要になるためです。各記述形式は次のとおりです：
git clone [email protected]/schacon/grit.git --SSH协议
git clone git://github.com/schacon/grit.git --GIT协议
git clone https://github.com/schacon/grit.git --HTTPS协议Git 基本コマンドの使い方
以下では git でよく使ういくつかのコマンドを紹介します：
- git config：設定情報
- git add：ファイルをキャッシュに追加するコマンド
- git status：ファイルの状態を確認するコマンド
- git diff：更新の詳細情報を確認するコマンド
- git commit：コミットコマンド
- git reset HEAD：キャッシュを取り消すコマンド
- git rm：削除コマンド
- git mv：移動または名前変更コマンド
以下ではこれらのコマンドを詳しく紹介します：
1. git config
git config を使ってユーザー名とメールアドレスを設定できます。これによりコードをリモートリポジトリにコミットしやすくなります。具体的な形式は次のとおりです：
git config --global user.name '你的用户名'
git config --global user.email '你的邮箱'2. git add
git add コマンドはファイルをキャッシュに追加できます。たとえば新しいプロジェクトでは、すべてのファイルを追加するのが一般的です。次のコマンドを使えます：
git add .もちろん、特定の種類のファイルだけを指定することもできます。たとえば java ファイルをキャッシュに追加する場合は、次のコマンドを使います：
it add *.javaたとえば、2 つのファイルを作成し、それをキャッシュに追加する場合の具体的な操作は次のとおりです：
3. git status
git status コマンドを使って関連ファイルの状態を確認できます。次のコマンドをそのまま実行します：
git status変更されたファイルがある場合、実行結果は次のとおりです：
上記の git status コマンドのヒント内容から、次の 3 つの対処状況が分かります：
ファイルをステージングするコマンド：git add <ファイル名>
ステージングされていないファイルの変更を破棄するコマンド：git checkout – <ファイル名>
変更されたファイルをステージングしてコミットするコマンド：git commit -a
Git の各種状態にかなり慣れている場合は、git status -s を使って省略形式の状態を確認することもできます。この省略形式の状態は SVN のものとほぼ同じで、M - 変更済み、A - 追加済み、D - 削除済み、R - 名前変更済み、?? - 未追跡 などです。変更されたファイルがある場合、実行結果は次のとおりです：
4. git diff
git diff を実行すると更新の詳細情報を確認できます。git status との違いは、git status が更新状態だけを表示するのに対し、git diff はキャッシュに書き込まれた変更と、変更されたがまだキャッシュに書き込まれていない変更との違いを具体的な詳細として表示できることです。
- まだキャッシュされていない変更：git diff
- キャッシュ済みの変更を確認：git diff --cached
- キャッシュ済みと未キャッシュのすべての変更を確認：git diff HEAD
- diff 全体ではなく概要を表示：git diff --stat
たとえば、test.txt ファイルの内容を変更し、git diff を使って変更の詳細情報を確認します：
その後、変更内容をキャッシュに add し、再度 git diff を使って変更の詳細情報を確認します：
5. git commit
git commit はキャッシュ領域の内容をリポジトリに追加します。後ろに -m オプションを付けると、コマンドラインでコミットコメントを指定できます。形式は次のとおりです：
git commit -m "第一次版本提交"毎回 commit の前に add するのが面倒で、add の手順を飛ばしたい場合は、-a オプションを直接使えます。たとえば：
git commit -am "第一次版本提交"たとえば、ファイルを作成してキャッシュに追加し、その後コミットする場合の具体的な操作は次のとおりです：
6. git reset HEAD
git reset HEAD コマンドは、キャッシュ済みの内容を取り消すために使います。たとえば、コミット済みの test.txt ファイルを取り消したい場合は、次のように使えます：
git reset HEAD test.txt実行後、commit でコミットする際に test.txt ファイルはコミットされません。
たとえば、まず test1.txt、test2.txt ファイルを変更し、その後どちらもキャッシュに追加し、さらに git reset HEAD コマンドで test1.txt を復元し、最後にコミットする場合の具体的な操作は次のとおりです：
変更された test1 ファイルは git reset HEAD の後、コミットされていないことが分かります。要するに、git reset HEAD を実行すると、以前に git add で追加した内容を取り消せます。
7. git rm
もし作業ディレクトリから手作業でファイルを削除しただけなら、git status を実行すると Changes not staged for commit の通知が表示されます。Git からあるファイルを削除するには、追跡対象ファイルのリストから外してからコミットする必要があります。次のように使用します：
git rm <file>削除前に変更を加えていて、すでにステージングエリアに置かれている場合は、強制削除オプション -f を使う必要があります。
git rm -f <file>ファイルをステージングエリアから削除しつつ、現在の作業ディレクトリには残しておきたい場合、つまり追跡リストから削除するだけの場合は、--cached オプションを使えばよいです。
git rm --cached <file>再帰的に削除することもできます。つまり、引数としてディレクトリを指定すると、そのディレクトリ内のすべてのサブディレクトリとファイルを再帰的に削除します：
git rm –r *例：上で作成した hello.java ファイルを削除します：
8. git mv
git mv コマンドは、ファイル、ディレクトリ、シンボリックリンクの移動や名前変更に使用します。例えば test.txt ファイルを newtest.txt に名前変更する場合、次のコマンドを使用します：
git mv test.txt newtest.txt例：上記の test1.txt ファイルを test.txt に名前変更します：
Git のブランチ管理
ほとんどすべてのバージョン管理システムがブランチ管理をサポートしています。ブランチを使えば、主干（メインブランチ）から分離して開発を続けられ、主干に影響を与えません。以下では Git におけるブランチのよく使うコマンドを紹介します：
- git branch：ブランチを表示するコマンド
- git branch (branchname)：ブランチを作成するコマンド
- git checkout (branchname)：ブランチを切り替えるコマンド
- git merge：ブランチをマージするコマンド
- git branch -d (branchname)：ブランチを削除するコマンド
以下ではこれらのコマンドについてそれぞれ詳しく紹介します：
1. git branch
git branch はブランチを表示することも、作成することもできます。引数がない場合、git branch はローカルのブランチを一覧表示します。引数がある場合、git branch はその引数のブランチを作成します。
ブランチを表示する場合、コマンドの書式は次のとおりです：
git branchbash で実行した結果は次の図のとおりです：
ブランチを作成したいときは、後ろに引数を追加します。コマンドの書式は次のとおりです：
git branch branchname例えば test というブランチを作成したい場合、次のように操作します：
これで、新しいブランチ test が増えたことが分かります。また master ブランチは、git init を実行したときに、デフォルトで Git が master ブランチを作成してくれるものです。
2. git checkout (branchname)
git checkout はブランチを切り替えることができます。コマンドの書式は次のとおりです：
git checkout branchname上で作成したばかりの test ブランチに切り替えたい場合、次のように操作します：
実行前は現在のブランチが master で、実行後は現在のブランチが test になっていることが分かります。このとき、切り替えた後のブランチで操作を続けても、他のブランチには影響しません。
また、git checkout -b (branchname) コマンドを使えば、新しいブランチを作成して即座にそのブランチに切り替え、そのブランチ内で操作できるようにもできます。例えば newtest ブランチを作成し、作成後にそのブランチへ切り替えたい場合、次のように操作します：
実行前はまだ master ブランチにいたのに、実行後は直接 newtest ブランチに入っていることが分かります。
3. git merge
git merge コマンドは、任意のブランチを現在のブランチにマージすることができます。コマンドの書式は次のとおりです：
git merge branchname例えば、newtest ブランチを新規作成し、その中に test3.txt ファイルを追加してから、master で newtest ブランチの変更を master にマージすると、結果は次のようになります：
master にも test3.txt ファイルが存在するようになったことが分かります。
マージの競合
マージで最大の難点は競合です。マージは単純にファイルを追加・削除する操作だけではなく、Git は変更もマージします。もし二つのブランチで同じファイルを同時に変更していると、その後のマージで競合が発生する可能性があります。競合そのものは恐ろしいものではなく、恐ろしいのはそれをどう解決するかです。以下では小さな例を通して、マージ時の競合の解決方法を示します。
先ほどのリポジトリをそのまま使い、現在二つのブランチ master と newtest があり、両方のブランチに test.txt ファイルがあるとします。このとき、両方のリポジトリのファイルをそれぞれ変更してからコミットし、最後に newtest を master にマージします。具体的な操作は次のとおりです：
1、まずブランチ master と newtest の test.txt ファイルを変更し、コミットします：
2、その後、newtest ブランチで変更した内容を master ブランチにマージします：
newtest ブランチで変更した内容と master ブランチで変更した内容が競合していることが分かります。これは具体的な状況に応じて解決します。次のように、両方のブランチにある内容を残してから、add し、commit すればよいです：
これで簡単なマージは完了です。実際のプロジェクト開発では、マージはこれよりもはるかに複雑であり、具体的な状況に合わせて操作する必要があります。
4. git branch -d (branchname)
git branch -d はブランチを削除することができます。ブランチ削除コマンドの書式は次のとおりです：
git branch -d (branchname)例：test ブランチを削除します：
Git でコミット履歴を表示する
Git でいくつかの更新をコミットした後、あるいはあるプロジェクトをクローンした後、コミット履歴を振り返りたいときには、git log コマンドで確認できます。例えば、履歴のコミット記録を一覧表示したい場合は次のとおりです：
以下では履歴を表示するいくつかのオプションを紹介します：
- –oneline ：履歴の簡潔なバージョンを表示
- –graph ：履歴の中でいつブランチやマージが現れたかを表示
- –reverse ：すべてのログを逆順に表示
- –author ：指定したユーザーのコミットログを検索
- –since、–before、 --until、–after： 日付で絞り込む
- –no-merges ：マージコミットを非表示にするオプション
–oneline オプションを使うと、履歴の簡潔なバージョンを確認できます：
また –graph オプションを使うと、履歴の中でいつブランチやマージが現れたかを確認できます：
これにより、いつ作業が分岐し、いつ統合されたのかをよりはっきりと把握できます。また –reverse パラメータを使うと、すべてのログを逆順に表示できます：
指定したユーザーのコミットログだけを検索したい場合は、git log --author コマンドを使います。例えば、Git のソースコードの中で qtqt によるコミット部分を探したいとします：
日付を指定したい場合は、–since と --before、あるいは --until と --after といったオプションを使えます。–no-merges オプションはマージコミットを非表示にします。
例えば、Git プロジェクトにおいて八月一日より前で、かつ七月二十九日より後のすべてのコミットを見たい場合は、次のように実行します：
多くの場合、各コミットがどのブランチ／タグに関連しているかを把握することは非常に有用です。–decorate フラグを使うと、git log が各コミットを指すすべての参照（ブランチ、タグなど）を表示するようになります。例えば：
Git タグ
タグを使うと、特定のコミットスナップショットを永久に覚えておくことができて便利です。例えば、新しいバージョンをリリースする際に「vx.x」というバージョンを付けることができます。その際に git tag を使ってタグを打つことができます。
新しいタグの作成
git tag -a vx.x を使ってタグを作成できます。a オプションは「注釈付きタグを作成する」という意味です。-a オプションなしでも実行できますが、その場合、タグをいつ誰が打ったのかが記録されず、タグの注釈を追加することもできません。
例えば、先ほどの例に対してタグを作成してみましょう：
タグの追加
あるコミットにタグを打つのを忘れて、そのまま公開してしまった場合でも、後からタグを追加できます。例えば、コミット d6f7147 を公開したけれど、そのときタグを打つのを忘れていたとします。今からでも次のように実行できます：
タグの確認
すべてのタグを確認したい場合は、次のコマンドを使います：
git tag実行結果は以下のとおりです：
タグ情報を指定するコマンド：
git tag -a <tagname> -m "某某标签"PGP 署名付きタグのコマンド：
git tag -s <tagname> -m "某某标签"Git リモートリポジトリ
これまで使ってきた Git コマンドはすべてローカルで実行していました。Git を通じてコードを共有したり、他の開発者と協力したりしたい場合は、データを他の開発者が接続できるサーバー上に置く必要があります。本記事では GitHub をリモートリポジトリとして使用し、Git リモートリポジトリの使い方を紹介します。
以下では、リモートリポジトリでよく使われるいくつかのコマンドを紹介します：
- git remote add：リモートリポジトリを追加する
- git remote：現在のリモートリポジトリを確認する
- git fetch、git pull：リモートリポジトリから取得する
- git push：リモートリポジトリへプッシュする
- git remote rm：リモートリポジトリを削除する
1. git remote add
git remote add はリモートリポジトリを追加できます。コマンドの形式は次のとおりです：
git remote add [alias] [url]パラメータ [alias] は別名、[url] はリモートリポジトリのアドレスです。例えば、https://github.com/qtqt/test.git
というリポジトリをローカルに追加し、test と命名する場合、操作は次のようになります：
2. git remote
git remote を使うと、現在どのようなリモートリポジトリがあるかを確認できます。実行結果は以下のとおりです：
上で追加した別名 test のリポジトリがあることがわかります。
3. git fetch、git pull
git fetch はリモートリポジトリのデータを取得できます。複数のリモートリポジトリがある場合は、後ろにリポジトリの別名を付けることができます。操作は次のとおりです：
このコマンドを実行した後、git merge でリモートブランチを自分のブランチにマージする必要があります。リモートリポジトリを設定済みで、更新されたデータを取得したいとします。まず git fetch [alias] を実行して、Git に自分が持っていないデータを取得するよう指示し、次に git merge [alias]/[branch] を実行して、サーバー上の更新（このとき誰かがサーバーにプッシュしたと仮定します）を現在のブランチにマージします。操作は次のとおりです：
実行が完了すると、ローカルリポジトリでリモートリポジトリのファイルを確認できます。この方法では、ローカルが空のリポジトリである場合にのみ保証されます。空でない場合は、fatal: refusing to merge unrelated histories というエラーが発生します。
git pull コマンドは、別のリポジトリまたはローカルブランチから取得して統合（マージ）するために使います。デフォルトモードでは、git pull は git fetch の後に git merge FETCH_HEAD を続けたものの省略形です。使用形式は次のとおりです：
git pull [options] [<repository> [<refspec>…]]例えば、リモートリポジトリをローカルに pull できます。ローカルリポジトリとリモートリポジトリが実質的に独立した2つのリポジトリである場合は、–allow-unrelated-history オプションで解決できます。
git fetch と git pull の違い：
- git fetch：リモートから最新バージョンをローカルに取得するだけで、自動的にマージは行いません。
- git pull：リモートから最新バージョンを取得し、ローカルにマージします。
4. git push
git push は、新しいブランチとデータを特定のリモートリポジトリへプッシュするコマンドです。形式は次のとおりです：
git push [alias] [branch]例えば、先ほどコミットしたファイルをリモートリポジトリに push できます：
5. **git remote rm **
git remote rm はリモートリポジトリを削除します。形式は次のとおりです：
git remote rm [别名]例えば、まず test2 というリポジトリを追加し、その後で削除できます。操作は次のとおりです：
これで、Git のよく使う操作についての紹介はほぼ終わりです。
- 微信
- 支付宝
