GitHub勉強会~当日資料~

GitHub勉強会
～当日資料～
@who3411
1

目次
 はじめに
 GitとGitHubについて
 ブランチについて
 実際に操作する
 Pull requestの流れを知る
 おわりに
2

目次
 はじめに
 おわりに
3

はじめに
1/1
 当日資料では、GitとGitHubに関する基礎的な知識か
ら、実際にGitとGitHubを体験してみるところまでを
行います。
 今回説明する部分はあくまで一部であり、詳しく知
りたい場合については、更に個別で学ぶ必要があり
ます。
 スライドに使用している画像では、黒で塗りつぶし
ている部分がありますが、個人情報に関わる内容を
塗りつぶしています。
4

目次
 はじめに
 おわりに
5

GitとGitHubについて (1/38)
GitとGitHubの違い
 まず前提として「GitとGitHubは別物」ということを
覚えておきましょう。
 Gitとは、Gitリポジトリ(後述)にソースコードなどを
格納して利用するものです。
 GitHubとは、Gitで作成したリポジトリをネット上に
置くことができるサービスです。
 結果として、GitHubを利用する上で、Gitを覚えるこ
とは必要不可欠です。
6

使用例
 GitとGitHubは以下の用途で用いることが可能です。
 集団でのシステム開発
 オープンソースソフトウェアの開発
 Apache HTTP Server
 Mozilla Firefox
 Linux kernel
 などなど
 バージョン管理(後述)が必要なシステムの開発
 など
7

使用例
8
 情報科学実験Ⅰでも…
https://github.com/who3411/exp1part2group9/tree/mizuno

リポジトリについて
 リポジトリとは、「ファイルなどの状態を記録する
領域」のことを言います。
 「状態を管理する」ということは、「管理した状態
に戻せる」ことを表します。
9

リポジトリについて
 例えば、ファイルAの状態をリポジトリで管理したと
します。
 ファイルAの状態が変更されたとき、変更されたファ
イルAをもう一度記録することで、変更前と変更後の
状態がリポジトリに管理されます。
 このときファイルAは、変更前と変更後の状態がリポ
ジトリに存在するため、「ファイルAを変更前に戻し
たい」としたら、リポジトリを通して戻すことが可
能となります。
10

Gitについて
 Gitを一言で表すと「分散型バージョン管理システ
ム」です。
 バージョン管理システムとは、「ソフトウェアの
ソースなどの変更をある時点ごとに管理することで、
ある時点のソースコードを取得したり、間違えて削
除したファイルを戻すことができるシステム」です。
 「リポジトリを利用して、バージョンを管理する」
システムだと思えばいいと思います。
11

バージョン管理システムのイメージ
12
データベース
 version1.2を指してる状態
version1.2
version1.1
version1.0
リポジトリ
ファイル群

13
データベース
 version1.1へ戻りたい場合
version1.2
version1.1
version1.0
リポジトリversion1.1へ
ファイル群

14
データベース
 version1.1へ戻りたい場合
version1.2
version1.1
version1.0
リポジトリ
ファイル群

分散型と集中型
 今回利用するGitは分散型バージョン管理システムで
すが、一昔前の主流は集中型バージョン管理システ
ムでした。
 集中型では、ある1箇所にバージョン管理システムを
搭載させる仕組みになっています。
 分散型では、バージョン管理システムを利用するす
べてのサーバやパソコンにバージョン管理システム
を搭載させる仕組みになっています。
15

集中型のイメージ
16
サーバ
データベース
version1.2
version1.1
version1.0
リポジトリ
PC 1
ファイル群
PC 2
ファイル群

分散型のイメージ
17
サーバ
データベース
version1.2
version1.1
version1.0
リポジトリ
PC 1
データベース
version1.2
version1.1
version1.0
リポジトリ
ファイル群
PC 2
データベース
version1.2
version1.1
version1.0
リポジトリ
ファイル群

GitとGitHubのイメージ
18
GitHub(サーバ)
Git(PC 1)
Gitリポジトリ
Gitリポジトリ
Git(PC 2)
Gitリポジトリ
Gitリポジトリ
Gitリポジトリ Gitリポジトリ
Gitリポジトリ

ローカルとリモート
19
 前ページのイメージのように、GitリポジトリはGitに
もGitHubにも存在します。
 それぞれの位置にあるリポジトリは、ローカルリポ
ジトリとリモートリポジトリといいます。
 ローカルリポジトリ : 自分のパソコンにあるGitリポジトリ
 リモートリポジトリ : GitHubにあるGitリポジトリ

Gitリポジトリ内の状態
20
 Gitリポジトリ内の管理対象となっているディレクト
