Git入門（SourceTree の使い方）

これだけは知っておいたほうが良いと思ったことを中心に、SourceTree の基本的な操作をまとめて紹介します (^^)

これで基本的なことはだいたい出来るようになると思いますが、まだまだ Git 勉強中なので、間違いがあればご指摘頂ければと思います m(__)m

SourceTree 基本機能一覧

新規/クローンを作成する
ファイルステータス/ログ

追加
削除
破棄
無視
スタッシュ（一時退避）

ブランチ
コミット
コミットのリセット
インタラクティブリベース（コミットの編集）
コミットを打ち消し
チェックアウト（切り替え）
マージ
チェリーピック

フェッチ
プル
プッシュ

SouceTree画面のボタンやメニューから操作するであろう手順に沿って紹介します
ちょっとボリュームがありますが、どれも大切な機能なのでしっかり覚えましょう

新規/クローンを作成する

ローカルリポジトリの作成を行います
新規に空のリポジトリを作成するか既存のリポジトリのクローン（複製）を作成します

これは、前回の Git入門（GitBucket と SourceTree の準備）で紹介しているのでそちらを参照して下さい

ファイルステータス/ログ

SourceTree は指定したレポジトリの様々な状態を常に表示しています

この画面から様々な操作を行うことになります

画面左からリポジトリを選択（複数存在時はダブルクリックで切り替え）
リポジトリを選択するとファイルステータス、ログ状態を確認できるようになります

ファイルステータス

作業ツリーとステージ（Index）間の状態を確認します
ファイル追加、修正、削除状態と変更内容の確認を行いコミットの準備をします

ブランチ情報

リビジョングラフ（樹形図）、コミットログ、変更点等を確認出来ます
履歴から現在までの全体的な状況を把握することが出来ます

Gitでは、ブランチを用いて作業を進めていくので、自分が今どこにいるかを把握しておく必要があります。何か操作した後には、この画面で確認しておくと安心します (^^)

他にもタグを付けたリビジョンやリモートリポジトリの状態の確認等ができます

作業ツリーとステージ（Index）エリアの操作

追加

ステージ（Index）にコミット対象を登録します

作業ツリーから新規/変更ファイルを選択してステージへ追加（追加ボタンをクリック）することでコミット対象となります

ポイントは、コミット対象のみをステージに追加して、コミットに関連しない変更分まで含めないように注意することです

ステージに追加するのはファイルが最小単位というわけではなく、作業したファイルの変更部分（hunk）単位に行うことも可能です

例えば、今回のコミットしたい内容とは関係のない修正も同時に行ってしまった場合等に変更箇所が部分（Hunk）ごとに表示されるので、Hunkをステージに移動 ボタンで必要な部分のみをコミット対象とすることが出来ます。間違えてコミット対象とした場合は、Hunkをステージから除く ボタンをクリックするだけです

削除

ステージ（Index）にコミット対象（削除したいファイル）を登録します

作業ツリーから削除ファイルを選択してステージへ追加（削除ボタンをクリック）することでコミット対象となり、削除されるファイルには赤いマークが付きます

ポイントは、削除は、そのコミット時点でのリポジトリ内の管理データに削除という状態を記録することにすぎないということです

ステージに削除登録して、コミットすることでファイルが削除されたことになります

作業ツリー内のファイルを直接消しただけでは本当に削除したことにはなりません。
SourceTree 上では、削除されたことを検出して状態表示してくれますが、ステージへの削除登録とコミットが必要となります

コミットでリポジトリへ反映することをお忘れなく (^^)

破棄

コミット前の作業ファイルの変更を破棄します

破棄ボタンをクリックすると変更箇所の表示を確認する為の画面が表示されます

全ファイルの変更を破棄するか、指定したファイルの変更のみ、あるいは変更箇所部分（Hunk）を選択して破棄することが出来ます

破棄する変更を選択して実行すればOKです

注意：破棄すると、まだコミット前なので、元には戻せません

無視

特定のファイルをバージョン管理対象から除外する為の設定

例えば管理対象がプログラムコード等の場合には、プログラム言語毎に生成される中間ファイルや設定ファイル等があり、それらのファイルをバージョン管理対象から除外する必要があるので、除外対象ファイルの定義を .gitignore というファイルに定義します

作業ツリー内の無視したいファイルを選択して、マウス右クリックでメニューが表示されるので無視を選択します

