Basic lecture of Git and GitHub 2021

Slide 1

Slide 1 text

Git/GitHub基礎講座 cordx56

Slide 2

Slide 2 text

事前準備 ❖ 講座を受講する前に、次の事前準備を行っておくとよいでしょう ➢ Linux環境の構築 ■ 詳しくはWSL2講座で ■ Ubuntuを利用する場合は20.04を利用してください！ ● 比較的新しいバージョンの gitを使いたいため ➢ gitのインストール ■ UbuntuやDebianの場合 $ sudo apt update $ sudo apt install -y git ➢ GitHubアカウントの作成 ■ https://github.com/join からアカウントを作成してください ● Usernameは自分のハンドルネームなど好きなものを入力してください 2

Slide 3

Slide 3 text

事前準備 ❖ 講座を受講する前に、次の事前準備を行っておくとよいでしょう ➢ Gitの設定 ■ 次のコマンドを実行してくださいユーザ名とメールアドレスは GitHubに登録したものを使ってください $ git config --global user.name “ユーザ名” $ git config --global user.email “メールアドレス” 3

Slide 4

Slide 4 text

目次 - 前編 ❖ 導入 ➢ Gitとは ➢ バージョン管理システムとは ❖ Gitの仕組み ➢ リポジトリ（repository） ➢ コミット（commit） ➢ ステージングエリア（ staging area） ➢ ブランチ（branch） ➢ マージ（merge） 4

Slide 5

Slide 5 text

目次 - 後編 ❖ リモートリポジトリを使った開発 ➢ リモートリポジトリの意義 ➢ クローン（clone） ➢ プル / プッシュ（pull / push） ➢ 共同開発での利用 ❖ GitHubの活用 ➢ GitHubとは ➢ Fork ➢ Issue ➢ Pull Request ➢ その他の機能 ❖ GitHub Pagesを使ってみよう 5

Slide 6

Slide 6 text

導入 6 Introduction of Git

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

バージョン管理システムとは ❖ プログラミングをしていると、ソースコードの変更を細かく記録しておきたいことはよくある ➢ もう使わないけど残しておきたいコードをコメントアウトして残しておいたり ■ これは可読性を下げる原因になる ➢ 前は動いていたコードが急に動かなくなったり ■ 過去のコードを参照したくなるのはよくある話 ➢ 古いバージョンからの変更点がわからなくなったり 8

Slide 9

Slide 9 text

バージョン管理システムとは ❖ バージョン管理システムを活用すると、手動でのバージョン管理で消耗する必要がなくなる ❖ バージョン管理システムのログを叩けば、変更点と変更日時、添えられたコメントを見ることができる ➢ いらないコードをコメントアウトで残す必要がなくなる ❖ 過去のソースコードまでさかのぼって、過去のソースコードの途中から開発を進めたり、変更を細かく追ったりすることもできる ➢ よりわかりやすい形で過去の状態を参照できる 9

Slide 10

Slide 10 text

バージョン管理システムとは ❖ この辺の利点は特に共同開発で強い味方になる ❖ バージョン管理システムをうまく使うことで、各自の変更点が明確になったり、こまめにソースコードを集約できたりして、共同開発のコストを減らせる 10

Slide 11

Slide 11 text

バージョン管理システムとは ❖ ここまでをまとめると今日からはバージョン管理システムを使ってうまく開発しよう 11

Slide 12

Slide 12 text

Gitの仕組み 12 Terms and Behavior of Git

Slide 13

Slide 13 text

リポジトリ（repository） ❖ ソースコードのバージョンを管理するデータベース単位 ❖ ローカルとリモートの2種類がある ❖ ローカルリポジトリ ➢ 開発者のパソコンにある、手元でいじるリポジトリ開発者が手元で作業するためのもの ❖ リモートリポジトリ ➢ サーバ上にある、遠隔から管理するリポジトリ共同開発で共有して利用できる 13

Slide 14

Slide 14 text

リポジトリ（repository） ❖ 開発者はリモートからリポジトリをクローンするか、ローカルでリポジトリを作成して、ローカルリポジトリとする ❖ クローンしてきたリポジトリの場合、既にリモートリポジトリとの紐づけがされている ➢ クローンはダウンロードみたいな意味、詳しくは後述 ❖ ローカルリポジトリに対してリモートリポジトリは名前を付けて複数紐づけることができる ➢ デフォルトではoriginという名前が使われる ❖ リモートリポジトリは複数人で共同で開発を行うときに特に活用する 14

Slide 15

Slide 15 text

リポジトリ（repository） ❖ 新しいディレクトリを作成し、ローカルリポジトリを初期化 $ mkdir ユーザ名.github.io $ cd ユーザ名.github.io $ git init ➢ 「ユーザ名」には自分の GitHubのユーザ名を入れてください ❖ リモートリポジトリとの紐づけには、git remote addコマンドを利用する ➢ 後編で説明 15

Slide 16

Slide 16 text

