GitHub勉強会

GitHub勉強会@arusuDev
GitHub勉強会
GitHub/Gitの使い方

GitHub勉強会(2019)@arusuDev
Outline
• Git/GitHubってなんだろう？
• Gitを使うことのメリット
• ローカルリポジトリを作ってみよう！
• ソースをコミットしてみよう
• GitHubにリモートリポジトリを作ってみよう
• GitHubを使うことのメリット
• Branch(ブランチ)とは？
• Gitにおけるマージ
• GitHubにおける開発の流れ
• PullとPush
• Pull request（コードのレビュー）とは？
• ブランチモデルとは？
• Issue機能を使ってみよう！
• Project機能を使ってみよう！
2/112

まずは`Git`の説明から!
Git/GitHubってなんだろう？
3/112

Gitは
“バージョン管理システム”
である！
って何？ってなりますよね
Gitってなんだろう？
4/112

© Basic Inc. All Rights Reserved.
GitHub勉強会(2019)@arusuDev 5/112
ファイルを管理したい時、そして古いバージョンを残したい時
こんな管理の方法をしませんか？
（私はよくやります。）

この方法だと、バージョンが増えてくるとぱっと見で
このバージョンがどんなときだったのかわからず、たくさん開いたりすることになる
ソースコードもこの管理の仕方をするとだんだん訳わからなくなってくる
そこで登場するのが “Git”

Gitを使うことのメリット
Gitを使うと、ファイルの変更を記録することができる！
例えば次のようなプログラムがあるとします。
“Hello World”を”Hello Git”に変更した！