確認ダイアログが表示されます
無視するファイルは、ファイル名だけでなくパターンで指定することも出来ます

確認してOKをクリックします

作業ツリーに .gitignore という無視するファイルを定義したファイルが作成されます
また、この無視ファイル .gitignore は設定の詳細から編集することも出来ます

言語毎の推奨設定 github/gitignore を参考にして下さい

作成された .gitignore ファイルをステージに追加して、コミットします

無視するファイルを間違えてコミットしてしまった場合

作業ツリーでファイルを選択し、マウス右クリックから追跡を解除でバージョン管理から削除することが出来ます

すると、ステージ（Index）に削除マーク付きで追加されるのでコミットします

コミットすると作業ツリーに未追加ファイルとして表示されます

このファイルを改めて無視ファイルとしてステージに追加、コミットすればバージョン管理対象から除外することが出来ます

スタッシュ（一時退避）

現在の作業ツリーの内容を一時的に退避させ作業前のクリーンな状態に戻します

作業途中に急に割り込みで対応が必要な場合等で使用します
割り込みで入った作業を行った後、元の状態へ戻せがOKです

スタッシュボタンをクリックします

適当な名前を付けてOKをクリック

ログを確認するとコミットされていない変更が消されて、画面左にスタッシュとして先ほど設定した名前が表示されます

割り込み作業が終了したら、作成したスタッシュを選択してマウスを右クリックすると

適用と削除がメニュー表示されるので適用を選択します

元に戻してもこのスタッシュは残っているので、マウス右クリックから削除を選びスタッシュを削除します

ここまでステージ（Index）エリアに対しての主な操作について紹介しました

ローカルリポジトリに対する主な操作コマンド

ブランチ

バージョン管理するためには、リポジトリにコミットして変更データを登録する必要があります

ここでは、ブランチを知った上でコミットを使ったほうが、Git が理解しやすくなると思いますので先にブランチを紹介します

ブランチって何？と思うかも知れませんが、Gitを使うには避けては通れません (^^)

ブランチとは、あるコミット履歴位置からブランチ（枝分かれ）させて、他のブランチに影響を与えないバージョンを作成作成するための仕組みです

この機能により、複数の機能追加を別々のブランチで分散して行い、後で統合することも出来ますし、機能に違いを持たせた複数バージョンを別々に管理していくことも出来ます

追跡ブランチ

前回の作業でローカルリポジトリを作成した時の最初のコミットで、既にローカルブランチ master とリモートブランチ origin/master の名前がデフォルトで作成されています

この一番最初に自動的に作成されるブランチを master ブランチといいます

ここで大切なのは、ローカルリポジトリの master ブランチは、リモートリポジトリの origin/master ブランチに関連付けられている追跡ブランチとなっていることです

追跡ブランチとは、リモートブランチと関連付けされているローカルブランチのことで、ブランチ間の同期をとるためのマージやプルコマンドの対象ブランチとして設定されているローカルブランチのことです

ブランチには３種類あることを意識して下さい

リモートブランチ（リモートリポジトリで共有されているブランチ）
追跡ブランチ（リモートブランチに関連付けられたローカルブランチ）
ローカルブランチ（自分専用の作業用ローカルブランチ）

また、リモートブランチは共有されているので、追跡ブランチとは、１対複数の関係になります。誰か他の人がいつ内容を更新しているかわかりません。追跡して内容を最新状態に保つことが大切です

特に master ブランチは、最新のメインバージョンを管理する役割がありますので、共有されている一番大切なデータを操作しているということを自覚することも大切です

何か作業が必要なときは、直接 master ブランチで作業しないことがお勧めです

作業用ブランチの作成

master ブランチに限った話ではありませんが、リモートリポジトリ上のブランチに対して、機能の追加や修正を行う時は、そのブランチの追跡ブランチを操作するよりも自分専用の作業用ローカルブランチを作成して作業します

自分一人だけで使用している範囲ではあまり関係ないかも知れませんが、普段から自分専用のブランチを作成して作業する癖をつけておけば、複数人で作業するときにトラブルになりにくくなります (^^)

さっそく作業用にブランチを作成してみます

作成

どこにブランチを作成するかを指定します

作業コピーの親：現在のブランチ（HEAD）位置にブランチが作成されます
指定のコミット：作成位置を選択する画面が表示されるので位置（コミット）を選択
新規ブランチを作成してチェックアウトをチェックするとブランチ作成後、そのブランチにチェックアウト（切り替え）します

