Basic lecture of Git & GitHub

Slide 1

Slide 1 text

Git/GitHub 基礎講座 Kaoru @cordx56 cordx.net

Slide 2

Slide 2 text

2 目次 - 前編 ● 導入 – Git/ バージョン管理システムとは – Git の利点 ● Git の仕組み – リポジトリ – branch – merge – commit – staging – pull/push

Slide 3

Slide 3 text

3 目次 - 後編 ● リモートリポジトリを使った開発 – clone – pull/push – 共同開発での利用 ● GitHub の活用 – Fork – Issue/Pull Request – GitHub Pages を使ってみよう

Slide 4

Slide 4 text

4 導入 Introduction of Git

Slide 5

Slide 5 text

5 導入 - Git とは ● バージョン管理システムの一種 ● バージョン管理システムとは？ – コンピュータ上のファイルの変更履歴を管理するためのシステム – 場面にもよるが，こういった場で言うときは，大抵ソースコードの管理をするためのものバージョン管理システムがあると何が嬉しい？

Slide 6

Slide 6 text

6 導入 - バージョン管理システムとは ● プログラミングをしていると，ソースコードの変更を細かく記録しておきたいことはよくある – 皆さんはもう使わないけど残しておきたいコードや新しい実装をする前に念の為確実に動く古いコードをコメントアウトで残して可読性を下げたりしたことはありませんか？ – あるいは， ver1.zip ，配布 .zip ，最新 .zip ， 08/26 最新 .zip とか，ソースコードをまとめて zip ファイルにして結局混乱したり，古いバージョンからの変更点がわからなくなったことはありませんか？

Slide 7

Slide 7 text

7 導入 - バージョン管理システムとは ● バージョン管理システムを活用すると，こういった手動でのバージョン管理で消耗する必要がなくなる ● バージョン管理システムのログを叩けば，変更点と変更日時，添えられたコメントを見ることができる – いらないコードをコメントアウトで残す必要がなくなる ● あるいは，一気に過去のソースコードまで遡って，過去のソースコードの途中から開発を再開したり，変更を細かく追ったりすることもできる – よりわかりやすい形で過去の状態を参照できる

Slide 8

Slide 8 text

8 導入 - バージョン管理システムとは ● この辺の利点は特に共同開発で強い味方になる ● 共同開発だと，コードの同じ部分を同じタイミングで編集してしまい，変更がだいぶ蓄積してから，じゃあみんなのコードを一つにまとめましょうという段で，とてつもない量のコードがどんな変更を経てそうなったのかわからなくなってしまう例もある – 締切直前とかに手作業で問題が起きないように大量のコードを集約するのは地獄の図 ● バージョン管理システムを上手く使うことで，各自の変更点が明確になったり，こまめにソースコードを集約できたりして，共同開発のコストを減らせる

Slide 9

Slide 9 text

9 導入 - バージョン管理システムとは ● ここまでをまとめると今日からはバージョン管理システムを使って上手く開発していこう

Slide 10

Slide 10 text

10 Git の仕組み Terms and Behaviour of Git

Slide 11

Slide 11 text

11 Git の仕組み - リポジトリ (repository) ● ソースコードのバージョンを管理するデータベース単位 ● ローカルとリモートの 2 種類がある ● ローカルリポジトリ – 開発者のパソコンにある，手元でいじるリポジトリ開発者が手元で作業するためのもの ● リモートリポジトリ – サーバ上にある，遠隔から管理するリポジトリ共同開発で共有して利用できる

Slide 12

Slide 12 text

12 Git の仕組み - リポジトリ (repository) ● 最初に，開発者はリモートからリポジトリをクローンして，あるいはローカルでリポジトリを作成して，手元にあるローカルリポジトリとする ● クローンしてきたリポジトリの場合，既にリモートリポジトリとの紐づけがされている ● ローカルでリポジトリを作成した場合は，リモートリポジトリを紐づけをする必要がある – リモートリポジトリには，デフォルトで origin という名前が使われる ● リモートリポジトリは，複数人で共同で開発を行うときに特に活用する

Slide 13

Slide 13 text

13 Git の仕組み - リポジトリ (repository) ● カレントディレクトリでローカルリポジトリ初期化 ● リモートリポジトリとの紐づけ – [email protected]... の部分は適宜変更してください ( 後編で説明します ) $ git init $ git remote add origin [email protected]:SIT-DigiCre/idrs-slack

Slide 14

Slide 14 text

