GitHubの基本操作<後半>【GitHub講座 #4】

前回はリポジトリの基本操作について勉強しました。自分ひとりで開発する際に必要な知識及び操作のほとんどは述べたつもりです！(ブランチとか.gitingnoreとか説明してないものもあるけど)

今回は複数人で開発をする際に必要となる知識と前回の残りの部分について説明していきます。

ブランチ

最初にブランチ(branch)について説明していきます。この知識は個人の開発でも役に立つので飛ばさないでくださいね！

ブランチというのはリポジトリの派生のことを指します。branchの英単語の意味は枝とか支店とかなので分岐するイメージは掴みやすいでしょう。ブランチを作ることで本流(masterブランチと呼ばれるもの)に影響を与えることなく改変が行えます。

また複数人で開発をするとプルしてからプッシュをしなければならない場合があるという話をしましたが、ブランチを使って作業を進める形にすればその心配もなくなります。ブランチを最後にマージ(結合)してあげれば同時並行で開発が進められます。

それでは早速ブランチの作り方を勉強していきましょう。

まずはSourcetreeを開きます。左側にある履歴を選択するといつもの画面になりますね。

実はこの画面に表示されているグラフはブランチを表していて、その横に書かれている説明はコミット時のコメントになっています。グラフ上にある点はコミット単位で記録されています。

今回はブランチを作りファイルをひとつ作成してコミットをしてみます。

私は例として以下の部分から派生を作りますが、読者の方はどこから派生させても大丈夫です。

最初に上にある『ブランチ』を選択します。

そうすると以下のようなウィンドウが現れるので必要事項を入力していきます。

新規ブランチの部分にはブランチの名前を半角英字で入力してください。また今回は特定のコミットから分岐を作りたいので、指定したコミットから分岐をしたいコミットを選択します。

全部入力できたら『ブランチを作成』を押しましょう。

無事にブランチが作成されている人は、以下のように左側のブランチのところと指定したコミットのところに先ほど入力したブランチ名が表示されているはずです。

これでブランチの作成はできました。しかし内容的にmasterブランチ上にあるコミットから何にも変えていないのでグラフ上に見えませんね。というわけで今作ったブランチを使ってみるとどうなるのかを試していきましょう！

その前に現在のブランチがmasterブランチではなく、先ほど作ったブランチになっていることを画面左側のブランチの項目で確認してくださいね。(なってない人は右クリックなりダブルクリックなりを試してチェックアウトしてください！)

今まで勉強してきた通りにコミットをしてみます。

コミットが完了するとグラフの線がこんな感じに2つに分かれた形になると思います。このようにブランチを作ることでプロジェクトの細分化や同時並行の作業がしやすくなります。

作業をそれぞれのブランチごとに分けて進めたあとに統合できなければ困る(意味がない)ので次の項目ではマージ(統合)について学んでいきます。

マージ

マージ(merge)というのは、2つに分かれているブランチを結合して一つにまとめる操作のことを指しています。これにより同時並行で進めていた作業を一つにまとめたり、プルで持ってきたリモートリポジトリとローカルにあるリポジトリを結合したりすることが可能となっているわけですね。

早速マージの仕方を実践しながら勉強していきましょう！この記事では、先ほど作ったブランチをmasterブランチにマージする方法を紹介します。

まずは画面左側にあるブランチの中からmasterブランチに切り替えます(右クリックからチェックアウトするかダブルクリックでなんとかなるはず)。

masterブランチを選択できたら画面の上側にある『マージ』を選択します。

下のウィンドウで結合したいブランチを選択し、『OK』をクリックします。

無事にマージが完了すると以下のように、グラフのところで2つに分かれていた線が1つに纏まっているのがわかりますね。

このようにブランチとマージを組み合わせることで、複数人で1つのリポジトリを使うことが簡単にできるわけです。ただしマージをする前に正しい変更がなされているかをチェックする姿勢が重要視されている現代では、プルリクエストを送り変更を精査した上でマージするのが一般的です。詳しくは後述するプルリクエストの項目にて確認してくださいね。

