Gitのpullコマンド

このコマンドは、他のリポジトリ（リモート・リポジトリなど）のデータを取得し、ローカルのブランチに統合するものだ。

このコマンドが実行されると、リモート・リポジトリからの変更が現在のブランチに組み込まれる。

コマンドの基本は簡単だ。

git pull [リポジトリ] [ブランチ]

では、実際の使い方を見てみよう。

リモート・リポジトリをpullする場合

例えば、リモート・リポジトリをクローンしたローカルのリポジトリがあったとする。クローンした時点では、リモートと同じ内容のものがそっくりローカルにコピーされる。次の図は、V0から始まったリモートのリポジトリがV1の時点でクローンされた時の様子を表している。

この時点までの変更の記録はローカルもリモートも同じなので、ローカルの変更履歴がリモートの変更履歴でもある。

しかし、ローカルでV1に変更を加えたV2が記録され、続いてリモートでもV1が変更されたV3が記録されるとどうなるだろう。クローンされた後は、別々に変更の記録が独立して行われることになる。

ローカルで変更の記録を確認（git log）すると、

ローカルにはV3がないことが分かる。つまりローカルとリモートには違いがあると言うことだ。そこで、リモートの変更をローカルに反映させたいとする。

ここで、pullコマンドの出番だ。

リモートのリポジトリの名前は、クローンした時点で自動的にoriginという名前になっている。それで、originという名前を指定して、

$ git pull origin master

と、コマンドを叩けばOKだ。

コマンドが実行されると、ローカルにリモートの変更内容がマージされる。そして、新しいタグ（ここでは、V4）が追加される。

では、ローカルにリモートの変更が反映された履歴を見てみよう。

$ git log

と、コマンドを叩けばOKだ。

今度は、ローカルの履歴にリモートのV3とローカルの新たなタグV4の変更履歴が追加されている。

まとめ

このページではGitのpullコマンドについて簡単にご紹介した。Gitを使いこなすために参考にしていただければと思う。

SourceTreeとは

SourceTreeはバージョン管理システムのGUIだ。しかも、GitとMercurialに対応している。それで、基本的な使い方を学べばバージョン管理システムは異なっても操作は同じになる。

ここで説明するのは、Gitによるバージョン管理のGUIとしての使い方だ。

では、初期設定から見ていこう。

初期設定をする

初期設定としてGitを使うために必要最小限の設定を行う。必要最小限の設定とは、ユーザ名とメールアドレスを入力することだ。

SourceTree画面のメニューバーのツール→オプションを選択する。

オプション画面が表示されたら、全般タブを選ぶ。「SoucetreeにGitとMercurialのグローバル設定をファイルの変更を許可する」と「Use this version of SourceTree for URI association」にチェックを入れる。フルネームとメールアドレスのそれぞれの項目に必要なデータを設定する。

変更を記録する

SourceTreeを使ってローカルに変更を記録する作業の流れは以下の通りだ。①リポジトリを作成し、バージョン管理の対象ファイルを②インデックスに登録し、③コミットする。

では、実際の作業の流れを見てみよう。

リポジトリを作成する

ローカルにリポジトリの作成を行なう方法は次の通りだ。結果は、コンソールでgit initコマンドを実行したのと同じになる。

リポジトリがひとつも作られていないとNewTabという名のタブが表示されるので、Localボタンを選択しCreateボタンを押す。

Create a repository画面が表示されるので、リポジトリを作成するディレクトリ（フォルダ）名を入力する。この例では、「C:\gitwork」を指定している。リポジトリの名前に「gitwork」が自動的に入力されるが、変更も可能である。バージョン管理はGitを選択する。最後に作成ボタンを押す。

タブの名前がNew tabから作成したリポジトリの名前gitworkに変わる。

確認すると作業ツリーのためのディレクトリgitworkが作成されている。このディレクトリにJavaのソースファイルを置く。

作業ツリーの中のファイルProgram.javaが表示されればOKだ。

インデックスに追加する

管理したいファイルをインデックスに追加する方法は次の通りだ。結果は、コンソールでgit addコマンドを実行したのと同じになる。

具体的に作業ツリーに置かれたJavaのソースファイル：Program.javaをインデックスに追加する手順を見ていこう。

Javaのソースファイルを選択すると、ファイル名が反転し右側のウィンドウにソースコードが表示される。「選択をインデックスに追加」ボタンを押す。

Program.javaファイルが「作業ツリーのファイル」から「インデックスにステージしたファイル」に移動する。

もし、表示されたすべてのファイルをインデックスに追加したいのであれば、「全てインデックスに追加」ボタンを押すだけでよい。逆に、追加したファイルを取り消すには、「全てインデックスから除く」ボタンか、ファイルを選択して「選択をインデックスから除く」ボタンを押せばよい。

コミットする

コミットする方法は次の通りだ。結果は、コンソールでgit commitコマンドを実行したのと同じになる。

「インデックスにステージしたファイル」にあるファイルをコミットする。

