Basic lecture of Git & GitHub

Explanation of Git & GitHub for who use Git & GitHub for the first time. (in Japanese)

GitとGitHubの用語や使い方の解説。
GitとGitHubに初めて触れる方が対象です。
厳密な表現よりは初心者の理解を優先している旨を理解していただけると助かります（私が理解していないだけ）。
参考文献: https://www.amazon.co.jp/dp/B07JLJSDMJ/

予定していた日に講座が終わらなかったため、最終的に別日に2日かけて、前編後編各1時間程度で講座を行っています。
何か誤り等ございましたらご指摘頂ければ幸いです。
個人・公的機関での学習・講義用途であれば、本スライドはご自由にご利用いただいて構いません。いずれにせよ、利用に際してご連絡をいただけると有難いです。

Transcript

1. Git/GitHub 基礎講座 Kaoru @cordx56 cordx.net
2. 2 目次 - 前編 • 導入 – Git/ バージョン管理システムとは – Git の利点 • Git の仕組み – リポジトリ – branch – merge – commit – staging – pull/push
3. 3 目次 - 後編 • リモートリポジトリを使った開発 – clone – pull/push – 共同開発での利用 • GitHub の活用 – Fork – Issue/Pull Request – GitHub Pages を使ってみよう
4. 4 導入 Introduction of Git
5. 5 導入 - Git とは • バージョン管理システムの一種 • バージョン管理システムとは？ – コンピュータ上のファイルの変更履歴を管理するための システム – 場面にもよるが，こういった場で言うときは，大抵 ソースコードの管理をするためのもの バージョン管理システムがあると何が嬉しい？
6. 6 導入 - バージョン管理システムとは • プログラミングをしていると，ソースコードの変更を 細かく記録しておきたいことはよくある – 皆さんはもう使わないけど残しておきたいコードや 新しい実装をする前に念の為確実に動く古いコードを コメントアウトで残して可読性を下げたりしたことは ありませんか？ – あるいは， ver1.zip ，配布 .zip ，最新 .zip ， 08/26 最新 .zip とか，ソースコードをまとめて zip ファイルにして 結局混乱したり，古いバージョンからの変更点が わからなくなったことはありませんか？
7. 7 導入 - バージョン管理システムとは • バージョン管理システムを活用すると，こういった 手動でのバージョン管理で消耗する必要がなくなる • バージョン管理システムのログを叩けば， 変更点と変更日時，添えられたコメントを 見ることができる – いらないコードをコメントアウトで残す必要がなくなる • あるいは，一気に過去のソースコードまで遡って， 過去のソースコードの途中から開発を再開したり， 変更を細かく追ったりすることもできる – よりわかりやすい形で過去の状態を参照できる
8. 8 導入 - バージョン管理システムとは • この辺の利点は特に共同開発で強い味方になる • 共同開発だと，コードの同じ部分を同じタイミングで 編集してしまい，変更がだいぶ蓄積してから，じゃあ みんなのコードを一つにまとめましょうという段で， とてつもない量のコードがどんな変更を経てそうなった のかわからなくなってしまう例もある – 締切直前とかに手作業で問題が起きないように大量の コードを集約するのは地獄の図 • バージョン管理システムを上手く使うことで，各自の 変更点が明確になったり，こまめにソースコードを 集約できたりして，共同開発のコストを減らせる
9. 9 導入 - バージョン管理システムとは • ここまでをまとめると 今日からは バージョン管理システムを使って 上手く開発していこう
10. 10 Git の仕組み Terms and Behaviour of Git
11. 11 Git の仕組み - リポジトリ (repository) • ソースコードのバージョンを管理するデータベース単位 • ローカルとリモートの 2 種類がある • ローカルリポジトリ – 開発者のパソコンにある，手元でいじるリポジトリ 開発者が手元で作業するためのもの • リモートリポジトリ – サーバ上にある，遠隔から管理するリポジトリ 共同開発で共有して利用できる
12. 12 Git の仕組み - リポジトリ (repository) • 最初に，開発者はリモートからリポジトリをクローン して，あるいはローカルでリポジトリを作成して， 手元にあるローカルリポジトリとする • クローンしてきたリポジトリの場合， 既にリモートリポジトリとの紐づけがされている • ローカルでリポジトリを作成した場合は，リモートリポ ジトリを紐づけをする必要がある – リモートリポジトリには，デフォルトで origin という名前が使われる • リモートリポジトリは，複数人で共同で開発を行うとき に特に活用する
13. 13 Git の仕組み - リポジトリ (repository) • カレントディレクトリでローカルリポジトリ初期化 • リモートリポジトリとの紐づけ – git@github.com... の部分は適宜変更してください ( 後編で説明します ) $ git init $ git remote add origin git@github.com:SIT-DigiCre/idrs-slack
14. 14 Git の仕組み - branch • 本流から分かれる枝のイメージ • branch 間でコードの変更は共有されない – branch を分けることで，本流の開発， 同時進行するトピックが別の開発に影響を与えずに 開発を進めることができる • 特に共同開発の場面では，異なるトピックについて 同時に同じコードをいじると，混乱が発生することは 容易にわかる – トピックごとに branch を分けて，実装が終わった 段階で本流に merge するのが一般的
15. 15 Git の仕組み - branch • ブランチ作成 ( ここではブランチ名を impl-i2c とする ) • ブランチ移動 • ブランチ作成 & 移動 ( 上記 2 ステップを一括実行 ) • ファイルを変更してコミットしてからブランチを 移動すると，他のブランチではファイル変更の影響を 受けていない様子が確認できる $ git branch impl-i2c $ git checkout -b impl-i2c $ git checkout impl-i2c
16. 16 Git の仕組み - merge • branch 間のコードの差異を吸収し，一つの branch に まとめること • git merge コマンドは，今いる branch に，指定した branch の変更を取り込む • merge commit を作ることができる • 自動で吸収できない差異があった場合 (2 つの branch でコードの同じ位置を更新していた場合など ) ， conflict が発生し，手動でどちらのコードにまとめるか 決定して commit する必要がある
17. 17 Git の仕組み - merge • master ブランチに impl-i2c ブランチをマージ • 上のコマンドでは，場合によってはマージコミットが 生成されない – 常にマージコミットの生成を強制する (Fast-Forward マージをしないようにする ) には 以下のコマンドを利用する $ git checkout master $ git merge impl-i2c $ git checkout master $ git merge --no-ff impl-i2c
18. 18 Git の仕組み - commit • ファイルの変更とそれに対するコメントをリポジトリに 記録すること • コミットが Git で管理される変更の最小単位 – 関数の実装や小さなバグ修正など，比較的小さな 単位の変更に切り分けてコミットをすることが 推奨される ( コード変更の意図がわかりやすくなる， 頻繁に pull/push できるなどの理由が挙げられる ) • staging area に登録されている変更を記録 – stage については次のスライドで解説
19. 19 Git の仕組み - staging area • 次にコミットする対象となる変更を登録する場所 • git add コマンドを利用して，ファイルの変更を staging に乗せる = stage する • 全ての変更の中から特定の変更を staging area に 乗せる / 乗せないを分けることで，どの変更を 同じ commit に乗せるかを選択することができる
20. 20 Git の仕組み - stage & commit • main.py ファイルの変更をステージする • ステージされた全ての変更にコメントをつけて コミットする – -m はコミットメッセージをコマンド中で明示して コミットする，というオプション • -m をつけずにコミットすると，テキストエディタ が起動して，長いコミットメッセージを入力する ことができる • message の m $ git add main.py $ git commit -m “Implement I2C communication”
21. 21 Git の仕組み - pull/push • pull – 指定したリモートリポジトリのブランチを取得し， ローカルリポジトリの今いるブランチに取得した ブランチをマージすること • push – ローカルリポジトリのコミットを指定した リモートリポジトリのブランチに反映させること • pull と push は頻繁にしよう – 特に共同開発では， pull と push を怠るとトラブルが 発生しやすくなる
22. 22 リモートリポジトリを使った開発 Development with Git remote repository
23. 23 リモートリポジトリの意義 • Git は「分散型」と呼ばれる仕組みでバージョン管理を 行う – 対するのは「集中型」であり， SVN などがある – 集中型ではリポジトリは常にサーバ上にあるもの 1 つのみであり，開発者は常にサーバと通信をして ソースコードの取得，変更をする – 分散型ではサーバ上のリモートリポジトリ，手元の ローカルリポジトリなど，複数のリポジトリを利用 して開発を進める • 何故 2 つの方式があるのか？
24. 24 リモートリポジトリの意義 • 集中型ではリポジトリは常にサーバ上にあり，複数の リポジトリが存在しないため各種操作が簡単な反面， ソースコードの取得，変更に常にサーバとの通信を 必要とする – もしリポジトリを持つサーバが落ちてしまったら？ • GitHub もたまに落ちる • 分散型では複数のリポジトリを利用するため，各種操作 が複雑になりがちだが，サーバとの通信は最終的に 変更をリモートリポジトリに反映させたい時のみで良い – ローカルで ( サーバが落ちても ) 作業可能 – 手元の変更をよく検討してからリモートに送れる
25. 25 リモートリポジトリの意義 • Git は分散型 • 開発者は，基本的にローカルで行った変更をローカル リポジトリにコミットし，ある程度蓄積したところで リモートリポジトリにプッシュする – 常に通信が発生するわけではないので，効率が良い – リモートとローカルでリポジトリが分散している ため，リポジトリ操作等が必要になり，開発者は 多少複雑な操作をする必要がある – Git はブランチを切る，マージするためのコストが SVN に比べ非常に低く，気軽にブランチを切って開 発を進めやすいという利点がある．
26. 26 リモートリポジトリ - clone • 既存のリモートリポジトリをローカルリポジトリとして ダウンロードすること • 既存プロジェクトに参加する場合や，別のコンピュータ で作業を開始する時に行う – HTTP で clone( 認証不要 ) – SSH で clone( 要認証 ) $ git clone https://github.com/SIT-DigiCre/ idrs-slack/ $ git clone git@github.com:SIT-DigiCre/ idrs-slack/
27. 27 リモートリポジトリ - 新規作成 • 13 番スライドと同等の内容 • ローカルリポジトリを作成して，リモートリポジトリに origin と名前をつけて結びつける $ git init $ git remote add origin git@github.com:SIT-DigiCre/idrs-slack
28. 28 リモートリポジトリ - pull/push • pull – 指定したリモートリポジトリのブランチを取得し， ローカルリポジトリの今いるブランチに取得した ブランチをマージすること – pull の後は特定条件下で省略可 • push – ローカルリポジトリのコミットを指定した リモートリポジトリのブランチに反映させること – push の後は特定条件下で省略可 $ git pull origin master $ git push origin master
29. 29 リモートリポジトリ - pull/push • pull/push のデフォルト挙動はアップストリームの設定 で変更可能 • これで， pull/push の後を省略しても，ローカルの master ブランチで pull/push を行えば，自動的に origin の master へ pull/push されるようになる． • アップストリームの設定確認は次のコマンドで可能 $ git branch -u origin/master master $ git branch -vv
30. 30 リモートリポジトリ - 共同開発での利用 • 共同開発では，サーバにリモートリポジトリを置いて， それを基軸に開発を進める – リモートリポジトリからクローンするか，又は ローカルリポジトリからリモートリポジトリを作成 – 開発を進め，ローカルリポジトリにコミットを積む – 適切なタイミング（一日の開発の終わりや 1 つの 機能実装，マージなど）でリモートにプッシュする – 次に開発を続きからやるときは，リモートからプル することで他の人の開発進捗をローカルにとり込み 開発を継続する • このサイクルが Git リモートリポジトリを利用した開発 の基本的な流れとなる
31. 31 リモートリポジトリ - 共同開発での利用 • Git で共同開発する典型的な作法のようなものはある – コミットは比較的小さい変更単位で行う • 変更履歴の確認など様々な面で利点がある – トピックが違う開発を進めるときには，基本的に ブランチを切る • 頻繁に変更が衝突したり，実装途中のコードが master に混じったりさせないため – 頻繁に pull/push を行う • 進捗管理ができ，相互にレビューもしやすくなる ため，プロジェクト全体の効率向上に寄与する • 細かい決まりはプロジェクトごとに取り決めると良い
32. 32 GitHub の活用 Practical use of GitHub
33. 33 GitHub の活用 - GitHub とは • Git 向けリポジトリホスティングサービス • リモートリポジトリのサーバを提供してくれるサービス • 公開リポジトリであれば，無制限に作成可能 – 学生であれば非公開リポジトリも作成可能 • 簡単に申し込めるのでオススメ • 講座の後に、無料アカウントでも非公開リポジトリを 作成できるようになりました。やったね！ • これに加えて強力なソーシャル機能が加わる – GitHub の前のロゴには「 Social Coding 」とある
34. 34 GitHub の活用 - Fork • Fork は既存のリポジトリのコピーを自分のアカウント に追加できる • 既存のリポジトリのコピーを自分のリポジトリとして 扱える – 自由にコードの改変ができるようになる • そのまま元のリポジトリとは別の派生プログラムとして 開発を続けることも可 • Fork したリポジトリから，元のリポジトリの管理者に PullRequest を投げることで，自分の改変を元の リポジトリに取り込んでもらうことも可
35. 35 GitHub の活用 - Issue • 直訳すると「問題」 • GitHub では，ソースコードの行やコミットに対して 問題点を別に記述し，共有することができる – これを Issue と呼ぶ • 共同開発でのコミュニケーションや実装課題の管理に 非常に便利 – 個人で ToDo 管理などに利用している例も見る • GitHub のリポジトリを開いて，上部のタブから Issues を開くことで見られる
36. 36 GitHub の活用 - Issue
37. 37 GitHub の活用 - Issue • 基本的な利用の流れは次のようになる – タイトル，問題点など議論すべきことを書いて， 必要に応じて Assignees （担当者）と Label を付加 して， Issue を発行する – 以降，この Issue に関係するコミットには Issue 番号 をコミットメッセージに書いてコミットすると良い – 必要に応じて Issue にコメントをつけていくことで， 議題について話し合うことができる – Issue の議題が解消されれば， Close する • この辺の慣習も詳細はプロジェクトごとに取り決めて， 開発者全員で共有すると良い
38. 38 GitHub の活用 - Issue • コメントに @ アカウント名 /@ 組織名を含めると 通知を送れる • Issue の対応が終わるコミットのコミットメッセージを – fix #Issue 番号 – closed #Issue 番号 – resolved #Issue 番号 などにすると，自動で Issue を閉じることもできる • 他にも色々な機能があるので，調べてみて欲しい
39. 39 GitHub の活用 - PullRequest • PullRequest は Issue にコミットを付加したもの • リポジトリの管理者に，別ブランチや別リポジトリの 変更を該当リポジトリに取り込んでもらう為に使う • 基本機能は Issue と一緒 • PullRequest の強い点は，他の人が簡単に開発に関与 できるようになること – 他の人が改善したソースコードを送ってきたり – 自分が他の人に改善したソースコードを送ったり • これらの開発コミュニケーションを円滑にしてくれる
40. 40 GitHub の活用 - PullRequest • PullRequest が飛んできたら – 飛んできた PR からコミットの変更点をレビュー – 必要に応じてコミュニケーションを取る – 問題がなさそうであればマージ • 他人のソースコードを変更したくなったら – Fork する or ブランチを切る – 変更をする – 元リポジトリの管理者に対して PullRequest を発行 – コミュニケーションを取りつつ，マージしてもらう
41. 41 GitHub の活用 • 他にも開発者を支援する機能が沢山あります – Projects – Wiki – Insights • 詳細な説明は省きますが，調べてみてください – 活用できるといいですね！
42. 42 GitHub Pages を使ってみよう Try to use GitHub Pages
43. 43 GitHub Pages を使ってみよう • ここからは Git/GitHub に触れてみよう！のコーナー – 多分 Git は実際に触って慣れたほうが早い – 慣れれば便利なので使うようになる • 多分 • ここでは，プロジェクトの Web サイトを公開するのに 利用できる「 GitHub Pages 」の機能を利用して， 自分のホームページを作りながら， Git/GitHub に 親しんでいきましょう
44. 44 GitHub Pages を使ってみよう • 大まかな手順 – 「 [ 自分のアカウント名 ].github.io 」という名前で リモートリポジトリを作成 – index.html という名前で HTML ファイルを作成 – GitHub 上のリモートリポジトリにプッシュ – http://[ 自分のアカウント ].github.io/ にアクセス！ 　　　　　　　　　　 Success!
45. 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 git@github.com: 　 [ アカウント名 ]/[ アカウント名 ].github.io $ git push origin master
46. 46 GitHub Pages を使ってみよう • わからないコマンドはスライドを振り返るとだいたい 書いてあります – ググりをするなどして解決しても良い – その方がいいか…… • 公式にいい手順紹介ページがあります – https://pages.github.com/ • とりあえず使ってみよう！ – 慣れが大事な印象です