はじめてのGit - Speaker Deck

Slide 1

Slide 1 text

はじめてのGit 2018/12/27 業務支援グループ d_hirayama

Slide 2

Slide 2 text

もくじ 1. Gitとは 2. Gitの何がそんなにいいのか 3. Gitのツール 4. 「分散型」を理解しよう 5. ブランチを使ってこそGit 6. SourcetreeでGitを使おう -初級編- 1. クローン 2. プル 3. チェックアウト 4. ブランチ作成その１ 5. ブランチ作成その２ 6. ブランチの切替 7. ステージ 8. コミット 9. プッシュ 10. マージ 11. 破棄

Slide 3

Slide 3 text

1.Gitとは

Slide 4

Slide 4 text

Wikipediaより • Git（ギット）は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。 Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナンスは濱野純 (Junio C Hamano) が担当している。

Slide 5

Slide 5 text

バージョン管理システム？ • ファイルの作成日時、変更日時、変更点などの履歴を保管するシステム。 • ソース管理ツールとか構成管理ツールと呼ぶこともある。

Slide 6

Slide 6 text

何のために使うのか？最新ファイル一式しか無いと・・・ • バグが見つかったときにいつ混入したバグかわからない • 変更後に問題が見つかったときに前の状態に戻したり参考にして修正することができない • いかにも不要に思える処理があってもいつ、誰が、何のために入れたかわからないと消しづらい。（実は必要なのかも） • 複数人で作業したときに何が最新かよくわからなくなる • 複数人で作業すると簡単にソースが壊れる

Slide 7

Slide 7 text