下のテキストボックスに変更に伴って記録するメッセージ：「Version-1」を記入し、コミットボタンを押す。

コミットが完了すると、「コミット対象が選択されていません」が表示される。正しくコミットされているかを確認するためにブランチのmasterをクリックする。

樹形図の始まりにVersion-0が表示され、ログにはそのコミットの詳細情報が表示される。これらの情報によってコミットが正しく実行され、記録されたことを確認できるのだ。

さらに、次のコミットにより新たなバージョンが追加されることにより樹形図が伸びる。最初のバージョン：Version-0に続いてVersion-1がコミットされた画面を見てみよう。

樹形図にVersion-0からVersion-1が伸びている。また、表示されたソースコードでは、変更された部分がどこかが分かるようになっている。

変更を共有する

SourceTreeを使ってリモート・サーバで変更を共有する作業の流れは以下の通りだ。最初にローカルからリモート・サーバ上にあるリモート・リポジトリに変更をプッシュする。こうすることによって変更を共有する準備ができる。次にリモート・リポジトリの変更をクローン（コピー）、または、プルする。

既にリモート・リポジトリがあって、ローカルにリポジトリがない場合はクローンを使ってローカルに最初のリポジトリを作れば簡単だ。

では、実際の作業の流れを見てみよう。

リモート・リポジトリの設定をする

リモート・リポジトリにローカルのリポジトリの変更を記録するために、リモート・リポジトリを設定する。

SourceTree画面の設定ボタンを押すかメニューバーのリポジトリ→リポジトリ設定を選択する。

リポジトリ画面が表示されるので、追加ボタンを押す。

リモート詳細設定画面が表示されるので、リモート名とパスを設定する。リモート名はデフォルトモードにチェックを入れると、自動的にoriginになる。

また、ここではURL/パスはWindows上のリモート・リポジトリを設定している。このリモート・リポジトリの詳細については「リモート・リポジトリを作成する」の記事で解説している。

プッシュする

リモート・リポジトリの設定ができたら、プッシュを使ってローカルのリポジトリからリモートのリポジトリに変更の記録をする。

プッシュする方法は次の通りだ。結果は、コンソールでgit pushコマンドを実行したのと同じになる。

SourceTree画面のプッシュボタンを押す。

プッシュ画面が表示される。プッシュ先はリモート名のorigin、プッシュするローカルの対象がmasterで、リモートブランチmasterにプッシュされる設定になっている。確認してプッシュボタンを押す。

クローンする

リモート・リポジトリにプッシュを使って変更の内容が記録されたので、今度はクローンを使ってその内容のコピーを作ってみよう。

クローンする方法は次の通りだ。結果は、コンソールでgit cloneコマンドを実行したのと同じになる。

SourceTree画面の設定ボタンを押すかメニューバーの「ファイル→新規／クローンを作成する」を選択する。

New tab画面が表示される、クローンするために必要な情報を入力する。

一番目の入力項目にクローン元となるリポジトリ（先のセクションで作成したリモート・リポジトリ）を設定する。二番目の入力項目にクローン先のディレクトリを設定する。そして、クローンボタンを押す。

タブの名前が設定したリポジトリの名前gitcloneになり、gitworkと同じ内容のリポジトリがコピーされたのが確認できればOKだ。

プルする

プルする方法は次の通りだ。結果は、コンソールでgit pullコマンドを実行したのと同じになる。

プル画面が表示されるので、OKボタンを押す。

プルが実行される。画面のプルボタンの右上に表示された青抜きの数字が消え、別のリポジトリからプッシュされた新しい変更記録が表示されていればOKだ。

まとめ

このページではSourceTreeの使用方法について簡単にご紹介した。SourceTreeを使いこなすために参考にしていただければと思う。

このページではfetchコマンドの使い方について入門者の方向けに解説した。参考にしていただけれと思う。

Gitのfetchコマンド

このコマンドは、リモート・リポジトリなど他のリポジトリのデータを取得するものだ。

このコマンドが実行されると、ローカルからリモート・リポジトリの最新の情報を見ることができるようにもなる。また、必要に応じてリモート・リポジトリとマージすることもできるようになる。

ただし、コマンドは他のリポジトリのデータを取得するだけで、ローカルで作業しているファイルを書き換えたりマージしたりするようなことはない。

コマンドの基本は簡単だ。

git fetch [リポジトリ]

では、実際の使い方を見てみよう。

リモート・リポジトリをfetchする場合

例えば、リモート・リポジトリをクローンしたローカルのリポジトリがあったとする。クローンした時点では、リモートと同じ内容のものがそっくりローカルにコピーされる。次の図は、V0から始まったリモートのリポジトリがV1の時点でクローンされた時の様子を表している。

この時点までの変更の記録はローカルもリモートも同じなので、ローカルの変更履歴がリモートの変更履歴でもある。

