誰でも簡単!GitHubで管理するためのSourcetreeの最低限の使い方

GitHubとのやり取りをコマンドではなく、ボタンなどの操作で直感的に操作できるのがSourcetreeというツールです。

ターミナルなどの黒い画面が苦手な方でも、Sourcetreeを入れておけば簡単にGitの操作、およびGitHubとのやり取りができるようになります!

この記事ではクローン、ブランチ作成、プル、プッシュ、マージなどなどの基本な操作を紹介していけたらと思います。細かい部分で足りない説明はあるかもしれませんが、大雑把な流れがイメージできるようになれば嬉しく思います。

Sourcetreeのインストール

Sourcetreeのダウロードページ
Sourcetree | Free Git GUI for Mac and Windows

「Download」ボタンからダウンロードしてください。

インストールするために「Atlassian」と「GitHub」のアカウントが必要になります。もっていない方は、インストールの手順で出てくる指示に従いつつ登録していきましょう。

この記事では詳しいインストール手順は割愛しますが、以下の記事が詳しく紹介されていますので、ご不明点が出てきたら参考にインストールしてもらえたらと思います。
SourceTreeのダウンロードとインストール方法 | サービス | プロエンジニア

Sourcetreeの最低限の使い方

Sourcetreeの最低限の使い方を紹介していきます。この流れで使えるようになれば、個人でも複数人でも、一応は使えるという状態にはなれるはずです。

全くできないのと、最低限でもできるの違いは、とてつもなく大きな違いなので、ここで紹介する最低限だけでも理解しておくと、今後の仕事に役立つかもしれません!

ローカル環境にクローン

クローンとは、GitHubで管理しているソースを丸ごとローカルに移す作業のことですね。ただコピーするだけでなく、GitHubのブランチと紐付いた状態になっていることも特徴だと思います。

タブの「+」アイコンから新しいタブを開きます。

「Clone」ボタンをクリックします。

ご自身の権限があるGitHubで管理しているプロジェクトの「Clone or Download」ボタンからURLを取得してください。(※ 権限がないものはクローンできません)

「元のパス」のところにGitHubのURL、「保存先のパス」にローカル(自分のパソコン)で保存するパス、ローカルに保存するときのフォルダ名を入力して「クローン」ボタンを押します。

クローンが完了すると、指定したローカルのフォルダに丸ごとごっそり移動されていることが分かるはずです。
.gitのフォルダも自動で作られます)

Sourcetreeの方を見てみると、「master」ブランチが作られて管理されていることが分かります。

ブランチの管理方法は案件や会社のルールによって異なってくると思います。

いきなりmastarに反映されない仕組みで運営することが基本なので、次はブランチの作り方を見ていこうと思います。ブランチを作ることで、masterに影響を与えずに開発を進めていくことができます。

ブランチの作成(ブランチを切る)

何かしら修正する時は、目的に応じてブランチを作成します。
(「ブランチを切る」という表現のされ方がされたりします)

「ブランチ」ボタンから追加することができます。

現在ブランチ(どこからの派生か)を確認して、ブランチ名を入力して作成します。

作成したブランチが選択されていることが分かります。

今から修正する部分はこの「test/add_unitty」のブランチに反映させることで「master」ブランチを傷つけずに管理することができます。

次は実際に修正してGitHubに反映させるところまでを見ていきましょう。

ローカルでのコミットとGitHubへプッシュ

ファイルを修正してみます。

流れとしては、以下のような感じになります。

  1. ファイル修正
  2. ローカルでコミット
  3. GitHubへプッシュ
  4. プルリクエスト

_utility.scssに以下のような記述を追記してみました。

.tal {
	text-align: left !important;
}

修正して保存すると、Sourcetree側でも反映されます。確認する場所は下の方にあるタブ「ファイルステータス」の作業ツリーのファイルです。

修正したファイルはどんどんここに追加されていきます。ファイル箇所をクリックするとどんな修正をしたかを右側で確認できます。

これをGit上で確定させるには、コミットという作業を行います。ここも手順があって、

  • ステージング
  • コミット

という流れです。ステージングはコミット対象にするファイルを選定する作業で、コミットが確定ですね。

ステージング

作業ツリーのファイルから「全てインデックスに追加」もしくは部分的にインデックスしたい場合は「選択をインデックスに追加」でステージングします。

