SourceTreeとgitで変更管理 ローカルで管理する手順説明

Sourcetree
この記事は約10分で読めます。
スポンサーリンク

コードの変更管理をするのに、Git が便利ですし、
使っているプロジェクトも多いと思います。

ただ、毎回、コマンド打ち込むのも煩わしいし、
履歴がグラフィカルに把握できると、作業の効率が
とても良くなります。

ですので、gitのコマンドラインも今まで通り使いながら、
Sourcetree を導入して、GUIの利点も満喫するのが
おすすめです。

Sourcetreeは、あなたが、git のコマンドを使わずに、
GUIで状態の確認・操作をすることで、git で変更履歴を
管理することができます。

私は、

  • 過去の変更履歴を確認したり、
  • 作業フォルダで変更したファイルの一覧を確認し、
  • コミット対象をステージングとして選択、
  • コミット作業

の作業は、ほぼSourcetree でやっています。

ただ、コミットの取り消しとかマージなどで
イレギュラーな作業には、
git のコマンドを直接使うことが多いです。

理由は、イマイチ、私がSourcetree の振る舞いを把握
していないからなだけです。

そこで、なるべくSourcetreeを使って楽をするために、
Sourcetreeの振る舞いをテスト環境で確認するようにしました。

 

もしあなたも、ちょっとSourcetreeの振る舞いわからないからググってみよって
思ってこちらを訪れたのであれば、
簡単にSourcetreeをテストできるローカル環境を
作ることをおすすめします。

そんな、ローカルにSourcetreeのテスト環境を作って、
振る舞いの確認をする方法をお伝えします。

※windows7での説明になります。
操作説明しているSourcetreeのバージョンは 2.3.1.0です。

ローカルのSourcetreeテスト環境の作成手順

ローカルレポジトリの新規作成

「ファイルメニュー → 新規/クローンを作成する」を選択します。

「Create(新規作成)」を選択し、

作業フォルダを選択、

「次のアカウントでリポジトリを作成」のチェックをはずし、

「作成」を押します。

存在するフォルダを選択した場合、

「すでにフォルダがありますが、続けて良いですか?」

と聞かれるので、「Yes」で続行します。

できました。「ログ」タグを開いてください。まだ、一つもファイルがありません。

新規コミットのテスト

コミット用のファイルを準備

とりあえず、ローカルレポジトリを作成したときの指定フォルダを開いて、
ファイルを追加します。

Windowsであれば、

「フォルダで右クリック、新規作成→テキスト文書」

で、作ります。

この作成時の指定フォルダを以後、「作業フォルダ」と呼びます。

ここでは例として2つ作ってみました。

  • test_to_be_committed.txt
  • test_not_to_be.txt

ここで、sourcetree を開くと、
ちゃんと2つのファイルが認識されています。

? のアイコンは、gitで管理していないファイルと言う意味です。

クリックするとそれぞれのファイルの変更点(この場合新規なので内容)が
表示されます。

コミット前の操作・ステージングエリアへファイルを追加

コミットする際には、まず、
コミット対象のファイルをステージング状態にする必要があります。

この2段階コミットは、最初煩わしいと思われるかもしれませんが、
「作業フォルダ」で変更したファイルたち全部を
一斉にコミットせず、指定したファイルだけコミットできるので
大変便利です。

コミットするファイルだけを選べる他に、
コミットを変更の意味ごとに分ける使い方もできます。

さて、ステージングエリアへ、「テスト環境のテスト文書.txt」だけ
追加しましょう。

「ログ」タブの「作業ツリーのファイル」領域の中から、
「テスト環境のテスト文書.txt」を選択し、
「選択をインデックスに追加」をクリックします。

すると、「Indexにステージしたファイル」の領域にファイルが移動します。

これで、コミットの準備が整いましたので、次はコミットします。

ローカルレポジトリへのコミット

コミットの方法です。

まず、「ファイルステータス」タブを開き、
コミットのコメントを書き、
「コミット」をクリックします。

コミットが完了しました。

コミット履歴の表示

コミット内容の表示

コミットの内容を確認するには、

「ログ」タブを開き、
上部のコミット一覧からコミットを選択します。

さらに、ファイルごとの変更点を見たいときは、
下部左側の変更ファイル一覧から、ファイルを選択します。

すると、下部右側に変更点が表示されます。
ファイルの右側の+アイコンは、ファイルを追加したという意味です。

複数コミット後の履歴表示

とりあえず、コミットを繰り返した後の表示です。
いまのところは、全て、master ブランチのみとしています。

ファイルの前にオレンジ色したペンのアイコンがありますが、
ファイルを編集したという意味です。右側には変更点が表示されています。

ブランチのテスト

ブランチ作成の前に、変更点を管理したくないファイルを無視する設定

ブランチ作成の際には、
作業フォルダを変更点のない状態にする必要があるため、
ここでは、変更を管理するつもりのないファイルである
text_not_to_be.txt を、無視するように設定します。

手順:

  1. 「ログ」タブを選択します。
  2. 「コミットされていない変更があります」を選択します。
  3. 変更を管理しないファイルを右クリックして、
  4. 「無視」をクリックします。

「無視」ウィンドウが開くので、
「名前が一致するファイルを無視」を選択して、
「OK」をクリックします。

すると、「無視」を選択したファイルは見れなくなります。
ところが、一つ、「.gitignore」というファイルが追加されてしまってます。

gitで無視するファイルを指定するファイルであり、
右側ウインドウに表示された変更内容をみると、
「text_not_to_be.txt」と、
指定したファイルが書かれています。

このファイルは、追加してコミットしておきます。

