数値計算屋のためのGit入門 / Starting Git

Slide 1

Slide 1 text

1 1 47 数値計算屋のためのGit入門慶應義塾大学理工学部物理情報工学科渡辺

Slide 2

Slide 2 text

2 2 47 • バージョンを管理してくれる • 変更点を後から見やすくしてくれる • 多人数による開発を容易にしてくれるバージョン管理システムの一つ (Version Control System: 略してVCS) プログラム開発現場ではVCSの導入は必須いまどきVCSを使ってない開発現場は無い……と思う

Slide 3

Slide 3 text

3 3 47 「しまった！」を「なかったこと」にできる「以前は動いてたのに」を再現できるバックアップがわりになる修士論文提出直前にPCが壊れた USBに保存してたデータが読めなくなった ※ リモートリポジトリを別サーバに用意した場合 ↑ こういう悲劇を防ぐ編集の歴史を保存し、いつでも過去に戻ることができる

Slide 4

Slide 4 text

4 4 47 機能を追加し、別のインプットを与えたら計算が失敗した →機能を追加したことによるバグ？もともとバグっていたものが顕在化？計算ルーチン (修正前) インプット A OK 計算ルーチン (修正版) インプットB NG 容疑者機能追加前のソースを取って来て、Input Bを食わせる OK NG 今回の修正でバグが入った計算ルーチン (修正前) インプット B もともとのバグが顕在化したバージョン管理をしていると、問題の切り分けが容易

Slide 5

Slide 5 text

5 5 47 いつの間にかバグが入っていて、いつ入ったバグかわからない →「歴史」を二分探索開発時間軸 Ver. 1 Ver. 2 Ver. 3 Ver. 4 Ver. 5 (1)ここでバグ発覚 (3)ここでバグ混入と確定 (2)ここまでは動作することを確認デバッグ時間軸 Ver. 2とVer. 3の差分をとれば、何が原因かがすぐにわかる「容疑者」を絞るのは捜査の基本

Slide 6

Slide 6 text

6 6 47 年に二編論文を書きたい→ 半年で一つの研究を完結させたいプログラム開発＋計算執筆調査調査：先行研究の調査や、計算手法についての調査 (1ヶ月) 開発＋計算：プログラム開発、計算の実行(4ヶ月) 執筆：結果の解析＋論文執筆＋投稿 (1ヶ月) 実態は・・・執筆調査デバッグ開発計算半年デバッグの時間を減らすことが最も効果的な「高速化」バージョン管理システムはデバッグ時間を減らす強力なツール

Slide 7

Slide 7 text

7 7 47 正直な話、Gitは簡単ではない • コマンドが多い • 使い方に自由度が高い(人によって違う) • よくわからない状態になりがち慣れるまで時間がかかると思って、根気よく使ってみよう使い慣れると、無い生活は考えられません

Slide 8

Slide 8 text

8 8 47 git init git add git commit git status git diff git log git clone git remote git fetch git push git switch git merge ローカルリポジトリの操作ブランチの操作状態や歴史の確認リモートとのやりとり「とりあえず」でもこんなにある

Slide 9

Slide 9 text

9 9 47 • 「リポジトリ」という単位で管理する • リポジトリごとに「データベース」がある • データベースには「歴史」が保存される • 「コミット」により、「歴史」が追加されるリポジトリデータベース管理されているファイルやフォルダ ※ データベースの実体は .git というディレクトリに保存されている

Slide 10

Slide 10 text

10 10 47 管理したいファイルを含むディレクトリで git initを実行するリポジトリデータベース管理されているファイルやフォルダ管理したいファイルやフォルダ git init ※ 実際にはgit addしてからgit commitしないとgitの管理下に入らない

Slide 11

Slide 11 text

11 11 47 Gitでは「歴史」を丸と線で表現する • 丸：ある時点の「状態」 • 線：二つの状態の関係(差分) 三日前二日前昨日昨日から修正を加えたファイル歴史

Slide 12

Slide 12 text

12 12 47 コミット：現在の状態を保存して「歴史」に加える三日前二日前昨日昨日から修正を加えたファイルコミット歴史

Slide 13

Slide 13 text

13 13 47 三日前二日前昨日歴史今日この玉それぞれを「コミット」と呼ぶこの玉を新たに作る作業を「コミットする」と呼ぶ commit (名詞) : Gitの歴史のある「点」(スナップショット) commit (動詞): Gitの歴史に新たにスナップショットを付け加えること https://git-scm.com/docs/gitglossary A Git Glossary