Sourcetreeでは、上のエリアに移動させるイメージでOKだと思います。ドラッグ&ドロップでも移動できます。

コミット

ステージングしたら、コミットすることで確定されます。下部にあるテキストエリアにコメントを記載して、コミットをクリックします。コミットの文章は目に見える場所で残るので、何をやったかが明確に分かると後々に助かるかもしれません。

この時点でローカルのGit上では、「test/add_unitty」というブランチ上で1つの修正が確定された状態になります。

プッシュ

ローカルで確定したブランチへの反映をGitHubにも反映させていきます。

「プッシュ」ボタンをクリックしてください。

プッシュ対象のブランチにチェックを入れて、「プッシュ」ボタンをクリックします。
(この記事では触れませんが、プッシュ先は案件によって異なるはずです)

GitHubのプッシュした先の管理画面を見てみましょう。めっちゃ丁寧に「プッシュされましたよ!」というメッセージが分かりやく表示してくれているのが分かります。

右ある「Compare & pull request」ボタンから「プルリクエスト」します。

プルリクエスト

プルリクエストとは、レビュー対象者に対して「こんな修正しましたが、どうでしょう?」みたいなイメージで捉えています。

意識的に確認すべき箇所は3つです。ブランチから矢印されている先が、このプルリクエストが承認(?)された時に反映される先のブランチです。ここは案件によって異なるかもしれないので、注意深く確認した方がいいかと思います。今回はmasterに反映されるようになっています。

あとは、タイトルと内容です。わたしはゴリゴリのチーム開発の経験がないので具体的なことは書けませんが、プロジェクトによって書き方のルールが定まっていることが多いです。

プルリクエストするとこんな画面になります。

右上の「Files Changed」タブから変更点を確認できたります。

下のテキストエリアからコメントでやり取りしたりもできます。「LGTM」とコメントする文化があるようです。(分からない方は画像検索でググってください笑)

修正内容に問題なさそうなら「Merge pull request」でGitHubの対象のブランチ(ここではmaster)に反映させる流れです。

これでプルリクエスト対象のmastarに反映されました。

基本的にはこんな感じの流れを経てメインとなるGitHubのブランチを更新していく感じになります。

クローン以外で開発し始める場合の流れ

クローンする場合はその時点で最新のGitHub上の情報が取れるのでいいですが、2回目以降は基準となるmasterブランチをもう一度ローカルに反映させる必要があります。

手順としては、

  • 基準となるブランチに切り替え
  • フェッチ
  • プル

の順番でポチポチするだけです。

GitHubのマスターに反映した後のSourcetreeを見てみると、masterの横に何やら数字が出ています。これは、「GitHubのmasterと異なる部分がありますよ」と教えてくれてます。

ローカルでは、「add_utility」というブランチで修正を加えただけで、masterに反映されているわけではありません。一方のGitHub上ではmasterまで反映しているので、ここに差異が生まれているわけですね。

まずはローカルでのメインで管理している「master」ブランチに切り替えます。ダブルクリックするだけでOKです。左に丸のアイコンが付いている状態が今のブランチであることを示しています。

「フェッチ」ボタンをクリックして「OK」ボタンを押します。

続いて「プル」ボタンをクリックして、GitHubのmasterをローカルのmasterに反映させます。

右側の数字も消えて、これで最新の状態からまた開発を続けられるようになります。

あとの流れはブランチの作成(ブランチを切る)からと同様です。

GitHubで開発するときは、プルしてブランチを切ってプッシュして、プルしてブランチを切ってプッシュして、プルしてブランチを切ってプッシュして、の繰り返しのイメージをしてもらえたらと思います。

おわり


GitHubと連動させながら開発するときの大雑把な流れを紹介しました。Sourcetreeを使えば黒いコマンドを一切触ることなくボタンをポチポチしていくことで開発を進めていけるので、とてもありがたいツールです。

細かい部分で抜けいていることもあるかもしれませんが、この記事を読んで大まかにでも流れがイメージできたならよかったなと思います。

実際にGitHubにダミーでもいいのでプロジェクトを作成して開発フローを擬似体験してみると、よりリアリティを持ってイメージできるかもしれません。見たことあるだけと、実際に体験している差はとても大きいので!

このページが役に立ったら
いいね!お願いします

運営の励みになります...。

関連の記事