Git講習会

趣旨
 Gitについて、基本を学習していきます
 Git、およびWebサービスGitHubは、学校での学習にお
いても、社会に出てからのお仕事でも、使う頻度の高い
ツールになります
 一端は「授業の前提知識として」のGitの知識を学習して
いきましょう

バージョン管理システムとは？
 「変更履歴」がないと困る
 「誰が」「いつ」「どのように」修正したかの経緯が必要な時が
ある
 「コメントによる」変更履歴
 読みにくい(特に量が増えると後半、極端に可読性が落ちる)、
全体を通しての差分がわかりにくい
 例 →
// 20170325 古庄修正start
//$hoge = hoge();
// 20170901 鵜沢修正start
//$hoge = hoge(1);
$hoge = hoge(2);
// 20170901 鵜沢修正end
// 20170325 古庄修正end

 「ファイル/ディレクトリのバックアップによる」変更履歴
 ファイルが増える、差分が解らない、命名を間違えると「どれ
が最新かわからない(例：新しい.xls、より新しい.xls、最新.xls、
更新した最新.xls、最新より新しい.xls、新しい最新.xls)」
 「日付(＋ナンバリング)」にすればマシだが、差分は相変わら
ずある程度不明
 「細かい巻き戻し」はできない事が多い(か、極端にファイルや
ディレクトリが増えるか)
 バージョン管理による変更履歴
 バージョン管理システムにもよるが基本「差分が見やすい」よ
うに出来ているので、わかりやすい
 細かい巻き戻しなども可能

 バージョン管理システムがないと「なぜ」困る？メリット
は？
 過去の状態や変更内容を確認
 変更前の状態を復元することが容易
 同一ファイルに対する変更が競合するなどの問題を防ぐ(防ぎ
方は色々)
 バージョン管理は「プログラムが多い」が、設定ファイル
や原稿など、様々なものもバージョン管理できるし、便利
でメリットがある
 「テキストファイル」が多く、バイナリファイル(画像、動画など)
を適切に差分管理できるものはあまりない

デグレード(degrade)の恐怖
 直接的には「grade(等級、階級、品等、グレード)」に「de-
(離れる、下がる等を意味する接頭語)」がついた言葉
 実例：特にバージョン管理システムを使っていない場合
(コメントによる変更履歴、は使ってみる)
 次Pageで、図解

大本の記述1
大本の記述2
大本の記述3
Aさ
ん
ソースコード管理サーバ：とあるファイル
大本の記述1
大本の記述2
大本の記述3
AさんPC：とあるファイル
//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3

大本の記述1
大本の記述2
大本の記述3
Bさ
ん
大本の記述1
大本の記述2
大本の記述3
BさんPC：とあるファイル
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3

大本の記述1
大本の記述2
大本の記述3
Aさ
ん
//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3
//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3

//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3
Bさ
ん
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3

 本当は望まれているはず、のソースコード
 「Aさんの修正」と「Bさんの修正」が双方とも適切に反映され
ている
 実際のサーバのソースコード
//大本の記述1
大本の記述1-A
//大本の記述2
大本の記述2-B
大本の記述3
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3

 質問
 「Aさんが修正した」修正→
 どこに消えた？？？
現在のサーバのソース↓
 これがデグレードです
 絶対厳禁！！
//大本の記述1
大本の記述1-A
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3

 デグレードを防ぐためにはどうすればよいか？
 いくつか方法がありますが(後述)、そのために「バージョ
ン管理システム」と呼ばれるツールがあります
 今日、メインで学ぶGitは、バージョン管理システムの一
つ、になります

バージョン管理システムの簡単な歴史
 SCCS(Source Code Control System)
 世界初のバージョン管理システム。1972年に出来た。
 RCS(Revision Control System)
 1982年に作られたバージョン管理システム。ファイル単位で管理を
行い、軽い。
 CVS(Concurrent Versions System)
 1990年に作られた。当初はRCSをベースにしていたらしい。(RCS
やSCCSと異なり)「ネットワーク越し」に使えるシステムだったので、
一時期、割とよく使われていた。
 SVN(Subversion / Apache Subversion)
 2000年に作られた。のちに(2009年)にApacheプロジェクトに入った
