プロになるGit & GitHubハンズオン

はじめに

みなさんこんにちは、こねこ。です。大学3年生にもなって初めてのAdvent Calendarです。
大学では「セキュリティ情報学プログラム」というところで学んでいます。好きな言語はJavaです。ピアノも弾けます。

さて、本題ですが、エンジニアの皆さんにとってGitやGitHubは馴染みが深いものだと思います。しかしながら、あまりにも機能が多く、また複数人で試してみないとわかりづらいことも多く、初心者にとっては敬遠してしまう部分もあると思います。今回のAdvent Calendarでは、Gitの基本操作や、GitHubを使ったプロジェクトの管理について、初心者でもなるべくわかりやすいようにまとめることにしました。

本来、Advent Calendarはこんなに長ったらしい記事を書くものではないっぽいのですが、いろいろもりもりしてたらこんな長さになってしまいました......ごめんなさい。

題名について

学生の癖に「プロになる」などと生意気な......と思ったと思います。ごめんなさい。私の大好きな書籍である『プロになるJava』をリスペクトしました。

著者の方はすごいエンジニア（こなみかん）の方であるにも関わらず、LINE OpenChatなどでたくさんの方々のJavaの質問に毎日答えてくださるとても素晴らしい方です。私も何度も救われました。現代はすごいエンジニアの方と気軽に繋がれるので、いい時代ですね。

書籍『プロになるJava』はその辺の書店でも普通に売ってますし、Amazonでも売っているのですが、オリジナルステッカーやJetBrainsのクーポン券がついているこちらのサイトでの購入がおすすめです（筆者の方のサイトです）。
https://samuraism.com/jetbrains/projava
※ 私が勝手に宣伝しているだけで、筆者の方に頼まれたわけではありません。ステマではありませんので、ご承知おきください。

この記事の内容

狙い

• Gitを初めて触る人が、Gitを使って簡単な管理ができるようになる。

話すこと

• gitコマンドを用いたcommitやmergeなどの基本操作
• GitHub Desktopの操作
• GitHubとGitの連携
• GitHubの各機能の紹介

話さないこと

• GitやGitHubの運用方法におけるベストプラクティス
• Gitの応用的な操作
• Conflictしたときのベストプラクティス

構成

それぞれの章では、まずはじめにコマンドの使い方を紹介し、その後「gitコマンドの場合」「GitHub Desktopの場合」という2つの場合に分けて記述しています。いずれか好きな方のみ読んでいただいて構いません（どちらか片方しか読まなくても理解できるようにつくってあります）。

GitとGitHub

Git

Gitは「バージョン管理システム」と呼ばれるソフトウェアの一種です。端的にいえば、特定のディレクトリに対し、任意の時点の変更履歴をセーブすることができるソフトウェアです。この「特定のディレクトリ」のことを、リポジトリといいます。Gitでは、ローカル環境（自身の端末）内でバージョン管理を行います。

GitHub

GitHubは、複数人で1つのリポジトリを管理するためのクラウドソフトウェアです。Gitではローカル環境内でバージョン管理を行うので、複数の端末でリポジトリを管理することが出来ません。GitHubは、ある対象のリポジトリに対して複数人が編集した結果をうまく統合して、齟齬が生じないようにする機能を備えています。

GitHubはグループ開発に便利ですが、個人で利用する際にも重宝します。筆者は大学の課題のバックアップはすべてGitHubでとっています。

GitHub Desktop

GitHubが制作している、GitをGUI上で操作できるツールです。初心者の方におすすめです。

現在はVS CodeなどのエディタやIntelliJなどのIDEにGit操作ツールがついていることもあります。コマンド操作が苦手な方は、好きなGUIツールを使用してください。

おことわり

この記事では、「Git」と頭文字を大文字で書く場合は「Gitというソフトウェアそのもの」を表現します。「git」と頭文字を小文字で書く場合は、「Gitの操作の際に使う、gitというコマンド」を意味します。

Gitを使ってみる

インストール方法

Windows、MacともにGitHub Desktopをダウンロードしインストールすることで、Gitを導入することができます。GitHub DesktopはLinuxには対応していません。Linuxの場合は、apt-getなりなんなりでGitを導入してください。
GitHub Desktopからではなく、Git単体でダウンロードする方法もありますが、ここでは紹介しません。