色々なバージョン管理システム • 共有フォルダ日付や人別にフォルダを作成 • VSS(Microsoft Visual Source Safe) VisualStudio2005までの標準ツール • CVS(Concurrent Versions System> 1990年に作成されたフリーウェア • SVN(Apache SubVersion) CVSの問題点を解決すべく開発された • Git

Slide 8

Slide 8 text

広く使われる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サービスが稼働させることができる

Slide 9

Slide 9 text

https://docs.microsoft.com/ja-jp/visualstudio/version-control/?view=vs-2017 VSでもMS製のツールより先に説明がある

Slide 10

Slide 10 text

2.Gitの何がそんなにいいの？バージョン管理システムの比較

Slide 11

Slide 11 text

共有フォルダ • お手軽簡単 • わかりやすい • バックアップも楽 • 本当に状態が維持できている保証がない（ファイル足りてないかも。うっかり誰か触ってるかも） • 複数人が同時作業するとマージが辛い(WinMerge使うとはいえ・・・） • どんどん増えがち(日付付きフォルダ) • 差分がわかりづらい(WinMerge) • 容量多くなりがち（コンパイル後ファイルは入れないで！） • コメントつけにくい

Slide 12

Slide 12 text

VSS • 「誰が」「いつ」「何を」「なぜ」変更したかわかる！ • 変更差分だけを管理するため容量が減らせる • ある時点の状態のソースを取り出せる (↑ここまで以降省略) • ファイルをロックするので共同作業しても壊す心配がない。わかりやすい。 • 複数ファイルを1回でコミットできる • ロックするので同時に作業できない • ロックしたまま帰らないで！！！ • Windowsでしか使えない • 有償(Visual Studio Professional に同梱) • 既に開発終了

Slide 13

Slide 13 text

CVS • ファイルロックしないので同時作業も可能 • リポジトリがほぼ元のテキストファイルのままなので簡単に見れる • フリーウェア！！！ • 複数ファイルを１まとまりとしてコミットできない。（１ファイルずつの連続したコミットになる） • 文字コードが危険

Slide 14

Slide 14 text

SVN • 複数ファイルを１まとまりでコミットできる • 文字コードも大丈夫 • フリーウェア！！！ • 複数バージョンの並行管理（本番環境用、検証環境用、開発環境用、障害対応中）が辛い • マージがしんどい • リポジトリにつながらないとコミットできない

Slide 15

Slide 15 text

Git • 強力なブランチ機能 • 複数バージョンの並行管理も楽 • 複数案件の並行作業も安心 • 分散型なのでローカルでもコミットできる • マージが楽 • GitHub等のリポジトリサービスが使える • 従来のものと考え方が違うところがあるので、最初全然わからない。怖い • Git自体には権限管理機能が無いので誰でもmasterが触れてしまう • リポジトリにはバイナリで保存されてるのでツール使ったりコマンド叩かないとソース見れない

Slide 16

Slide 16 text

• 従来のものと考え方が違うところがあるので、最初全然わからない。怖い • Git自体には権限管理機能が無いので誰でもmasterが触れてしまう • リポジトリにはバイナリで保存されてるのでツール使ったりコマンド叩かないとソース見れないこの資料で解決！ Gitbucketなら管理できる！ GitbucketならWebで見れる！

Slide 17

Slide 17 text

比較 VSS CVS SVN Git 価格有償フリーフリーフリーハードル低い低め低めﾁｮｯﾄﾀｶｲファイルロックロックするしないしないしない一括コミットできるできないできるできるブランチ機能なしサブフォルダ方式サブフォルダ方式リポジトリで管理ソース自体を入替集中/分散集中型集中型集中型分散型リポジトリのソースバイナリテキストバイナリバイナリ管理対象ファイルテキストファイルファイル行マージ衝突しない！辛い辛いわりと自動でいけるコミット番号連番連番連番ハッシュ

Slide 18

Slide 18 text

3.Gitのツール Gitを使うためのツール

Slide 19

Slide 19 text

Git / Git for windows • Gitそのもの https://git-scm.com/ • Windows用のGit https://gitforwindows.org/ • これさえインストールすればGitが使える！ • CUIツールなのですべてコマンドラインで実行

Slide 20

Slide 20 text

Sourcetree • ATLASSIAN製のGit(とMercurial)用GUIツール https://ja.atlassian.com/software/sourcetree • 無料！（素敵！） • 操作ももちろん楽だが、ブランチの可視化ができて見やすい！ • 基本的なことはSourcetreeがあればできる！ • ダウンロードして使い始めるにはアカウントが必要 • アカウントの認証メールはHTMLで見る必要あり（Becky!だと注意！）

Slide 21

Slide 21 text

GitHub • Web上のGitリポジトリサービス • アカウントを作れば(無料)自分のリポジトリが作れる • ブラウザでソースも履歴も見れる、ソース一式をZipダウンロードもできる • 権限管理、Issue管理、PullRequest、Wikiなどの機能がある • 現在はMicrosoft傘下 • 類似サービスにBitbucket(ATLASSIAN),GitLab

Slide 22

Slide 22 text

Gitbucket • GitHubを模したフリーウェア https://github.com/gitbucket/gitbucket/releases • 自前でGitHubのようなサービスを立てられる • ブラウザでソースも履歴も見れる、ソース一式をZipダウンロードもできる • 権限管理、Issue管理、PullRequest、Wikiなどの機能がある • デザインはGitHubとちょっと違う(GitHubに指摘された為)

Slide 23

Slide 23 text

4.「分散型」を理解しよう Gitの基本その１。まずはここをしっかり理解しよう

Slide 24

Slide 24 text

集中型リポジトリ • ソースコードとその履歴を管理するデータベースのことを「リポジトリ」という • VSS、CVS、SVNはいずれも集中型なのでサーバーだけにリポジトリがある

Slide 25

Slide 25 text

分散型リポジトリ • Gitは分散型リポジトリ • サーバーだけでなくローカル(自分の PC)にもリポジトリがある • サーバーにつながらなくても作業可能 • サーバーを使わずローカルだけで管理することも可能 (とりあえず作業するときに便利) • もしサーバーが壊れてもローカルから履歴も含めて簡単に復元できる

Slide 26

Slide 26 text

リポジトリの種類・呼び方リポジトリの種類を指す言葉 • 中央リポジトリ(ベアリポジトリ) 作業フォルダを持たないバイナリの管理情報だけのリポジトリ ≒リモートリポジトリ • ノンベアリポジトリ作業フォルダのあるリポジトリ ≒ローカルリポジトリリポジトリの場所を指す言葉 • リモートリポジトリ自分のPC以外のリポジトリ。 • ローカルリポジトリ自分のPCのリポジトリ

Slide 27

Slide 27 text

分散型ならではの操作 • プル(pull) リモートリポジトリの変更をローカルリポジトリに反映する PCに引っ張って来る • プッシュ(push) ローカルリポジトリの変更をリモートリポジトリに反映するサーバーに押し込むプルプッシュ

Slide 28

Slide 28 text

基本的な作業の流れ 1. リモートリポジトリの最新をプルする 2. ローカルで作業(ファイルを変更) 3. 変更をローカルリポジトリにコミット（確定） 4. 変更をリモートリポジトリにプッシュ ※コミットしただけではサーバーに反映されないことに注意！！！ 1.プル 2.作業 3.コミット 4.プッシュ

Slide 29

Slide 29 text

5.ブランチを使ってこそGit Gitの基本その２。ここが理解できればGit使い！

Slide 30

Slide 30 text

ブランチとは？ • 幹(trunk)から分かれた枝(branch) ※Gitではtrunkと言わずmasterブランチという • ソースコードの履歴の枝分かれ • 各ブランチは独立して互いに影響しない • リモートにもローカルにも作れる commit commit commit init commit commit commit commit commit commit

Slide 31

Slide 31 text

ブランチが無いと？ • 異なる作業を１つの履歴で管理しないといけない 1 2 新画面レイアウト master 3 表示処理実装 4 緊急バグ対応 5 更新処理実装差分を抜き出して本番に反映３で変更した共通処理でしか正しく動かない！！！

Slide 32

Slide 32 text

ブランチがあれば？ • それぞれのブランチの作業が完了する毎に反映(マージ)する develop (開発用ソース) master (本番用ソース) 新機能作成バグ対応新画面レイアウト表示処理実装緊急バグ対応 merge 更新処理実装 merge merge merge DBの接続先を本番用に変更テストテスト

Slide 33

Slide 33 text

ブランチの使い方（環境） • 管理したい環境ごとのブランチを必要に応じて作成・管理 • これにより本番環境にはどの変更が入ってる、検証環境には先にこれを入れる、などが管理できる開発(develop) 機能追加本番(master) 検証(stage)

Slide 34

Slide 34 text

ブランチの使い方（作業） • ソースコードを触るときは基本的に作業用のブランチを作成する通常はdevelopから枝分かれさせる • 作業が完了したら元のブランチにマージ • 元のブランチに変更があれば先に変更内容を作業ブランチにマージ develop 機能追加A 機能追加B バグ対応

Slide 35

Slide 35 text

つまりこんな感じ develop 機能追加A 機能追加B バグ対応 master stage バグ対応だけリリースバグ対応と機能追加Aを検証中全部入れてテスト中

Slide 36

Slide 36 text

マージの注意その１ • マージする前にマージ先の最新コミットをマージしよう (先の例では便宜上省略) • 同じファイルに対して変更があるとコンフリクト(競合・衝突) が発生し、編集が必要な場合がある • マージ先の最新の状態に対する差分になるようにする develop 機能追加A 機能追加B マージ前にすり合わせ

Slide 37

Slide 37 text

マージの注意その２ • ブランチのマージ作業もまずはローカルリポジトリでやる • マージが完了してからリモートリポジトリにプッシュする • ※誰がやるべきかはまた別の話（各メンバー？リーダー？） 3.プッシュ 2.マージ作業 1.プル

Slide 38

Slide 38 text

ブランチを切り替えると何が起きるか？ • 現在のブランチを切り替えると実際のフォルダ、ファイルが置き換わる

Slide 39

Slide 39 text

• IDEを開き直す必要が無い最近のIDEはGitに対応しており自動的に再読み込みする • 再コンパイル(リビルド)を忘れないように • ファイルの更新日時は参考にならなくなるので注意ファイル自体が書き換わるので・・・

Slide 40

Slide 40 text

6.SourcetreeでGitを使おう -初級編- Sourcetreeを使ったGitの基本的な操作を覚える！

Slide 41

Slide 41 text

1.クローン • リモートリポジトリのソースコードを基にローカルリポジトリを作成する

Slide 42

Slide 42 text

1 2 3 4 このURLをコピーする (Gitbucketの場合) 1. 新しいタブでCloneを選択 2. 対象のリポジトリを入力 3. 保存するフォルダ、ローカルでのリポジトリ名を入力 4. 「クローン」をクリック

Slide 43

Slide 43 text

完成！

Slide 44

Slide 44 text

2.プル • リモートリポジトリのソースコードをローカルリポジトリに反映する

Slide 45

Slide 45 text

1 2 3 1. 「プル」をクリック 2. プルしたいリモートリポジトリのブランチを選択 3. 「OK」をクリック

Slide 46

Slide 46 text

3.チェックアウト（リモート） • リモートリポジトリのブランチをローカルリポジトリにも作る

Slide 47

Slide 47 text

1 2 3 1. 「リモート」からチェックアウトしたいブランチを選択 2. 対象のブランチを右クリック 3. 「〇〇をチェックアウト」をクリック 4. 「新規ブランチを作成してチェックアウト」で「OK」 4

Slide 48

Slide 48 text

完成！

Slide 49

Slide 49 text

4.ブランチ作成その１ • ローカルリポジトリにブランチを作成 • 基本のやり方

Slide 50

Slide 50 text

2 3 4 1 1. 元となるブランチに切替（参照「5.ブランチの切り替え」） 2. 「ブランチ」をクリック 3. 任意のブランチ名を入力 4. 「ブランチを作成」をクリック

Slide 51

Slide 51 text

完成！ブランチを作成した時点では元となるブランチと全く同じ状態。この後コミットしていくことで別物になっていく。

Slide 52

Slide 52 text

5.ブランチ作成その２ • Git Flowを使ってブランチを作成 • Git Flowはブランチ名を定番の名前で作るための補助機能 • やり方が違うだけでブランチを作るのはその１と全く同じ

Slide 53

Slide 53 text

まずは下準備・・・ 1 2 1. 「Git Flow」をクリック 2. デフォルトのまま「OK」をクリック

Slide 54

Slide 54 text

下準備完了！(見た目は何も変わらない) この下準備は各ローカルリポジトリ毎に1度だけやればOK

Slide 55

Slide 55 text

1 2 1. 再度「Git Flow」をクリック 2. 「新規フィーチャーを開始」をクリック

Slide 56

Slide 56 text

3 4 5 3. 任意のフィーチャー名(ブランチ名)を入力 4. 「ここから」は通常はデフォルトのまま「最新の開発ブランチ」を選択 5. 「OK」をクリック

Slide 57

Slide 57 text

完成！

Slide 58

Slide 58 text

「フィーチャー」？ feature。「機能」とか「価値」などの意味。ユーザーにとって意味のあるひとまとまりの作業。例えば「画面の見た目だけ作ったけど動かない」ではフィーチャーが完了したとはいえない。運用上はどこまでできたらdevelopにマージするかがポイントなので、プロジェクトで取り決めればOK 「リリース」と「ホットフィックス」リリースはdevelopからmasterにマージするための中間作業をするためのブランチを作る。特になければいきなりmasterにdevelopをマージしてしまえばOK ホットフィックスが緊急バグ対応用のブランチでmasterからブランチを作成しmasterとdevelopに反映する。

Slide 59

Slide 59 text

6.チェックアウト(ブランチの切り替え) • 作業するブランチを切り替える • Gitの機能としてはこれも「チェックアウト」になる • チェックアウト＝あるブランチ(コミット)のファイルをディレクトリに持ってくる

Slide 60

Slide 60 text

1 1. 切り替えたいブランチをダブルクリック 1 2 または 1. 切り替えたいブランチを右クリック 2. 「〇〇をチェックアウト」をクリック

Slide 61

Slide 61 text

完了！

Slide 62

Slide 62 text

7.ステージ - コミットの準備 • 追加、変更、削除した内容をステージ状態にする。（ステージング） • ステージ状態になっている変更だけがコミットの対象となる • １ファイルの中でもこの行はステージ、この行はステージしない、ということも可能 • 変更行のかたまりを「Hunk」という • ステージの取消（アンステージ）も簡単にできる

Slide 63

Slide 63 text

1 2 3 1. 「ファイルステータス」タブを表示 2. 追加、変更、削除があれば自動的に一覧される (表示されないときは「F5」で再読込) 3. ステージするものを行選択して「選択をインデックスに追加」すべてステージするなら「全てインデックスに追加」

Slide 64

Slide 64 text

完了！アンステージするときは「インデックスから除く」をする

Slide 65

Slide 65 text

8.コミット • ステージした変更を確定する • バージョン管理システムの核となる最も重要な作業 • VSSやSVNと違ってローカルPCでの作業なので多少は気楽にやっても大丈夫

Slide 66

Slide 66 text

1 3 2 4 5 6 1. コミット対象がステージされているか？ 2. 内容は間違いないか？ 3. ステージ漏れがないか？ 4. ユーザー情報が正しいか？ 5. コミットコメントを記載 6. すぐにプッシュして大丈夫か？

Slide 67

Slide 67 text

7 7. コミット

Slide 68

Slide 68 text

完了！

Slide 69

Slide 69 text

コミットコメントには何を書くべきか？ Gitではいわゆる５Ｗ１Ｈがそれぞれ次のように記録される WHO - 著者・auther(ユーザー情報) WHAT - ステージしたファイル一覧 WHEN - コミットした日時 HOW - 変更前後の内容 WHEREとWHYは自動的に記録されない。どこで作業をしたかが重要なことはあまりないので通常は記載する必要はないため、「なぜその変更を行ったか」をコミットコメントに記載するのが最も重要となる。例えば「顧客要望により機能追加」「障害管理表No.37の対応」など。加えて変更内容の簡単なまとめがあると後から見やすいし他者のレビューも楽になる。日付や名前は自動記録と重複するので不要。 who when what how why

Slide 70

Slide 70 text

コミットするタイミングは？ Gitではローカルリポジトリで作業ができるので、コミットしただけでは他の人に迷惑がかかることはない。極端に言えばコンパイルエラーがある状態でコミットしてもすぐには問題にならないが、さすがに後から見たときにある程度まとまりがあったり区切りとなるものでなければ意味がない。基本的にはコンパイルエラーがでない程度に区切りまで作業が進めばこまめにコミットするのがオススメ。操作ミスでソースを失う危険が減るし、「さっきまでうまく動いてたのに動かなくなった。どこ変えたっけ！？」逆に「動いてなかったのにいつの間にか動くようになってる。何が違うの？？？？」というときに差分を確認できる。コミットが多くなりすぎるとログが見づらいという意見もあるが、「スカッシュ」機能を使えば複数のコミットを１コミットにまとめ直すこともできるので、やはりローカルではこまめなコミットを推奨する。

Slide 71

Slide 71 text

9.プッシュ • ローカルリポジトリの内容をリモートリポジトリに反映する • コミットしただけではPC内の変更だけ

Slide 72

Slide 72 text

1 2 3 4 1. 「プッシュ」をクリック 2. プッシュするローカルブランチをチェック 3. プッシュ先となるリモートブランチを選択 or入力 4. 「プッシュ」をクリック

Slide 73

Slide 73 text

完了！

Slide 74

Slide 74 text

10.マージ • あるブランチの内容を他のブランチに反映する • 競合があっても怖がらずに落ち着いて対応しよう

Slide 75

Slide 75 text

1 2 3 1. マージ先となるブランチに切り替え 2. マージ元のブランチを右クリック 3. 「現在のブランチに〇〇をマージ」をクリック 4. 確認して問題なければ「OK」をクリック 4

Slide 76

Slide 76 text

11.競合(コンフリクト、衝突) • マージの際に同じファイルの同じ場所を変更していると競合となる • 競合が起きたときはファイルの内容を確認して、適切な内容にファイルを編集する。

Slide 77

Slide 77 text

1 1. マージしようとすると競合が発生。「閉じる」をクリックしてダイアログを閉じる 2. 競合の起きたファイルを確認 3. 競合の起きた場所を確認 2 3

Slide 78

Slide 78 text

4 HEAD(=現在のブランチ)の内容「Feature/タイトル追加」ブランチの内容 5 4. エディタやIDEでそれぞれのブランチの内容を見て・・・ 5. お互いの内容を潰さないように編集して保存

Slide 79

Slide 79 text

6 6. 編集が完了したファイルを右クリックして「解決とマーク」する

Slide 80

Slide 80 text

7. 編集が完了したファイルを右クリックして「解決とマーク」する 7 コミットコメントはそのままでよいマージしようとしたら競合があって何かしら編集したことがわかる。

Slide 81

Slide 81 text

12.破棄 • 変更、削除した内容を現在のコミット時点の状態に戻す。変更の破棄＝変更を取り消して元に戻す削除の破棄＝ファイルを復活させる • 追加はまだコミットされていないファイルなので破棄できない。削除すればOK

Slide 82

Slide 82 text

1 2 3 1. 変更ファイルを選択 2. 削除ファイルを選択 3. 右クリックして「破棄」

Slide 83

Slide 83 text

完了！削除したファイルも復活

Slide 84

Slide 84 text

破棄？チェックアウト？破棄はコマンドとしては「checkout」なので、コミット時点の状態のファイルをディレクトリに反映する作業を選択したファイル毎に行っている。そのため、まだコミットされていない新規作成のファイルは「破棄」できない。この資料の中でチェックアウトは 1. リモートリポジトリのブランチをローカルリポジトリに取込 2. ブランチの切替 3. 破棄と3種類登場したが、いずれも「あるブランチ(コミット)の状態をディレクトリに反映する」という作業となる。

Slide 85

Slide 85 text

この資料でまだ書けていないこと • スタッシュ(一時退避) • .gitignore(無視) • スカッシュ • リベース • Amend(直前コミットの修正) • プルリクエスト • タグ • 他にも色々

Slide 86

Slide 86 text

以上！