作業コピーの親に develop1 ブランチを作成してみます

何が行われたかというと、指定したコミット位置にブランチ名が設定されただけです。

コミットしてバージョン管理データに差異が生じることで枝分かれした樹形図として表示されます

Develop1 にコミットしてみます
ちょっとわかりづらいですが master の先に develop1 が分岐しています

もう一つ develop2 ブランチを作成してコミットしてみます
この状態で master, develop1, develop2 ３つのローカルブランチがあります

ブランチの削除

現在のブランチ以外のブランチを削除することが出来ます

確認を求められるので、削除するならOKをクリックします

※現在のブランチを削除しようとするとエラーとなります

この場合は、チェックアウトで現在のブランチを切り替えてから削除を行います

ブランチは、難しそうと感じるかも知れませんが、慣れれば、ブランチなしでは作業できなくなると思います

追跡ブランチと作業ブランチを使い分けることがポイントです

機能の追加変更時は、ブランチを作成して試してみて、必要ならマージ、不要ならブランチ削除なんてことが手軽に行えます (^^)

コミット

ステージ（Index）に登録したファイルをローカルリポジトリに反映します

コミットするとリポジトリに変更内容を記録したリビジョンが生成され履歴として残ります

既に何回か使用しているので、動作はわかっていると思いますが、先にブランチを知って欲しかったので説明が後になってしまいました (^^)

コミットボタンをクリックするとダイアログが表示されるので、コミットメッセージに理由や対応内容等を記述して実行します

ポイントは３点

コミットメッセージは、出来るだけ推奨形式に合わせましょう
修正内容、コミット先ブランチが合っていますか
コミット時にプッシュは行わない

コミットメッセージ

1 行目に概要を 50 字以内、2行目は空白行、3行目以降にコミット内容の詳細を記述する形式が推奨されています

修正内容の確認

コミットと関連しない修正が含まれていないことを確認
コミット先ブランチが合っていることを確認します

コミット時にプッシュは行わない

リモートへのプッシュはここで同時に行う必要はありません。というかむしろ同時に行わないほうが良いです。

コミットを間違えたりした場合にプッシュまでしているとかえって面倒です

別途必要に応じてプッシュしましょう (^^)

コミットのリセット

リモートリポジトリへプッシュする前のコミットの取り消しに使用します

コミットしてしまった修正内容を取り消し（リセット）することが出来ます

ログ画面の樹形図（コミットグラフ）上で指定したコミットの後から最後のコミットまでがリセット対象となります

最後のコミットを取り消したい場合は、一つ前のコミットを選択すればOKです (^^)

一つ前のコミットを選択してマウス右クリックから 現在のブランチをこのコミットまでリセット を選択します

どのようにリセットするかダイアログが表示されます

リセット方法は、３つの選択肢があります

Soft ：ローカルの変更を全てそのままにする
Mixed ：作業コピーの変更はそのままにするが、インデックスの状態はリセットする
Hard ：全ての作業コピーの変更を破棄する

Soft ：ローカルの変更を全てそのままにする

指定コミットの後から最後までのコミット履歴が全てクリアされますが、その間に行われた全ての変更は、コミットされてない変更として作業ファイルに残っています

また、変更されているファイルもステージに追加された状態で復元され、コミットだけを行っていない状態となります

あっ！今のコミットちょっと待ってと言う場合の操作にピッタリです (^^)

また、複数コミットをリセットした場合は、この状態から再度コミットすれば、リセットした複数の変更内容を１つのコミットにまとめたのと同じこととなります

Mixed ：作業コピーの変更はそのままにするが、インデックスの状態はリセットする

Soft タイプとの違いは、ステージがクリアされるところだけなので、お好きな方を使用すれば良いと思います

ここから何をどのような順番にコミットしていくかステージを再構築してコミットしていきます

Hard ：全ての作業コピーの変更を破棄する

このリセットは、指定コミットの後から最後までのコミット間に行われた全ての変更が破壊されてしまいます

とても危険な操作で致命的な事故となる恐れもありので再度確認を求められます

実行すると、他の２つのタイプのようなコミットされていない変更として変更内容が保持されることもなく、削除されてしまいます

それまでの全ての変更が綺麗になくなってしまいます。

Hard リセットは、やり直しはききません
出来れば使わないほうが良いです。後悔先に立たずです (^_^;)

インタラクティブリベース