しかし、ローカルでV1に変更を加えたV2が記録され、続いてリモートでもV1が変更されたV3が記録されるとどうなるだろう。クローンされた後は、別々に変更の記録が独立して行われることになる。

ローカルで変更の記録を確認（git log）すると、

ローカルにはV3がないことが分かる。つまりローカルからリモートは見えない。

それで、fetchコマンドの出番だ。

リモートのリポジトリの名前は、クローンした時点で自動的にoriginという名前になっている。それで、originという名前を指定して、

$ git fetch origin

と、コマンドを叩けばOKだ。

コマンドが実行されると、ローカルにリモート追跡のためのブランチが作られる。このブランチの名前を使ってリモートにどんな変更が記録されているかを見ることができる。

では、ローカルでリモートとローカルの変更の履歴を見てみよう。

リモートの変更履歴はリモート追跡のためのブランチの名前origin/masterという名前を指定して、

$ git log origin/master

と、コマンドを叩けばOKだ。

今度は、V3の変更履歴がある。

まとめ

このページではGitのfetchコマンドの使い方についてまとめてご紹介した。

リモート・リポジトリの状態を把握するために、定期的にfetchコマンドを実行しておこう。

SourceTreeのインストール方法

インストール方法

SourceTreeはリポジトリを可視化するバージョン管理システムのGUI（Graphical User Interface）だ。これから、そのSourceTreeのインストール方法を順を追って説明するが、インストール方法は大まかに下記のようになっている。

では、順を追って見てみよう。

ダウンロード

まず最初行なうのは、SouceTreeの公式サイト（URL: https://ja.atlassian.com/software/sourcetree）よりインストーラーをダウンロードすることだ。

ダウンロードは「Windows向けダウンロード」ボタンまたは「無料ダウンロード」ボタンを押すことによって始まる。

インストール

ダウンロードが終わって、ダウンロード・フォルダに最新バージョンのインストーラー（SourceTreeSetup-2.1.11.0.exe）が格納されていればOKだ。この記事を書いている時点では、最新バージョンが2.1.11である。

エクスプローラのダウンロード・フォルダにあるインストーラーをダブルクリックすると、インストーラーが起動される。

インストーラーを起動すると、最初に「セキュリティの警告」の画面が表示されるので、「実行」ボタンを押す。

インストーラーがライセンスに関する同意を求めてくるので、利用許諾契約書をクリックする。

SourceTreeを利用する顧客とその開発元であるAtlassian間の利用許諾契約書が表示される。内容を読んで確認する。

利用許諾契約書の内容に同意できたら、「ライセンスに同意します」をチェックし、続行ボタンを押す。これで、利用許諾契約書の確認は終わりだ。

アカウントを新規作成

インストールを行うためには、Atlassianにアカウントを登録する必要がある。ここではその手順を説明する。

「Atlassian アカウントにログイン」画面が開いたら、Atlassian アカウントを持っている場合と持っていない場合で操作が異なる。アカウントを持っていないときは「My Atlassianを開く」ボタンを押す。

もし、アカウントを持っていれば「既存のアカウントを使用」ボタンを押す。そして、ログインのセクションに進む。

ブラウザが立ち上がり、そこに「My Atlassianログイン」画面が表示されたならば、「Need an account? Sign up」の青字の部分「Sign up」を押す。

「Atlassianにようこそ（Welcome to My Atlassian）」画面が表示される。Email addressにユーザのメールアドレス、Full nameにユーザの名前、Choose & password にパスワードを入力する。これらの項目の入力が終わったら「私はロボットではありません」を押す。

画像を使った質問が表示されるので、質問に合った画像にチェックを入れ次へのボタンを押す。そうすると、もう一度同じ質問の画面が続くので同じようにチェックを入れ確認ボタンを押す。

再度「Atlassianにようこそ（Welcome to My Atlassian）」画面が表示され、「私はロボットではありません」にチェックマークが付く。これで、入力はすべて完了だ。

最後にSign upボタンを押す。

認証のためのメールを送りました。（We’ve sent you a verification email.）画面が表示されたなら、登録したメールが届いていることを確認する。

メールを受け取ったなら、Hi.に続く部分の名前が正しいかどうか確認し「Verify my email address」ボタンを押す。

この画面が表示されれば、アカウントの登録は完了だ。

ここまでの作業で、準備はできたのでログインに進もう。

ログイン

ここからは、インストールを行うためにアカウントを使ってログインする手順だ。ログインするには、アカウントとパスワードの入力が必要だ。

ログイン（Log in）画面が表示されたら、先にアカウント登録したメールアドレスを入力し、Nextボタンを押す。

次のログイン（Log in）画面が表示されたらパスワードを入力し、「Log in」ボタンを押す。

アカウントとパスワードの登録が完了すると、「登録を完了しました！」画面が表示されるので、続行ボタンを押す。

リモート

既にリモート・サーバを持っていれば、表示された３つの中から選ぶ。ここでは、リモート・サーバのリポジトリを独自に作るのでスキップするだけでOKだ。