14 Git の仕組み - branch ● 本流から分かれる枝のイメージ ● branch 間でコードの変更は共有されない – branch を分けることで，本流の開発，同時進行するトピックが別の開発に影響を与えずに開発を進めることができる ● 特に共同開発の場面では，異なるトピックについて同時に同じコードをいじると，混乱が発生することは容易にわかる – トピックごとに branch を分けて，実装が終わった段階で本流に merge するのが一般的

Slide 15

Slide 15 text

15 Git の仕組み - branch ● ブランチ作成 ( ここではブランチ名を impl-i2c とする ) ● ブランチ移動 ● ブランチ作成 & 移動 ( 上記 2 ステップを一括実行 ) ● ファイルを変更してコミットしてからブランチを移動すると，他のブランチではファイル変更の影響を受けていない様子が確認できる $ git branch impl-i2c $ git checkout -b impl-i2c $ git checkout impl-i2c

Slide 16

Slide 16 text

16 Git の仕組み - merge ● branch 間のコードの差異を吸収し，一つの branch にまとめること ● git merge コマンドは，今いる branch に，指定した branch の変更を取り込む ● merge commit を作ることができる ● 自動で吸収できない差異があった場合 (2 つの branch でコードの同じ位置を更新していた場合など ) ， conflict が発生し，手動でどちらのコードにまとめるか決定して commit する必要がある

Slide 17

Slide 17 text

17 Git の仕組み - merge ● master ブランチに impl-i2c ブランチをマージ ● 上のコマンドでは，場合によってはマージコミットが生成されない – 常にマージコミットの生成を強制する (Fast-Forward マージをしないようにする ) には以下のコマンドを利用する $ git checkout master $ git merge impl-i2c $ git checkout master $ git merge --no-ff impl-i2c

Slide 18

Slide 18 text

18 Git の仕組み - commit ● ファイルの変更とそれに対するコメントをリポジトリに記録すること ● コミットが Git で管理される変更の最小単位 – 関数の実装や小さなバグ修正など，比較的小さな単位の変更に切り分けてコミットをすることが推奨される ( コード変更の意図がわかりやすくなる，頻繁に pull/push できるなどの理由が挙げられる ) ● staging area に登録されている変更を記録 – stage については次のスライドで解説

Slide 19

Slide 19 text

19 Git の仕組み - staging area ● 次にコミットする対象となる変更を登録する場所 ● git add コマンドを利用して，ファイルの変更を staging に乗せる = stage する ● 全ての変更の中から特定の変更を staging area に乗せる / 乗せないを分けることで，どの変更を同じ commit に乗せるかを選択することができる

Slide 20

Slide 20 text

20 Git の仕組み - stage & commit ● main.py ファイルの変更をステージする ● ステージされた全ての変更にコメントをつけてコミットする – -m はコミットメッセージをコマンド中で明示してコミットする，というオプション ● -m をつけずにコミットすると，テキストエディタが起動して，長いコミットメッセージを入力することができる ● message の m $ git add main.py $ git commit -m “Implement I2C communication”

Slide 21

Slide 21 text

21 Git の仕組み - pull/push ● pull – 指定したリモートリポジトリのブランチを取得し，ローカルリポジトリの今いるブランチに取得したブランチをマージすること ● push – ローカルリポジトリのコミットを指定したリモートリポジトリのブランチに反映させること ● pull と push は頻繁にしよう – 特に共同開発では， pull と push を怠るとトラブルが発生しやすくなる

Slide 22

Slide 22 text

22 リモートリポジトリを使った開発 Development with Git remote repository

Slide 23

Slide 23 text

23 リモートリポジトリの意義 ● Git は「分散型」と呼ばれる仕組みでバージョン管理を行う – 対するのは「集中型」であり， SVN などがある – 集中型ではリポジトリは常にサーバ上にあるもの 1 つのみであり，開発者は常にサーバと通信をしてソースコードの取得，変更をする – 分散型ではサーバ上のリモートリポジトリ，手元のローカルリポジトリなど，複数のリポジトリを利用して開発を進める ● 何故 2 つの方式があるのか？

Slide 24

Slide 24 text

24 リモートリポジトリの意義 ● 集中型ではリポジトリは常にサーバ上にあり，複数のリポジトリが存在しないため各種操作が簡単な反面，ソースコードの取得，変更に常にサーバとの通信を必要とする – もしリポジトリを持つサーバが落ちてしまったら？ ● GitHub もたまに落ちる ● 分散型では複数のリポジトリを利用するため，各種操作が複雑になりがちだが，サーバとの通信は最終的に変更をリモートリポジトリに反映させたい時のみで良い – ローカルで ( サーバが落ちても ) 作業可能 – 手元の変更をよく検討してからリモートに送れる