Windowsの場合、環境変数の登録をすると便利です（Macは勝手にパスが通るので不要です）。Windowsスタートの横のsearch boxに「env」と入力し、「システム環境変数の編集」を選択します。

「環境変数」を選択します。下図では「Environment Variables...」と書いてあります。

「ユーザー環境変数」の「Path」を選択します。

「新規」より、以下のパスを入力してください。

C:\Users\username\AppData\Local\GitHubDesktop\app-x.x.x\resources\app\git\cmd

（usernameには自分のWindows ユーザー名、x.x.xにはGitHub Desktopのバージョンを入れてください。）
「新規」を押してから「参照」を押すと、フォルダ選択をGUI上で行うことができます。

これでインストールは終了です。

リポジトリの作成 : init

まず、Gitの管理対象とするディレクトリを作成します。このディレクトリのことをリポジトリといいます。リポジトリはいくつでも作成できます。

gitコマンドの場合

リポジトリを作成する際には、Git管理対象にしたいディレクトリの中で、次のコマンドを打ちます。

git init

すると、以下のように表示されるはずです。

hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint: 	git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint: 	git branch -m <name>
Initialized empty Git repository in /path/to/repository/.git/

Initialized empty Git repository（空のGitリポジトリを初期化）されてますね！

GitHub Desktopの場合

GitHub Desktop上では、以下の手順でリポジトリを作成できます。
File > New Repositoryを開くと、以下のような画面が出てきます。「Name」にリポジトリの名前、「Local Path」にリポジトリが存在する場所を入力し、「Create Repository」を押してください。例えば、「/path/to/repository」の「repository」ディレクトリをgit管理対象にしたい場合は、「Name」に「repository」、「Local Path」に「/path/to/」を入力します。

作成したリポジトリをGitHubにアップロードする : publish

gitコマンドの場合

まず、GitHub上にリモートリポジトリを作成します。リモートリポジトリとは、クラウド上にあるリポジトリのことです。
https://github.com 上でログインしたのち、図のように「New repository」を選択します。

リポジトリ名（ローカルで作成したリポジトリ名と同じものが望ましいです）を設定し、Public/Privateを選択します。Publicではリポジトリは世界に公開されます。Privateでは公開されません。終わったら、「Create Repository」を押します。

ここでページの真ん中らへんに出てきたURLをコピってください。

管理対象のリポジトリを、リモートリポジトリとしてGitに認識させます。

git remote リモート名 リモートURL

ここでは、以下のように打ちました。大抵、リモート名は「origin」で登録します。

git remote add origin https://github.com/KonekoPhysics/Test.git

これで完了です。

GitHub Desktopの場合

「Create Repository」を押すと、「Publish repository」が出てきます。押してください。

こんな感じのUIが出てくるので、「Name」に適当なリポジトリ名をつけてください（ローカルで作成したリポジトリ名と同じものが望ましいです）。Privateリポジトリにしたい場合は、「Keep this code private」にチェックを入れてください。Publicではリポジトリは世界に公開されます。Privateでは公開されません。

入力が終わったら、「Publish Repository」を押して完了です。

gitコマンドでつくったリポジトリをGitHub Desktopの管理下にいれることはできる？

できます。GitHub Desktop上でAdd repositoryするだけです。書くのめんどくさいので書きません......ごめんなさい。

編集履歴をセーブしたい : commit

Gitでは、作業履歴を自分の好きなタイミングで保存することができます。ゲームでいうセーブですね。これをcommitと言います。

gitコマンドの場合

適当にリポジトリの中で作業を行ったら、次のコマンドを、リポジトリ内の任意の場所で実行します。

git add --all
git commit -m "なにかメッセージ"

git addでは、そのコミットでセーブ対象となる変更を指定します。例えば、ファイルAは編集中だから今はコミットしたくないけど、ファイルBはコミットしておきたいな、という場合に便利です。今回は--allオプションを用いて、リポジトリ内のすべてのファイルをコミット対象としています。
git commitの-mオプションは、コミットメッセージを記入することを意味します。コミットメッセージはそのコミットが何を表しているのかを端的に示すためのもので、必ず記入する必要があります。

GitHub Desktopの場合

ここの「Summary (required)」になにかメッセージ（コミットメッセージ）を入れて、「Commit to main」を押すだけです。コミットメッセージはそのコミットが何を表しているのかを端的に示すためのもので、必ず記入する必要があります。

いまあるファイルはそのままの状態で残したまま、編集したい : branch