リには、3つの状態が存在します。それぞれ以下の通
りです。
 コミット済 : リポジトリ内のデータベースに、データが安
全に格納されている状態
 修正済 : ファイルの変更を行われている部分が存在するが、
データベースに記録が取られていない状態
 ステージ済 : 次に記録を取る際、記録するファイルについ
て印がつけられている状態

Gitリポジトリ内の状態
21
 前ページの3つの状態に対応するように、3つの領域
が存在します。それぞれ以下の通りです。
 ワーキングディレクトリ : リポジトリの管理対象となって
いる領域。
 ステージングエリア : 次回コミットする際に、どのような
情報が必要となるかを記録する領域。
 Gitディレクトリ(リポジトリ) : 管理するために必要となる
情報を格納するための領域。

ローカルリポジトリの内部構造
22
Gitディレクトリ
ワーキング
ディレクトリ

Gitディレクトリの内部構造
23
Gitディレクトリ
ステージングエリア

Gitリポジトリ内の状態のイメージ
24
ワーキング
ディレクトリ
Gitディレク
トリ
ステージング
エリア
修正済からステージ済へ
ステージ済からコミット済へ
コミット済から修正済へ

ファイルの状態
25
 Gitリポジトリの対象となっているディレクトリ内の
ファイルには、4つの状態が存在します。それぞれ以
下の通りです。
 Untracked : これまで一度も記録を取っていないファイル
 Unmodified : 既に記録を取っており、変更がないファイル
 Modified : 既に記録を取っており、変更があるファイル
 Staged : 次に記録を取る際に、対象となっているファイル

ファイルの状態のイメージ
26
Untracked ModifiedUnmodified
ファイルを追加
Staged
ファイルを変更
ファイルを追加
ファイルを記録
ファイルを削除

GitHubのリポジトリ
27
 GitHubには、プライベートリポジトリとパブリック
リポジトリと呼ばれる2種類のリポジトリが存在しま
す。
 プライベートリポジトリ : 一般に公開されないリポジトリ。
通常であれば有償だが、GitHub Educationに入っていれば
作成することも可能。
 パブリックリポジトリ : 一般に公開されるリポジトリ。一
般的にはこちらのリポジトリを使用することが多い。

28

29
 Owner : リポジトリの作成先
 Repository name : リポジトリの名前
 Description(任意) : リポジトリに関する説明
 Public or Private : リポジトリの公開/非公開
 Initialize this repository with a README : README.md
を作成の有無(後述)
 Add .gitignore, Add a license : .gitignoreファイルと
LICENSEファイルの作成の有無(後述)

LICENSEについて
30
 一般的に、ライセンスのないものGitHubに公開され
ているコードには著作権が適用されます。
 ですが共有してプロジェクトを開発する際に、著作
権が適用されると、他人がプロジェクトのソース
コードを変更することが出来ません。
 そこで、一定の条件下でソースコードの変更を認め
る形を取ります。その際に、「一定の条件下」を適
用するのがライセンスです。

ライセンスの種類
31
 ライセンスには以下のような種類があります。一般
的にはMITライセンスが多く使用されています。
 MITライセンス
 BSDライセンス
 Apacheライセンス
 GNU General Publicライセンス
 なお.gitignoreは、「実際に操作する」の後半で説明
します。

32
https://github.com/who3411/isLL1

GitHubのサービス
33
 GitHubでは、様々なサービスがありますが、中でも
以下の2つは使用されやすいサービスです。
 Issue : 開発やバグ報告、議論といった様々な場面で使用さ
れるサービス。
 Pull request : 自分が変更したコードを、相手のリポジトリ
へ取り込んでもらうように依頼するサービス。
 今回は、様々な機能の中でもこの2つを中心に説明を
行っていきます。

Issueについて
34
 Issueでは、基本的に以下のような場合に使用されま
す。
 リポジトリのプロジェクトのバグ報告をする。
 プロジェクトで相談したい内容を問い合わせる。
 今後の予定や進捗を書き出す。
 Issueは、Markdown記法が使用できるため、表現の
幅がテキストよりも広いです。

Issueのイメージ
35
https://github.com/who3411/git-practice/issues/1

Pull requestについて
36
 Pull requestsは、GitHubで目玉の機能と言っても過
言ではありません。
 ソースコードを修正して、相手のリポジトリへ取り
込むように依頼することは、プロジェクト参加への
敷居が下がっていることを意味します。
 この機能によって、今日でも様々なオープンソース
プロジェクトに開発者が参加することが出来ていま
す。

Pull requestのイメージ
37
GitHub(サーバ)
Git(PC 1)
Gitリポジトリ
Git(PC 2)
Gitリポジトリ
リポジト
リを複製

