Basic lecture of Git and GitHub 2021

2021年度版Git/GitHub基礎講座です。
スライドのご利用は自由にどうぞ。
（事前に連絡をいただけるとありがたいです。連絡先は https://cordx.net/ よりご確認ください。）

Transcript

1. Git/GitHub基礎講座 cordx56
2. 事前準備 ❖ 講座を受講する前に、次の事前準備を行っておくとよいでしょう ➢ Linux環境の構築 ▪ 詳しくはWSL2講座で ▪ Ubuntuを利用する場合は20.04を利用してください！ • 比較的新しいバージョンの gitを使いたいため ➢ gitのインストール ▪ UbuntuやDebianの場合 $ sudo apt update $ sudo apt install -y git ➢ GitHubアカウントの作成 ▪ https://github.com/join からアカウントを作成してください • Usernameは自分のハンドルネームなど好きなものを入力してください 2
3. 事前準備 ❖ 講座を受講する前に、次の事前準備を行っておくとよいでしょう ➢ Gitの設定 ▪ 次のコマンドを実行してください ユーザ名とメールアドレスは GitHubに登録したものを使ってください $ git config --global user.name “ユーザ名” $ git config --global user.email “メールアドレス” 3
4. 目次 - 前編 ❖ 導入 ➢ Gitとは ➢ バージョン管理システムとは ❖ Gitの仕組み ➢ リポジトリ（repository） ➢ コミット（commit） ➢ ステージングエリア（ staging area） ➢ ブランチ（branch） ➢ マージ（merge） 4
5. 目次 - 後編 ❖ リモートリポジトリを使った開発 ➢ リモートリポジトリの意義 ➢ クローン（clone） ➢ プル / プッシュ（pull / push） ➢ 共同開発での利用 ❖ GitHubの活用 ➢ GitHubとは ➢ Fork ➢ Issue ➢ Pull Request ➢ その他の機能 ❖ GitHub Pagesを使ってみよう 5
6. 導入 6 Introduction of Git
7. Gitとは ❖ バージョン管理システムの一種 ❖ バージョン管理システムとは？ ➢ コンピュータ上のファイルの変更履歴を管理するためのシステム ➢ 場面にもよるが、こういった場で言うときは、大抵ソースコードの管理をするためのもの バージョン管理システムがあると何が嬉しい？ 7
8. バージョン管理システムとは ❖ プログラミングをしていると、ソースコードの変更を細かく記録して おきたいことはよくある ➢ もう使わないけど残しておきたいコードをコメントアウトして残しておいたり ▪ これは可読性を下げる原因になる ➢ 前は動いていたコードが急に動かなくなったり ▪ 過去のコードを参照したくなるのはよくある話 ➢ 古いバージョンからの変更点がわからなくなったり 8
9. バージョン管理システムとは ❖ バージョン管理システムを活用すると、手動でのバージョン管理で消耗する 必要がなくなる ❖ バージョン管理システムのログを叩けば、変更点と変更日時、 添えられたコメントを見ることができる ➢ いらないコードをコメントアウトで残す必要がなくなる ❖ 過去のソースコードまでさかのぼって、過去のソースコードの途中から 開発を進めたり、変更を細かく追ったりすることもできる ➢ よりわかりやすい形で過去の状態を参照できる 9
10. バージョン管理システムとは ❖ この辺の利点は特に共同開発で強い味方になる ❖ バージョン管理システムをうまく使うことで、各自の変更点が明確に なったり、こまめにソースコードを集約できたりして、共同開発のコストを 減らせる 10
11. バージョン管理システムとは ❖ ここまでをまとめると 今日からは バージョン管理システムを 使ってうまく開発しよう 11
12. Gitの仕組み 12 Terms and Behavior of Git
13. リポジトリ（repository） ❖ ソースコードのバージョンを管理するデータベース単位 ❖ ローカルとリモートの2種類がある ❖ ローカルリポジトリ ➢ 開発者のパソコンにある、手元でいじるリポジトリ 開発者が手元で作業するためのもの ❖ リモートリポジトリ ➢ サーバ上にある、遠隔から管理するリポジトリ 共同開発で共有して利用できる 13
14. リポジトリ（repository） ❖ 開発者はリモートからリポジトリをクローンするか、 ローカルでリポジトリを作成して、ローカルリポジトリとする ❖ クローンしてきたリポジトリの場合、既にリモートリポジトリとの紐づけが されている ➢ クローンはダウンロードみたいな意味、詳しくは後述 ❖ ローカルリポジトリに対してリモートリポジトリは名前を付けて複数 紐づけることができる ➢ デフォルトではoriginという名前が使われる ❖ リモートリポジトリは複数人で共同で開発を行うときに特に活用する 14
15. リポジトリ（repository） ❖ 新しいディレクトリを作成し、ローカルリポジトリを初期化 $ mkdir ユーザ名.github.io $ cd ユーザ名.github.io $ git init ➢ 「ユーザ名」には自分の GitHubのユーザ名を入れてください ❖ リモートリポジトリとの紐づけには、git remote addコマンドを利用する ➢ 後編で説明 15
16. コミット（commit） ❖ ファイルの変更とそれに対するコメントをリポジトリに記録すること ❖ コミットがGitで管理される変更の最小単位 ➢ 関数の実装や小さなバグ修正など、比較的小さな単位の変更に切り分けてコミットを することが推奨される ❖ コミットはステージングエリアに登録されている変更を記録する ➢ ステージについては次のスライドで解説 16
17. ステージングエリア（staging area） ❖ 次にコミットする対象となる変更を登録する場所 ❖ git addコマンドを利用して、ファイルの変更をステージングに乗せる ➢ これをステージするという ❖ すべての変更の中から特定の変更をステージングエリアに乗せる / 乗せない をわけることで、どの変更をコミットに乗せるかを選択することができる 17
18. ステージ & コミット（stage & commit） ❖ （index.htmlファイルを作成する） $ echo “Hello, world!” > index.html ❖ index.htmlファイルの変更をステージする $ git add index.html ❖ ステージされたすべての変更にコメントをつけてコミットする $ git commit -m “Hello, world!” ➢ -mはコミットメッセージをコマンド中で明示してコミットする、というオプション ➢ -m以降をつけずにコミットすると、テキストエディタが起動して、 長いコミットメッセージを入力することができる 18
19. ブランチ（branch） ❖ 本流から分かれる枝のイメージ ❖ ブランチ間でのコードの変更は共有されない ➢ ブランチを分けることで本流の開発や同時進行するトピックが別の開発に影響を与えずに 開発を進めることができる ❖ 特に共同開発の場面では、異なるトピックについて同時に同じコードを いじると、混乱が発生する ➢ トピックごとにブランチを分けて、実装が終わった段階で本流にマージするのが一般的 19
20. ブランチ（branch） ❖ ブランチのイメージはこんな感じ ➢ masterブランチに対して様々な分岐が生えている様子が確認できる 20
21. ブランチ（branch） ❖ ブランチ作成（ここではブランチ名をtestとする） $ git branch test ❖ ブランチを移動 $ git switch test ❖ ブランチ作成 & 移動（上記2ステップを一括実行） $ git switch -c test2 ❖ ファイルを変更してコミットしてからブランチを移動すると、 他のブランチではファイル変更の影響を受けていない様子が確認できる ➢ 次のスライドで実際に確認してみる 21
22. ブランチ（branch） ❖ 既存のファイル（index.html）にテキストを追記してコミット、内容を表示 $ echo “Hello, git!” >> index.html $ git add index.html $ git commit -m “Hello, git!” $ cat index.html ❖ ブランチ一覧を表示する $ git branch ❖ ブランチを移動して、ファイルの中身が変わっていることを確認 $ git switch master $ cat index.html 22
23. マージ（merge） ❖ ブランチ間のコードの差異を吸収し、一つのブランチにまとめること ❖ git mergeコマンドは今いるブランチに指定したブランチの変更を取り込む ❖ マージコミットを作ることができる ➢ マージしましたよ、というコミットのこと ❖ 自動で吸収できない差異があった場合（二つのブランチでコードの 同じ位置を更新していた場合など）、コンフリクトが発生し、 手動でどちらのコードにまとめるか決定してコミットする必要がある 23
24. マージ（merge） ❖ masterブランチにtest2ブランチをマージ $ git switch master $ git merge test2 ❖ 上のコマンドでは、場合によってはマージコミットが生成されない ➢ 常にマージコミットの生成を強制する（ Fast-Forwardマージをしないようにする）には 以下のコマンドを利用する $ git switch master $ git merge --no-ff test2 24
25. リモートリポジトリを使った開発 25 Development using Git remote repository
26. リモートリポジトリの意義 ❖ Gitは「分散型」と呼ばれる仕組みでバージョン管理を行う ➢ 対するのは「集中型」であり、 SVNなどがある ➢ 集中型ではリポジトリは常にサーバ上にあるもの一つのみであり、開発者は常にサーバと 通信をしてソースコードの取得、変更をする ➢ 分散型ではサーバ上のリモートリポジトリ、手元のローカルリポジトリなど、 複数のリポジトリを利用して開発を進める ❖ なぜ分散型のGitを使うのか？ 26
27. リモートリポジトリの意義 ❖ 集中型ではリポジトリは常にサーバ上にあり、複数のリポジトリが存在 しないため各種操作が簡単な反面、ソースコードの取得、変更に常に サーバとの通信を必要とする ❖ 分散型では複数のリポジトリを利用するため、各種操作が複雑になりがち だが、サーバとの通信は最終的に変更をリモートリポジトリに反映させたい 時のみでいい ➢ ローカルで作業可能 ➢ 複数のリポジトリを使うため、中央のリポジトリに変更を加えず手元のリポジトリに変更を 加えることができる ▪ ソーシャルコーディングの普及 • 詳しくはGitHubについての章で説明します 27
28. クローン（clone） ❖ 既存のリモートリポジトリをローカルリポジトリとしてダウンロード すること ❖ 既存プロジェクトに参加する場合や、別のコンピュータで作業を開始する ときに行う ❖ 下記コマンドはクローンの例、講座中は実行しなくて大丈夫です $ git clone https://github.com/cordx56/cordx56.github.io 28
29. プル / プッシュ（pull / push） ❖ プル（pull） ➢ 指定したリモートリポジトリのブランチを取得し、ローカルリポジトリの今いるブランチに 取得したブランチをマージすること ❖ プッシュ（push） ➢ ローカルリポジトリのコミットを指定したリモートリポジトリのブランチに反映させること 29
30. 共同開発での利用 ❖ 共同開発では、サーバにリモートリポジトリを置いて、それを基軸に開発を 進める ➢ リモートリポジトリからクローンするか、またはローカルリポジトリから リモートリポジトリを作成 ➢ 開発を進め、ローカルリポジトリにコミットをしていく ➢ 適切なタイミング（実装の区切りのいいところ、マージしてほしいところなど）で リモートにプッシュする ❖ この流れがGitでリモートリポジトリを利用した開発の基本的な流れとなる 30
31. 共同開発での利用 ❖ Gitで共同開発する際の作法としては、次のような例が挙げられる ➢ コミットは比較的小さい変更単位で行う ▪ 変更履歴が詳細に残るなど様々な面で利点がある ➢ トピックが違う開発を進めるときには、基本的にブランチを切る ▪ 変更の衝突や実装途中のコードが masterに混じるのを防ぐため ❖ 細かい決まりはプロジェクトごとに取り決めると良い 31
32. GitHubの活用 32 Practical use of GitHub
33. GitHubとは ❖ Git向けリポジトリホスティングサービス ❖ リモートリポジトリのサーバを提供してくれるサービス ❖ 公開、非公開を問わず、無料でリポジトリを無制限に作成可能 ❖ これに強力なソーシャル機能が加わる 33
34. Fork ❖ Forkは既存のリポジトリのコピーを自分のアカウントに追加できる機能 ❖ 既存のリポジトリのコピーを自分のリポジトリとして扱える ➢ 自由にコードの改変ができるようになる ❖ 元のリポジトリとは別の派生プログラムとして開発を続けることもできる ➢ ただし、ライセンスには注意が必要 ❖ Forkしたリポジトリから、元のリポジトリの管理者にPull Requestを投げる ことで、自分の改変を元のリポジトリに取り込んでもらうこともできる ➢ Pull Requestについてはこの後解説 34
35. Issue ❖ 直訳すると「問題」 ❖ GitHubでは問題点などを記述し共有することができる ➢ これをIssueと呼ぶ ❖ 共同開発でのコミュニケーションや実装課題の管理に非常に便利 ➢ 個人でToDo管理などに利用している例も見る ❖ GitHubのリポジトリを開いて、上部のタブからIssuesを開くことで 見られる 35
36. Issue ❖ 基本的な利用の流れは次のようになる ➢ タイトル、問題点など議論すべきことを書いて、必要に応じ Assignees（担当者）とLabelを 付加して、Issueを発行する ➢ 以降、このIssueに関係するコミットには #Issue番号をコミットメッセージに書いて コミットするとよい ➢ 必要に応じてIssueにコメントを付けていくことで、議題について話し合うことができる ➢ Issueの議題が解消されれば、 Closeする ❖ この辺の慣習も詳細はプロジェクトごとに取り決めて、開発者全員で 共有すると良い 36
37. Issue ❖ コメントに @アカウント名 を含めると通知を送れる ❖ Issueの対応が終わるコミットのコミットメッセージを以下のように すると、自動でIssueを閉じることもできる ➢ fix #Issue番号 ➢ close #Issue番号 ➢ resolved #Issue番号 ❖ 他にもいろいろな機能があるので、調べてみてほしい 37
38. Pull Request ❖ Pull RequestはIssueにソースコードを付加したもの ❖ リポジトリの管理者に、別ブランチや別リポジトリの変更を 該当リポジトリに取り込んでもらうために使う ❖ 基本機能はIssueと一緒 ❖ Pull Requestの強い点は、他の人が簡単に開発に関与できるようになること ➢ 他の人が改善したソースコードを送ってきたり ➢ 自分が他の人に改善したソースコードを送ったり ❖ これらの開発コミュニケーションを円滑にしてくれる ➢ これがGitが分散型である恩恵のうちの一つ 38
39. Pull Request ❖ Pull Requestが飛んできたら ➢ 飛んできたPull Requestの変更点をレビュー ➢ 必要に応じてコミュニケーションを取る ➢ 問題がなさそうであればマージ ❖ 他人のソースコードを変更したくなったら ➢ Forkする or ブランチを切る ➢ 変更をする ➢ 元リポジトリに対して Pull Requestを発行 ➢ コミュニケーションを取りつつ、マージしてもらう 39
40. その他の機能 ❖ 他にも開発者を支援する機能がたくさんあります ➢ Projects ➢ Wiki ➢ Insights ❖ 詳細な説明は省きますが、調べてみてください ➢ 活用できるといいですね！ 40
41. GitHub Pagesを使ってみよう 41 Try to use GitHub Pages
42. GitHub Pagesを使ってみよう ❖ ここからは、プロジェクトのWebサイトを公開するのに利用できる 「GitHub Pages」の機能を利用して、自分のホームページを作りながら、 Git/GitHubに慣れ親しんでいきましょう ❖ 大まかな手順 ➢ 「ユーザ名.github.io」という名前でGitHubにリポジトリを作成 ▪ ユーザ名は自分のGitHubのユーザ名で置き換えてください ➢ index.htmlという名前でHTMLファイルを作成 ➢ GitHub上のリモートリポジトリにプッシュ ➢ http://ユーザ名.github.io/にアクセス 42
43. リモートリポジトリの作成 ❖ https://github.com/new にアクセス ❖ Repository nameに「ユーザ名.github.io」と入力 ➢ ユーザ名は自分のGitHubのユーザ名で置き換えてください ❖ それ以外は何も変更せずに（何にもチェックをつけず、Publicが選択されて いる状態で）Create repositoryボタンを押す 43
44. リモートリポジトリにプッシュ ❖ GitHubのリモートリポジトリをローカルリポジトリに関連付けてプッシュ $ git switch master $ git remote add origin https://github.com/ユーザ名/ユーザ名.github.io $ git push origin master ➢ ユーザ名は自分のユーザ名で置き換えてください ➢ プッシュの際にユーザ名とパスワードを聞かれるので、入力してください ❖ http://ユーザ名.github.io/にアクセスして確認 ➢ 反映まで少し時間がかかります 44
45. おわり ❖ わからないコマンドなどはスライドを振り返ると書いてあります ➢ ググったりしてもよい ▪ その方がいいか…… ❖ とりあえず使ってみよう！ ➢ 慣れが大事な印象です 45