あなたは課題で何らかのプログラムを作成していて、それが一旦完成したとします。あなたはそのプログラムをみて、こう思いました。

「あれ、バグがあるぞ......」

バグをしっかり修正した場合、高得点を得られることがわかっています。しかし、いまのプログラムは一は応にも「完成版」です。今のまま提出することもできます（点数は低いかも知れませんが）。バグ修正手法はなんとなく頭の中で想像できていますが、もし失敗して元のプログラムがぐちゃぐちゃになってしまった場合、取り返しのつかないことになります。こんなとき、あなたはどうしますか？

ひとつの解決策は、「修正は行わない」ことでしょう。しかし、大した処理でなければよいのですが、プログラムの根幹に関わる深刻なバグの場合は簡単に逃げることはできなくなります。

もうひとつの解決策として、「ファイルをコピーする」ことがあげられます。簡単な手ではありますが、いくつも修正を加えることになった場合、えげつない量のコピーが生成されることになります。これらを管理するのは非常に大変です。

Gitは、この問題に対して非常に有効なソリューションを提供します。それが「ブランチ」です。

branchは、コミットの頭を表すポインタです。ブランチを作成することを「ブランチを切る」と表現します。名前の通り、コミット履歴の枝分かれを作成する際に非常に有効な機能です。

下の図では、紫色が「main」ブランチの履歴、緑色が「bug-hoge」ブランチの履歴を表現しています。ブランチを切り替えれば、いつでも「Version 1」コミットに戻ることができます。

branchの作成

gitコマンドでの方法

bug-hogeという名前のブランチを作る際には、以下のようにします。

git branch bug-hoge

ブランチが出来上がったことを確認するために、次のコマンドを打ってみましょう。

git branch

すると、以下のような出力が得られます。「*」が現在あなたがいるブランチです。

bug-hoge
* main

ブランチはできていますが、今はmainブランチにいるようです。ブランチを切り替えてみましょう。ブランチを切り替えることを、checkoutといいます。

git checkout bug-hoge 

すると、以下のような出力が得られます。

Switched to branch 'bug-hoge'

もう一度git branchをしてみましょう。

$ git branch
* bug-hoge
main

今度はきちんと切り替えられているみたいですね。
今の一連の動作を図示すると、こうなります。
これ（白いmainが選択されている状態）を

こうしてます（白いbug-hogeが選択されている状態）。

ブランチを切り替えるとコミット内容が変わることを確認するために、以下の一連の作業を行ってみましょう（Linuxコマンドですが、電通大の皆さんなら理解できると思います）。

$git checkout main # mainにチェックアウト
$ls
（なにも表示されない）
$ git checkout bug-hoge　# bug-hogeにチェックアウト
$ cat > main.c # 編集を加えてみる
#include<stdio.h> int main(){printf("Hello World!!");return 0;}
^C
$ git add --all
$ git commit -m "Made main.c" #bug-hogeブランチでコミットしてみる
[main c5f1774] Made main.c
1 file changed, 2 insertions(+)
create mode 100644 main.c
$ ls
main.c # 確かにbug-hogeブランチ内ではmain.cが存在する
$ git checkout main #mainブランチに戻ってみる
$ls
（なにも表示されない）# mainブランチには変更を加えていないので、なにも表示されない
$

GitHub Desktopの場合

「Current Branch main」と書かれているところをクリックして、「New Branch」

ブランチ名を入力して、「Create Branch」とすると、ブランチを切ってくれます。

ブランチの切り替え（checkout）も同じ画面から行えます。

ある程度編集したbranchの内容を、別のbranchに反映させる : merge

さて、ブランチを用いて、無事バグを修正することができました。効率化した結果をmainブランチに反映したいです。
このような場合には、mergeが役立ちます。こんな感じです。

mergeを行っても、「修正履歴がmainブランチに反映される」だけなので、bug-hogeブランチ自体は消えません。引き続き、バグ修正のためのブランチとして使用できます。こんな感じです。

また、bug-hogeブランチからみると、「mainブランチに自身のブランチの内容を反映させているだけ」なので、mainブランチの内容はbug-hogeブランチには反映されません。
例えば、以下のような場合にはコミット「Version 1.1」はbug-hogeには反映されません。

mergeはmainブランチ以外のブランチに対しても行うことができます。ブランチとマージをうまく利用すると、下のような木構造を得ることができます。

gitコマンドの場合

