ミケガモのブログ

GitとSourceTreeを初めて導入しGitHubでPull Requestするまでの話

自分はとあるゲームが大好きで、海外勢開発の解析ツールを使ってゲームの内部パラメータを覗いたり編集したりということをよくやっている。ツールのソースコードGitHubからDLし、自分用にいろいろカスタムしたものを先日Uploaderに公開したのだが、それを開発者が見てくれていて「良かったらPull Requestしてくれ」とリプライを貰ってしまった。ちょうど同志にも「Pull Requestしてもらえると助かる」と渡されたファイルがあったところなので、意を決してGitHubへの投稿に挑戦してみることにした。

で、ほとんど一から環境を構築したのだが、解説サイトが専門用語のオンパレードで本当に分かりにくい。一般的なパソコン用語で事足りるところを別の用語に置き換えているので、ひたすら煙に巻かれた気分である。

この記事はエンジニアではない人間が、そんな専門用語を一般用語に置き換えながら手順を振り返るレビューである。慣れてくると初見で抱いた専門用語への違和感が薄れてきてしまうだろうから、こういう記事を書くなら始めたての今しかないと思う。

基本用語解説

Git

プロジェクトの変更履歴を管理するためのプログラム。SourceTreeの実行に必要なので、言われるがままに適当にインストールした。

SourceTree

コマンドライン専用プログラムであるGitを視覚的に使えるようにしたGUIソフトフェアコマンドラインそのものには慣れている(と自分では思っている)のだが、Gitに関しては正真正銘の完全初心者なので、何をやっているのかが分かりやすいGUIは非常にありがたい。コマンドライン版で必要な作業のいくつかが自動化されているのも見逃せない。日本語版がリリースされたのは割と最近らしい。ありがとうございます。

GitHub

ソースコードの管理・公開を行うオンラインサービス。複数の開発者でやり取り可能なのが大きな特長(だと思う)。GitやSourceTreeでアップロード・ダウンロードを行う。

Pull Request

他人のソースコードを編集してGitHubにアップロードし、変更を本流のプロジェクトに加え入れてもらうようリクエストすること。本記事のゴール。

プロジェクト

あるソフトウェアを作るためのソースファイル一式。

リポジトリ

プロジェクトを含むフォルダのこと。GitHub上にあるものはリモートリポジトリ、手元にあるものはローカルリポジトリと呼ぶ。

実際の作業

一連の流れ

Pull Requestを送るためには、まず自分のGitHubアカウントにプロジェクトをコピーし、それをダウンロード>編集>アップロードするという手順を踏む必要がある。

1. 開発者のプロジェクトを登録する。

登録は、開発者ページ右上のFolkボタンをクリックすることで行う。Forkすると、そのプロジェクトのコピーが自分のGitHubアカウント内に生成される。

2. リポジトリを自分のアカウントからダウンロードする
3. ローカルリポジトリとしてGitに登録する。

SourceTreeでは手順2と3をクローンを作成するという操作で同時に行う。まずGitHubリポジトリページにてCrone or Downloadをクリックし、"~.git" という形式のURLをコピーする。次にSourceTreeでクローン作成ボタンから、先程のURLと作業フォルダのパスを指定する1。プロジェクトは作業フォルダにダウンロードされ、同時にそのフォルダはGitによるバージョン管理下に入る。入力したURLは、後程出てくる"プッシュ"のアップロード先としても登録される。

4. ローカルリポジトリのファイルを編集する。

直接Visual Studioで開いて編集しても良いし、別の場所にあるファイルを編集してローカルリポジトリにコピーしても良い。

5. 編集したファイルをプロジェクトに登録・適用する。

この登録作業をコミットという。後から変更を取り消すことも可能。この手順はまさにバージョン管理ツール・Gitの本分である。 SourceTreeでは前回から追加・変更・削除があったファイル一覧がリストアップされるので、それらを選択し「コミット」ボタンを押せばよい。コマンドラインのGitでは、新規ファイルについてのみaddコマンドでGitの管理下に登録する必要があるが、SourceTreeではその必要はない。

6. 編集したプロジェクトをアップロードする。

これをプッシュという。SourceTreeでクローンをしてローカルリポジトリを作った場合、プッシュを実行するだけで自動的にダウンロード元となったリモートリポジトリを更新できる。リモートリポジトリの指定は手動で行うことも可能。Gitコマンドラインでは、commitコマンドの後にアップロード先のURL(GitHub)とパスワードを入力しなければならない。

7. 開発者に更新の適用要請を送る

自分のGitHubリポジトリの内容を取り入れてもらうよう申請する。開発者ページにて、New Pull Requestを選択。Folkして編集したリポジトリがマイページにあれば、それが候補として出てきてPull Requestが送信できる。

ブランチについて

ある時点の本流バージョン(master)からの枝分かれとして作られるのがブランチである。Gitには1つのプロジェクトに対し複数のバージョンを管理する機能がある。編集は基本的にブランチで行い、変更が一通り済んだらmasterに合流させる、というのがブランチ機能の使い方である。

複数人が携わるプロジェクトでは、ブランチのフロー形式をどのようにするか、すなわちどのような開発体制を敷くかが問題になるらしい。例えばGitFlowというモデルでは、全体の指標となるmaster、開発用のdevelop、不具合修正用のfixなどのブランチを設置する。

今回自分がクローンしたプロジェクトはそれほど本格的ではないのか、クローン時点ではmasterブランチしかなく、それに自分が編集するためのブランチを1つ作成したのみだった。




「サルでも分かる!」といった見出しで初心者を呼び込む記事があるが、それを読んでもいまひとつ理解が進まずなんだかバカにされたような心持ちになることがある。勿論本当に分かりやすいこともあるのだけれど、そうでないものは簡潔さを重んじて文章量を削ったのが裏目に出ているように見える。

人間の自分は、長い文章でくどくど説明してくれた方が安心はできるかなぁ。


  1. 指定する作業フォルダは空である必要がある。