前のバージョン(左）もとっておきたい…
ってなったときに左にGit_Hello_v1.cpp 右にGit_Hello_v2.cpp
みたいに管理するのが従来の方法になるよね。

でもこれって、変わってる部分1行だけだよね？
全部別ファイルにして保存するの管理しにくいし分かりづらい！
そうそう、この色が変わったところだけを保存してくれれば、変更を知るには十分。
どこかにそんなシステムがないかなー？？

そう、Gitならね。

Git を使うと、ファイルの変更だけを
記録することができる！
ということで、まずは複数人数での開発にも欠かせない
Gitの使い方を勉強していこう！

ローカルリポジトリを作ってみよう！
さて、Gitではいくつか専用の用語が出てくる。
なれるまでは、ちょっと大変だけどなれるとサクサクできるようになるよ！
予め言っておくと、これから説明する単語は
私の理解で説明していくから正確な説明とは異なる場合があります。
（予防線）
またこの勉強会では、VSCodeを使ってGitの管理をすることを
想定してます。ベースとしてコマンドラインでの処理をまず覚えて、
イメージが掴めたらVSCodeでの処理方法までふれられたら良いな

まず一番初めに出てくる単語は、
Repository(リポジトリ,レポジトリ）自分はリポジトリって読んでるけど好きな方で呼べばいいと思う
これは、Gitで管理するフォルダのことをさします。
リポジトリの中にあるファイルが管理対象になるってイメージだね。

まずは、手持ちのPCで好きな場所に、GitMeetingフォルダを作ろう。
作成した、GitMeetingフォルダに入ったら、このフォルダをリポジトリにします。
このコマンドを叩くと、
みたいに表示されるはず！
$ mkdir GitMeeting
$ cd GitMeeting
$git init
$ git init
Initialized empty Git repository in C:/Users/Arusu/GitMeeting/.git/

コマンドを叩いて、.git (隠しフォルダ）っていうフォルダが
作成されていれば、おｋ！
これで、GitMeetingフォルダがローカルリポジトリになって、このフォルダで
の変更をGitが見ることができるようになりました！
$ ls -al

ソースをコミットしてみよう
さて、次はなにかソースコードを追加してみよう！
適当にリポジトリ内で、Hello Worldのソースでも作成して、
Hello.cppとしてみよう。
プログラムが書き終わったら、保存して次のコマンドを叩いてみよう。
$ code Hello.cpp
$ git status

そうすると、次のような表示が多分出てくる。
これは、まだHello.cppの変更をgitで追ってないよ！っていう意味
$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
Hello.cpp
nothing added to commit but untracked files present (use "git add" to track)

ソースコードを追跡対象（変更を追う）にしてみる。
そして、もう一度
を叩くと、赤かった部分が
に変わっているはず！
これで、gitでHello.cppが管理対象になります。
$ git add Hello.cpp
$ git status
new file: Hello.cpp

でも、管理対象になっても、今の状態だと、どのタイミングに戻ればいいかわ
からない！
今までの管理方法だと、この時の状態をv1,v2みたいにしてファイル分けし
ているタイミングで、
gitではcommit(コミット）という操作を行います。

Gitでコミットするコマンドは
git commit –m “メッセージ”
このメッセージの部分には、その変更で何をしたか、が分かるようなメッセージ
を付けてあげると良いです。
後で述べる、複数人数で開発する場合は、コミットメッセージの書き方の
ルールを相談しておくと、あの変更どこでやったっけ？っていうのがスムーズに
進んだりする、かも！
$ git commit -m "はじめてのこみっと"
[master (root-commit) 3cd0f76] はじめてのこみっと
1 file changed, 6 insertions(+)
create mode 100644 Hello.cpp

次に、Hello.cppの中身を少し書き換えてみよう。
例として、今回は
coutを1行増やしてみた。
#include <iostream>
using namespace std;
int main(void){
cout << "Hello,World" << endl;
cout << "Hello,Git" << endl;
}

この変更を保存した状態で、
コマンドを実行すると、
のような表示が出て、Hello.cppが変更されていて、commitされていない
ことが分かります。
さっきと同じようにcommitしてみよう。
$ git status
modified: Hello.cpp
$ git add Hello.cpp
$ git commit -m "Update : coutを追加したよ"

コマンドを使うと、今までの変更が見ることができるよ。
基本的なgitの操作の流れは、
$ git log
ソースの編集
コミットの対象にする
（ステージング）
git add (filename)
コミット
（変更の記録）
git commit –m “message”

GitHubってなんだろう？
Gitの最も基礎的な使い方を学んだので、
次は
GitHub
について見ていこう

GitHubってなんだろう？
GitHubとは、オンライン上で
Gitのリポジトリを共有するためのプラットフォームである。（私の解釈）
Gitを共有・複数人数で開発することに特化したクラウドサービスみたいなも
のかな。

ローカルリポジトリとリモートリポジトリ
Gitで使用するリポジトリをローカルリポジトリ
GitHubのリポジトリをリモートリポジトリっていう。
ローカルで作業した内容をリモートリポジトリに反映させることで、ソースコード
の共有ができるシステムになってる。
Local
rep
commit
commit
commit
GitHub
Remote
rep
ローカルでの作業をリモートに反映させる

リモートリポジトリを作ってみよう
なにはともあれ、一回やってみないとイメージが掴めないはず！
GitHubで、リモートリポジトリを作ってみよう。
まずはGitHubのサイト
(マイページでも可）
https://github.com/
にアクセス（ログインしてね）
これは私のマイページ

画面の右上、自分のアイコンが設定されている画像の隣に
+ マークがあるのでクリック！
New repositoryを選択します。

リモートリポジトリの新規作成の
画面にいきます。
今回は、Repository nameに、
GitMeeting
と入れてみましょう。
他の人からリポジトリが見えるかどうかを
設定できますが、Publicで
いいんじゃないかな。
Initialize~にはチェックを入れず
Create repository をおします！

これでリモートリポジトリが作成されました！
今回は、ローカルですでにリポジトリがある
ので、’…or push an existing~’
って書いてあるところを実行しましょう。
ローカルでさっき作業した、ターミナルに
戻って、

サイトに書いてあるコマンドを入力します。
1行目は、ローカルのリポジトリに、リモート(GitHub)のURLはここだよ、
って教えるコマンドです。
git remote add origin https://github.com/arusuDev/GitMeeting.git
git push -u origin master
Local
rep
GitHub
Remote
rep
ローカルのリポジトリにリモートのリポジトリを連携させる

2行目は、pushコマンドと呼ばれるコマンドで、ローカルのcommitをリモートに
反映させるときに使います。originというのはリモートだよっていう指定です。
git remote add origin https://github.com/arusuDev/GitMeeting.git
git push -u origin master
Local
rep
commit
commit
commit
GitHub
Remote
rep
ローカルでの作業をリモートに反映させる(push)

コマンドを実行したら、GitHubのサイトをリロード(F5)してみよう。
上手くいってれば、説明の画面から、
こういう画面に切り替わるはず！
これで、リモートリポジトリが完成！

GitHubを使うことのメリット
ふむふむ、ローカルリポジトリでのコミットの内容をネット上に公開できるのね。
で？それだけ？？？
ってなると思うんだけど、GitHubを使うと
複数人数でプログラムを開発することができるようになります。

GitHubを使わない場合、複数人数で開発するときは、
AさんとBさんがそれぞれ別のコードを作業してるときは良いけど、
A
BC
ソースコード
A B

GitHubを使わない場合、複数人数で開発するときは、
同じソースコードをいじってしまった場合、ソースコードの変更を合
わせるのが困難になってしまう…。
A
BC
ソースコード
A
B
競合

この問題をGitHubを使うとどうなるかというと…
AさんとBさんがソースコードAの別の場所をそれぞれ作業するとす
ると、Gitではコミットの情報(変更した情報）を保存して
A
BC
ソースコード
A
B
A BXX行に～を書き込んで、
YY行の行を削除したよ
ZZ行に～を書き込んで、
AA行の行を削除したよ
リモートリポジトリ(Github)

同じソースコードでも、AとBで作業箇所が被っていなければそれぞ
れのコードの変更を取り込むことができます。（マージ）
A
A BXX行に～を書き込んで、
YY行の行を削除したよ
ZZ行に～を書き込んで、
AA行の行を削除したよ
Aの変更を取り込む A‘ Bの変更を取り込む New A

GitHubを使って開発をするときのイメージ
Remote
Repository
Local
repository
commit
ローカル環境
Push:
ローカルの変更をリモートへ送信
Pull:
リモートの変更を（他の人による変更）
ローカルへ反映
GitHub
commit
commit

Branch(ブランチ)とは？
Git/GitHubには、ブランチという機能があります。
Gitではじめリポジトリを作成すると、
masterという名前のブランチが作成されます。
リポジトリ
master

Gitでは、ローカルで作業してコミットをすると、
今いるブランチに変更がコミットされます。
リポジトリ
master
First Commit
Update:
xxxx

Aという機能と、Bという機能をプログラムに追加したくなったとしましょう。
GitHubでは、範囲が被っていなければ同時に作業することは可能です。
リポジトリ
master
First Commit
Update:
xxxx

よし、じゃあ作業しよう！
となって、AさんとBさんが機能Aと機能Bを同時に実装していくと…
リポジトリ
master
機能Aのコミット1 機能Aのコミット2
機能Bのコミット1 機能Bのコミット2

なんだか、変更履歴がちょっとぐちゃぐちゃに…
しかもこのときに例えば問題が起きて、機能Bのコミットまで戻りたい…ってな
ると、
リポジトリ
master

Aさんが開発していた機能Aのコミット2まで消えてしまいました。
これだと管理がぐちゃぐちゃになってしまいます。
リポジトリ
master
機能Aのコミット1
機能Bのコミット1

そこで、ブランチという機能を使うと、
コミットの流れを分岐させることができます。
機能Aの実装のために、Aというブランチを、
機能Bの実装のために、Bというブランチを切ると…
リポジトリ
master

そこで、ブランチという機能を使うと、
コミットの流れを分岐させることができます。
機能Aの実装のために、Aというブランチを、
機能Bの実装のために、Bというブランチを切ると…
リポジトリ
master
Branch : A
Branch : B

ブランチが分けられたことで、それぞれの機能がmasterの特定のポイントか
ら分岐され、別々の履歴にコミットされるようになり、機能毎にまとまった開
発ができるようになりました！
リポジトリ
master
Branch : A
Branch : B

ただ、このままだと、機能Aを持ったプログラムと、機能Bを持ったプログラムが
別々に存在するだけになってしまうので、それらを合わせる必要があります。
ブランチでの作業を、もとのブランチ(この例だとmaster)に反映させることを、
と、いいます。
リポジトリ
master
Branch : A
Branch : B
マージ(merge)

Gitにおけるマージ
マージをすると、マージコミット、と呼ばれるものが作成されます。
リポジトリ
master
Branch : A
Branch : B
MasterへのAのマージコミット
MasterへのBのマージコミット

これによって、masterブランチに機能Aと機能Bを持ったプログラムが
完成します。
リポジトリ
master
Branch : A
Branch : B
機能AとBを持ったプログラム

Gitを使って開発するときは、主に次の流れで開発していきます。
メインの開発するブランチ
から機能毎に分けた
ブランチを切る（作成する）
機能毎に分けたブランチで
開発をすすめる。
ブランチを切るもとの
ブランチにマージを行う。
リポジトリ
master
Branch : A
Branch : B

ローカルでブランチを切ってみよう
前に作ったローカルリポジトリ、GitMeetingを開きます。
まず、次のコマンドを利用してみよう。
このコマンドを利用すると、
のような表示が出ると思います。
これは、今いるリポジトリに、masterブランチがあるということを示しています。
$ git branch
$ git branch
* master

今いるmasterブランチから、新たなブランチを切って（作成して）みよう。
例では、function_Aという名前のブランチを作成しています。
もう一度、
コマンドを利用すると、
という表示が出て、function_Aというブランチが作成されていること
がわかります。
$ git branch function_A
$ git branch
$ git branch
function_A
* master

しかし、この表示が示している通り、branchを作成しただけでは、まだ
masterブランチにいることがわかります。
そこで、checkoutコマンドを使って、ブランチを移動します。
このコマンドを使って、git branchコマンドを使うと、
移動できてますね！
$ git branch
function_A
* master
$ git checkout function_A
Switched to branch 'function_A'
$ git branch
* function_A
master

ローカルでブランチを切ってみよう（コマンド）
新しいブランチを作成するコマンドは、
ブランチを移動するコマンドは、
また、これらをまとめて行うコマンドとして、
のようなcheckoutのオプションも存在します。
$ git branch (branch_name)
$ git checkout (branch_name)
$ git checkout -b function_B
Switched to a new branch 'function_B'
新しいブランチは現在のブランチから作成される点に注意！

さて、新しく作成したブランチ function_A でソースコードをなにか
編集してみよう。
例として、function_Aを実装してみました。

今現在、リポジトリは次のような状態になっています。
$ git add Hello.cpp
$ git commit -m "Update : function_A"
[function_A 2efddae] Update : function_A
リポジトリ
master
Branch : A
Update:function_A

試しに、masterブランチに移動してみましょう。
この状態で、先程変更を加えたファイルを見てみると、その変更がなかったこ
とになっていると思います。
リポジトリ
master
Branch : A
$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
いまここ！

ローカルでブランチをマージしてみよう
Function_Aブランチでの作業はすでに終わっているので、
変更をmasterブランチに取り込んでみましょう。
まずは、取り込みたいベースとなるブランチに移動します。
今回はmasterブランチに function_Aブランチをマージしたいので、
masterブランチに移動します。(checkoutコマンド）
リポジトリ
master
Branch : A
ここにBranch:Aの変更を取り込みたい。

ブランチをマージするには次のコマンドを利用します。
すると、次のような表示が出ると思います。
今回の例だと、マージによって、Hello.cppに5行分の追加が
行われたことがわかります。
$ git merge function_A
Updating 38efb93..2efddae
Fast-forward
Hello.cpp | 5 +++++

ローカルで、マージするときのイメージを持って、
次のGitHubで開発する時のイメージを付けていこう！
リポジトリ
master
Branch : A
function_Aの変更が
masterにマージされた！

GitHubにおける開発の流れ
GitHubで複数人数開発するときのの流れは次のようになります。
初回
リモートリポジトリ
からcloneする
[clone]
開発のための
ブランチを切る
[checkout]
作成したブランチ
で作業をコミット
[commit]
に変更を送信
[push]
コードのレビュー
を依頼する
[pull request]
コードの変更を開発
ブランチに取り込む
[merge]
コードの変更を
ローカルに取り込む
[pull]
開発

GitHubで複数人数開発するときのの流れは次のようになります。
初回
からcloneする
[clone]
開発のための
[checkout]
[commit]
に変更を送信
[push]
を依頼する
[pull request]
[merge]
[pull]
開発
Githubのソースコードをローカルにダウンロードするコマンド
リモートと同様のローカルリポジトリが作成されます。
git clone URL

GitHubで複数人数開発する時の流れは次のようになります。
開発のための
[checkout]
[commit]
に変更を送信
[push]
を依頼する
[pull request]
[merge]
[pull]
リモートでの作業
ローカルでの作業

pullコマンド
pullコマンドを使うと,今現在いるローカルのブランチに、リモートリポジトリの
変更をマージすることができます。
$ git pull origin (branch_name)
Remote
Rep
master
Remote
(GitHub)
Local
Local
Rep
master
pull

pullコマンド
pullコマンドを使うと,今現在いるローカルのブランチに、リモートリポジトリの
変更をマージすることができます。(リモートとローカルを同期させるイメージ）
$ git pull origin (branch_name)
Remote
Rep
master
Remote
(GitHub)
Local
Local
Rep
master
pull

開発のための
[checkout]
[commit]
に変更を送信
[push]
を依頼する
[pull request]
[merge]
[pull]

checkout/commit
これは前にやったローカルでの作業と一緒です！
実装したい機能の名前をつけたbranchを切って、
作業したら、作業したファイルをステージング（add)して、
コミットメッセージをつけてコミットしましょう！
$ git checkout -b feature
$ git add (file)
$ git commit –m “commit message”

開発のための
[checkout]
[commit]
に変更を送信
[push]
を依頼する
[pull request]
[merge]
[pull]

pushコマンド
コミットした内容を今度はリモートリポジトリに送信しよう。
このコマンドで、リモートリポジトリに現在のコミット内容を送信することができ
る。originが前についているブランチ名は、リモートのブランチ名であることを
示しています。
ローカルのmasterブランチをpushするときは、
となります。
git push origin (branch_name)
git push origin master

pushコマンド
Remote
Rep
master
Remote
(GitHub)
Local
Local
Rep
master
push

pushコマンド
ローカルでの変更をリモートに反映します。
Remote
Rep
master
Remote
(GitHub)
Local
Local
Rep
master
push

開発のための
[checkout]
[commit]
に変更を送信
[push]
を依頼する
[pull request]
[merge]
[pull]

pull request(コードのレビュー依頼）
さて、ここに来てまた馴染みのない単語が出てきました。
これは複数人数で開発するときに、使うものです。
例えば、AさんとBさんで開発をしていたとしましょう。
Remote
master
Aさん
master
feature
Aさんがfeatureブランチで
新しい機能を開発

Aさんは機能を開発したので、featureブランチをリモートにpushしました。
Remote
master
Aさん
master
feature
feature
push

Aさんは機能を開発したので、featureブランチをリモートにpushしました。
そしてAさんは、masterブランチにマージを行いました。
Remote
master
Aさん
master
feature
feature
masterブランチに
featureブランチをマージ

小規模な開発の場合は、あまり問題になることは少ないですが、
例として、Aさんの作ったコードにバグが存在したとしましょう。
Remote
master
Aさん
master
feature
feature

そうすると、一緒に開発していた人たちのメインの開発ブランチにバグが混在
することになってしまいます。開発しているブランチに色んな人が好き勝手に
マージしてしまうと、いろんなバグや整合性がとれなくなってしまう恐れがある
のです。
Remote
master
Aさん
master
feature
feature

そこで登場するのがこの、pull request（通称プルリク）という機能です。
これは、一緒に開発を行っている人に、コードのレビューを依頼するという機
能になっていて、GitHub上から行うことができます。
Remote
master
Aさん
feature
featureブランチをmasterブランチに
マージしたいからレビューしてくれ

そこで登場するのがこの、pull request（通称プルリク）という機能です。
これは、一緒に開発を行っている人に、コードのレビューを依頼するという機
能になっていて、GitHub上から行うことができます。
Remote
master
Aさん
feature
featureブランチをmasterブランチに
マージしたいからレビューしてくれ
masterブランチに
featureブランチを
マージしたい
pull request
Bさん
レビュー依頼

Bさんは受け取ったプルリクエストの内容を見て、問題がないと判断した場合
には、マージを
Remote
master
feature
マージ

問題点がある（コード、実際に動かしてみて）と思った場合には、そのこと
を開発者に伝えて、再度変更をpushしてもらうように依頼します。
Remote
master
feature
マージ
Remote
master
feature
Bさん：この辺の機能
おかしくない？
Aさん：確かに！
修正します。

Remote
master
feature
マージ
Remote
master
feature
Aさん：修正しました！
Bさん：直ってるの確認
したのでマージ！

Remote
master
feature
マージ
Remote
master
feature
バグを除けた！

このようにコードをレビューすることによって、コードについて議論する場であっ
たり、品質の高いコードを作ることができるようにする機能がpull requestと
呼ばれる機能です。
実際にGitHubで、どのようにしてプルリクエストが
作成されるか見ていきましょう。

GitHub上では、新しいブランチでコードのpushを行ったときに、
次のような表示がでます。

Compare & pull requestをクリックすると、このような画面になります。
Baseにマージをされるブランチを、compareに実装した機能のあるブランチ
を選択します。
Writeの中には、
レビューしてもらうのに
参考になるような内容を
書くと良いです！
(markdownが使えます)

89
Pull requestを作成すると、
上のタブでPull requestの欄の
数字が増えます。
ここには前のページで記述した
内容が表示されます。
ここでは、他の人が同じ行から作業している
コンフリクト（衝突）がないかを表示します。
コンフリクトがなければ、チェックマークが付き
マージは問題なく行われます。
Pull requestに対してなんらかのメッセージを
送る場合はこっちに書きます。

90
Pull requestでレビューをする場合
GitHub上で行うときは、
右のFile changedをクリックします。

File changedをクリックすると追加された行が緑、削除された行が赤で表
示されます。実装された機能が問題なければ、Review changesをクリッ
クし、
Review changes

コメントや変更のリクエストを書いて、Submit reviewを押します。

コメントや変更のリクエストを書いて、Submit reviewを押します。
問題がなければここからマージを行いましょう！

Confirm mergeをクリック！

これでmasterブランチに変更がマージされました。
開発に使ったブランチを削除するかどうかは、開発の規模によると思うので、
開発する人たちの中で決めるのが良いと思います。
あまりにブランチが増えすぎるとそれはそれで管理が大変になってくることも…

開発のための
[checkout]
[commit]
に変更を送信
[push]
を依頼する
[pull request]
[merge]
[pull]

pullに戻る
mergeまでいったのでここまでが開発のイテレーションが一巡します。
開発メインのブランチ（例だとmaster)がマージされて更新されているので、
pullでローカルのmasterを更新して、ブランチを切って、と進んでいきます。
Remote
Rep
master
Remote
(GitHub)
Local
Local
Rep
master
pull
$ git pull origin master

ブランチモデル
GitHubでの開発の流れはここまでで抑えてきました。
Gitで開発するときに、どのようなルールでブランチを切るのかということを決め
たものがブランチモデルと言います。
Gitではいろいろなブランチモデルが提案されています
ここまで例で上げてきたものは、
masterとfeatureの二種類で開発するものを例としてあげてきました。
Repository
master
feature
feature

この例に上げてきた手法では、常にmasterのコードがマージによって
書き換わっていくため、リリース時点や安定版のコードを保存することが
できないという問題点があります。
そこで、master + develop + featureの三種類のブランチを使って管
理する方法などがあります。
Repository
master
featureA
featureB
develop
v0.1 v0.2
featureC

ブランチモデルには様々なモデルが有り、開発の規模に合わせたブランチモデ
ルを利用すると良いと思います。（Google等でブランチモデルなどと検索す
ると色々と出てきます。
Repository
master
featureA
featureB
develop
v0.1 v0.2
HotFix
featureC

Issue機能を使ってみよう
GitHubにはissueという機能がある。
issueは、
・こういう機能を実装したらどうだろう？（追加機能）
・こういう問題があるから直さないといけないよね（課題）
などのタスク管理ができる機能になっています。

Issueのタブをクリックすると、
右のような画面が開く。
右にあるNew issueを
クリックすると新たなタスクを
登録することができる。

Titleにはその提案する機能や問題について見て分かるようなものを書こう。
Leave a commentのところは、Titleだけで事足りてしまう場合は
書かなくても良いかもしれないけれど、他の人の理解の助けに
なりそうなことを書くと
優しいです。
右側にいくつか項目が
あるのでそっちについて
少し見ていこう。

これらの項目は右側の歯車をクリックすると
設定できる項目が出てきます。
・Assignees
担当者を決める機能（一人だと自分だけ出てくる…）
・Labels
問題がどういう内容なのか
(バグなのか、新しい機能なのかとか、自分で作ることもできるよ！）
・Projects
あとで説明するProjectという機能に紐付け！
・Milestone
Issueの期限を決めたりするのに使えるみたい

試しに、issueを作成してみると次のような画面になる。
このissue一つにつき、一つブランチを切って作業するように私はしています。
Issueに取り組んでいるときに、
調べたことや出てきた問題点をコメントに
記しておけば、あとで開発するときに
役立つ可能性があるのでおすすめです。

Project機能を使ってみよう
今回説明する機能の最後になります。GitHubにはプロジェクトの管理を
するための機能として、
Projects機能があります。
Projectsタブを開いて、
Create a projectボタンを
押してみましょう。

Projects機能を使うと、issueを付箋のような形で管理することができます。
まずは付箋を貼り付けるボード（看板）を作成します。
ボードの名前は小規模なプロジェクト
であれば好きな名前で良いと思います。

プロジェクトボードのテンプレートがあるので、
好きなものを選びます。
個人的なおすすめは
“Automated Kanban”
です。
これはissueの作成時にこのプロジェクトを
作成すると勝手に紐付けしてカードを
追加してくれるオプションになります。

110
作成すると次のような画面になります。Todoには簡単な使い方の説明(英
語)が乗っています。必要でなければ右上の・・・から
”Archive all cards”
してしまいましょう。

画面右上のAdd cardsをクリックすると、今現在存在する
issue と pull requeset が表示されるので、To doに持っていきましょう。
カードは自由に移動することができます。これによって、今やらないといけない
タスク、”To do”や
作業中である
“In progress”
終了後である
“Done”
を管理することが
できます。

GitHub勉強会@arusuDev
複数人開発ですごく便利なツール
Git/GitHubを使っていろいろ開発しよう！
おつかれさまでした。

GitHub勉強会

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to GitHub勉強会

Similar to GitHub勉強会 (20)

Recently uploaded

Recently uploaded (8)

GitHub勉強会