自分がマージする側（bug-hoge）にいるとします。それを、mainブランチ上にマージしたいものとします。まず、mainブランチに移動します。

git checkout main

その後、マージを行います。

git merge マージしたいブランチ名

今回の場合、

git merge bug-hoge

となります。

GitHub Desktopの場合

自分がマージする側（bug-hoge）にいるとします。それを、mainブランチ上にマージしたいものとします。
mainブランチに切り替えて、「Choose a branch to merge into main」を選択します。

マージするブランチ（bug-hoge）を選択して、「Create a merge commit」を押して完了です。

コミット履歴を確認したい : log

コミット履歴を確認したいこともありますね。

gitコマンドの場合

git log

でコミット履歴がみられます。

git log --graph

とすると、mergeの例でみせたような図を表示することができます。

GitHub Desktopの場合

対象のリポジトリおよびブランチに切り替え、「History」を参照してください。

クラウドに履歴をアップロードしたい : push

ローカルにある編集履歴をクラウドに反映します。これをpushといいます。

これを

こうします。

pushはcommitがたまってからやれば十分です。

gitコマンドの場合

次のコマンドを実行しましょう。

git push

GitHub Desktopの場合

commitがある程度たまってから「Push origin」を押すだけです。

クラウド上の変更をローカルに反映したい : pull

pushの逆の操作です。pullといいます。
pullを行う際には、まずfetchを行います。fetchとは「クラウド上に変更があるかどうかを確認しに行くこと」です。もし変更があった場合、Gitは変更をダウンロードし、「fetch専用の、意味のないブランチ」を作成します。

その後このブランチをマージすると、変更が反映されます。
Gitでは、この「fetch」と「merge」を一緒にした、pullというコマンドが用意されています。pullを行うと、fetch -> mergeの処理が一括で行われます。

gitコマンドの場合

次のコマンドを打ちます。

git pull

これは、内部的には以下のコマンドと同等です。

git fetch 
git merge origin/master

GitHub　Desktopの場合

対象のリポジトリのブランチで、「Fetch Origin」を押します。

変更がある場合は表示が下のように変わるので、「Pull Origin」を押します（ここが紛らわしいところで、GitHub Desktopでは「fetch」してから「pull」する流れになっています）。

リモートリポジトリとして既に存在しているリポジトリを自分の環境に導入したい : clone

誰かがつくってくれたリポジトリや、別のパソコンで作ったリモートリポジトリを、自分のパソコンに反映させることをcloneといいます。

まず、自分が導入したいリポジトリのサイトに行き、図の「Code」から「HTTPS」を選択して、出てきたURLをコピーしてください。

gitコマンドの場合

次のコマンドを、リポジトリを置きたいディレクトリ上で打ちます。

git clone さっきコピーしたURL

GitHub Desktopの場合

File > Clone repositoryから、次の画面を開き、「URL」を選択します。上のボックスには先ほどのURLを、下のボックスにはリポジトリを置きたいディレクトリを、それぞれ入力して「Clone」を押します。

GitHubをさらに便利に使ってみる

他の人にGitHub 上のリポジトリ内のブランチにプッシュした変更について知らせる : Pull Request

Mainリポジトリはみんなの変更履歴が集まる場所なので、衝突が起きやすいです。したがって、mergeの処理を管理者に任せる必要があります。GitHubには、リポジトリの所有者の他に同じリポジトリにアクセスできる人に対して権限レベルを変更する機能があります。

管理者の人にmergeを促し、さらにリポジトリの利用者にpullを促すための機能がPull Requestです。これはgitではなくGitHubの機能です。

gitコマンドの場合

適当なブランチでpushし、そのリポジトリのURLに行くと、このような通知がきています。「Compare & Pull request」を選択します。

題名と、どんなプルリクエストなのかの概要をWriteに書きます。終わったら、「Create pull request」を押します。

GitHub側が衝突を検査してくれます。うまく検査が通れば、自分が管理者の場合「merge pull request」というボタンが出てきますので、これを押します。すると、リモートリポジトリのmainブランチに変更が反映されます。

GitHub Desktopの場合

上の欄からBranch>Create Pull Requestを選択します。

サイトが勝手に開かれます。 題名と、どんなプルリクエストなのかの概要をWriteに書きます。終わったら、「Create pull request」を押します。