Slide 25

Slide 25 text

25 リモートリポジトリの意義 ● Git は分散型 ● 開発者は，基本的にローカルで行った変更をローカルリポジトリにコミットし，ある程度蓄積したところでリモートリポジトリにプッシュする – 常に通信が発生するわけではないので，効率が良い – リモートとローカルでリポジトリが分散しているため，リポジトリ操作等が必要になり，開発者は多少複雑な操作をする必要がある – Git はブランチを切る，マージするためのコストが SVN に比べ非常に低く，気軽にブランチを切って開発を進めやすいという利点がある．

Slide 26

Slide 26 text

26 リモートリポジトリ - clone ● 既存のリモートリポジトリをローカルリポジトリとしてダウンロードすること ● 既存プロジェクトに参加する場合や，別のコンピュータで作業を開始する時に行う – HTTP で clone( 認証不要 ) – SSH で clone( 要認証 ) $ git clone https://github.com/SIT-DigiCre/ idrs-slack/ $ git clone [email protected]:SIT-DigiCre/ idrs-slack/

Slide 27

Slide 27 text

27 リモートリポジトリ - 新規作成 ● 13 番スライドと同等の内容 ● ローカルリポジトリを作成して，リモートリポジトリに origin と名前をつけて結びつける $ git init $ git remote add origin [email protected]:SIT-DigiCre/idrs-slack

Slide 28

Slide 28 text

28 リモートリポジトリ - pull/push ● pull – 指定したリモートリポジトリのブランチを取得し，ローカルリポジトリの今いるブランチに取得したブランチをマージすること – pull の後は特定条件下で省略可 ● push – ローカルリポジトリのコミットを指定したリモートリポジトリのブランチに反映させること – push の後は特定条件下で省略可 $ git pull origin master $ git push origin master

Slide 29

Slide 29 text

29 リモートリポジトリ - pull/push ● pull/push のデフォルト挙動はアップストリームの設定で変更可能 ● これで， pull/push の後を省略しても，ローカルの master ブランチで pull/push を行えば，自動的に origin の master へ pull/push されるようになる． ● アップストリームの設定確認は次のコマンドで可能 $ git branch -u origin/master master $ git branch -vv

Slide 30

Slide 30 text

30 リモートリポジトリ - 共同開発での利用 ● 共同開発では，サーバにリモートリポジトリを置いて，それを基軸に開発を進める – リモートリポジトリからクローンするか，又はローカルリポジトリからリモートリポジトリを作成 – 開発を進め，ローカルリポジトリにコミットを積む – 適切なタイミング（一日の開発の終わりや 1 つの機能実装，マージなど）でリモートにプッシュする – 次に開発を続きからやるときは，リモートからプルすることで他の人の開発進捗をローカルにとり込み開発を継続する ● このサイクルが Git リモートリポジトリを利用した開発の基本的な流れとなる

Slide 31

Slide 31 text

31 リモートリポジトリ - 共同開発での利用 ● Git で共同開発する典型的な作法のようなものはある – コミットは比較的小さい変更単位で行う ● 変更履歴の確認など様々な面で利点がある – トピックが違う開発を進めるときには，基本的にブランチを切る ● 頻繁に変更が衝突したり，実装途中のコードが master に混じったりさせないため – 頻繁に pull/push を行う ● 進捗管理ができ，相互にレビューもしやすくなるため，プロジェクト全体の効率向上に寄与する ● 細かい決まりはプロジェクトごとに取り決めると良い

Slide 32

Slide 32 text

32 GitHub の活用 Practical use of GitHub

Slide 33

Slide 33 text

33 GitHub の活用 - GitHub とは ● Git 向けリポジトリホスティングサービス ● リモートリポジトリのサーバを提供してくれるサービス ● 公開リポジトリであれば，無制限に作成可能 – 学生であれば非公開リポジトリも作成可能 ● 簡単に申し込めるのでオススメ ● 講座の後に、無料アカウントでも非公開リポジトリを作成できるようになりました。やったね！ ● これに加えて強力なソーシャル機能が加わる – GitHub の前のロゴには「 Social Coding 」とある

Slide 34

Slide 34 text

34 GitHub の活用 - Fork ● Fork は既存のリポジトリのコピーを自分のアカウントに追加できる ● 既存のリポジトリのコピーを自分のリポジトリとして扱える – 自由にコードの改変ができるようになる ● そのまま元のリポジトリとは別の派生プログラムとして開発を続けることも可 ● Fork したリポジトリから，元のリポジトリの管理者に PullRequest を投げることで，自分の改変を元のリポジトリに取り込んでもらうことも可