アカウントと接続画面が表示されるので、スキップボタンを押す。

ツールをインストール

SSH（Secure Shell）キーの読み込み、Git 及びMercurialのインストールを行なう。

SSHはリモートにあるコンピュータとの通信するためにセキュリティを高めるための仕組みだ。そのために使用するSSHキーを読み込み設定する。後で設定することもできるので、ここでは設定しない。

「SSHキーを読み込みますか？」の画面が表示されたら、Noボタンを押す。

Gitはバージョン管理を行なうシステムの本体だ。Mercurialも別のバージョン管理システムの本体だ。これらのシステムからSourceTreeが単体で使うために必要とする部分をダウンロードする。

「Gitが見つかりませんでした」の画面が表示されたら、「システム全体でなく、SourceTree単独で使うためだけの内蔵用のGitをダウンロードする。」を押す。

そうすると、ダウンロードが始まる。

ダウンロードが完了すると、「Mercurialが見つかりませんでした」の画面が表示される。

「システム全体でなく、SourceTree単独で使うためだけの内蔵用のMercurialをダウンロードする。」を押す。そうすると、ダウンロードが始まる。

「Improved Tabs!」画面が表示されたら「Got it」を押す。

この画面が表示されれば、インストールは完了だ。

まとめ

このページではSourceTreeのインストールについて簡単にご紹介した。Gitを使いこなすために参考にしていただければと思う。

Gitインストール方法

Gitはバージョン管理システムのひとつであり分散型と呼ばれている。そのGitのインストール方法を表示される画面の順に従って説明を行う。

ダウンロード

「git for windows」の公式サイト（URL: https://git-for-windows.github.io/）よりインストーラーのダウンロードを行う。

ダウンロードは「Download」ボタンを押すことによって始まる。

インストール方法

ダウンロードが終わると、ダウンロード・フォルダーに最新バージョンのインストーラー（OSに応じてGit-2.13.2-64-bit.exeまたはGit-2.13.2-32-bit.exe）が格納される。この記事を書いている時点では、最新バージョンが2.13.2である。

ダウンロードされたインストーラーをダブルクリックすると、インストーラーが起動される。

インストーラーを起動すると、最初に「ユーザ・アカウント制御」の画面が表示されるので、「はい」ボタンを押す。

インストーラーがコンピュータの変更を許可すると、GNUのライセンスに関する「Setup – Information」画面が開き、ライセンスについての記述が表示される。内容を確認して「Next」ボタンを押す。

Gitをインストールするフォルダーを指定する画面「Setup – Select Destination Location」が開くので、インストール先のフォルダーを確認し「Next」ボタンを押す。この場合はデフォルトのフォルダーである。もし、他のフォルダーを指定したい時は「Brose...」ボタンを押してインストールしたいフォルダーを指定し、「Next」ボタンを押す。

インストールするコンポーネントを選択する画面「Setup – Select components」が開くので必要なコンポーネントにチェックを入れて「Next」ボタンを押す。

• Additional Icon → On the Desktop：デスクトップへのアイコンの追加を行う。
• Windows Explore → Git Bash Here：エクスプローラーの右クリックメニューのリストに「Git Bash Here」を追加する。
• Windows Explore → Git GUI Here：エクスプローラーの右クリックメニューのリストに「Git GUI Here」を追加する。
• Git LFS (Large File System)：Git LFS（大きなサイズのファイル・システム）の導入を行う。
• Associate .git* configuration files with the default text editor：デフォルトのテキスト・エディターと「.git*」コンフィグレーション・ファイルを関連付ける。
• Assiciate .sh files to be run with Bash：Bashと「.sh」ファイルを関連付ける。

この場合はデフォルトの設定である。

メニューフォルダーを選択する画面「Setup – Select Start Menu Folder」が開くのでフォルダーを設定し「Next」ボタンを押す。この場合はデフォルトの設定である。もし、他のフォルダーを指定したい時は「Brose...」ボタンを押してフォルダーを指定し、「Next」ボタンを押す。

Setupは指定されたスタートメニューフォルダーにプログラムのショートカットを作成する。

PATH環境を設定する「Setup – Adjusting your PATH environment」画面が開くのでオプションを選択し「Next」ボタンを押す。PATH環境の設定によりGitのコマンドに加えてWindowsやUnixのコマンドを併用することができる。それぞれのオプションの意味は次の通りである。

• Use Git from Git Bash only：最も安全な選択であり、このオプションを選ぶとPATHが変更されることはない。そして、Git BashからのGitコマンド・ライン・ツールのみを使うことが可能になる。
• Use Git from the Windows Command Prompt：現在の環境がオプションのUnixツールと混じることを避けるために最小限のGitラッパーを環境に追加する。Git BashとWindowsコマンド・プロンプトの両方を使うことができる。
• Use Git and optional Unix tools from the Windows Command Prompt：現在の環境にオプションのUnixツールをPATHに追加する。警告：「find」や「sort」のようなWindowsツールが上書きされる。この実装についてよく理解できている場合にのみこのオプションを使用することが望ましい。。