38
GitHub(サーバ)
Git(PC 1)
Gitリポジトリ
Git(PC 2)
Gitリポジトリ
リポジト
リを取得

39
GitHub(サーバ)
Git(PC 1)
Gitリポジトリ
Git(PC 2)
Gitリポジトリ
ソースを
変更

40
GitHub(サーバ)
Git(PC 1)
Gitリポジトリ
Git(PC 2)
Gitリポジトリ
修正したソースを
リポジトリへ

41
GitHub(サーバ)
Git(PC 1)
Gitリポジトリ
Git(PC 2)
Gitリポジトリ
相手のリポジトリ
へ取り込むように
依頼

42
GitHub(サーバ)
Git(PC 1)
Gitリポジトリ
Git(PC 2)
Gitリポジトリ
相手のリポジトリ
へ取り込むように
依頼

その他のサービス
43
 他にも視覚的に進捗状況やブランチ(後述)が分かる機
能、リポジトリ用のWikiを作成する機能など、様々
な機能があります。
 GitHub自体が発展中のサービスということもあり、
サービスや画面については、日々変化しています。
 そのため、最新情報を知りたい場合は、自分で調べ
るしかありません。詳しくは自分で調べてみましょ
う。

その他のサービス例: Network
44
https://github.com/who3411/isLL1/network

目次
 はじめに
 おわりに
45

ブランチについて (1/17)
ブランチとは
46
 前節では、コミット(以下、「記録を取る」操作や行
為のことを「コミット」と呼びます)でリポジトリ内
の対象となるファイルを管理していることについて
触れました。
 ではコミットごとに管理する場合、どのようにして
戻るのかが問題となります。
 このようなときにブランチを知っておく必要があり
ます。

コミットの内容
47
 記録を取るとき、リポジトリでは以下のような情報
を記録しています。
 SHA-1のハッシュ値
 記録を取った人(コミット作成者)
 記録を了承した人(コミット適用者)
 スナップショット(差分など、記録した内容)
 前回のコミット時のSHA-1のハッシュ値

ブランチの正体
48
 コミット時及び前回コミット時のハッシュ値を取得
しているということは、「コミットした時点から、
その前にコミットした時点に戻ることが可能」とい
うことを示しています。
 よく分からないという人は、ハッシュ値について調べてみ
てください。
 ブランチとは、コミットを指すハッシュ値であり最
も新しいコミットの別名でもあります。

Gitリポジトリ作成時の話
49
 Gitリポジトリを作成する際、masterというブランチ
が作成されます。
 コミットを繰り返すことで、47ページで説明したよ
うな情報がリポジトリに蓄積されていきます。また
masterは、masterブランチ内で最も新しいコミット
を行ったコミット情報を指していきます。

コミットのイメージ
50
master
作成時にmaster
ブランチを作成

51
master
コミットすると、masterは
最新のコミット情報を指す
コミットを実施

52
コミットすると、masterは
最新のコミット情報を指すmaster
コミットを実施
前回コミットのハッシュ値を保持している
ため、前回コミットへ辿ることが可能

53
master

新たなブランチを作成
54
 現在、ブランチはmasterしかありませんが、新たな
ブランチを作成することも可能です。
 注意点として、新たなブランチでコミットした場合、
masterでのコミットと分割されてしまいます。
 なお全てのブランチの中で、最も新しいコミットを
行ったブランチ(つまりブランチ内での最新コミット)
には、HEADというポインタも同時に利用することが
出来ます

ブランチのイメージ
55
master
sub
新たにsubブラ
ンチを作成
HEAD

56
master
sub
subブランチで
コミット
HEAD

57
sub
masterブランチ
でコミット
master
HEAD

ブランチのマージ
58
 subとmasterに分割されてしまいましたが、分割され
たコミットは、1つにまとめることが可能です。
 このときの「1つにまとめる」作業のことを「マー
ジ」といいます。
 次ページでは、2つのコミットを1つにまとめていま
すが、別の方法でマージを行うことも可能です。(詳
しい方法については、ここでは触れません)

マージのイメージ
59
masterHEAD
 masterからsubをマージした状
態
sub

トピックブランチについて
60
 今回、subブランチとmasterブランチを1度ずつコ
ミットしてからマージしました。
 ですが一般的に、masterブランチは他のブランチか
らのマージを受け付けるのみにする形のほうが好ま
しいです。
 このときマージ用に作成するブランチのことを「ト
ピックブランチ」といいます。
 「開発用ならdevelop」など、トピックブランチを用
途別に分けるのも一つの手です。

トピックブランチのイメージ
61
トピック
ブランチ
masterHEAD
sub マージマージ

個人開発でのブランチの様子
62
 今回、subブランチとmasterブランチを1度ずつコ