先ほどのリセットは、最後のコミットまでがまとめてリセット対象になってしまいましたが、インタラクティブリベースという機能で特定のコミットをピンポイントで削除することが出来ます

プッシュする前のコミットをいろいろ編集したい場合に、GUI操作を用いて対話的に、コミット履歴の編集操作をすることが出来ます

↑↓ を使用して指定したコミット位置の入れ替えや、コミットメッセージの変更、前のコミットとまとめる（Squash with previous）、コミットの削除等が行えます

試しに、最後から１つ前のコミット追加２のコミットを取り除いてみます

一つ前のコミットを選択して右クリックメニューから インタラクティブなリベースを行う を指定します

指定コミット以降の履歴リストが表示されます

今回は、コミット追加２を画面下部の削除ボタンで選択して実行してみます

コミット追加２が削除されました

※リベース指定範囲に同一箇所の修正があるとコンフリクトを起こしてエラーとなります。万能ではありませんので状況に合わせて使用していくことが大切です

コミットを打ち消し

既にリモートリポジトリへプッシュした後のコミットは削除したい場合は、コミットの打ち消し（リバート）を使用して、打ち消したいコミットの逆作用のコミットを適用します

プッシュ済みの共有されているコミットを削除するのはトラブルの元となりやすいので、そのコミットと逆の作用のコミットを適用して削除したのと同じ効果を得るようにすることです

コミットを選択してマウス右クリックから コミットの打ち消し を選択

確認ダイアログ

実行すると打ち消し（Revert）コミットが追加されます

これをプッシュすればリモート（共有）ブランチに反映されます

参考：リモートブランチのコミットを消したい場合

トラブルの元なのでお勧めしませんが、リモートブランチへ間違ってプッシュしてしまったコミットをコマンドラインから削除することが出来ます

間違ってプッシュしてしまったコミットを GitBucket から見てみる

SourceTree のターミナルボタンをクリックしてコマンドラインから実行します

Gitコマンド知らないので検索検索 (^_^;)

どうやらこのコマンドで出来るらしいのでやってみる

git push -f origin HEAD^:master

エラー発生 HEADの一つ前を指定したつもりなのにマッチしないらしい

それではということで GitBucket に表示されているリビジョン番号を指定してみる

git push -f origin 660ed8bbfe:master

うまくいきました (^^)

念のため、もう一度言いますが、オススメはしません

チェックアウト（切り替え）

チェックアウトは、ブランチを切り替えて指定コミット時点の作業ツリーを復元することです

ローカルリポジトリ上の切り替えたいブランチのコミットを指定すれば、作業ツリー内のファイルがそのコミット時点の状態に戻ります

どんな時に使われるかというと、指定したバージョンでのプログラム動作を確認したい場合やブランチを作成する時、マージするブランチを指定する時等で切り替えを行います

試しにチェックアウトボタンをクリックして実行してみます

選択画面が表示されるので、切り替えるコミットを選択してみます

ブランチの最後のコミット位置以外へのチェックアウトでは、こんな確認メーッセージが表示されます

※ブランチの最後のコミットにチェックアウトした場合は、警告ダイアログは表示されません

通常 HEAD というのは、現在のブランチの最後を指しているのですが、ブランチの途中のコミットにチェックアウトすると、あたかもそのコミットがブランチの最後であるかのように HEADがそこにセットされますという警告です

OKをクリックすると作業ツリー内のファイルも全てその時の状態に復元され、 HEAD がそこに設定されます

この状態は、HEADはどこにも属さない名無しのブランチを指しているので、そこに新たにブランチを作成して名前を付けないとコミットしても保存されませんよということです

ファイル内容の確認だけで変更等の作業がないなら特に問題はありませんので、再度、ブランチの最後のコミットを指定してチェックアウトすれば元の状態に戻ります

ローカルリポジトリ上の任意のコミット位置へのチェックアウトが出来ることを確認してみましたが、チェックアウトにはもうひとつタブがあり 新規ブランチを作成してチェックアウト と言うのが指定出来ます

新規ブランチを作成してチェックアウト

どのような場面を想定しているかというと、誰か他の人がリモートリポジトリに新しくブランチを作成した場合、その新しいブランチを自分のローカルリポジトリへ取り込み、そのブランチにチェックアウトを行うという複合的な動作です

例えば、リモートブランチに origin/develop2 ブランチがあることを検出しましたが、まだローカルリポジトリには origin/develop2 を追跡する develop2 ローカルブランチがない場合です