ここでは、デフォルトの「Use Git from the Windows Command Prompt」を選んでいる。

HTTPS接続の設定をする「Setup – Choosing HTTPS transport backend」画面が開くのでオプションを選択し「Next」ボタンを押す。それぞれのオプションの意味は次の通りである。

• Use the OpenSSL library：サーバー認証はca-bundle.crtファイルを使って行われる。
• Use the native Widows Secure Channel library：サーバー認証はWindows Certificate Storeを使って行われる。

ここでは、デフォルトの「Use the OpenSSL library」を選んでいる。

テキスト・ファイルの行末の変換を設定する画面「Setup – Configuring the line ending conversion」が開くのでオプションを選択し「Next」ボタンを押す。それぞれのオプションの意味は次の通りである。

• Checkout Windows-style, commit Unix-style line endings：Gitはテキス・ファイルのチェックアウトを行う時LFをCRLFに変換する。テキスト・ファイルをコミットする時CRLFをLFに変換する。クロス・プラットフォーム・プロジェクトのためにWindowsに対して推薦される設定である。（「autocrlf」が「true」に設定される）
• Checkout as-is, commit Unix-style line endings：Gitはテキス・ファイルのチェックアウトを行う時どんな変換も行わない。テキスト・ファイルをコミットする時CRLFをLFに変換する。クロス・プラットフォーム・プロジェクトのためにUnixに対して推薦される設定である。（「autocrlf」が「input」に設定される）
• Checkout as-is, commit as-is：Gitはテキス・ファイルのチェックアウトやコミットを行う時どんな変換も行わない。このオプションを選択することはクロス・プラットフォーム・プロジェクトのために推薦することはできない。（「autocrlf」が「false」に設定される）

ここでは単独のパソコンで使用することを想定して、どんな変換も行わない「Checkout as-is, commit as-is」を設定することをお勧めする。

Git Bashと共に使うターミナル・エミュレータの設定を行う「Setup – Terminal emulator to use with Git Bash」画面が開くのでオプションを選択し「Next」ボタンを押す。それぞれのオプションの意味は次の通りである。

• Use MinTTY(the default terminal of MSYS2)：Git BashはMinTTYをターミナル・エミュレータとして使う。そして、それはサイズが変更可能なウインドウで、非長方形の選択、Unicodeをサポートしている。Windowsコンソール・プログラムは（対話型のPythonのような）MinTTYの中で動作させるために「winpty」を通して起動しなければならない。
• Use Widow’s default console windows：GitはWindowsのデフォルト・コンソール。ウインドウ（exe）を使用する。そして、それは対話型のPythonやnode.jsのようなWin32コンソール・プログラムと共に正常に動作する。しかし、デフォルトのスクロール・バックは非常に限られたものである。非ASII文字を正しく表示するためにはUnicodeフォントが使えるように設定する必要がある。また、Windows10以前のウインドウは自由にサイズを変更できないし、長方形のテキスト選択しか許されていない。

ここでは、デフォルトの「Use MinTTY(the default terminal of MSYS2)」を選んでいる。

拡張オプションの設定を行う画面「Setup – Configuration extra options」が開くのでオプションを選択し「Install」ボタンを押す。それぞれのオプションの意味は次の通りである。

• Enable file system caching：ファイル・システム・データはある操作を行うためにメモリに野中にバルクやキャッシュされる。（fscacheがtrueに設定される）これは大幅なパフォーマンス向上を提供する。
• Enable Git Credential Manager：WindowsのためのGit Credential Managerは、Windowsに対して安全な認証証明の付きのストレージを提供する。それは、特にVisual Studio Team ServiceやGitHubのためのさまざまな認証サポートを行う。（.NET framework v4.5.1またはそれ以降が求められる）
• Enable symbolic links：シンボリック・リンクを有効にする。（SeCreateSymbolicLink 許可が要求される）現状のリポジトリーは、この設定に影響されないことに注意してください。

ここでは、「Enable file system caching」と「Enable Git Credential Manager」のふたつのオプションを有効にする。

インストールが開始され、「Setup - Installing」画面が表示される。

最後に「Setup – Completing the Git Setup Wizard」画面が表示されれば、インストール完了である。

まず、Gitを起動しよう。

Gitを起動する

これから、Bashのコマンドラインを使って説明するのでGit Bashを起動する。

Windows 7の場合は、スタート→すべてのプログラム→Git→Git Bashと進めばGit Bashが起動する。

Git Bashが起動した時に最初に表示される画面である。正しくインストールされているかバージョンを表示して確認しておこう。コンソールにgit --versionと入力するとバージョンが表示される。

確かに表示された画面にバージョンが「2.13.2.windows.1」と表示されている。これで正しく最新のバージョンがインストールされたことが確認できた。

では、Git Bashが起動すれば、次に行うのは初期設定である。

初期設定