Slide 14

Slide 14 text

14 14 47 三日前二日前昨日今日 git diff - 任意の二点の「差分」が取れるこれは昨日書いた文章です。 -これは今日削除した文章です。 +これは今日追加した文章です。 $ git diff HEAD^ 白地：変更なし赤字：削除緑字：追加自分がいつどこを修正したか確認できて便利

Slide 15

Slide 15 text

15 15 47 三日前二日前昨日今日 git switch - 任意の時間に戻ることができる $ git switch –c twodaysago HEAD^^ 二日前の状態「いつの間にか動かなくなった」時に「この時点では動く」ことを確認できる

Slide 16

Slide 16 text

16 16 47 git log – これまでの履歴を確認できる $ git log commit 1ee64f77e9f32a947b0774eb2c82cd8da59aed40 (HEAD -> main) Author: H. Watanabe Date: Fri Apr 10 19:42:01 2020 +0900 test2.txtを追加 commit 2a2ae2c7f601bf3d2a6d727745e57fa4a7de83b0 Author: H. Watanabe Date: Fri Apr 10 19:41:26 2020 +0900 test.txtを追加 commit 1a2da617b848413daee9b2880c2f7e6d201ed2b9 Author: H. Watanabe Date: Fri Apr 10 19:41:06 2020 +0900 initial commit 誰が、いつ、どんな修正をしたかを確認できる

Slide 17

Slide 17 text

17 17 47 gitには、三種類のエリアがあるワークツリーインデックスリポジトリ git init 直後の状態 https://www.slideshare.net/matsukaz/git-17499005 いつやるの？Git入門 file1 file2 まだGit管理下に置かれていない

Slide 18

Slide 18 text

18 18 47 ワークツリーリポジトリ file1 file2 リポジトリへの追加が予約された「git add ファイル名」により、インデックスに入る git add file1 file2 file1 file2 インデックス

Slide 19

Slide 19 text

19 19 47 ワークツリーリポジトリ file1 file2 リポジトリ管理下に入った git commitにより、変更がリポジトリに記録される git commit –m “file1とfile2を追加” file1 file2 インデックス

Slide 20

Slide 20 text

20 20 47 Q: なぜインデックスがあるか？ A: 複数の修正がある時、一部の修正を選んでコミットを作るため

Slide 21

Slide 21 text

21 21 47 ワークツリーリポジトリ file1 file2 file1 file2 最後にコミットした状態から、file1とfile2を修正したインデックス

Slide 22

Slide 22 text

22 22 47 ワークツリーリポジトリ file1 file2 file1 file2 file1だけaddするインデックス file1 git add file1

Slide 23

Slide 23 text

23 23 47 ワークツリーリポジトリ file1 file2 file1 file2 コミットするインデックス git commit –m “file1を修正”

Slide 24

Slide 24 text

24 24 47 ワークツリーリポジトリ file1 file2 file1 file2 file2も同様にするインデックス git add file2 git commit –m “file2を修正” file2

Slide 25

Slide 25 text

25 25 47 file1 file2 file1 file2 file1 file2 こんな歴史ができあがった file1とfile2を追加 file1を修正 file2を修正 Gitでは積極的に歴史を作成、改変する

Slide 26

Slide 26 text

26 26 47 ワークツリーリポジトリ file1 file2 file1 file2 インデックス file2 file1 git commit –a オプションで「修正があったファイルを全てコミットに含める」ことができる(git addを省略できる) 一人で使っている時は、慣れるまではこれで良いと思う

Slide 27

Slide 27 text

27 27 47 コミットが作成されると自動的に「ハッシュ」と呼ばれる識別子がつく 831967136c9b05c721c87d2f8acff4bb4f3d907b c5961f9ec26906976814db253f2821f4b4786be3 78ec9625eff1d974b8b150842dca62d49a909f3b ハッシュ

Slide 28

Slide 28 text

28 28 47 831967136c9b05c721c87d2f8acff4bb4f3d907b c5961f9ec26906976814db253f2821f4b4786be3 78ec9625eff1d974b8b150842dca62d49a909f3b ハッシュ main main: 最初に作成されるブランチ HEAD: いま自分がいるブランチ HEAD ブランチとはコミットにつけられた「別名」

Slide 29

Slide 29 text