またマージをする際に気を付けることについてコラムにまとめておくのでよかったら読んでみてください。

フォーク

ここまでは複数人で作業をする際にブランチを作って同時並行で作業する方法を学びましたね。ここからは別の方法で同時に作業をする方法について勉強していきます。

ここで学ぶ開発手法はリモートにある共用リポジトリを自分のリモートリポジトリに持ってきて、そのリポジトリに対してクローン、コミット、プッシュ等を行って開発を進めていき最後にプルリクエストを行う手法になります。

リモートにある共用リポジトリを自分のリモートリポジトリに持ってくる操作のことをフォーク(fork)と呼びます。この項ではフォークの仕方について学んでいきます。

以下ではSourcetreeの使い方から少しGitHub上のお話に戻ります。まずはGitHubにサインインして私のリポジトリ(practice)のページへ移動してください。

画面右上に3つ並んでいる中の『Fork』をクリックしてください。

これで自分のリポジトリに私のpracticeリポジトリが複製されました。GitHubのリポジトリページから確認してみると良いでしょう。

フォークの操作はこれだけです。他の人が公開しているリポジトリをいじる際にはこの方法を使って自分のところに持ってくることになるので、覚えておいてくださいね。

プルリクエスト

自分のところに複製されたリポジトリを早速クローンしてローカルに持って来ましょう。クローンをして持ってきたリポジトリの中に『forPullRequest.txt』があります。今回はこのファイルに変更を施してプルリクエストについて学んでいきます。

適当なテキストエディタでforPullRequest.txtを開いて数文字打ってください(適当に一行コメントを付け足して保存するだけで大丈夫です)。

保存ができたらコミットをしましょう。

無事にコミットが終わると以下のようになります。

変更した内容をプッシュしてリモートにあるリポジトリ(フォークで持ってきたリポジトリ)に適用させます。GitHub上から確認してみてください。

ここからはプルリクエストについての操作になるので丁寧に説明をしていきます。そもそもプルリクエストというのは『こんな感じでどうですか?』みたいな提案を送るための機能でマージをする前のレビュー(確認)用途としてよく用いられています。

今回はプルリクエストとしてリポジトリの所有者(開発者)に送ってみましょう。

まずはフォークして持ってきたリポジトリのページを開きます。

次にこの画像の中段右側にある『New pull request』を選択します。

そうすると以下のようにプルリクエストを送るための情報を入力する画面に移動します。

『Able to merge』になっていることを確認し『Create pull request』をクリックします。

そうするとコミットの時のコメントと同様にプルリクエストを送る際のメッセージを入力するフォームが出てくるので簡単に記入して『Create pull request』を押しましょう。

これでプルリクエストを送ることができました。後は開発者さんがプルリクエストを取り入れてくれるか、コメントを返してくれるのを待ちましょう。(現在承認はしていません。すみません)

.gitignore

最後に.gitignoreについて簡単に説明しておきます。.gitignoreというのはバージョン管理システムのGitで無視(ignore)して欲しいものをあらかじめ指定することができるファイルのことを指します。今回は特に使いませんがOSが勝手に生成するファイルやコンパイル等で自動生成されるものをバージョン管理から除くことができます。

『.gitignore』という名前のファイルを作成し、その中にバージョン管理から除外したいファイルの名前やファイルのタイプを書き込みます。詳しい書き方は時間的な余裕があれば別記事を設けて書きますが、使用ツールや言語名を入れて『gitignore』と一緒に検索をかければ大体のテンプレートがあるので自分で書くことはあまりないでしょう。

まとめ

今回と前回の記事を通して、リポジトリの基本操作について勉強しました。これで必要最低限の操作を学べたはずです。次回はIssueとMilestoneについて勉強していく予定です。

GitHubの基本操作<前半>【GitHub講座#3】

IssueとMilestone【GitHub講座#5】

---

最後まで記事を見ていただきありがとうございます。また別の記事でお会いできることを祈っております。