初期設定としてGitを使うために必要最小限の設定を行う。必要最小限の設定とは、「ユーザ名」と「メール・アドレス」である。

ユーザ名の設定

ユーザ名を設定するには、「git config --global user.name “名前”」と入力する。

設定したユーザ名が正しく設定されたかを確かめるには「git config --global user.name」と入力する。

設定された名前が表示される。

次にメール・アドレスを設定する。

メール・アドレスの設定

メール・アドレスを設定するには、「git config --global user.email “メール・アドレス”」と入力する。

メール・アドレスが正しく設定されたかを確かめるには「git config --global user.email」と入力する。

設定されたメール・アドレスが表示される。ユーザ名とメール・アドレスが正しく設定されていれば必要最小限の初期設定が完了である。

まとめ

このページではGitのインストール方法から初期設定について簡単にご紹介した。

今回、紹介したGitを活用してバージョン管理についても勉強していただきたい。

Gitのインストール方法から初期設定について参考にしていただければと思う。

このページではgit statusコマンドの使い方と、情報の見方について解説を行なっていく。 

Gitのstatusコマンド

statusコマンドの基本

このコマンドは、ワーキング・ツリーの状態を表示するためのものだ。以下に示す条件でコンテンツのパスが表示される。

• ワーキング・ツリーに追跡されていないものがある。
• ワーキング・ツリーとインデックスに違いがある。
• コミットされたものとインデックスに違いがある。

コマンドの基本は簡単だ。

git status [オプション]

このコマンドを実行すると、下記のようなコンテンツの状態が表示される。

では、実際の使い方と、どのように状態が表示されるかを見てみよう。

追跡されていない場合

新たなファイル；Program01.javaをワーキング・ツリーに加えただけだと、statusコマンドで表示されるのは「追跡されていないファイル（Untracked Files:）」だ。

追加された場合

追跡されていないファイル（Untracked）が追加されると、statusコマンドで表示されるのは「コミットされるべき変更（Changes to be committed）」の「新たなファイル（new file）」だ。

コミットされた場合

追加されるか、ステージされたファイルがコミットされると、ファイルは修正されていない（Unmodified）になる。しかし、statusコマンドで表示されるのは「nothing to commit, working tree clean」、つまり「コミットするものは何もない。ワーキング・ツリーは修正されていない」だ。

修正された場合

コミットされたファイル（Unmodified）が修正されると、statusコマンドで表示されるのは「修正されたファイル（Modified）」だ。Gitは、コミットされた後、ファイルが修正されたかどうかをチェックしているのだ。

ステージされた場合

修正されたファイル（Modified）がステージされると、statusコマンドで表示されるのは「コミットされるべき変更（Changes to be committed）」の「修正された（modified）」だ。

削除された場合

修正されていないファイル（Unmodified）が削除されると、statusコマンドで表示されるのは「コミットされるべき変更（Changes to be committed）」の「削除された（deleted）」だ。次のコミットでこの削除がリポジトリに反映される。

commitコマンドのオプション

commitコマンドでは次のオプションが使える。

まとめ

このページではgit statusコマンドの使い方についてまとめてお伝えをしてきた。見方も難しくなく、また多用するコマンドなので覚えておきたいところだ。

ファイル削除にはGUIツールを使うことが多いかもしれないが、手早くやりたければやはりコマンドだ。覚えておいて損はないだろう。

Gitのrmコマンド

このコマンドは、ワーキング・ツリーとインデックスからファイルを削除するためのものだ。

このコマンドを実行すると、インデックスのみ、またはワーキング・ツリーとインデックスの両方からファイルが削除される。現在作業中のディレクトリからファイルを削除することはできないし、ワーキング・ツリーのファイルだけを削除してインデックスには残すということもできない。

コマンドの基本は簡単だ。

git rm [オプション]

では、実際の使い方をみてみよう。

インデックスのみ削除する場合

プログラム・ファイル：Program01.javaを指定してコマンドを実行する時は下記のようになる。

オプション：--cacheを指定して、

$ git rm --cache Program01.java

コマンドを叩けばOKだ。

例えば、Program01.javaとProgram02.javaがインデックスに登録されているとする。

git rmを実行するとどうなるか？

コマンドのオプションで指定したProgram01.javaファイルがインデックスから削除されている。しかし、ファイルは残っている。

インデックスとファイルの両方を削除する場合

インデックスとファイルをまとめて削除することもできる。

修正されていないファイルProgram01.javaがインデックスに登録されていれば、

$ git rm Program01.java

コマンドを叩けばOKだ。

もしファイルが修正されていたら、-fオプションを付けない。更新チェックが行われるため修正されたファイルを削除できない。

-fオプションを付けて、

$ git rm -f Program01.java

コマンドを叩けばOKだ。

例えば、一度コミットされたProgram01.javaとProgram02.javaが修正され、もう一度コミットのためにインデックスに追加された場合を考えよう。

このコマンドを実行すると、