コミット（commit） ❖ ファイルの変更とそれに対するコメントをリポジトリに記録すること ❖ コミットがGitで管理される変更の最小単位 ➢ 関数の実装や小さなバグ修正など、比較的小さな単位の変更に切り分けてコミットをすることが推奨される ❖ コミットはステージングエリアに登録されている変更を記録する ➢ ステージについては次のスライドで解説 16

Slide 17

Slide 17 text

ステージングエリア（staging area） ❖ 次にコミットする対象となる変更を登録する場所 ❖ git addコマンドを利用して、ファイルの変更をステージングに乗せる ➢ これをステージするという ❖ すべての変更の中から特定の変更をステージングエリアに乗せる / 乗せないをわけることで、どの変更をコミットに乗せるかを選択することができる 17

Slide 18

Slide 18 text

ステージ & コミット（stage & commit） ❖ （index.htmlファイルを作成する） $ echo “Hello, world!” > index.html ❖ index.htmlファイルの変更をステージする $ git add index.html ❖ ステージされたすべての変更にコメントをつけてコミットする $ git commit -m “Hello, world!” ➢ -mはコミットメッセージをコマンド中で明示してコミットする、というオプション ➢ -m以降をつけずにコミットすると、テキストエディタが起動して、長いコミットメッセージを入力することができる 18

Slide 19

Slide 19 text

ブランチ（branch） ❖ 本流から分かれる枝のイメージ ❖ ブランチ間でのコードの変更は共有されない ➢ ブランチを分けることで本流の開発や同時進行するトピックが別の開発に影響を与えずに開発を進めることができる ❖ 特に共同開発の場面では、異なるトピックについて同時に同じコードをいじると、混乱が発生する ➢ トピックごとにブランチを分けて、実装が終わった段階で本流にマージするのが一般的 19

Slide 20

Slide 20 text

ブランチ（branch） ❖ ブランチのイメージはこんな感じ ➢ masterブランチに対して様々な分岐が生えている様子が確認できる 20

Slide 21

Slide 21 text

ブランチ（branch） ❖ ブランチ作成（ここではブランチ名をtestとする） $ git branch test ❖ ブランチを移動 $ git switch test ❖ ブランチ作成 & 移動（上記2ステップを一括実行） $ git switch -c test2 ❖ ファイルを変更してコミットしてからブランチを移動すると、他のブランチではファイル変更の影響を受けていない様子が確認できる ➢ 次のスライドで実際に確認してみる 21

Slide 22

Slide 22 text

ブランチ（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

Slide 23

Slide 23 text

マージ（merge） ❖ ブランチ間のコードの差異を吸収し、一つのブランチにまとめること ❖ git mergeコマンドは今いるブランチに指定したブランチの変更を取り込む ❖ マージコミットを作ることができる ➢ マージしましたよ、というコミットのこと ❖ 自動で吸収できない差異があった場合（二つのブランチでコードの同じ位置を更新していた場合など）、コンフリクトが発生し、手動でどちらのコードにまとめるか決定してコミットする必要がある 23

Slide 24

Slide 24 text

マージ（merge） ❖ masterブランチにtest2ブランチをマージ $ git switch master $ git merge test2 ❖ 上のコマンドでは、場合によってはマージコミットが生成されない ➢ 常にマージコミットの生成を強制する（ Fast-Forwardマージをしないようにする）には以下のコマンドを利用する $ git switch master $ git merge --no-ff test2 24

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

リモートリポジトリの意義 ❖ 集中型ではリポジトリは常にサーバ上にあり、複数のリポジトリが存在しないため各種操作が簡単な反面、ソースコードの取得、変更に常にサーバとの通信を必要とする ❖ 分散型では複数のリポジトリを利用するため、各種操作が複雑になりがちだが、サーバとの通信は最終的に変更をリモートリポジトリに反映させたい時のみでいい ➢ ローカルで作業可能 ➢ 複数のリポジトリを使うため、中央のリポジトリに変更を加えず手元のリポジトリに変更を加えることができる ■ ソーシャルコーディングの普及 ● 詳しくはGitHubについての章で説明します 27

Slide 28

Slide 28 text

クローン（clone） ❖ 既存のリモートリポジトリをローカルリポジトリとしてダウンロードすること ❖ 既存プロジェクトに参加する場合や、別のコンピュータで作業を開始するときに行う ❖ 下記コマンドはクローンの例、講座中は実行しなくて大丈夫です $ git clone https://github.com/cordx56/cordx56.github.io 28

Slide 29

Slide 29 text

プル / プッシュ（pull / push） ❖ プル（pull） ➢ 指定したリモートリポジトリのブランチを取得し、ローカルリポジトリの今いるブランチに取得したブランチをマージすること ❖ プッシュ（push） ➢ ローカルリポジトリのコミットを指定したリモートリポジトリのブランチに反映させること 29

Slide 30

Slide 30 text

共同開発での利用 ❖ 共同開発では、サーバにリモートリポジトリを置いて、それを基軸に開発を進める ➢ リモートリポジトリからクローンするか、またはローカルリポジトリからリモートリポジトリを作成 ➢ 開発を進め、ローカルリポジトリにコミットをしていく ➢ 適切なタイミング（実装の区切りのいいところ、マージしてほしいところなど）でリモートにプッシュする ❖ この流れがGitでリモートリポジトリを利用した開発の基本的な流れとなる 30