Slide 35

Slide 35 text

35 GitHub の活用 - Issue ● 直訳すると「問題」 ● GitHub では，ソースコードの行やコミットに対して問題点を別に記述し，共有することができる – これを Issue と呼ぶ ● 共同開発でのコミュニケーションや実装課題の管理に非常に便利 – 個人で ToDo 管理などに利用している例も見る ● GitHub のリポジトリを開いて，上部のタブから Issues を開くことで見られる

Slide 36

Slide 36 text

36 GitHub の活用 - Issue

Slide 37

Slide 37 text

37 GitHub の活用 - Issue ● 基本的な利用の流れは次のようになる – タイトル，問題点など議論すべきことを書いて，必要に応じて Assignees （担当者）と Label を付加して， Issue を発行する – 以降，この Issue に関係するコミットには Issue 番号をコミットメッセージに書いてコミットすると良い – 必要に応じて Issue にコメントをつけていくことで，議題について話し合うことができる – Issue の議題が解消されれば， Close する ● この辺の慣習も詳細はプロジェクトごとに取り決めて，開発者全員で共有すると良い

Slide 38

Slide 38 text

38 GitHub の活用 - Issue ● コメントに @ アカウント名 /@ 組織名を含めると通知を送れる ● Issue の対応が終わるコミットのコミットメッセージを – fix #Issue 番号 – closed #Issue 番号 – resolved #Issue 番号などにすると，自動で Issue を閉じることもできる ● 他にも色々な機能があるので，調べてみて欲しい

Slide 39

Slide 39 text

39 GitHub の活用 - PullRequest ● PullRequest は Issue にコミットを付加したもの ● リポジトリの管理者に，別ブランチや別リポジトリの変更を該当リポジトリに取り込んでもらう為に使う ● 基本機能は Issue と一緒 ● PullRequest の強い点は，他の人が簡単に開発に関与できるようになること – 他の人が改善したソースコードを送ってきたり – 自分が他の人に改善したソースコードを送ったり ● これらの開発コミュニケーションを円滑にしてくれる

Slide 40

Slide 40 text

40 GitHub の活用 - PullRequest ● PullRequest が飛んできたら – 飛んできた PR からコミットの変更点をレビュー – 必要に応じてコミュニケーションを取る – 問題がなさそうであればマージ ● 他人のソースコードを変更したくなったら – Fork する or ブランチを切る – 変更をする – 元リポジトリの管理者に対して PullRequest を発行 – コミュニケーションを取りつつ，マージしてもらう

Slide 41

Slide 41 text

41 GitHub の活用 ● 他にも開発者を支援する機能が沢山あります – Projects – Wiki – Insights ● 詳細な説明は省きますが，調べてみてください – 活用できるといいですね！

Slide 42

Slide 42 text

42 GitHub Pages を使ってみよう Try to use GitHub Pages

Slide 43

Slide 43 text

43 GitHub Pages を使ってみよう ● ここからは Git/GitHub に触れてみよう！のコーナー – 多分 Git は実際に触って慣れたほうが早い – 慣れれば便利なので使うようになる ● 多分 ● ここでは，プロジェクトの Web サイトを公開するのに利用できる「 GitHub Pages 」の機能を利用して，自分のホームページを作りながら， Git/GitHub に親しんでいきましょう

Slide 44

Slide 44 text

44 GitHub Pages を使ってみよう ● 大まかな手順 – 「 [ 自分のアカウント名 ].github.io 」という名前でリモートリポジトリを作成 – index.html という名前で HTML ファイルを作成 – GitHub 上のリモートリポジトリにプッシュ – http://[ 自分のアカウント ].github.io/ にアクセス！　　　　　　　　　　 Success!

Slide 45

Slide 45 text

45 GitHub Pages を使ってみよう ● 詳しい手順例 $ mkdir [ アカウント名 ].github.io $ cd [ アカウント名 ].github.io $ git init $ echo “Hello, world!” > index.html $ git add index.html $ git commit -m “init commit” $ git remote add origin [email protected]: 　 [ アカウント名 ]/[ アカウント名 ].github.io $ git push origin master

Slide 46

Slide 46 text

46 GitHub Pages を使ってみよう ● わからないコマンドはスライドを振り返るとだいたい書いてあります – ググりをするなどして解決しても良い – その方がいいか…… ● 公式にいい手順紹介ページがあります – https://pages.github.com/ ● とりあえず使ってみよう！ – 慣れが大事な印象です