develop2 ブランチを新規ブランチとしてローカルブランチに取り込んでみます

チェックアウトボタンをクリックして 新規ブランチを作成してチェックアウト タブを選択

チェックアウトするリモートブランチを選び、ブランチ名を指定します

※リモートブランチとローカルブランチは、違うブランチ名にすることも可能ですが、名前は同じ方が分かりやすいので変えないことをお勧めします

また、新しいブランチを取り込む時に追跡ブランチにするかどうか設定します

設定のメッセージはローカルブランチでリモートブランと尻切れ状態ですが、追跡ブランチにするかどうかの指定です

実行すると develop2 ローカルブランチが生成され、チェックアウトされました

マージ

ブランチで作業したコミット（成果）を取り込んで統合する処理です

マージは現在のブランチに対して行われ、どのブランチのコミットを統合するか指定します

ブランチまでは、すんなり頭に入ってきましたが、マージ、リベースあたりから何かモヤモヤしてきますこのあたりが Git の難しさでしょうか？

ここでは３つのブランチ（master, develop1, develop2）に枝分かれしたものをマージしてみます

マージボタンをクリックすると統合するコミットの選択ダイアログが表示されます

現在のブランチ（develop1）に develop2 のコミットをマージしてみます

ちなみに同じ位置にメッセージを追加したのでコンフリクトが発生するはずです

予想通りコンフリクト発生です

コンフリクトした部分が、コミットされていない変更 となっています

コンフリクトは、マージするブランチ間で同じ場所を修正していた場合に発生します

<<<<<<< HEAD から ======== という行までが現在のブランチの情報で、

======== から >>>>>>> XXXXXXXXXX までがマージするブランチの情報です

修正してコミットすればマージが終了します

今回は単純な同一箇所のメッセージ追加のコンフリクトなので、エディターで修正しますが、外部のマージツール等で修正してコミットしてもOKです

マージ後の状態

develop1ブランチにマージコミット（develop2コミットの取り込み）が行われますが、develop2ブランチは、閉じるわけではなく何も変わりません。このまま develop2 へコミットすれば develop1 とは別のブランチとして管理されていきます

樹形図（コミットグラフ）はゴチャゴチャした表示となりますが、コミット履歴がブランチを含めて残っていく基本的な統合方法です

リベース

マージと同じようにブランチを統合するのにリベースというコマンドもあります

先ほどのマージコミットを削除して同じ状態に戻してから、現在のブランチ（develop1）に develop2 のコミットをリベースしてみます

マージボタンをクリックしてダイアログを表示させます

リベースで統合する develop2 のコミットを選択します
オプションの マージの代わりにリベースする をチェックしておきます

今回も同じ位置にメーッセージの変更があるのでコンフリクトが発生です

コンフリクト部分をエディターで修正してコミットします

継続します

樹形図（コミットグラフ）は再構築されてスッキリしました

但し、ブランチされていたという履歴が改変されてしまいます

リベース後の状態

Develop1 ブランチに develop2 のコミットが挿入されます
develop2ブランチは、ブランチ上にあったコミットが develop1 ブランチに取り込まれ、基点が変わりブランチ名だけが残っている状態です。

よく見ないと何が起こったのかわかりません (^_^;)

基本的にはリモートブランチと統合する場合はマージを使用するのが鉄則です
リベースは、まだプッシュしていないローカルブランチの範囲で使用しましょう

※複数人でバージョン管理を利用している場合は、リベースでリモートリポジトリに統合すると思わぬトラブルの元となるので注意

詳しくはこわくない Git が参考になります

チェリーピック

他のブランチの特定のコミットを現在のブランチの最後に取り込みます

イメージとしては、別のブランチで行われたコミットをピックアップして取り込む感じです

Develop1 ブランチに develop2 のコミット追加２－１というコミットを取り込んでみます

取り込むコミットを選択して、マウス右クリックからメニューのチェリーピックを選択

確認ダイアログが表示されるので OK をクリック

Develop1 の最後にピックアップしたコミット追加２－１のコミットが追加されました

意外と分かりやすくていい感じです (^^)

逆に不要な変更を取り除く時は、既に紹介したインタラクティブリベースかコミットの取り消しを使用します

これでローカルリポジトリに対する主なコマンドの紹介がようやく終わりました

残りはリモートリポジトリ間との操作コマンドです　もう少しがんばりましょう　(^^)