Slide 31

Slide 31 text

共同開発での利用 ❖ Gitで共同開発する際の作法としては、次のような例が挙げられる ➢ コミットは比較的小さい変更単位で行う ■ 変更履歴が詳細に残るなど様々な面で利点がある ➢ トピックが違う開発を進めるときには、基本的にブランチを切る ■ 変更の衝突や実装途中のコードが masterに混じるのを防ぐため ❖ 細かい決まりはプロジェクトごとに取り決めると良い 31

Slide 32

Slide 32 text

GitHubの活用 32 Practical use of GitHub

Slide 33

Slide 33 text

GitHubとは ❖ Git向けリポジトリホスティングサービス ❖ リモートリポジトリのサーバを提供してくれるサービス ❖ 公開、非公開を問わず、無料でリポジトリを無制限に作成可能 ❖ これに強力なソーシャル機能が加わる 33

Slide 34

Slide 34 text

Fork ❖ Forkは既存のリポジトリのコピーを自分のアカウントに追加できる機能 ❖ 既存のリポジトリのコピーを自分のリポジトリとして扱える ➢ 自由にコードの改変ができるようになる ❖ 元のリポジトリとは別の派生プログラムとして開発を続けることもできる ➢ ただし、ライセンスには注意が必要 ❖ Forkしたリポジトリから、元のリポジトリの管理者にPull Requestを投げることで、自分の改変を元のリポジトリに取り込んでもらうこともできる ➢ Pull Requestについてはこの後解説 34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Issue ❖ コメントに @アカウント名を含めると通知を送れる ❖ Issueの対応が終わるコミットのコミットメッセージを以下のようにすると、自動でIssueを閉じることもできる ➢ ﬁx #Issue番号 ➢ close #Issue番号 ➢ resolved #Issue番号 ❖ 他にもいろいろな機能があるので、調べてみてほしい 37

Slide 38

Slide 38 text

Pull Request ❖ Pull RequestはIssueにソースコードを付加したもの ❖ リポジトリの管理者に、別ブランチや別リポジトリの変更を該当リポジトリに取り込んでもらうために使う ❖ 基本機能はIssueと一緒 ❖ Pull Requestの強い点は、他の人が簡単に開発に関与できるようになること ➢ 他の人が改善したソースコードを送ってきたり ➢ 自分が他の人に改善したソースコードを送ったり ❖ これらの開発コミュニケーションを円滑にしてくれる ➢ これがGitが分散型である恩恵のうちの一つ 38

Slide 39

Slide 39 text

Pull Request ❖ Pull Requestが飛んできたら ➢ 飛んできたPull Requestの変更点をレビュー ➢ 必要に応じてコミュニケーションを取る ➢ 問題がなさそうであればマージ ❖ 他人のソースコードを変更したくなったら ➢ Forkする or ブランチを切る ➢ 変更をする ➢ 元リポジトリに対して Pull Requestを発行 ➢ コミュニケーションを取りつつ、マージしてもらう 39

Slide 40

Slide 40 text

その他の機能 ❖ 他にも開発者を支援する機能がたくさんあります ➢ Projects ➢ Wiki ➢ Insights ❖ 詳細な説明は省きますが、調べてみてください ➢ 活用できるといいですね！ 40

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

GitHub Pagesを使ってみよう ❖ ここからは、プロジェクトのWebサイトを公開するのに利用できる「GitHub Pages」の機能を利用して、自分のホームページを作りながら、 Git/GitHubに慣れ親しんでいきましょう ❖ 大まかな手順 ➢ 「ユーザ名.github.io」という名前でGitHubにリポジトリを作成 ■ ユーザ名は自分のGitHubのユーザ名で置き換えてください ➢ index.htmlという名前でHTMLファイルを作成 ➢ GitHub上のリモートリポジトリにプッシュ ➢ http://ユーザ名.github.io/にアクセス 42

Slide 43

Slide 43 text

リモートリポジトリの作成 ❖ https://github.com/new にアクセス ❖ Repository nameに「ユーザ名.github.io」と入力 ➢ ユーザ名は自分のGitHubのユーザ名で置き換えてください ❖ それ以外は何も変更せずに（何にもチェックをつけず、Publicが選択されている状態で）Create repositoryボタンを押す 43

Slide 44

Slide 44 text

リモートリポジトリにプッシュ ❖ GitHubのリモートリポジトリをローカルリポジトリに関連付けてプッシュ $ git switch master $ git remote add origin https://github.com/ユーザ名/ユーザ名.github.io $ git push origin master ➢ ユーザ名は自分のユーザ名で置き換えてください ➢ プッシュの際にユーザ名とパスワードを聞かれるので、入力してください ❖ http://ユーザ名.github.io/にアクセスして確認 ➢ 反映まで少し時間がかかります 44

Slide 45

Slide 45 text

おわり ❖ わからないコマンドなどはスライドを振り返ると書いてあります ➢ ググったりしてもよい ■ その方がいいか…… ❖ とりあえず使ってみよう！ ➢ 慣れが大事な印象です 45