ミットしてからマージしました。
 ですが一般的に、masterブランチは他のブランチか
らのマージを受け付けるのみにする形のほうが好ま
しいです。
 このときマージ用に作成するブランチのことを「ト
ピックブランチ」といいます。
 「開発用ならdevelop」など、トピックブランチを用
途別に分けるのも一つの手です。

目次
 はじめに
 おわりに
63

実際に操作する (1/40)
操作する前に
64
 今回操作する範囲は以下の通りです。
 Gitリポジトリの作成・状態の確認
 ステージングエリアへのファイルの追加
 ファイルのコミット
 コミット前と後の差分を確認
 ブランチの作成・移動・併合(マージ)
 コミット時点への移動・操作
 GitHub上のリポジトリとの連携
 GitHub上のサービスの使用

Gitリポジトリを作成する
65
 実際に操作を行っていきます。
 Git Bashなど、gitコマンドの使用できるものを起動
しましょう。
 まずはホームディレクトリへ移動し、パスを確認し
ます。以下のコマンドを入力してください。
 cd
 pwd
 (cdでホームディレクトリへの移動、pwdでカレント
ディレクトリのパスを確認)

Gitリポジトリを作成する
66
 次に今回操作するリポジトリ用のディレクトリを作
成し、Gitリポジトリを作成します。以下のコマンド
を入力します。
 mkdir git-practice
 cd git-practice
 git init
 すると、git-practiceディレクトリ内に.gitディレクト
リが作成されます。(Windowsの場合、隠しファイル
を見えるように設定にしておきましょう)

Gitリポジトリの状態を確認する
67
 現在のGitリポジトリの状態を確認しましょう。以下
のコマンドを入力します。
 git status
 すると、以下のような情報が出力されます。
 現在のブランチがmasterであること
 まだコミットが行われていないこと
 ※git statusは、ファイルがUntrackedかModifiedか、
なども表示してくれるので、管理状態が不安になっ
たらとりあえず利用してみましょう。

ステージングエリアに追加する
68
 git-practice内に、新たにREADME.mdという名前の
ファイルを追加します。そしてこのファイルをス
テージングエリアに追加しましょう。コマンドは以
下の通りです。
 touch README.md
 git add README.md
 touchコマンドでREADME.mdを作成し、git addコマ
ンドでREADME.mdをステージングエリアに追加しま
した。

コミットする
69
 現在、ステージングエリアに追加した状態なので、
コミットを行います。コマンドは以下の通りです。
 git commit -m “First commit”
 git commitコマンドでコミットを実施し、-m “First
commit”でコミット時のメッセージを記述します。
 git commitコマンドだけでもコミットは実施できま
すが、コミットメッセージ記述のためにエディタが
開きます。(Git Bashだとvimが開きます)

現状を確認する
70
 まず状態を確認するために、git statusを実行します。
すると、以下の情報が表示されます。
 現在のブランチがmasterであること
 コミットを行う必要がないこと

現状を確認する
71
 またコミットされたログを確認するために、以下の
コマンドを入力します。
 git log
 すると以下のような情報が表示されます。
 コミット時のSHA-1のハッシュ値(commitの横の16進数)
 コミット作成者(Authorの横)
 コミット実施日時(Dateの横)
 コミットメッセージ

ファイルの差分を確認する
72
 README.mdに、以下の1行を入力します。
 # GitHub勉強会
 入力した状態で、以下のコマンドを入力します。
 git diff
 するとREADME.mdについての変更内容が表示されま
す。ファイルが増えれば増えたファイルについて確
認できます。README.mdのみ確認したい場合は以下
 git diff README.md

もう一度コミットする
73
 もう一度README.mdをステージングエリアに追加し
てコミットします。以下のコマンドを入力します。
 既に管理対象となっているファイルの中で、変更のあったファイル
のみをステージングエリアに追加したい場合、git add -uコマンド
を利用することも出来ます。
 git commit -m “Second commit”
 そしてgit logコマンドを入力すると、2回分のコミッ
ト情報が出力されます。

ここまでのイメージ
74
masterHEAD
First
commit
Second
commit

ブランチを作成する
75
 現在のブランチを確認するため、以下のコマンドを
入力します。
 git branch
 するとmasterのみ表示されます。つまり現在は
masterブランチしか存在しないことが分かります。
 ではsubAブランチを作成します。以下のコマンドを
入力します。
 git branch subA

ブランチへ移動する
76
 もう一度git branchコマンドを実行すると、masterと
subAになっていることが分かります。
 masterブランチからsubAブランチへ移動するため、
以下のコマンドを入力します。
 git checkout subA
 これでsubAブランチへ移動することが出来ました。
 ちなみに、git branch subAとgit checkout subAを同時に行