ので、名前の頭にApacheがつくようになる。
CVSでいくつかある難点を補うために作られた。会社等によっては
今でも現役。

 VSS(Visual SourceSafe / Microsoft Visual
SourceSafe)
 2005年作成。Microsoft Visual Studioによるアプリケーション
開発において使用することに主眼をおいたバージョン管理シ
ステム。
現在はサポートが終了しており、TFS(Team Foundation
Server)が後続になっている
 Mercurial
 2005年作成。Gitと一時期、覇を競っていた時期がある。現状
でもGitとMercurialは「互いの機能を取り入れつつ開発が進
んでいる」。ただし、Gitよりはマイナー。

 Git
 2005年作成。元々は「Linuxカーネルのソースコード管理に用
いるためにリーナス・トーバルズによって開発された」という逸
話をもつバージョン管理システム(ちなみに、Git開発以前は
BitKeeperというバージョン管理システムが使われていた)。
各ユーザのワーキングディレクトリに「全履歴を含んだリポジ
トリの完全な複製が作られる」ために「ネットワークにアクセス
できないなどの理由で中心リポジトリにアクセスできない環境
でも、履歴の調査や変更の記録といったほとんどの作業を行
うことができる」のが大きな特徴にしてメリット。
現在、バージョン管理ソフトとしてはおそらく「もっともよく使わ
れている」。

バージョン管理で使われる用語の簡単な説明
 注意
 いきなり「全部覚える」のは難しいと思うので、必要に応じて読み返
すようにしてください
 リポジトリ
 概ね「ファイル一式」。１プロジェクトあたり１リポジトリ、が比較的多
いが「複数プロジェクトで１リポジトリ」「１プロジェクトで複数リポジト
リ」も、ケースとしては存在する
 チェックアウト
 リポジトリからソースコードを取り出す事。バージョン管理システムに
よっては「一人がチェックアウトをしたら、ほかの人はチェックアウト
できないようにする」事で「１つのファイルを複数人で同時に修正す
る(デグレード)」を抑止する(後述の「ロック方式」参照)。
 今回メインで学習するGitにはこの概念は存在しない。

 ロック方式
 デグレを防ぐために「一人がチェックアウトしたら、ほかの人は
チェックアウトできない」ようにしてファイルを守る方法。
シンプルだが、状況等によっては「効率が悪い」事がある。
今回メインで学習するGitにはこの概念は存在しない。
 コピー・マージ方式
 同一ファイルでも「明らかに異なる行への修正」であれば、コ
ンピュータ側である程度把握して自動的に変更分を足していく
方法。
多人数でもある程度まで「同時に同一のファイルを触れる」の
で効率的だが、「コンピュータ側で自動で判断できない」状況
になれば最終的には人力に頼る事になるので、過信は禁物。
今回メインで学習するGitはこのパターン。

 バージョン番号、コミットID
 ある１回の「変更」に対して割り振られる番号。「バージョン番
号」の場合は比較的「1や1.1などの整数」から始まってインク
リメントされる事が多い。
「コミットID」の場合は「他とぶつからないユニークでランダム
(に見える)文字列」である事が多い。
今回メインで学習するGitはコミットIDが用いられている。
 タグ
 「この時点での変更(バージョン番号、コミットID)」に対して入
れる、しおりのようなもの。
あってもなくてもよいが、「あるとわかりやすい」ケースも多い
ので、折に触れてタグを打つ事、も多い。

GitHubについて
 Gitを使いますが、同時にGitHubも少し使っていきます
(授業で使う事が多いので)。
 Git
 バージョン管理システム
 GitHub
 「Gitを使う事ができて、リモートにHDDがある」Webサービス。
 Gitが持つ本来の機能以外に、いくつか独自の機能も持って
いる
 認証機能
 Issues、 Pull Requests、wiki など

 GitHubを使う場合のリポジトリ関連図(「こうでなければ
いけない」わけではないが、大抵、こういう感じになりや
すい)
Aさ
ん Bさ
ん
Aさん
PC
Bさん
PC
GitHub
色々な人

 GitHubを使う事によって
 多人数でも開発が出来る
 GitHubの場合「ほかの人にソースを見てもらう事ができる/提
供できる」
 なお、単純に「Gitのみ」で開発をしたり(それでも「多人数
で開発が出来る」というメリットは享受できる)、GitHubと
似たような機能を持つOSS(GitLabなど)もあるので、興
味があったら色々と調べてみましょう！！