確かにインデックスとワーキング・ツリーの両方からProgram01.javaが削除されている。この削除は、次のコミットを実行した時にリポジトリに反映される。

ディレクトリをまとめて削除する場合

ファイルをひとつひとつ指定しなくても、ディレクトリごとまとめて削除できる。

コマンドの基本は簡単だ。

git rm -r [ディレクトリ]

例えば、ディレクトリ：srcにあるProgram01.javaとProgram02.javaがインデックスに追加されている場合を考えよう。

ディレクトリを指定して、

$ git rm -r -cache src

コマンドを叩けばOKだ。

コマンドのオプションで指定したディレクトリの中のファイルが全てインデックスから削除される。

rmコマンドのオプション

rmコマンドでは次のようなオプションが使える。

まとめ

このページではGitのrmコマンドについて使い方を画面キャプチャも含めてまとめてみた。参考にしていただければ幸いだ。

参考にしていただければ幸いだ。

そもそも、リポジトリの変更を共有するとは？

リポジトリの変更を共有するとは、ローカルのリポジトリの変更をGitサーバ上のリモート・リポジトリに記録し、リモート・リポジトリを介してその変更を共有することだ。

リポジトリの変更を共有する作業の流れは、ローカルから報告された変更をリモートに記録するところから始まる。

記録されたリモートの変更をローカルの別のリポジトリに反映させることもできるし、リモート・リポジトリをそのままクローンしてローカルに別のリポジトリを作成することもできる。

Gitを使った作業の流れは次の通りだ。

• 変更をgit pushでリモート・リポジトリに反映させる。
• リモート・リポジトリをgit cloneでクローンする。
• 変更をgit pushとgit pullで他のリポジトリに反映させる。

では、基本的なGitの使い方と流れを見てみよう。

変更をリモート・リポジトリに反映させる

変更を共有するためにローカルのリポジトリに記録された変更をリモート・リポジトリに反映させる。この時originがリモート・リポジトリの名前で、masterがローカルにあるリポジトリの名前になる。

このために使うコマンドは簡単だ。

git push origin master

コマンドの実行の仕方を確認していこう。

使い方と流れ

ローカルにあるリポジトリのディレクトリに移動する。変更をリモート・リポジトリに反映させるためにgit pushコマンド実行する。

実行結果

リモート・リポジトリがあるディレクトリに移動して、git logコマンドを実行する。リモート・リポジトリにローカルのリポジトリの変更が反映されたことが確認できる。

リモート・リポジトリをクローンする

ローカルにリポジトリを作成するためにリモート・リポジトリをクローンすることもできる。クローンするとリモート・リポジトリのコピーが作成される。

このために使うコマンドの基本は簡単だ。

git clone [リモート・リポジトリ]

ここで、リモート・リポジトリをどのように指定するかだが、「リモート・リポジトリを作成する」のセクションで共有設定を行ったときに出てきた「ネットワーク・パス」を指定する。

コマンドの実行の仕方を確認していこう。

使い方と流れ

リポジトリをクローンするディレクト：/c/gitworkcloneを作成する。そのディレクトに移動して、git cloneコマンドを実行する。

実行結果

リポジトリのディレクトリに移動して、git logコマンドを実行するとリポジトリが作成されていることが確認できる。

さらに、lsコマンドでディレクトリ内のファイルを書くにしてみると、Program01.javaファイルがあるのが確認できる。

変更を他のリポジトリに反映させる

最初に説明したように、変更を共有するためにgit pushを使ってローカルのリポジトリに記録された変更をリモート・リポジトリに反映させることが必要だ。そして、リモート・リポジトリに反映された変更をローカルの別のリポジトリに反映させる。

このために使うコマンドの基本がpullだ。

git pull

コマンドの実行の仕方を確認していこう。

使い方と流れ

前のセクションでクローンして作成したリポジトリのディレクトリにあるProgram01.javaファイルを変更して、その変更が別のリポジトリに反映されるか確かめてみよう。

クローンで作成したディレクトリに移動して、現在のProgram01.javaのコードを見る。

Program01.javaのコードをエディタで「System.out.println("Function-01");」を追加し、コードが修正されたことを確認する。

変更をgit addとgit commitコマンドによりリポジトリに記録する。

次にgit pushコマンドで変更をリモート・リポジトリに反映させる。

他のリポジトリのディレクトリに移動する。リモート・リポジトリの変更をgit pullコマンドでローカルのリポジトリに反映させる。

実行結果

変更の記録を見るためにgit logコマンドを実行すると、別のリポジトリのProgram01.javaの変更が反映されていることが分かる。

さらに、Program01.javaのコードを確認すると確かに「System.out.println("Function-01");」が追加されている。

まとめ

このページではリモートサーバへ変更を共有するgit pushおよび反対にローカルへ反映するgit pullについてまとめてみた。

gitの使い方の基本となるので、ぜひ参考にしていただければと思う。

基本中の基本だけまとめたので、初心者の方は参考にしていただければと思う。