いたい場合、以下のコマンドを入力します。
 git checkout -b subA

subAブランチでコミットする
77
 README.mdに、以下の内容を記述します。

 ## Create subA branch
 コミットを行うため、以下のコマンドを入力します。
 git commit -m “subA first commit”
 git logで確認すると、subAにHEADが移動しているこ
とを確認できます。

マージする
78
 ブランチをsubAからmasterへ戻します。
 git checkout master
 そしてマージを行うために、以下のコマンドを入力
します。
 git merge --no-ff subA
 --no-ffオプションについては、今回は触れませんが、意味を理解す
るまではつけておくことをオススメします。
 するとエディタが立ち上がるので、Git Bashを利用し
ている場合は以下の文字を入力します。
 :q

79
SubA first
commit
masterHEAD
subA マージマージ

ある地点のコミットへ戻る
80
 現在のmasterブランチから、Second commitを行っ
た地点へ戻ります。まずgit logコマンドを使って、
Second commitを行ったコミットのハッシュ値を確
認します。(このときの値を<hash value>とします)
 以下のコマンドを入力します。
 git reset --hard <hash value>
 --hard以外にもオプションはありますが、今回は触れません
 この時点のREADME.mdを確認してもらうと、subA
ブランチで記述した内容が存在しません。

新たなブランチを作成する
81
 今度はsubBブランチを作成します。以下のコマンド
を入力します。
 git checkout -b subB
 README.mdに、以下の内容を記述します。

 ## Fix subA branch

コミットを行い、現在地点を確認する
82
 コミットを行うため、以下のコマンドを入力します。
 git commit -m “SubB first commit”
 masterブランチに戻るため、以下のコマンドを入力
します。
 git checkout master
 この状態でgit logコマンドを実行してもらう
と、”Second commit”の地点にいることが分かります。

ブランチを戻す
83
 masterブランチをマージした状態の地点に戻します。
そのために、まず以下のコマンドを入力します。
 git reflog
 すると「merge subA: Merge made by the ‘recursive’
strategy.」というログがあると思うので、その行の
始めにある7桁の16進数を<hex value>として、以下
 git reset --hard <hex value>
 この状態でgit logを使用してもらうと、マージした
地点に戻っているはずです。

競合を解消する
84
 マージを行うために、以下のコマンドを入力します。
 git merge --no-ff subB
 ”CONFLICT(content): Merge conflict in README.md”
と表示されるので、README.mdを確認します。
 README.mdでは、HEADとsubBでの変更点を区別し
て表示されているはずです。今回は、README.mdを
81ページの状態にしましょう。

コミットする
85
 コミットを行うために、以下のコマンドを入力しま
す。
 git commit -m “Merge subB”
 これでsubBが正常にコミットされました。
 git logコマンドで確認してもらうと、正常にマージ
されているはずです。

86
SubB first
commit
master
HEAD
subB
マージマージsubA

リモートリポジトリを作成する
87
 ここからは作成したローカルリポジトリを、リモー
トリポジトリへと送ります。
 まずはリモートリポジトリを作成しましょう。
 GitHubにログインして、「Start a project」を選択し
ます。
 記述する内容や選択する内容は以下の通りです。
 Owner : 自分のアカウント
 Repository name : git-practice
 その他 : 変更や記述はなし

リモートリポジトリを登録する
88
 前ページの内容を記述したら「Create repository」を
クリックします。するとリモートリポジトリが作成
されます。
 作成されたリモートリポジトリをローカルリポジト
リへ登録します。コマンドは以下の通りです。なお
<username>にはユーザ名が入ります。
 git remote add origin https://github.com/<username>/git-
practice.git
 以降ローカルリポジトリでリモートリポジトリを表
す場合、originという識別子になります。

リモートリポジトリへ送る
89
 先ほど登録したoriginを利用して、ローカルリポジト
リからリモートリポジトリへデータを送ります。コ
マンドは以下の通りです。
 git push -u origin master
 -uオプションについて、今回は触れません。気になった人は調べて
みましょう。
 コマンド実行後に
https://github.com/<username>/git-practiceにアク
セスすると、次ページのようになっているはずです。

リモートリポジトリの画面
90

リモートリポジトリへブランチを送る
91
 ローカルリポジトリで新たにブランチを作成して、
リモートリポジトリへ送ってみましょう。
 今回はsubCブランチを作成して送ってみます。コマ
ンドは以下の通りです。
 git checkout -b subC
 git push -u origin subC
 前ページのブラウザを更新して、「Branch:master」
をクリックすると、「Branches」にsubCがあるはず
です。

リモートリポジトリを取得する
92
 先ほど送ったリモートリポジトリを取得してみま