OSSについて少し
 Open-source software / オープンソースソフトウェア
 ソフトウェアを、学習、変更、そして配布するための権利
を提供するというライセンスに基づいたソフトウェア
 端的には、Linuxがそうで、Gitがそうで、様々なOSSを
我々は使っている
 GitHubを使うと「ソフトウェアを配布する」ための環境が、
(ライセンスによっては)無料で手に入る

GitHubアカウントを作成する
 Gitを学習する一貫として、GitHubを使った実習をします
 また、授業で使う事なども増えてくると思います
 ですので、GitHubアカウントを作成しましょう
 画面は2017年9月のものです
 まず
https://github.com/
をブラウザで開きます。以降、手順を説明していきます
 「後でまとめてやる」と、途中でつまづきます。
集中して、しっかりと手順を一緒に追いかけてください

 https://GitHub.com/
 [Sign up]をclick
 Username、Email Address、Passwordを入力：Usenameは
重複不可。なので「すでに使われている」アカウントの場合、
「Username is already taken」と出る
 [Create an account]をclick
 Choose your plan
 [Unlimited public repositories for free.]を選択(有料でも止
めはしないけど、"後で変更"出来るので、一端は無料でよい
でしょう)
 [Continue]をClick

 アンケートへの入力はお好みで。
 下に[skip this step]があるので、skipしてもよし。
 登録したメールアドレスを確認する。
 Gitからmailが来ているはずなので、メールの中にあるリ
ンク(Verify email address)をclickして、メールアドレスの
認証を終了させる。
 [Start a project]のボタンを押すとレポジトリの作成画面
になる。
 一端作成せず、ここまでで「GitHubのアカウント登録」の
完了。

Gitの「きわめて簡単な」使い方
 まずはGitを「とても簡単に」少しづつ使っていきます
 必要に応じて、パワーポイントを見直して復習をして、反復練
習をするように意識しましょう

準備
 レポジトリ用のディレクトリの準備
 コマンドプロンプト(cmd.exe)を立ち上げます
cd C:
mkdir git_work
cd git_work
(エクスプローラでやってもよいですが、後でコマンドプロンプト
は使います)
 もし「サブディレクトリまたはファイル git_work は既に存在し
ます。」というエラーが出た場合は
rmdir /S git_work
で削除してから上述を実行してください。
 エクスプローラでも同じディレクトリ(C:git_work)を開い
ておいてください
 エクスプローラ設定「隠しファイルの表示」「拡張子の表示」

「新しいレポジトリ」を作成、ファイルを１つ
 コマンドプロンプトで以下を打ち込みます
 git init
 [エクスプローラでテキストファイルを作成： README.txt]
 [README.txtを修正] test1
 git add README.txt
 git config --local user.name "自分の名前"
 localの前のハイフンは「二つ」なので注意
 お仕事等だと「 --global」が多いが、今回は共有PCなので、localで
 スペースが必要なので注意！！
 git config --local user.email "自分のメールアドレス"
 git commit -a -m "first commit"

 git init
 「新しいレポジトリ」を作成します
 git add
 指定したファイルを「gitの管理対象」にします
 git config
 色々な設定をします。今回は「自分の名前」と「連絡先」を登録
しました(後で出てきます)
 git commit
 変更をgitに登録します

ファイルの中身を修正して、commitする
 git commit -a -m 'second commit'
 git log
 git log --oneline
 git log --stat
 git log --graph --oneline

 git log
 gitの変更履歴を表示します。様々なオプションがあります
 前Pageで出てきたオプションは、全部「ハイフン２つ」です

「どこを変更したか」確認をしてからcommit
 git diff
 git commit -a -m '3rd commit'

 git diff
 「最後にcommitした」後、どこに変更があったかを教えてくれ
ます
 実際にはそれ以外にも「色々な"２点"の比較」が出来ます

 今までは「AさんPC(local)」のみでgitを扱ってきました
Aさ
ん
Aさん
PC

 次は「GitHub(remote)とAさんPC(local)」でgitを扱って
いきましょう
Aさ
ん
Aさん
PC
GitHub

事前準備
 Windowsの場合で、かつ共有PCの場合「認証情報」が
残っている可能性があるので、確認して削除しましょう
(以下は、Windows 10の場合)
 コントロールパネル