そもそもリモート・リポジトリを作成するとは？

リモート・リポジトリを作成するとは、Gitサーバ上に空のリポジトリを作成し、複数のユーザによって共有できるように設定することだ。作成したリポジトリをリモート・リポジトリとして使うためにリポジトリに名前が付けられる。

Gitを使った作業の流れは次の通りだ。

• リモート・リポジトリをgit initで作成する。
• リモート・リポジトリの名前：originをgit remote addコマンドで設定する。

共有可能なリポジトリを作成するコマンドだ。

git init --bare --share

リポジトリを作成するコマンドgit initに--bare --shareオプションを指定して空のリポジトリを作成する。オプションの--bareは中身のないリポジトリであること指定している。--sharedはリポジトリを複数のユーザによって共有可能なものにする。

リモートリポジトリに名前をつけるコマンドの基本だ。

git remote add [name] [url]

では、コマンドの実行の仕方を確認していこう。

使い方と流れ

サーバ上にリモート・リポジトリを新たに作成するためのディレクトリ：/c/gitrepoitory/sample.gitを作成する。

mkdir /c/gitrepository
mkdir /c/gitrepository/sample.git

Windowsの場合git initの--sharedオプションに加えて、ディレクトリ（Windowsではフォルダ）にリポジトリを共有するための設定が必要になる。

共有設定を行うとネットワーク・パスが決まる。このパスを他のコマンドとともに使用するので覚えておいて欲しい。コピーしておくといいだろう。

次に、共有設定したディレクトリに移動し、オプションを指定して「git init」コマンド実行する。

共有するリポジトリが作成されたら、ローカルのリポジトリに移動する。作成したリポジトリをoriginという名前のリモート・リポジトリとして追加する。コンソールにgit remote add [name] [url]を入力する。

実行結果

正しくリモート・リポジトリとして追加されたかを確認するためにgit remote にオプションに–v指定して実行する。このコマンドによりoriginに対する書き込み（push）と読み取り（fetch）コマンドが表示されれば、リモート・リポジトリが正しく作成されている。

まとめ

このページではgit initによるリモートリポジトリの作成方法についてまとめてご紹介した。参考にしていただければ幸いだ。

リポジトリに記録するというと少々難しいかもしれないが、ゲームでいうところの「セーブ」のようなものでそのタイミングで一度記録を残すことだ。

このページではリポジトリの記録方法についてお伝えしよう。

Gitで変更をリポジトリに記録するとは？

変更をリポジトリに記録するとは、ワーキング・ディレクトリのコンテンツの変更をリポジトリに記録する作業だ。

バージョン管理したいコンテンツを選んでその変更を記録する。

Gitを使った作業の流れは次の通りだ。

• インデックスにgit addでコンテンツを追加する。
• 変更をgit commitでリポジトリに記録する。

では、基本的なGitの使い方と流れを見てみよう。

インデックスにコンテンツを追加する

インデックスにコンテンツを追加するとは、リポジトリにあるインデックス（index）にコンテンツ（ファイルなど）を追加することだ。この操作は、次に行うコミット（commit）のための準備となる。コミットの対象となるのはインデックスに追加されたファイルのみだ。

コマンドの基本は簡単だ。

git add [ファイル名]

まとめてJavaプログラム・ファイルを追加したい時は、ファイル名に「*.java」と指定する。また、全てのファイルを指定する場合は「.」を指定する。

コマンドの実行の仕方を確認していこう。

使い方と流れ

ローカルのリポジトリを操作するためにリポジトリのあるディレクトに移動する。そのディレクトリ直下にあるProgram.javaファイルをgit add コマンドを使ってインデックスに追加する。

実行結果

ファイルがインデックスに追加されたかどうかは、git statusコマンドで確認できる。コマンドを実行すると、Program01ファイルの状態がUntracked filesからnew fileに変わっている。

変更をリポジトリに記録する。

変更をリポジトリに記録するとは、インデックスに登録された現在のコンテンツの変更をリポジトリに記録することだ。前のセクションでも説明したように、git addコマンドを実行しただけでは変更の記録はおこなわれない。コミットを行って初めて変更がリポジトリに記録される。

コマンドの基本は簡単だ。

git commit -m [コメント]

コマンドの実行の仕方を確認していこう。

使い方と流れ

現在のインデックスに登録されたコンテンツの変更をgit commitコマンドにより記録する。既にProgram01がインデックスに登録されているので、そのファイルの変更が記録される。

実行結果

コマンドgit statusを実行すると、コミットするものが何もなくなった（nothing to commit）ことが表示される。

コマンドgit logを実行すると、コミットが実行されたことが付加的な情報とともに記録されていることが分かる。

まとめ

このページではgit addからgit commitする基本的な流れをお伝えしてきた。git addでバージョン管理をする対象にして、git commitでそれを保存する形だ。

GUIツールでもできるが、基本的な使い方なのでコマンドでもできるように理解し、覚えておこう。