はじめてのGit

社内向けに作成した資料を公開します。
新人研修の資料としても使えるよう、バージョン管理システムそのものの説明も入れていますが、主にこれまでVSS・SVNなど他のバージョン管理システムを使っていた人を対象に「なぜGitを使うのか？」「Gitは他のバージョン管理システムと何が違うのか」をテーマに「分散型リポジトリ」「ブランチ」を中心にGitの考え方を説明しています。

一部社内の事情を踏まえた表現・内容もありますがご容赦ください。

Transcript

1. はじめてのGit 2018/12/27 業務支援グループ d_hirayama
2. もくじ 1. Gitとは 2. Gitの何がそんなにいいのか 3. Gitのツール 4. 「分散型」を理解しよう 5. ブランチを使ってこそGit 6. SourcetreeでGitを使おう -初級編- 1. クローン 2. プル 3. チェックアウト 4. ブランチ作成その１ 5. ブランチ作成その２ 6. ブランチの切替 7. ステージ 8. コミット 9. プッシュ 10. マージ 11. 破棄
3. 1.Gitとは
4. Wikipediaより • Git（ギット）は、プログラムのソースコードなどの変更履歴 を記録・追跡するための分散型バージョン管理システムである。 Linuxカーネルのソースコード管理に用いるためにリーナス・ トーバルズによって開発され、それ以降ほかの多くのプロジェ クトで採用されている。Linuxカーネルのような巨大プロジェ クトにも対応できるように、動作速度に重点が置かれている。 現在のメンテナンスは濱野純 (Junio C Hamano) が担当してい る。
5. バージョン管理システム？ • ファイルの作成日時、変更日時、変更点などの履歴を保管する システム。 • ソース管理ツールとか構成管理ツールと呼ぶこともある。
6. 何のために使うのか？ 最新ファイル一式しか無いと・・・ • バグが見つかったときにいつ混入したバグかわからない • 変更後に問題が見つかったときに前の状態に戻したり参考にし て修正することができない • いかにも不要に思える処理があってもいつ、誰が、何のために 入れたかわからないと消しづらい。（実は必要なのかも） • 複数人で作業したときに何が最新かよくわからなくなる • 複数人で作業すると簡単にソースが壊れる
7. 色々なバージョン管理システム • 共有フォルダ 日付や人別にフォルダを作成 • VSS(Microsoft Visual Source Safe) VisualStudio2005までの標準ツール • CVS(Concurrent Versions System> 1990年に作成されたフリーウェア • SVN(Apache SubVersion) CVSの問題点を解決すべく開発された • Git
8. 広く使われるGit • Visual StudioもGitに標準対応 https://docs.microsoft.com/ja-jp/visualstudio/version- control/?view=vs-2017 • 多くのOSSが公開されるGitHubももちろんGit JavaEE,Spring,サクラエディタ,VSCodeやEdgeも。 • PaaSのHerokuではHeroku内のGitにソースをpushするだけで Webサービスが稼働させることができる
9. https://docs.microsoft.com/ja-jp/visualstudio/version-control/?view=vs-2017 VSでもMS製のツールより先に説明がある
10. 2.Gitの何がそんなにいいの？ バージョン管理システムの比較
11. 共有フォルダ • お手軽簡単 • わかりやすい • バックアップも楽 • 本当に状態が維持できている保証 がない（ファイル足りてないかも。 うっかり誰か触ってるかも） • 複数人が同時作業するとマージが 辛い(WinMerge使うとはい え・・・） • どんどん増えがち(日付付きフォ ルダ) • 差分がわかりづらい(WinMerge) • 容量多くなりがち（コンパイル後 ファイルは入れないで！） • コメントつけにくい
12. VSS • 「誰が」「いつ」「何を」 「なぜ」変更したかわかる！ • 変更差分だけを管理するため 容量が減らせる • ある時点の状態のソースを取 り出せる (↑ここまで以降省略) • ファイルをロックするので共 同作業しても壊す心配がない。 わかりやすい。 • 複数ファイルを1回でコミッ トできる • ロックするので同時に作業できな い • ロックしたまま帰らないで！！！ • Windowsでしか使えない • 有償(Visual Studio Professional に同梱) • 既に開発終了
13. CVS • ファイルロックしないので同 時作業も可能 • リポジトリがほぼ元のテキス トファイルのままなので簡単 に見れる • フリーウェア！！！ • 複数ファイルを１まとまりと してコミットできない。（１ ファイルずつの連続したコ ミットになる） • 文字コードが危険
14. SVN • 複数ファイルを１まとまりで コミットできる • 文字コードも大丈夫 • フリーウェア！！！ • 複数バージョンの並行管理 （本番環境用、検証環境用、 開発環境用、障害対応中）が 辛い • マージがしんどい • リポジトリにつながらないと コミットできない
15. Git • 強力なブランチ機能 • 複数バージョンの並行管理も楽 • 複数案件の並行作業も安心 • 分散型なのでローカルでもコ ミットできる • マージが楽 • GitHub等のリポジトリサービ スが使える • 従来のものと考え方が違うと ころがあるので、最初全然わ からない。怖い • Git自体には権限管理機能が無 いので誰でもmasterが触れて しまう • リポジトリにはバイナリで保 存されてるのでツール使った りコマンド叩かないとソース 見れない
16. • 従来のものと考え方が違うと ころがあるので、最初全然わ からない。怖い • Git自体には権限管理機能が無 いので誰でもmasterが触れて しまう • リポジトリにはバイナリで保 存されてるのでツール使った りコマンド叩かないとソース 見れない この資料で解決！ Gitbucketなら管理できる！ GitbucketならWebで見れ る！
17. 比較 VSS CVS SVN Git 価格 有償 フリー フリー フリー ハードル 低い 低め 低め ﾁｮｯﾄﾀｶｲ ファイルロック ロックする しない しない しない 一括コミット できる できない できる できる ブランチ機能 なし サブフォルダ方式 サブフォルダ方式 リポジトリで管理 ソース自体を入替 集中/分散 集中型 集中型 集中型 分散型 リポジトリのソー ス バイナリ テキスト バイナリ バイナリ 管理対象 ファイル テキストファイル ファイル 行 マージ 衝突しない！ 辛い 辛い わりと自動でいけ る コミット番号 連番 連番 連番 ハッシュ
18. 3.Gitのツール Gitを使うためのツール
19. Git / Git for windows • Gitそのもの https://git-scm.com/ • Windows用のGit https://gitforwindows.org/ • これさえインストールすればGitが使える！ • CUIツールなのですべてコマンドラインで実行
20. Sourcetree • ATLASSIAN製のGit(とMercurial)用GUIツール https://ja.atlassian.com/software/sourcetree • 無料！（素敵！） • 操作ももちろん楽だが、ブランチの可視化ができて見やすい！ • 基本的なことはSourcetreeがあればできる！ • ダウンロードして使い始めるにはアカウントが必要 • アカウントの認証メールはHTMLで見る必要あり（Becky!だと 注意！）
21. GitHub • Web上のGitリポジトリサービス • アカウントを作れば(無料)自分のリポジトリが作れる • ブラウザでソースも履歴も見れる、ソース一式をZipダウン ロードもできる • 権限管理、Issue管理、PullRequest、Wikiなどの機能がある • 現在はMicrosoft傘下 • 類似サービスにBitbucket(ATLASSIAN),GitLab
22. Gitbucket • GitHubを模したフリーウェア https://github.com/gitbucket/gitbucket/releases • 自前でGitHubのようなサービスを立てられる • ブラウザでソースも履歴も見れる、ソース一式をZipダウン ロードもできる • 権限管理、Issue管理、PullRequest、Wikiなどの機能がある • デザインはGitHubとちょっと違う(GitHubに指摘された為)
23. 4.「分散型」を理解しよう Gitの基本その１。まずはここをしっかり理解しよう
24. 集中型リポジトリ • ソースコードとその履歴を管理す るデータベースのことを「リポジ トリ」という • VSS、CVS、SVNはいずれも集中 型なのでサーバーだけにリポジト リがある
25. 分散型リポジトリ • Gitは分散型リポジトリ • サーバーだけでなくローカル(自分の PC)にもリポジトリがある • サーバーにつながらなくても作業可能 • サーバーを使わずローカルだけで管理 することも可能 (とりあえず作業するときに便利) • もしサーバーが壊れてもローカルから 履歴も含めて簡単に復元できる
26. リポジトリの種類・呼び方 リポジトリの種類を指す言葉 • 中央リポジトリ(ベアリポジトリ) 作業フォルダを持たないバイナ リの管理情報だけのリポジトリ ≒リモートリポジトリ • ノンベアリポジトリ 作業フォルダのあるリポジトリ ≒ローカルリポジトリ リポジトリの場所を指す言葉 • リモートリポジトリ 自分のPC以外のリポジトリ。 • ローカルリポジトリ 自分のPCのリポジトリ
27. 分散型ならではの操作 • プル(pull) リモートリポジトリの変更を ローカルリポジトリに反映する PCに引っ張って来る • プッシュ(push) ローカルリポジトリの変更を リモートリポジトリに反映する サーバーに押し込む プル プッシュ
28. 基本的な作業の流れ 1. リモートリポジトリの最新をプルする 2. ローカルで作業(ファイルを変更) 3. 変更をローカルリポジトリにコミット （確定） 4. 変更をリモートリポジトリにプッシュ ※コミットしただけではサーバーに反映さ れないことに注意！！！ 1.プル 2.作業 3.コミット 4.プッシュ
29. 5.ブランチを使ってこそGit Gitの基本その２。ここが理解できればGit使い！
30. ブランチとは？ • 幹(trunk)から分かれた枝(branch) ※Gitではtrunkと言わずmasterブランチという • ソースコードの履歴の枝分かれ • 各ブランチは独立して互いに影響しない • リモートにもローカルにも作れる commit commit commit init commit commit commit commit commit commit
31. ブランチが無いと？ • 異なる作業を１つの履歴で管理しないといけない 1 2 新画面レイアウト master 3 表示処理実装 4 緊急バグ対応 5 更新処理実装 差分を抜き出して本番に反映 ３で変更した共通処理でしか正しく動かない！！！
32. ブランチがあれば？ • それぞれのブランチの作業が完了する毎に反映(マージ)する develop (開発用ソース) master (本番用ソース) 新機能作成 バグ対応 新画面レイアウト 表示処理実装 緊急バグ対応 merge 更新処理実装 merge merge merge DBの接続先を本番用に変更 テスト テスト
33. ブランチの使い方（環境） • 管理したい環境ごとのブランチを必要に応じて作成・管理 • これにより本番環境にはどの変更が入ってる、検証環境には先 にこれを入れる、などが管理できる 開発(develop) 機能追加 本番(master) 検証(stage)
34. ブランチの使い方（作業） • ソースコードを触るときは基本的に作業用のブランチを作成す る 通常はdevelopから枝分かれさせる • 作業が完了したら元のブランチにマージ • 元のブランチに変更があれば先に変更内容を作業ブランチに マージ develop 機能追加A 機能追加B バグ対応
35. つまりこんな感じ develop 機能追加A 機能追加B バグ対応 master stage バグ対応だけリリース バグ対応と機能追加Aを検証中 全部入れてテスト中
36. マージの注意その１ • マージする前にマージ先の最新コミットをマージしよう (先の例では便宜上省略) • 同じファイルに対して変更があるとコンフリクト(競合・衝突) が発生し、編集が必要な場合がある • マージ先の最新の状態に対する差分になるようにする develop 機能追加A 機能追加B マージ前にすり合わせ
37. マージの注意その２ • ブランチのマージ作業もまずはローカルリポジトリでやる • マージが完了してからリモートリポジトリにプッシュする • ※誰がやるべきかはまた別の話（各メンバー？リーダー？） 3.プッシュ 2.マージ作業 1.プル
38. ブランチを切り替えると何が起きるか？ • 現在のブランチを切り替えると実際のフォルダ、ファイルが置 き換わる
39. • IDEを開き直す必要が無い 最近のIDEはGitに対応しており自動的に再読み込みする • 再コンパイル(リビルド)を忘れないように • ファイルの更新日時は参考にならなくなるので注意 ファイル自体が書き換わるので・・・
40. 6.SourcetreeでGitを使おう -初級編- Sourcetreeを使ったGitの基本的な操作を覚える！
41. 1.クローン • リモートリポジトリのソースコードを 基にローカルリポジトリを作成する
42. 1 2 3 4 このURLをコピーする (Gitbucketの場合) 1. 新しいタブでCloneを選択 2. 対象のリポジトリを入力 3. 保存するフォルダ、ローカルでのリポジト リ名を入力 4. 「クローン」をクリック
43. 完成！
44. 2.プル • リモートリポジトリのソースコードを ローカルリポジトリに反映する
45. 1 2 3 1. 「プル」をクリック 2. プルしたいリモートリポジトリのブランチ を選択 3. 「OK」をクリック
46. 3.チェックアウト（リモート） • リモートリポジトリのブランチをロー カルリポジトリにも作る
47. 1 2 3 1. 「リモート」からチェックアウトしたいブラ ンチを選択 2. 対象のブランチを右クリック 3. 「〇〇をチェックアウト」をクリック 4. 「新規ブランチを作成してチェックアウト」 で「OK」 4
48. 完成！
49. 4.ブランチ作成その１ • ローカルリポジトリにブランチを作成 • 基本のやり方
50. 2 3 4 1 1. 元となるブランチに切替 （参照「5.ブランチの切り替え」） 2. 「ブランチ」をクリック 3. 任意のブランチ名を入力 4. 「ブランチを作成」をクリック
51. 完成！ ブランチを作成した時点では元となるブランチと 全く同じ状態。 この後コミットしていくことで別物になっていく。
52. 5.ブランチ作成その２ • Git Flowを使ってブランチを作成 • Git Flowはブランチ名を定番の名前で作 るための補助機能 • やり方が違うだけでブランチを作るのは その１と全く同じ
53. まずは下準備・・・ 1 2 1. 「Git Flow」をクリック 2. デフォルトのまま「OK」をクリック
54. 下準備完了！(見た目は何も変わらない) この下準備は各ローカルリポジトリ毎に1度だけやればOK
55. 1 2 1. 再度「Git Flow」をクリック 2. 「新規フィーチャーを開始」をクリック
56. 3 4 5 3. 任意のフィーチャー名(ブランチ名)を入力 4. 「ここから」は通常はデフォルトのまま 「最新の開発ブランチ」を選択 5. 「OK」をクリック
57. 完成！
58. 「フィーチャー」？ feature。「機能」とか「価値」などの意味。 ユーザーにとって意味のあるひとまとまりの作業。 例えば「画面の見た目だけ作ったけど動かない」ではフィーチャー が完了したとはいえない。 運用上はどこまでできたらdevelopにマージするかがポイントなの で、プロジェクトで取り決めればOK 「リリース」と「ホットフィックス」 リリースはdevelopからmasterにマージするための中間作業をする ためのブランチを作る。特になければいきなりmasterにdevelopを マージしてしまえばOK ホットフィックスが緊急バグ対応用のブランチでmasterからブラン チを作成しmasterとdevelopに反映する。
59. 6.チェックアウト(ブランチの切り替え) • 作業するブランチを切り替える • Gitの機能としてはこれも「チェックアウト」になる • チェックアウト＝ あるブランチ(コミット)のファイルをディレクトリに持ってく る
60. 1 1. 切り替えたいブランチを ダブルクリック 1 2 または 1. 切り替えたいブランチを右クリック 2. 「〇〇をチェックアウト」をクリック
61. 完了！
62. 7.ステージ - コミットの準備 • 追加、変更、削除した内容をステージ状態にする。（ステージ ング） • ステージ状態になっている変更だけがコミットの対象となる • １ファイルの中でもこの行はステージ、この行はステージしな い、ということも可能 • 変更行のかたまりを「Hunk」という • ステージの取消（アンステージ）も簡単にできる
63. 1 2 3 1. 「ファイルステータス」タブを表示 2. 追加、変更、削除があれば自動的に一覧 される (表示されないときは「F5」で再読込) 3. ステージするものを行選択して「選択を インデックスに追加」 すべてステージするなら「全てインデッ クスに追加」
64. 完了！ アンステージするときは「インデックスから除く」をする
65. 8.コミット • ステージした変更を確定する • バージョン管理システムの核となる 最も重要な作業 • VSSやSVNと違ってローカルPCでの作業なの で多少は気楽にやっても大丈夫
66. 1 3 2 4 5 6 1. コミット対象がステージされているか？ 2. 内容は間違いないか？ 3. ステージ漏れがないか？ 4. ユーザー情報が正しいか？ 5. コミットコメントを記載 6. すぐにプッシュして大丈夫か？
67. 7 7. コミット
68. 完了！
69. コミットコメントには何を書くべきか？ Gitではいわゆる５Ｗ１Ｈがそれぞれ次のように記録される WHO - 著者・auther(ユーザー情報) WHAT - ステージしたファイル一覧 WHEN - コミットした日時 HOW - 変更前後の内容 WHEREとWHYは自動的に記録されない。どこで作業をしたかが重要なことはあまりないので通常は 記載する必要はないため、「なぜその変更を行ったか」をコミットコメントに記載するのが最も重要 となる。 例えば「顧客要望により機能追加」「障害管理表No.37の対応」など。 加えて変更内容の簡単なまとめがあると後から見やすいし他者のレビューも楽になる。 日付や名前は自動記録と重複するので不要。 who when what how why
70. コミットするタイミングは？ Gitではローカルリポジトリで作業ができるので、コミットしただけでは他の人に迷惑がかかることは ない。極端に言えばコンパイルエラーがある状態でコミットしてもすぐには問題にならないが、さす がに後から見たときにある程度まとまりがあったり区切りとなるものでなければ意味がない。 基本的にはコンパイルエラーがでない程度に区切りまで作業が進めばこまめにコミットするのがオス スメ。 操作ミスでソースを失う危険が減るし、 「さっきまでうまく動いてたのに動かなくなった。どこ変えたっけ！？」逆に 「動いてなかったのにいつの間にか動くようになってる。何が違うの？？？？」というときに差分を 確認できる。 コミットが多くなりすぎるとログが見づらいという意見もあるが、「スカッシュ」機能を使えば複数 のコミットを１コミットにまとめ直すこともできるので、やはりローカルではこまめなコミットを推 奨する。
71. 9.プッシュ • ローカルリポジトリの内容をリモートリ ポジトリに反映する • コミットしただけではPC内の変更だけ
72. 1 2 3 4 1. 「プッシュ」をクリック 2. プッシュするローカルブランチをチェック 3. プッシュ先となるリモートブランチを選択 or入力 4. 「プッシュ」をクリック
73. 完了！
74. 10.マージ • あるブランチの内容を他のブランチに反映する • 競合があっても怖がらずに落ち着いて対応しよう
75. 1 2 3 1. マージ先となるブランチに切り替え 2. マージ元のブランチを右クリック 3. 「現在のブランチに〇〇をマージ」をク リック 4. 確認して問題なければ「OK」をクリック 4
76. 11.競合(コンフリクト、衝突) • マージの際に同じファイルの同じ場所を変更していると 競合となる • 競合が起きたときはファイルの内容を確認して、適切な 内容にファイルを編集する。
77. 1 1. マージしようとすると競合が発生。「閉じ る」をクリックしてダイアログを閉じる 2. 競合の起きたファイルを確認 3. 競合の起きた場所を確認 2 3
78. 4 HEAD(=現在のブランチ)の内容 「Feature/タイトル追加」ブランチの内容 5 4. エディタやIDEでそれぞれのブランチの内 容を見て・・・ 5. お互いの内容を潰さないように編集して保 存
79. 6 6. 編集が完了したファイルを右クリックし て「解決とマーク」する
80. 7. 編集が完了したファイルを右クリックし て「解決とマーク」する 7 コミットコメントはそのままでよい マージしようとしたら競合があって何かしら編 集したことがわかる。
81. 12.破棄 • 変更、削除した内容を現在のコミット時点の状態に戻す。 変更の破棄＝変更を取り消して元に戻す 削除の破棄＝ファイルを復活させる • 追加はまだコミットされていないファイルなので破棄できない。 削除すればOK
82. 1 2 3 1. 変更ファイルを選択 2. 削除ファイルを選択 3. 右クリックして「破棄」
83. 完了！ 削除したファイルも復活
84. 破棄？チェックアウト？ 破棄はコマンドとしては「checkout」なので、コミット時点の状態のファイルをディレクトリに反映 する作業を選択したファイル毎に行っている。 そのため、まだコミットされていない新規作成のファイルは「破棄」できない。 この資料の中でチェックアウトは 1. リモートリポジトリのブランチをローカルリポジトリに取込 2. ブランチの切替 3. 破棄 と3種類登場したが、いずれも「あるブランチ(コミット)の状態をディレクトリに反映する」という作 業となる。
85. この資料でまだ書けていないこと • スタッシュ(一時退避) • .gitignore(無視) • スカッシュ • リベース • Amend(直前コミットの修正) • プルリクエスト • タグ • 他にも色々
86. 以上！