しょう。
 1つ上のディレクトリへ移動し、リモートリポジトリ
を取得します。コマンドは以下の通りです。
 cd ../
 mkdir remote
 cd remote
 git clone https://github.com/<username>/git-practice
 cd git-practice

リモートのブランチへ移動する
93
 git-practice内の全てのブランチ(リモートも含む)を確
認します。コマンドは以下の通りです。
 git branch -a
 「remotes/origin/subC」がリモートリポジトリの
subCブランチです。ここでリモートリポジトリの
subCブランチを利用して、ローカルリポジトリへ
subCブランチを作成しましょう。コマンドは以下の
通りです。
 git checkout -b subC origin/subC

ローカルでコミットする
94
 README.mdを、以下の内容にします。
 #GitHub勉強会


 ## Add subC branch
 この状態でコミットを以下のコマンドで行います。
 git commit -m “subC first commit”

subCブランチをリモートへ送る
95
 subCブランチの内容をリモートリポジトリへ送りま
す。コマンドは以下の通りです。
 git push
 コマンドの実行が終了したら、先ほどまで利用して
いたgit-practiceに戻ります。コマンドは以下の通り
です。
 cd ../../git-practice

subCブランチを最新にする
96
 こちらのsubCブランチは、現在最新の状態ではあり
ません。そこでリモートリポジトリを利用して、こ
ちらのローカルリポジトリを最新の状態にします。
コマンドは以下の通りです。
 git pull origin subC
 git pullコマンドによって、両方のローカルリポジト
リが最新の状態になりました。

.gitignoreについて
97
 ここまでの操作では、手順どおりに行った場合git
addコマンドの後ろにREADME.mdを入力していまし
た。
 ですがgit addコマンドには、以下のような複数ファ
イルをステージングエリアに追加するコマンドがあ
ります。
 git add .
 カレントディレクトリ内の全ファイルをステージングエリアに追加
 git add *.c
 c拡張子のファイルをステージングエリアに追加

98
 .gitignoreファイルでは、「ステージングエリアに追
加したくないファイルのパス」を記述することで、
対象となるファイルをステージングエリアに追加し
ないように出来ます。
 subCブランチで、新たにtest.cファイルを作成します。
この時点でgit statusコマンドを実行すると、test.cが
Untrackedとして表示されます。

99
 次に.gitignoreファイルを作成し、以下の内容を記述
します。
 *.c
 この時点でgit statusコマンドを実行する
と、.gitignoreのみがUntrackedとなります。
 これで*.cのパスとなるファイルについては、全てス
テージングエリアに追加できなくなりました。

Issueを作成する
100
 実際にIssueを立ててみましょう。
 https://github.com/<username>/git-practiceにアク
セスし、Code, Issues, Pull requests, Projects…と並ん
でいる中の「Issues」をクリックします。
 画面右上にある「New issue」ボタンをクリックしま
す。

101
 TitleとLeave a commentと書かれたテキストエリアに、
以下の内容を記述します。
 Title
Test
 Leave a comment
# This is a test.

## For example : write your opinion.

102
 記述したら「Submit new issue」ボタンをクリックし
ます。
 すると、新たにTestというタイトルのIssueが立てら
れます。
 コメントを追加したければ、Issueを開いて、コメン
トを記述してから「Comment」ボタンをクリックし
ます。

Issueを閉じる
103
 先ほど作成したIssueを閉じるためには、「Close
issue」を選択するか、コミットメッセージで「close
#1」「fix #1」などを記述することで閉じることが出
来ます。
 今回は「Close issue」ボタンをクリックしてIssueを
閉じてみましょう。

目次
 はじめに
 おわりに
104

Pull requestの流れを知る (1/28)
Pull requestをコマンドで知る
105
 「GitとGitHubについて」では、Pull requestを送るま
での流れについて、大まかに説明しました。
 ここでは、Pull requestを送る場合、Pull requestを取
り込む場合について、実際のコマンドを通して説明
をします。
 なおPull requestに関する説明については「Gitと
GitHubについて」を参照してください。

今回の例
106
 今回は、「実際に操作する」で作成したリポジトリ
であるgit-practiceと同じ内容のgit-practice-prを利用
して、README.mdを一部修正してPull requestを送
るという流れで行っていきます。
 修正するブランチと修正内容は以下の通りです。
 ブランチ : subC
 内容 : README.mdを次ページのようにする。

Pull requestを送るREADME.md
107


 ## Add subC branch

 ## Pull request

Git(PC 1)
Gitリポジトリ
Pull request全体のイメージ
108
GitHub(サーバ)
Git(PC 2)
Gitリポジトリ
GitリポジトリGitリポジトリ
⑥
①
ABA
C
②③
④
⑤⑦ ⑨
B
⑧
⑩
⑪
⑫