これで、作業フォルダに変更点のない状態になり、
下図の通り、コミット内容だけが「ログ」タブに表示されるようになりました。

ブランチの作成

以下の手順でブランチさせます。

  1. ブランチアイコンをクリックします
  2. ブランチ名を指定します。ここでは、sub1 としてます。
  3. どのコミットから分岐させるかを指定します。
    最新コミットの場合「作業コピーの親」とします。
    過去のコミットから選択した場合、「指定のコミット」とすれば
    グラフィカルに選択できます。
  4. 「新規ブランチを作成してチェックアウト」にチェックを入れて、
    作業フォルダの作業対象を、新しいブランチにします。
  5. 「ブランチの作成」をクリックします。

すると、コミット一覧の最新コミットの先頭に、
「sub1」と「master」のふたつのブランチ名が表示されるようになります。

各ブランチでコミット

新しいブランチでコミット

ファイルを更新、コミットを2回繰り返してみます。
コミット後は、作業フォルダに変更点がない状態にしてください。

下図の通り2回コミットしてみました。

作業対象のブランチを変更(チェックアウト)

次にmasterでコミットテストをしてみたいのですが、
作業フォルダの作業対象を変更する必要があります。

この操作を、チェックアウトするといいます。

master のアイコンのあるコミットをダブルクリックすることで変更できます。

また、別の方法として、
左側メニューの「ブランチ」を開き、「ブランチ名」を
ダブルクリックしても、作業対象のブランチを
チェックアウトすることができます。

 

作業フォルダの作業対象のブランチには、白抜き丸 がついています。

新しいブランチ(選び直したブランチ)でコミット

masterブランチに切り替えたことで、
「text_to_be_committed.txt」ファイルの
sub1 ブランチでの変更が消えています。

今度は、切り替えた後の master ブランチで2回ほど
ファイルを更新してコミットしてみます。

2回コミットした後の「ログ」タブ表示です。コミット一覧表示の左側に、ツリーが表示されていますが、2つのブランチでどのコミットが行われたのか、とてもわかり易くなっています。

そして、各コミットをクリックすると、変更内容が、下段に表示されますね。

Sourcetree、本当におすすめです。

マージテスト

sub1ブランチのコミットうち、特定コミットまでを、masterへマージ

コミット「sub1ブランチ2回目のコミット」を master へマージしてみます。
sub1ブランチでこのコミットまでのすべての変更をマージすることになります。
(sub1ブランチでもう一回コミット、合計3回コミットしております)

手順:

  1. masterブランチで作業していることを確認。
  2. sub1のマージしたいコミットで右クリックし、
  3. マージを選択します。

「マージの確認」ウィンドウが出てくるため、「OK」で確定します。

結果は以下のようになります。

ツリー表示で、
masterブランチには、sub1ブランチの2回目までのコミットが反映され、
sub1ブランチには、さらに1回コミットされていることが
一目瞭然でわかります。

また、ファイルの差分表示からは、sub1ブランチの2回めまでのすべての
コミットが反映されていることが分かります。

コミットの削除のテスト

今、マージしてコミットした内容を完全に削除してみます。

手順:

  1. masterブランチであることを確認
  2. masterブランチの中で、戻りたいコミットを右クリック
  3. 「現在のブランチをこのコミットまでリセット」を選択

「コミットにリセット」ウィンドウが出てきます。

ここで、使うモードを選択して、「OK」を押すのですが、

使うモードは3つあります。

Soft: ローカルの変更をすべてそのままにする。
途中や中途半端なときにコミットしてしまったときなどに使う。

Mixed: 作業コピーの変更はそのままにするが、
インデックスの状態はリセットする。
コミット対象としてステージングエリアにインデックスした状態は
削除。ファイルの変更作業は残っています。

Hard: すべての作業コピーの変更を廃棄する。
ファイルへの変更作業もすべて消してしまいます。

今回は、マージした内容を跡形もなくなくしたいので、
Hard を選択します。

警告が出るので「Yes」で返答します。

きれいさっぱりマージコミットがなくなりました。
マージテスト前と全く同じ状態になってますよ。

 

特定のコミットだけのマージ(チェリーピック)テスト

先程のマージでは、特定のコミットまでの全部の変更がマージされましたが、
一つのコミットだけの変更をマージしたい時があります。

そんな時、チェリーピック という機能を使います。

手順:

  1. masterブランチにいることを確認
  2. sub1ブランチ2回めのコミットを右クリックし、
  3. チェリーピックを選択

確認ウィンドウで「Yes」をクリックします。

あれ、競合が起きてしまいました。ファイルを編集しましょう。

右側に衝突した内容が表示されています。

はっきり言って、 masterとsub1のブランチで、
それぞれ、違う位置に文を追加してるだけなので、
競合なわけが無いのですが、差分検出ロジックが甘いみたいです。
テキストエディタで編集するだけです。

修正が済んだら、普通にステージングエリアに上げてコミットします。

マージのときと違って、普通に更新したようになりますので、
ちゃんとコメントに、何をマージしたのか残しておきましょう。

まとめ

Sourcetree は、gitによる変更管理をGUIで視覚的にできるので素敵です。

テスト環境でテストしておくと、自身を持って本番のプロジェクトで使うことができます。

この記事では、

  • テスト環境の作り方
  • コミットテスト
  • ブランチテスト
  • 選択したコミットまでのマージテスト
  • コミットの削除のテスト
  • 選択したコミットだけのマージテスト

の手順をお伝えしました。

ぜひ、Sourcetree を導入、また、テスト環境を作って色々試してみてください。

 

 

 

この記事が気に入ったら
いいね ! しよう

コメント