→ユーザーアカウント
→資格情報の管理
→Windows 資格情報
 汎用認証情報に「git:https://github.com」があったら
 →削除する

レポジトリをGitHubに公開する
 先に、ブラウザから「必要な文字列」を探し出しておきま
しょう

 git remote add origin https://github.com/XX/test.git
 git push -u origin master
 ブラウザをリロードして「GitHubにソースコードが上がっ
ている事」の確認

 git remote add origin https://github.com/XX/test.git
 「origin」という名前に「 https://github.com/XX/test.git 」のリ
モートレポジトリを紐づける、という意味合い(下で使う)
 git push -u origin master
 "git push [リモートリポジトリ] [ローカルのブランチ名]：[リ
モートのブランチ名]"が、正式
 git push https://github.com/XX/test.git master：master
 git push origin master：master
 git push origin master
 -uは「一端、あまり気にしない」

ファイルを修正して、pushする
 git commit -a -m "4th commit"
 ブラウザでGitHub(リモート)のレポジトリをみて「まだ反映されて
いない」事を確認する
 ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい
る」事を確認する

「別の人(Bさん)」として当該レポジトリを取得
 次は「BさんPC(local)」でgitを扱っていきましょう
Aさ
ん
Bさ
ん
Aさん
PC
Bさん
PC
GitHub

 cd C:
mkdir git_work2
cd git_work2
 git clone https://github.com/[アカウント名]/test.git
 コンソールから「cd test」
または
エクスプローラで「C:git_work2test」
で、ファイルの存在を確認する
 git config --local user.name "自分の名前(別名で)"
 git config --local user.email "自分のメールアドレス(連
絡先)"

(Bさんとして)ファイルを修正
 git commit -a -m “5th commit"
 ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい
る」事を確認する

「Bさんが修正したファイル」を、Aさん(元の
人)が受け取る
 cd C:git_work
 git log
 [README.txt]を確認、まだ「test3」のままである事を確
認する
 git pull
 git log
 [README.txt]を確認、先ほどの「Bさんの修正」が反映
されている事を確認する

 git pull
 "git pull [リモートリポジトリ] [リモートのブランチ名]"が、正
式
 git pull https://github.com/XX/test.git master
 git pull origin master
 git pull

一端まとめ
 Git等のバージョン管理ツールは、このようにして「変更
履歴」を管理します
 まずは「一人で」プロジェクトのソースコードをGit管理し
て、ゆっくりと慣らしていくとよいでしょう
 慣れてきたら複数人数で。その場合はできれば「ブラン
チを使った開発」をした方がよりよいので、このPPTで後
述してある内容を、自分なりに学習してみましょう
 最後に整理(ディレクトリの削除)
 C:git_workとC:git_work2を、ディレクトリごと削除しましょう
 アカウント情報を削除しましょう

付録：多人数で開発するときのコツ
 作業を細かく分けてこまめにcommit
 「１作業」毎にcommit
 なので、こまめなcommitのタイミングでpull
 rebaseは好みが分かれるので、環境やほかの人と相談
しつつ。大体「がっつり使う」か「まったく使わない」か、の
二極化。現場で確認しましょう
 branchを使う(できれば定期的にリモートにもbranchを
push)
 ぶつかったら諦めて手動merge。その時に「他人の修正
をつぶしたり壊したりしない」用に気を付けよう

付録： .gitignoreファイルについて
 「管理対象にしたくないファイル」を登録できるファイル
 例えば、以下のようなファイルを登録しておくと、便利な
事も多いでしょう
 .DS_Store等の「OSが作っている」ファイル
 *.oのような「コンパイル用オブジェクト」ファイル
 ログファイル
 「他から持ってきている」ライブラリ群
 「空ディレクトリ」の保持には、 .gitkeep でもよいのです
が「対象ディレクトリに.gitignoreを置く」方法もあります
 *
!.gitignore

付録：公開鍵について
 「毎回、IDとパスワードを入力」するのも手間なので。
GitHubでは「SSHの公開鍵をGitHubに登録し、認証さ
せる」事ができます
 「公開鍵と秘密鍵(公開鍵暗号方式)」を使う認証は、イン
フラの世界では(ある程度以上しっかりしたところであれ
ば)比較的一般的なので。
興味があったら、調べてみてください。
(学校のPC環境なら、使えるはずです)