Git(PC 1)
Gitリポジトリ
Pull requestを送るまでのイメージ
109
GitHub(サーバ)
Git(PC 2)
Gitリポジトリ
⑥
①
AB
②③
④
⑤
A

送るまでの手順
110
① 「Fork」ボタンを押す。
② (Pull requestを送る対象となるローカルリポジトリ
がなければ、cloneコマンドを実行する。)
③ (Pull requestを送る対象となるローカルリポジトリ
が最新でなければ、pullコマンドを実行する。)
④ ブランチAからトピックブランチBを作成する。
⑤ 修正した内容をコミットし、トピックブランチBを
pushコマンドでリモートリポジトリへ送る。
⑥ トピックブランチBを対象に、Pull requestを送る。

送るまでの手順①
111
 Pull requestを送る対象となるリモートリポジトリの
ページへ行き、Forkボタンを押します。
ここをクリック

送るまでの手順①
112
 すると、自分のアカウントのリモートリポジトリに、
Fork元と同様のリポジトリが作成されます。ちなみ
に、Fork元と同名のリポジトリが既に存在する場合、
末尾に「-1」などの文字が追加されます。

送るまでの手順②③
113
 まずローカルリポジトリへ、Forkを行ったリモート
リポジトリをcloneコマンドで取得してディレクトリ
内に移動します。コマンドは以下の通りです。
 git clone https://github.com/<account>/git-practice-pr
 <account>にはForkを行ったアカウント名が入ります。
 cd git-practice-pr
 なおclone後に内容を変更しており、内容を最新にし
たい場合、pullコマンドを実行します。

送るまでの手順④
114
 現在のブランチを確認します。コマンドは以下の通
りです。
 git branch -a
 するとremotes/origin/subCはありますが、subCが存
在しないことが分かります。そこで
remotes/origin/subCを利用して、subPRというト
ピックブランチを作成します。コマンドは以下の通
りです。
 git branch subPR origin/subC

送るまでの手順⑤
115
 subPRに移動して、README.mdの中身を107ページ
で説明したような内容に変更します。移動コマンド
は以下の通りです。
 git checkout subPR
 README.md変更後、README.mdをステージングエ
リアに追加してコミットします。コマンドは以下の
通りです。
 git commit -m “For Pull request”

送るまでの手順⑤
116
 先ほどコミットした内容をリモートリポジトリへ送
ります。コマンドは以下の通りです。
 git push -u origin subPR
 pushコマンドによって、Pull requestを送るためのト
ピックブランチをリモートリポジトリに送信しまし
た。

送るまでの手順⑥
117
 送信先のリモートリポジトリを確認すると、
「Compare & pull request」ボタンがあるので、こち
らをクリックします。
ここをクリック

118
 baseをsubCに変更し、タイトルとLeave a comment.
を画像のように記述したら、ページ下にある変更点
が正しいかを確認します。
ここをsubCに

119
 前ページで確認した内容が全て正しければ「Create
pull request」ボタンをクリックします。
 これで相手にソースコードを取り込んでもらうよう
に依頼することが出来ました。
 以降のスライドでは、送られてきたPull requestをど
のように確認・取り込みを行うか説明していきます。

Git(PC 1)
Gitリポジトリ
Pull requestを取り込むイメージ
120
GitHub(サーバ)
Git(PC 2)
Gitリポジトリ
ABA
C
⑦ ⑨
B
⑧
⑩
⑪
⑫

取り込むまでの手順
121
⑦ (Pull requestを取り込む対象となるローカルリポジ
トリがなければ、cloneコマンドを実行する。)
⑧ (Pull requestを取り込む対象となるローカルリポジ
トリが最新でなければ、pullコマンドを実行する。)
⑨ Pull requestを送っているリモートリポジトリから、
対象のブランチをfetchコマンドで取得する。
⑩ fetchコマンドで取得したブランチBからブランチC
を作成し、動作を確認する。

取り込むまでの手順
122
⑪ 手順⑩での動作確認が正常であれば、ブランチAに
ブランチBをマージする。
⑫ マージした結果のブランチAを、pushコマンドを実
行してPull requestを取り込む対象のリモートリポジ
トリへ送信する。

送るまでの手順⑦⑧
123
 まずローカルリポジトリへ、Fork元のリモートリポ
ジトリをcloneコマンドで取得してディレクトリ内に
移動します。コマンドは以下の通りです。
 git clone https://github.com/<account>/git-practice-pr
 <account>にはForkされたアカウント名が入ります。
 cd git-practice-pr
 なおclone後に内容を変更しており、内容を最新にし
たい場合、pullコマンドを実行します。