ローカルリポジトリとリモートリポジトリ間の操作コマンド

フェッチ

現在のローカルブランチに対応するリモートブランチの最新情報を取得します

SourceTreeでは定期的にフェッチが自動で行われていますが、ボタンをクリックすれば直ぐに実行出来ます

例えば、あるローカルリポジトリからリモートの master ブランチへコミットが一つプッシュされたとします

リモートブランチは更新され、ローカルリポジトリでは master と origin/master が同じ位置を示しています

このリモートリポジトリを別のローカルリポジトリから見た時はどう見えるでしょうか？

フェッチを行うことでリモートブランチの最新状態を取得できるので、リモートブランチに更新があったかどうかを見ることが出来ます

こちらのローカルリポジトリから見ると master は origin/master に対して１コミット分遅れがあることが分かります

このようにリモートブランチと追跡ブランチ間の HEAD 参照位置の確認を行うことが出来ます

origin/master と master は別リポジトリ上のブランチなので違いがないかを常に確認することが大切です

プル

プルとは、フェッチとマージを行うことです
リモートブランチの更新を取り込み、ローカルブランチと同期をとることです

現在操作対象となっているローカルブランチの最後のコミットには、HEADというポインタがセットされます。同様にリモートブランチにも HEAD があるので、誰かがコミットすれば、HEADの位置が変わっていき、追跡ブランチとの間に差が生じてしまいます

このブランチ間の変更データを取り込んで同期をとることをプル（マージ）と言っています

先ほどのフェッチでプルボタンのところに赤く反映されていないコミット数が表示されていますので、プルして、ローカルブランチに取り込んでみます

プルボタンをクリックするとダイアログが表示されるのでOKをクリック

うまく同期がとれたようです

ローカルブランチにコミットが取り込まれて、master と origin/master が同じ位置を示すようになりました

プッシュ

追跡ブランチの変更をリモートブランチへ反映させて同期をとることです

ローカルブランチの作業が終わったら、リモートブランチへ共有するためにプッシュします

作業用にローカルブランチを作成していた場合は、その作業ブランチ自体は追跡ブランチではありませんので、リモートリポジトリに関連付けられたブランチは存在していません。プッシュする前に master 等の追跡ブランチへ作業ブランチの内容をマージしてから、プッシュを行いましょう

例えば、develop1, develop2 ブランチは追跡ブランチでないので、ローカルリポジトリにしか存在しませんので、プッシュ操作時のダイアログのリモートブランチが空欄になっています

これをプッシュ対象としてチェックすると、自動的にリモートブランチにブランチ名がセットされて追跡ブランチと設定されます

ここでそのまま実行するとリモートリポジトリ上にそのブランチが作成されてしまいます

ここ注意です　(^^)

Origin/master と別のリモートブランチを作成したい時は、新たにリモートブランチを作成することに問題はありませんが、作業ブランチとしてしか考えていない場合は、リモートブランチを作成することは考えていませんので、誤ってチェックしないように気をつけましょう (^^)

※間違ってリモートリポジトリ上にブランチを作成してしまった場合は、ブランチボタンをクリックして、ブランチを削除から該当するリモートブランチを指定して削除すればOKです

それでは、気を取り直して develop2 の内容を追跡ブランチ master にマージ

作業ブランチをマージした master をプッシュしてみます

リモートブランチが更新され origin/master と同期が取れました

GitBucketから見てみる

SouceTree で見たのと同じようにコミットされてます

作業ツリー develop2 が不要になったので削除

Develop2 のブランチが削除されました

こんな感じでプッシュ時はちょっと手間が増えますが、リモートリポジトリに無駄なブランチを誤って作成しないように気をつけましょう

作業用ブランチ作成
作業の区切りごとにコミット
作業終了したら追跡ブランチにマージ
リモートブランチにプッシュ
作業終了したブランチを削除

後は、これの繰り返しで作業を行うことでバージョン管理をスムーズに運用できるのではないかと思います (^^)

ふー　長かった

SourceTreeの断片的な紹介はたくさんあるのですが、まとまったものがあまり見当たらないようなので基本的なものはとりあえず盛り込んだつもりです

まだ、１０日ほど使っただけなので、間違いがあるかもしれませんが、ひと通りの操作は出来るようになると思います　(^_^;)

次回は、NetBeansでの使い方 Git入門（NetBeans からの使い方）を紹介します

開発ツールGit, SourceTree