GitHub側が衝突を検査してくれます。うまく検査が通れば、自分が管理者の場合「merge pull request」というボタンが出てきますので、これを押します。すると、リモートリポジトリのmainブランチに変更が反映されます。

開発についての話し合いや指摘をする : issue

バグについての指摘や、話し合いを行うことができます。Webサイト上で、「Issues」を選択し、「New Issue」から書きましょう。Markdownが使用できます。

ソフトウェアにバージョンをつける : タグづけとRelease

さきほど出てきたこの図をみてください。

確かにmainブランチにはいろいろな履歴が反映されていますが、Mergeコミットはすべて「Merge」という名前になっており、コミットメッセージがありません。コミットメッセージだけでは、バージョンがわかりづらい場合があります。このような場合に役立つのがtagです。

例えば、バージョンを「a.b.c」のようにあらかじめ定めておいて、「新機能が加わったらaに1を足す」「軽いマイナーチェンジがあればbに1を足す」「深刻なバグがみつかったらcに1を足す」のようにルールを定めます。よくある「ソフトウェアのバージョン」ですね。こうしてできたバージョンを、コミットに「タグをつけるように」付与することができます。こんな感じです。

gitコマンドの場合

mainブランチにタグづけをする際は、以下のコマンドを打ち込んでください。

git tag タグ

GitHub Desktopの場合

タグづけしたいコミットを右クリックして、「Create tag」を選択します。

タグ名を記入して「Create Tag」を押します。

Releaseを立てる

リポジトリのURLを開き、「Create a new release」を選択します。

「Choose a tag」でタグを選択します。ない場合は、タグ名を入力してから「Create new tag」を押すと、新しいタグを生成できます。

タイトルに適当な題名、「Describe this release」に適当な文章を書きます。もし実行可能ファイルなどがある場合は、「Attach binaries by dropping them here or selecting them.」にドラッグアンドドロップをします。
「Publish release」を押して完了です。

リポジトリの使い方や概要をドキュメントにまとめておく : Wiki

「Wiki」では、そのリポジトリで作成しているソフトウェアの概要や、どのような設計で作成しているかなどを、Markdownをつかってまとめておくことができます。素晴らしいのが、Wikiを書いているリポジトリとは別にリポジトリを立てて、Wikiだけのリポジトリを作れるという点です。
とは言っても記事を書くだけのものなので、本記事では紹介に留めておきます。

GitHubを使ってwebページを公開する : Pages

GitHubを簡易webサーバとして利用することもできます。無料でここまでできるのか......という感じです。

htmlファイルを含むリポジトリの設定を開きます。このとき、リポジトリはpublicにしておきましょう。

左メニューから「Pages」を選択します。

「Branch」から、公開するブランチを選択（大抵main）し、「Save」を押すと、公開先のリンクが出てきます。

終わりに

こんなにながいながいながいながいながあああああああああああい記事になるとは思ってませんでした。ここまで読んでくださった方々には感謝でしかありません。
実は全然テーマが決まらず、14日くらいまで放置状態でした。当初は「O'reilly風のデザインをLaTeXで実現する」というテーマで投稿するつもりで、O'reilly Japan様からの許可もいただいていたのですが、OSごとに出来ることが限られてしまう場面があり、「まだ公開することは出来ないな」ということでやめました。そのうち投稿すると思います。

今回gitをテーマにしようと思ったのは、自分がgitについてなにも知らなかったときに、初心者が自学できるようなウェブサイトが全然みつからなかったからです。今回の記事では「初心者が必要最低限の知識をつかって、なんとかgitの仕組みを理解しながらとっかかりを掴めるようになる」ことを目標に、「自分が初心者だったらこういう説明があると嬉しいな」という視点を大切にすることを心がけました。また、関連性のない譬え話は最小限にとどめ、なるべく正確性のある記事を作成するように心がけました。一旦方向性が決まると、ガーーーっと書き進めることができました。試してみるものですね。

gitは本当に便利なツールですので、ぜひぜひ使いこなしてください！

Before and Next

15日は、えぐちさんによる「調布祭にモバイルオーダーを導入した話」です。私も調布祭でみかけましたが、こんなの学生がつくっていいんだ......というほどの出来栄えでした。今年の1年生は本当に強者ばかりで、我々老害は戦々恐々としております。
17日は、Udonさんによる「2023に観た映画の雑振り返り」です。私こねこ。は2023年、全然映画みてないです。コナンの新作だけだったと思います（面白かったです）。

参考文献リスト