送るまでの手順⑨
124
 まずPull requestを送ってきたアカウントのリモート
リポジトリを登録します。そして登録したリモート
リポジトリの最新情報をfetchコマンドで取得します。
コマンドは以下の通りです。
 git remote add <account>
https://github.com/<account>/git-practice-pr
 git fetch <account>
 <account>にはPull requestを送ってきたアカウント名が入ります。

送るまでの手順⑩
125
 今回Pull requestが送られたsubCブランチから新たに
subPRCheckブランチを作成します。そして
subPRCheckブランチからPull requestを送ってきたリ
ポジトリのsubPRブランチをマージします。コマン
ドは以下の通りです。
 git checkout subC
 git checkout -b subPRCheck
 git merge --no-ff <account>/subPR

送るまでの手順⑩
126
 マージを行ったsubPRCheckブランチの動作を確認し
ます。(「確認」という作業を加えることで、Pull
requestを安全に行うことが可能となります。)
 確認用のブランチは、確認が終わり次第削除してか
まいません。コマンドは以下の通りです。なおコマ
ンド実行時、削除するブランチ以外のブランチから
行う必要があります。
 git branch -D subPRCheck

送るまでの手順⑪⑫
127
 正常であることが確認できたら、subCにリモートリ
ポジトリのsubPRをマージします。コマンドは以下
の通りです。
 git checkout subC
 git merge --no-ff <account>/subPR
 正常にマージできたことを確認したら、pushコマン
ドでsubCブランチをリモートリポジトリへ送信しま
す。コマンドは以下の通りです。
 git push

反映の確認
128
 この時点でPull requestを送ったアカウント・送られ
たアカウント双方のブランチが同一の内容であれば、
Pull requestの送信及び取り込みが正常に行われてい
ることになります。

Pull request送信者の注意点
129
 Pull requestを送ったアカウントのリポジトリには、
現在Forkを行った時点のリモートリポジトリとsubPR
ブランチが存在します。
 現状は良いのですが、今後Pull requestを送った先の
リポジトリの開発が進むと、Forkを行ったリポジト
リの内容は古くなっていきます。
 そこで「ローカルリポジトリに、新しくFork元のリ
モートリポジトリを登録してfetchコマンドで最新の
状態にする」という方法があります。

130
 前ページで説明した方法を行うために、まずはFork
を行ったリポジトリを取得します。コマンドは以下
の通りです。
 git clone https://github.com/<account>/<repository>
 cd <repository>
 <account>は自分のアカウントを入力します。
 <repository>は対象となるリポジトリを入力します。

131
 次にFork元のリモートリポジトリを登録してfetchコ
マンドで最新の状態にします。コマンドは以下の通
りです。
 git remote add upstream
https://github.com/<account>/<repository>
 git fetch upstream
 <account>はFork元のアカウントを入力します。
 <repository>は対象のリポジトリを入力します。
 以降、git fetch upstreamを実行することで、最新の
状態になります。

Pull request受信者の注意点
132
 Pull requestを送信するアカウントは、悪意の有無に
関わらず、必ず送信したソースコードが正しいとは
いえません。
 GitHubでは、Pull requestをGitHub上で行えるような
機能も存在しますが、手順⑩で行ったような確認を
行うことが出来ません。
 必ず手順⑩のような確認を行ってから、Pull request
を受け入れるようにしましょう。

目次
 はじめに
 おわりに
133

おわりに
1/3
 今回はGitとGitHubに関する基礎的な知識と、実践を
行いました。
 ここまでに行った内容は、初めての方には大変な内
容だったと思います。
 ですがコマンドの詳しいオプションや内容について
は触れていないので、GitやGitHubの詳しい内容につ
いては、一切触れていません。
 参考文献や入門者用のサイトのリンクを次ページ以
降に記述しておくので、参考にしていただくと幸い
です。
134

おわりに
2/3
 入門者用のサイト
 http://k.swd.cc/learnGitBranching-ja/, Learn Git
Branching.
 https://www.slideshare.net/kotas/git-15276118, こわ
くない Git, 2012.
https://try.github.io/levels/1/challenges/1, Git Tutorial
- Try Git.
 https://www.slideshare.net/matsukaz/git-17499005,
いつやるの?Git入門, 2013.
135

おわりに
3/3
 参考文献
 大塚弘記, GitHub実践入門 ~Pull Requestによる開発
の変革(WEB+DB PRESS plus), 技術評論社, 2014.
 https://git-scm.com/book/ja/v2, Git - Book, 2014(閲
覧日: 2017年9月5日).
136

GitHub勉強会~当日資料~

More Related Content

What's hot

Similar to GitHub勉強会~当日資料~

Recently uploaded

GitHub勉強会~当日資料~