29 29 47 main main main 「現在自分がいるブランチ」は、コミットすると自動的に動く現在の状態コミットを作成コミットを作成

Slide 30

Slide 30 text

30 30 47 main 「git switch –c branchname」により 1. branchnameという名前のブランチを作り 2. そのブランチに自分(HEAD)が移る git switch –c branch main branch HEAD HEAD この時点ではmainとbranchは同じコミットを指している

Slide 31

Slide 31 text

31 31 47 main branch 「コミット」により動くのは、HEADがある(自分が今見ている)ブランチ main branch banch上でコミットしたコミットが作られ、branchと HEADが動く(mainはそのまま) HEAD HEAD

Slide 32

Slide 32 text

32 32 47 git switch branchname 自分が見るブランチ(HEADが指すブランチ)をbranchnameに変更する main branch HEAD main branch HEAD git checkout main 今見ているブランチが mainに変わった

Slide 33

Slide 33 text

33 33 47 異なる二つのコミットから、新たなコミットを作ること git merge branchname 現在自分が見ているブランチに、branchnameの変更を取り込むこの時、「歴史が分岐しているかどうか」で動作が変わる

Slide 34

Slide 34 text

34 34 47 main branch 現在、自分はbranchにいて、 mainよりも進んだ状態 branch git checkout main mainブランチに移動した HEAD main HEAD

Slide 35

Slide 35 text

35 35 47 branch mainブランチに branchの修正を取り込む branch main HEAD main HEAD git merge branch ブランチが移動するだけ (Fast Forward)

Slide 36

Slide 36 text

36 36 47 main branch HEAD 歴史が分岐している場合自分がブランチで作業している間に mainブランチにコミットが増えていたここで分岐した自分はいまここにいる分岐した後に増えたコミット

Slide 37

Slide 37 text

37 37 47 main branch HEAD HEAD git checkout main まず、mainブランチに移る git merge branch 1. branchの修正を取り込み 2. 新たなコミットができて 3. main/HEADがそこを指す branch main HEAD

Slide 38

Slide 38 text

38 38 47 A. 「修正」をまとめるため mainブランチだけで作業していると… main HEAD main HEAD 機能Aと機能Bを実装するぞ機能Bがバグったんだけど、何が原因かわからない…

Slide 39

Slide 39 text

39 39 47 「まとまり」ごとにブランチを分けて作業 main branchA branchB 機能Bでバグったけど、少なくとも機能Aは無関係原則としてmainで作業しないブランチで作業し、テスト後にmainにmerge

Slide 40

Slide 40 text

40 40 47 リモートリポジトリとは、データベースだけのリポジトリ (ベアリポジトリ) ローカルリポジトリデータベース管理されているファイルやフォルダ (ワーキングツリー) リモートリポジトリデータベース .git .git ワーキングツリーを含まず .gitディレクトリだけを含むと思えばよい

Slide 41

Slide 41 text

41 41 47 リモートリポジトリデータベース .git ローカルリポジトリデータベース管理されているファイルやフォルダ (ワーキングツリー) .git git clone リモートからデータベースをローカルにコピーし、ワーキングツリーを展開する

Slide 42

Slide 42 text

42 42 47 git push ローカルリポジトリリモートリポジトリローカルで変更された「歴史」をリモートに反映させるローカルリポジトリリモートリポジトリ

Slide 43

Slide 43 text

43 43 47 git fetch ローカルリポジトリリモートリポジトリリモートで変更された「歴史」をローカルに取ってくるローカルリポジトリリモートリポジトリ

Slide 44

Slide 44 text

44 44 47 origin/main git fetchでローカルのmainやHEADは修正されない main HEAD git fetchで追加された部分 ※ リモートのブランチは origin/branch名という名前にすることが多い

Slide 45

Slide 45 text

45 45 47 origin/main main HEAD origin/main main HEAD git merge origin/main リモートのブランチをマージすることで修正を取り込む

Slide 46

Slide 46 text

46 46 47 git fetchしてgit merge origin/mainを一度に行う git pull ローカルリポジトリリモートリポジトリローカルリポジトリ main HEAD HEAD→mainも移動する事故が起こりやすいので慣れるまでgit pullは使わない方がよい

Slide 47

Slide 47 text

47 47 47 Gitは慣れるまではそこそこ大変しかし、使わない場合に比べて開発効率は倍以上になる使わない場合は人生を2倍以上損している ※ 個人差あり ※ 個人差あり普段から少しずつ使って慣れましょう