Table of Contents

GitHubの基本的な使い方

ここではGitHubの基本的な使い方に関してまとめています．このページに限らず，オンライン上にはGitHubに慣れ親しむための様々なリソースがありますので，それらも活用して基本的な使い方をマスターしてください．


バージョン管理とは

ソフトウェアの開発においては何度も修正や機能の追加・削除が行われることが一般的です．そのため日々コードに変更が行われます．バージョン管理はコードの変更を管理し，誰がどのような変更を行ったか，を記録しながら，ソフトウェアの開発を支援するためのものです．バージョン管理をすることで，

などのメリットがあります．


GitHubとは

GitHub(https://github.com)はgitと呼ばれるバージョン管理システムをオープンに提供しているサービスです．個人・企業・大学を問わず非常に広く使われているサービスで，チーム内でのコード管理以外でも，オープンソースのプロジェクトや自分の書いたコードを広く世の中に公開するために使用されることもあります．これから皆さんが働くであろう会社や団体においてもGitHubを使っていると思います．ですので，今の時点で基本的な使い方に慣れ親しんでおくことは，今後きっと役に立つことと思います．

このページでは厳密にはGitHubとgitの使い方を説明しています．ですがそれをまとめて「GitHubの使い方」として解説をしています．


gitを使う環境

GitHub時代は外部のオンラインのサービスですので，特に何かインストールする必要はありません．ただし，自分のアカウントを作っておく必要があります．これはGitHubのホームページを訪れれば簡単にできますので，ここでは説明しません．

GitHub上にあるリポジトリ(自分のコードを置く場所)と連携するためにgitコマンドを使うことになります．このgitを使う環境は自分のローカルに必要になります．MacとLinux，Windowsで環境構築が違います．以下に簡単に環境構築方法を書いておきますが，自分でもいろいろ調べてセットアップをしてください．


MacとLinux

まずコンソール(Macではターミナル)で以下のように打ってください． 

git --version

バージョン番号が返ってくれば，gitはすでにインストールされています．インストールされていなければhttps://git-scm.com/downloadsからダウンロードをしてインストールしてください．


Windows

Windowsではデフォルトではgitはインストールされませんので，ダウンロードを自分でする必要があります．https://git-scm.com/downloadsからダウンロードをしてください．すでにパッケージになったものがありますので，基本的にはウィザードに沿ってインストールするだけです．インストール時に気をつけることとしては，“Use Git from the Windows Command Prompt”を選択するようにしてください．Windows版にはGUIもあるので，そちらを使うことも可能ですが，コマンドでgitを使うことになれておく方が環境が変わったときなどにも対応できますので，ここではコマンドベースでgitを使用する方法を記載しています．


GitHub上のリポジトリとローカルのリポジトリの関係

gitにおいてコードを管理する場所をリポジトリと呼びます．特別な名前が付いてはいますが，git用の付加的なファイルが存在すること以外は，いわゆるフォルダやディレクトリと変わりません．通常1つのプロジェクトに対して，ローカルとGitHubに計2つのリポジトリを持つことになります．

基本的なGitHubを使い方としては

という棲み分けを行います．そして，自分の作業が完了したら，GitHubにコピーをする，という手順を取ることで，2つのリポジトリの同期を取ります．こうすることで，

などの利点があります．


GitHubの基本: cloneからpushまで

それでは，gitの基本的なコマンドと，GitHubとの基本的な連携方法に関して見ていきましょう．

まずGitHubを最初に使うときには2つの可能性があります．それは，

です．多くのプロジェクトにおいてはすでにGitHub上でリポジトリが存在します．情報可視化の実験でも同様です．ここでは上の場合に関して説明を行います．GitHubを使った最も基本的な開発の流れは，

  1. GitHub上のリポジトリをローカルにコピーする
  2. コードの編集やファイルの追加を行う
  3. 行った変更をgitに記録させる
  4. 変更をGitHub上のリポジトリに反映させる

となります．


clone

まずはGitHub上のリポジトリをローカルにコピーしましょう．この作業をクローン(clone)といいます．GitHubのホームページからクローンしたいリポジトリを探し，以下のような画面からリポジトリのURLを取得します．

次に自分のマシンのターミナル(windowsはコマンドプロンプト)を開き，リポジトリのコピー先ディレクトリへ移動します．そうしたら，以下のコマンドを打ちます． 

git clone [GitHub上のリポジトリのURL]

すると，自分のユーザ名(メールアドレス)とパスワードを聞かれますので，それを入力してください．問題がなければあとは自動的にローカルにダウンロードされるはずです．情報可視化の実験ではGitHub上のリポジトリを各チームごとに新しく作ります．ですので，クローンしてもReadmeファイルくらいしかありませんが，これから新しくファイルをどんどん追加していくことになります．


status，addとrm

それではリポジトリ内のファイルに変更を行っていきましょう．

まず適当なテキストファイルを作ります(test1.txt)．中身は何でもかまいませんが，ここでは“This is a test.”と1行書いたものだけが入っているものとします．テキストファイルを保存したら，以下のようにコマンドを打ってみましょう． 

git status

すると，

のような表示が返ってきます．少し見にくいですが，“Untracked files”にtest1.txtが挙げられています．このUntrackedとはgitでバージョン管理されていない，という意味です．なのでまずはgitに新しいファイルをバージョン管理することを伝えてあげる必要があります．そこで， 

git add [ファイル名]

とします．追加するファイルがいっぱいあるときは， 

git add .

とするとそのディレクトリにあるファイル全部が追加されることになります．

もう一度git statusを実行してみると，

となり，“Changes to be committed”(コミット予定の変更)となっていることがわかります．こうなっているとファイルがバージョン管理下に置かれていることになります．

また何らかの事情でファイルを削除したい場合は 

git rm [ファイル名]

としてリポジトリからも消去する必要があります．これをせずに単にファイルを消しただけだと，同期を取ったときにファイルがないものだと思って，GitHub上のリポジトリからコピーされてしまいます．


commitとlog

バージョン管理というからには，バージョンを作ることが必要となります．このバージョンを作るのをコミット(commit)といいます．このコミットをすることでgitは前のバージョンとの差を取って，変更を記録します．

このコミットをするときにはコメントをつけることが重要です．どんな変更を行ったか他の人がコメントを見るだけである程度わかるように記述します．1行でコメントが収まる場合は， 

git commit -a -m "[コメント]"

を実行します．コメントが複数行にわたる場合は， 

git commit -a

とすると以下のようなvimの画面が立ち上がるのでカーソルのあるところからコメントを書いて保存します．

ここでは，git commitでコメントを書いて保存しました．すると，

のようにどんな変更が行われたかの情報が表示されます．これでコミットが完了しました．

今までのコミットのログを見るためには， 

git log

とします．git logには様々なオプションがありますが，ログの一覧性を高めるためには， 

git log --oneline --graph --decorate

などとするとよいかと思います．いろいろ調べてみてぜひ自分好みにしてみてください．

commitだけではGitHub上のリポジトリに影響を及ぼしません．一方，バージョンを戻したりするのはコミットのレベルで行えますので，できる限りこまめにコミットをすることをおすすめします．


push

最後にGitHub上へローカルのリポジトリの状態をコピーします．これをプッシュ(push)といいます．これにより他のチームメンバーも自分が行った変更が見られるようになります．また情報可視化の実験では「提出物をpushしておいてください．」というような指示があります．これは自分のGitHub上のリポジトリに提出物をコピーすることによって，我々に提出をしてください，という意味です．commitをしてもpushを忘れると，提出したことになりませんので十分気をつけてください．

pushではcommitした変更のみが送られます．pushしたいものはまずcommitをし，ちゃんとコメントが付いていることが前提です．pushの準備ができたら， 

git push origin master

と打ちましょう．自分のユーザ名(メールアドレス)とパスワードを打つと，あとはgitが自動的にやってくれます．

pushが終わったら，GitHub上にあるリポジトリを見てみましょう．

このようにGitHub上のリポジトリにもtest1.txtがコピーされていることがわかります．

pushされたcommitはGitHub上で確認することができます．commitのページを見てみると，

という感じでコミットの履歴が確認できます．さらにコメント部分(added text1.txt)をクリックすると，

という風にどのような変更が行われたかを確認することができます．


pull

すでにcloneしたリポジトリがあっても時間がたつと他の人が変更を加えてしまい，ローカルのコピーが最新版でないときがあります．この状態で編集を行ってしまうと，最新版と不整合が起きることがあります．それを避ける意味でも作業を開始する前にはまず最新版にリポジトリを更新する必要があります．

GitHub上のリポジトリの最新版を取ってくることをプル(pull)といいます．pullは以下のように行います． 

git pull origin master

もしpullしたときにローカルのファイルがGitHub上のリポジトリと不整合した場合，単純な解決法としては，衝突を起こしているローカルのファイルをいったん別の場所に移動させ，pullを完了させた後に，個別に必要な変更を行う，という方法があります．これは1人でGitHubを使っているなど，限られた状況では問題ありませんが，規模の大きなチームで行うと，他人の変更を許可なく上書きしてしまうなど，よくない影響をもたらすことがありますので注意してください．


まとめ

以上が基本のGitHub(とgit)の使い方です．もう一度確認すると，

  1. 最新版のリポジトリの状態をコピーする
    1. 初めてならclone
    2. そうでないならpull
  2. コードを編集する
  3. 新規に追加するようなファイルがある場合はadd
  4. 変更が一通り終わったらcommit(わかりやすいコメントを必ずつけること)
  5. GitHub上のリポジトリにコピーを送る段階になったら，push

となります．特に重要なのは，

です．情報可視化の実験ではチームが大きくありませんので，あらかじめ誰がどのファイルを更新するかを決めて開発を進めていけば，ここに書かれているフローでほぼ問題ないと思います．


issueの使い方

GitHubのもう1つの大変便利な機能はissueです．issueとは実装や変更すべきことを記述した，いわばto-doみたいなものです．これを利用することで，

メリットがあります．情報可視化の実験においてもぜひ積極的に使ってください．


issueのオープン

issueを新しく作ることをオープンと言います．issueのオープンはGitHub上でできます．GitHub上のissueのページを見てみましょう．

右横に“new issue”というボタンがあります．これを押すことでissueをオープンします．

issueはタイトルと具体的な内容を記述します．どんな機能の実装や変更が必要なのか，正確に書くようにしましょう．書いた後保存すると，

のようになり，“Open”になっていることがわかります．

この後はissueごとにコメントを追加することなどができます．チームメンバーのとの議論もここに残しておくと後々便利だと思います．


issueのクローズ

issueに記述されている実装や変更が終わったら，issueをクローズすることになります．先ほどのissueのページでも可能ですが，もっと便利な方法として，commitと関連づけてクローズする方法があります．https://help.github.com/articles/closing-issues-via-commit-messages/によると，

というコメントを残すことでcommitと関連づけてクローズすることができます．

今回の例ではissueの番号は2ですので，

などというコメントを入れることで実行できます．例えば，git commit -a -m “fix #2”としてcommit，pushをすると，

というようにpushと同時にissueをクローズすることができます．

また単純に#XXXをコメントに入れることで，そのissueに関連づけを行うことができます．たとえばissueの一部を解決した場合など，何らかの理由でまだクローズはしたくないが，関連づけだけはしておきたい，などといった場合には便利な機能かと思います．上の例では“fixed issue #2”というコメントで，クローズしない関連づけのコミットを確認することができます．


変更の衝突が起きたら

情報可視化の実験では小さいグループ(多くの場合2人)で開発を行いますので，どのファイルを編集するか分担をあらかじめ決めておけば，同時に同じファイルを編集する可能性は低いと思います．しかし，場合によっては同じファイルを触ってしまうことがあり得ます．このとき複数の変更が発生することになり，レポジトリはどちらを採用すればいいかわからない状態になります．これをコンフリクト(conflict，衝突や競合ともいいます)といいます．

以下では簡単な例でconflictを解決する例を紹介します．

まず2人の人(AさんとBさん)が同時にtest1.txtに変更を行ったとします．Aさんは2行目に“This is another test.”と書き，Bさんは同じ行に“This is not another test.”と書いたとしましょう．Aさんが先にpushを済ませてしまい，Bさんが自分の変更を行ってpushを行おうとしている状況を想定してください．

このときBさんがpushを行うと，以下のようなメッセージが出てエラーになってしまいます．

エラーをよく読むとわかりますが，git pullをして修正しろ，といわれています．そこでgit pullをすると，

となりコンフリクトが起きていることが確認されます．gitは自動で2つの変更を統合(merge)しようとしますが，大抵失敗しますので，手で修正することになります．さらにgit statusを打つと，

となり，確かにtest1.txtがコンフリクトを発生させていることがわかります．実際にこのファイルを開いてみると，

という感じになっています．このうち“««««“の行から”=========“までの行の間にあるのが自分の変更，”=========“の行から”»»»»“の行の間にあるのが他の人が行った変更になります．今回は1行しか変更していませんので，2つの変更がどう違うかは比較的わかりやすいですが，現実には数行にわたるため，違いを把握するのが難しいこともあります．

そこでgitにはmergetoolという便利なものがあります． 

git mergetool

と打つと，以下のようなプロンプトが出ます．

ここでenterキーを押すと，外部のツールが実行されます．Windowsではtortoisemergeというツールがデフォルトでは使用され，以下のような画面が立ち上がります．

画面が3つに分かれていて，左上が他人の変更，右上が自分の変更，中央下が最終的に行う変更，となります．このツールではどの行がどう違うがより見やすく表示されています．これらを見ながら自分と他人の変更の必要なところを抽出し，中央下のエディタに反映させ，保存します．この2つの変更を統合するのがマージと呼ばれているものです．

マージ後にgit statusを実行すると，

となり統合された変更が追加されています．後は通常と同じくcommit，pushを行えば完了となります．


よくあるトラブル


参考資料

gitやGitHubに関してもっと知りたい人や上の説明ではわかりにくかった人は，以下のページなども参考にしてみてください．