付録：ブランチについて学ぶ(操作例)
 「一つの例」程度ですが、参考にしつつ、色々と自力で調
べたりしてみましょう
 # 先に「手元のレポジトリを最新にしておく」
 git pull
 # 現在見ているブランチがmaster(またはそれ以外の適
切なブランチ：git flow準拠ならdevelop)であることを一
度確認しておく
 git branch

 # 作業用ブランチを切って移動する
 # git branch ブランチ名
 # git checkout ブランチ名
 git checkout -b ブランチ名
 # 移動できたことを確認
 git branch
 # 修正等作業：作業完了してmergeできるところまでもっ
てこれた
 git commit -a

ブランチ：「リモートにアップしてpull
request等をする」流れの場合
 # リモートにアップする
 git push origin ブランチ名
 # レビュー等をしてもらう
 (mergeはおそらく「レビューをしてくれた人」がしてくれる)
 # merge後、リモートのブランチを削除する(ブランチ名の前
に：を付けると「削除」の意味)(削除してくれている、かも)
 git push origin :ブランチ名
 # localのブランチを削除する
 git branch -d ブランチ名
 git branch
 終了

ブランチ：「自分でmergeする」流れの場合
 # 「mergeしてOK」になったら
 # master(またはそれ以外の適切なブランチ：git flow準
拠ならdevelop)に移動する：コマンド例はmasterである
と仮定
 git checkout master
 git branch
 # レポジトリを最新の状態にしてから、mergeする
 git pull
 git merge ブランチ名

 # local masterの内容をリモートに反映する
 # localのブランチを削除する
 git branch -d ブランチ名
 git branch
 終了

付録：様々な開発方法の一例/ GitHub flow
 使用するブランチ
 master：「デプロイ可能」なブランチ
 topicブランチ：作業用のブランチ群。命名は決まっていない
 下準備
 masterブランチを用意します

 新しい機能の開発や修正、緊急のバグフィックス対応
 masterから新しいブランチを作成する
 git checkout -b ブランチ名
 新しいブランチ上で追加や修正の作業を行う
 リモートのブランチに、定期的にpushをしておく事が推奨されている
 Pull Request、merge を行う
 Pull Request → masterへmerge
 masterに入ったものは、いつdeployされてもよい、とみなす
 定期的、或いは即時、といったdeployタイミングが多いと思います

付録：様々な開発方法の一例/ Git flow
 使用するブランチ
 master：リリースするためのブランチ。リリース後、タグを切る
 develop：開発ブランチ。開発する時の元ネタ
 featuresブランチ群：実際に作業をしているブランチ群
 hotfixesブランチ群：リリース後の「クリティカルなバグ」などに
対応するためのブランチ群
 releases ブランチ群：リリースの準備用のブランチ群
 下準備
 masterブランチを用意します
 masterブランチからdevelopブランチを作成します

 新しい機能の開発や修正
 developから新しいfeatureブランチを作成する
 "feature/ブランチ名"という命名が多いです
 feature上で追加や修正の作業を行う
 以下の作業をします
 local上で、featureブランチをdevelopにmergeします
 developブランチをremoteにpushします
 push後、localのfeatureブランチは削除します

 リリース(deploy)準備
 developブランチからreleaseブランチを作成
 "release/リリース名"という命名が多いです
 必要であれば、 releaseブランチに修正を加えます
 リリースの準備が完了したら、以下の作業を行います
 releaseブランチをmasterにmergeして、pushします
 masterブランチにリリース用のタグをつけます(こちらもpush)
 releaseブランチの内容をdevelopブランチにmergeして、pushしま
す
 releaseブランチを削除します
 masterブランチの内容をリリース(deploy)します

 緊急のバグフィックス対応
 masterブランチからhotfixeブランチを作成
 "hotfixe/ホットフィックス名"という命名が多いです
 修正が終わったら、以下の作業をします
 hotfixeブランチをmasterにmergeします
 masterブランチに「緊急対応した」旨のタグをつけます
 hotfixeブランチをdevelopにmergeします
 hotfixeブランチを削除します
 masterブランチの内容をリリース(deploy)します

Git講習会

More Related Content

What's hot (20)

Similar to Git講習会 (20)

More from galluda (9)

Git講習会