JAWS-UG初心者支部#88わいわい初心塾(夏休みの宿題やったかGit編)

第3回コンテンツ:「バージョン管理の一歩目 ― Git ってなに？」
ゴールは「自走できる初心者」を増やすことです。

Git は、覚えるのが難しい。チーム開発で使えるようになるまでの壁も高い。 でもその手前で、こんな状態になっていないでしょうか。

コマンドを打つのが怖い（何が起きているか分からない）
Git / GitHub / GitLab / CodeCommit ・・・ うーん、違いは何？
そもそもファイル管理とコード管理が、まだ自分の中で結びついていない この会では、工夫や乗り越え方を語るより先に、使い方と基礎を確実に押さえます。 新人がファイル管理とコード管理を理解できないのは、仕方のないことです。だから、そこから手ほどきします。
この会で扱うこと
ファイル管理とコード管理は何が違うのか（Git を触る前の土台）
Git / GitHub / GitLab / CodeCommit の違い
コマンドラインとツール（GUI）の話
だれでも覚えられる、長年の研修で使ってきた「おまけ Tips」
最初にはまるポイント「コンフリクト」を避ける方法

Transcript

1. Gitをまずおぼえる＞ CodeCommit や AI-DLCにそなえよう
2. GItを操作したことがない SREやiaC といったインフラメンバで使うことがない わからないという声を 上級NWエンジニアからも耳にします。
3. 複雑に考えず・覚えず 擁護に溺れない 開発・運用できなかったら 意味がない だから今日は誓おう・そして自慢しよう 「お母さん俺進んだYo」
4. やることを やらないことを
5. やる ・Gitをつかむ ・ファイルを管理する件 ・コンフリクトはまったら ・GUIとCLIについて ・（疑問に答える）Gitいろいろ やらない ・ハンズオン → オフラインでやろう ・Git数多のコマンド → 調べてみよう ・CI/CD,IaC戦略のたてかた → CFn初心者塾へ ・「えっ？VimとEmacs。マウス？キーボードでよくない？」みたいな会話
6. イメージを掴む Gitをファイルサーバで考える
7. 普段のプロジェクトを業務する時のファイルの流れ DevとOps プロジェクトを 企画しゴールを目指す 作業する バックアップ 取る・戻す 整備・運用する 改善する
8. まいにちこつこつと 毎日フォルダをコピーして、日付つけようぜ ・毎日作業開始前に +A オリジナル ・・・・ 2023 0908̲x +B 今日の作業 x 2023 0910̲x ・・・・ 「20230910̲我らの案件名」 バックアップ向けに 年月日：YYYYMMDDを添えたフォルダをつけて作業に挑む。 ・なんなら「YMD＋連番」「YMD＋HMS」くらいの粒度にして 戻せるようにする
9. 今日の仕事終わったからバックアップとっとこ コミット と プッシュ 割り当てられたお仕事おわったから、サーバに退避しとこ
10. あっ！？まちがえた・・・ 作業ファイルの内容を盛大に書き換えてしまい +A オリジナル ・・・・ 2023 0908̲x +B 今日の作業 x もどしたい 2023 0910̲x
11. 昨日までバックアップを作った所まで、「秒」で戻って作業を再開する 20230905_作業 作業中 バックアップ 20230903_作業 20230902_作業 フォルダ名を オリジナルに戻して作業を再開
12. ロールバック
13. １つのオリジナルファイルを最新の状態で管理共有する オリジナルコード オリジナルコード +追加されたコード +修正されたコード オリジナルコード +修正されたコード +追加されたコード 一つのソースファイルで最新のリリースをしたい ・だれかが上書きした/ 消えた ・あの後世のファイルなら動いたのに ・ファイルの中身が新旧入り混じる
14. 「ファイル書き換えときました〜」 マージ と まーじーでー！？ 「書き換えたの誰だ！？あ」
15. デグレード： ファイルのバージョングレードがお かしくなることと コンフリクト： ファイルの中身がおかしくなること
16. 全ては、安全・安心のために、障害発生からの切り戻しと復旧の意識が大事 しくじり 作業中 ・・・ 作業中 破損 RTO 復旧後 復旧にかかる時間 Recovery Time Objective RPO RecoveryPointObjective RPO : 目標復旧時間 ・・・ 「どの時点まで」現状を戻せるか RTO：目標復旧時点 ・・・ 「どのくらいで」現状に戻せるか
17. すべては「年月日」 形式 毎日の小さな努力の 積み重ねが、歴史を 作っていくんだよ。
18. あるとき、偉い 人たちは考えた ファイルって管理すれば良くない？
19. Linux は 世界最大のOSであり、世界中のイケイケエンジニアがソースを投稿してくる https://ja.wikipedia.org/wiki/Linux
20. もちろんLinuxのコードも、たくさんのご意見や見直しが入ります ファイル管理を世界規模でやってると、「上書き」ファイル管理の多やみは多い https://ja.wikipedia.org/wiki/Linux
21. 世界のファイル管理ツールふぁっきん、作っちまおう どうも 僕です https://ja.wikipedia.org/wiki/Linux
22. いろいろなじじょうがあって、1０日待てっていって、リーナスがGitを開発 https://github.com/torvalds
23. gitとdocker たった５つの命令とコマンド
24. Gitって便利 $git コマンド init # 作成する clone #コピー持ってくる log #履歴見る commit {target} #登録する push #リモートにマージする pull #ローカルにマージする バーブ 動作・状態・出来事 オプション 初期に利用するコマンドを各自増やしてページも追加していこう https://git-scm.com/cheat-sheet
25. Git運用 おぼえるGit講座〜ファイルサーバで覚える〜
26. ファイル運用 ファイルサーバ 上書きしちゃうよ連絡 OKだよ上書 オリジナ ル オリジナル 複製 上書き or フォルダ名を変える コピー 作業マシン 日々の作業 許可を得る・上書きしても いいか確認する バックアップ 作業 20230601̲作業 +A 差分比較 20230602̲作業 +B 20230603̲作業
27. Git運用 プルリクエスト マージ GitServer ファイルサーバ リポジトリ マージコミット 上書きしちゃうよ連絡 ブランチ OKだよ上書 オリジナ ル オリジナル クローン 複製 LocalPC ＆ 日々の作業 +B LocalGit 上書き or フォルダ名を変える コピー 作業マシン プッシュ +B 日々の作業 コミット（日々の履歴が残る） プッシュ失敗 許可を得る・上書きしても いいか確認する ※すでに誰かが上書いてるので 後から更新する人は「マージ」する バックアップ ヒストリ （日々の履歴が残る） 作業 20230601̲作業 20230602̲作業 +B ディフ 日々の差分を見る +A 差分比較 +B 20230603̲作業
28. 同じこと並べて見てみよう
29. ソースコードの バージョンを 管理すること
30. ①まずはファイルサーバとPC 1.イメージ作り ローカル環境 PRJ01 外部サーバー 僕のPC LAN ファイルサーバ
31. ②作業対象のフォルダを複製してくる 1.クローン ローカル環境 PRJ01 PRJ01otsuki PRJ01otsuki PRJ01otsuki 外部サーバー 僕のPC LAN ファイルサーバ
32. ③ローカルの作業フォルダを切り替え 1.クローン ローカル環境 PRJ01 PRJ01 PRJ01otsuki PRJ01otsuki 外部サーバー 僕のPC LAN ファイルサーバ
33. この関係をまずは覚えよう チームメンバー共用の場所 ローカル環 作業ツリー PRJ01 ブランチ 自分だけの一時 保管場所 ※バージョン管理はできる PRJ01 PRJ01otsuki PRJ01otsuki 作業中のローカル ファイル 外部サーバー ローカルリポジトリ PCが壊れたらデータも 消える リモートリポジトリ
34. この関係をまずは覚えよう チームメンバー共用の場所 ローカル環 PRJ01 作業ツリー PRJ01 ブランチ PRJ01otsuki PRJ01otsuki 作業中のローカル ファイル 外部サーバー ローカルリポジトリ PCが壊れたらデータも 消える リモートリポジトリ
35. この関係をまずは覚えよう 1.作業ツリーとローカル/リモートリポジトリ 作業ツリーで行った編集は リモートリポジトリにCOMMITしよう！！ 他人の変更を取り込む ローカル環境内 バージョンを管理する ・変更を管理する ・Commitという単位の 変更履歴差分を積み重ねる 変更を保存 変更を共有 変更が発生 外部サーバー 作業マシン ローカル リポジトリ リモート リポジトリ
36. この関係をまずは覚えよう 2.作業ツリーとローカル/リモートリポジトリ サーバにあるリモートリポジトリを ローカルに複製する ローカル環境内 Clone 変更を保存 変更を保存 変更が発生 変更が発生 Checkout 外部サーバー ローカルリポジトリの中から 作業ツリーにするブランチを切り替える ローカル 作業マシン リポジトリ リポジトリ内でh、複数のブランチに分け リモート てコミットヒストリーを管理する リポジトリ
37. 3. add/commit/push/fetch/pull/(STASH) 作業する Addしてステージング add commit Pushして サーバーに格納 push →commitして保存 fetch stash 一時的に変更を 退避する pull リモートリポジトリとの同期を取る ※HEAD（ヒストリーの最新）を更新 する。 リモートリポジトリのソースを 作業ツリーへのソース反映は行わない。 取得する ※同ファイルに変更がある場合、 オートマージされる 作業ツリー ローカル リポジトリ リモート リポジトリ
38. 3. add/commit/push/fetch/pull/(STASH) add commit $ git add . push $ git commit –m ‘コミットメッセージ’ Pullする前は必ずfetch!! $ git push このあたりはGUIが おすすめ fetch stash $ git fetch $ git pull pull $ git stash $ git stash apply stash@{0} 一時退避 →退避リストの0番目に戻す 作業ツリー ローカル リポジトリ リモート リポジトリ
39. コンフリクト Stash / ん？ん？
40. 100% コンフリクトしたら回避する方法
41. 4.reset たとえば… ローカル環境内 • 動く状態に戻したい • Checkoutしたらcommitが溜まってた! • 別の人がpushした！ ※自分の作業はgit stashしておこう こんなときに使える この変更を取り消したいとき $ git reset –hard origin/branch 変更をcommit/push 作業ツリー オプション沢山はあるので 必要になったら調べてみて ブランチ名：branch リモートリポジトリ ローカル 外部サーバー内 リポジトリ ブランチ名：origin/branch
42. 5.rebase たとえば… • 親ブランチに、他ブランチがマージされた! 自分のブランチにその修正を取り込みたい こんなときに使えるよ ローカル環境 ヒストリーの順序を壊さずに自分の ブランチにマージする $ git rebase --rebase-merges origin/develop 外部サーバー内 別の人が同じブランチに commitしたヒストリー 親ブランチから 子ブランチを作成 オプション沢山はあるので 必要になったら調べてみてね 作業ツリー リモートリポジトリ ブランチ名：branch ブランチ名：origin/develop
43. 6.rebaseチートシート # 親子ブランチのローカルリポジトリを綺麗にする $ git checkout branch $ git reset --hard origin/branch $ git checkout develop $ git reset --hard origin/develop ローカル環 境 # 親ブランチに対して、子ブランチをリベースする $ git checkout branch $ git rebase --rebase-merges origin/develop 外部サーバー内 # con ict(競合)が発生したら手動修正してpush→リ ベースを続行する $ git rebase --continue 作業ツリー リモートリポジトリ # リベースを取りやめて元に戻す $ git rebase --abort ブランチ名：branch ブランチ名：origin/develop fl # 全てのリベースが終わったらpush $ git push -f origin/branch
44. 100% 無理しない編 ハンズオンの題材はCloudFormationテンプレート1枚がちょうどいいです。テキストなのでdiffが見やすく、「コンフリクトをわざと起こして解決する」が自然にできて、そのままCodePipelineに繋がる導線も見せられます。 コンフリクトしたら回避する方法
45. コンフリクトはなかったことにする Tips. コンフリクトは なかったことにする だっする コンフリクト １：作業ブランチを名前変えて ２：今一度最新をClone ３：作業した差分をコピペする
46. 恐れない使い方 Tips. 恐れない使い方 ブランチを分けよう 1人1ブランチ または 1機能1ブランチ の単位でブランチを作成しよう だっする コンフリクト チケットにひもづけよう タスク内容・コミットヒストリー・プルリクエスト(マージリクエスト)・備忘録etc…全て一括で管理する 毎日保存しよう PCはいつ壊れるかわからない。 マメにpushしよう！リモートリポジトリは動く状態を維持すること コミュニケーションを取ろう！ 特に同じブランチを共用している場合は、COMMITが重なって競合する可能性もあります 「PUSHしました」「OK、PULLしまーす」のやり取りの声がけって意外と大事！ なによりもコメントはしっかり書くこと。AIもgit 利用時のコメントはしっかり書いてるよ Commitログを見よう COMMITログを見る習慣をつけていけばリベースも怖くない リリース担当・変更管理担当者は必ず全体把握しておくこと ※みんなのソースの書き方から学べることも沢山ある
47. 恐れない使い方 Tips. Git戦略 フィーチャーブランチ コツ： ・自分の作業 と だっする Git管理 他人の作業を分けよう ・・・ 自分の開発分 ・Masterhaブランチは永久保存版最後の砦 ・・・ Master の一歩前に ・リリースしたら・する時タグをこまめに切る Featureブランチ切る DevとかProd ブランチ切っておく ・・・ ・バージョンはこまめに分ける（アプリ、ライブラリ、共通、インフラ、システム） ※まとめると組み合わせや再リリースで死ぬ ・タグを打ち、リリース計画をチケット管理して 使い倒そう とくにDB・バックアップの紐付けは大事 ※Brunch戦略 に 過去の開発の失敗を思い返そう（#ifdef で区切ってた C言語の悪夢をやめよう）
48. 恐れない使い方 雑学. タグの名前を変更する 雑学： タグの名前を変更する $ git tag 新しいタグの名前 古いタグの名前 $ git tag -d 古いタグの名前 だっする Git管理 一つのコミットに対して複数のタグを打つことが出来る。 なので、変更後のタグを追加し、そのあとで古いタグを削除してしまえば、 リネームできる。 ※GitHubには タグのほかに リリース というもう一つのリリース計画に つけられるタグ独自の拡張機能がある。 ※ラベルというものもある、タグとラベルを使い分けるとコード管理はさらに 便利になる
49. スタバde たーーん
50. ってする前に素直になること たよろう
51. すなおにGUIを使うって大事 無理すんなって で https://tortoisegit.org/ Win merge もおすすめ https://winmerge.org/?lang=ja
52. すなおにGUIを使うって大事 mac もいける SnailGitで無理すんなって TortoiseGitと同じように Finderのコンテキストメニューから利用ができる ファイルの状態もオーバーレイ機能してくれる機能をもってる Lite版（無償）もある fi https://apps.apple.com/us/app/snailgit-git-for- nder/id847260112?mt=12
53. すなおにGUIを使うって大事 mac もいける CompareMergeで無理すんなって 変更点の可視化は直感的かつスピード感が大事 リアルタイム同期やファイル対応、マージ機能があるってとても大事 アプリ内課金がある
54. Git GitHub GitLab Bitbucket 違いは何？ お便りコーナー
55. お便りコーナー Git GitHub GitLab Bitbucket GitBucket コマンド Saasサービス Duo 事実上の標準 Git文化の尖った会社 サービスでは2024年にAmazonQDeveloperと組み合わせる 開発コミュニケーションツール 自前サーバとSaasの選択肢がある OSSとして国産のGitサーバとして提供され 様々な機能も提供される
56. どう違うどう使う？ 提供形態 認証 GitHub SaaS （Enterprise Serverで自社設置可） CI/CD GitHubアカウント Actions GitLab SaaS + セルフホスト （CE無償） 独自 / LDAP / SAML GitLab CI （同梱） Bitbucket SaaS + Data Center Atlassianアカウント Pipelines GitBucket OSSを自分で建てる （Scala/WARを配置するだけ） 自前DB / LDAP なし （Jenkins等利用） fl CodeCommit AWSマネージド IAM CodePipeline （HTTPS/SSH CodeBuild git-remote-codecommit） 向いている場面 事実上の標準。 OSS・採用・学習コスト すべて最安 Issue〜デプロイまで 1製品で完結させたい組織 Jira / Con uence を 既に使っている現場 閉域網・オンプレ、 外部SaaSが使えない現場 AWS内で完結させたい IAMで権限を一元管理したい
57. お便りコーナー Git GitHub GitLab Bitbucket ぎふはぶ コマンド 事実上の標準 Duoからの今 チケット駆動 SAY YES
58. Git GitHub GitLab Bitbucket ぎふはぶ コマンド 事実上の標準 Duoからの今 チケット駆動 SAY YES 何でもGitで管理する組織
59. お便りコーナー エンジニアは ・ドキュメント書くの不得意 ・コードのテスト面倒にしがち ・ビルドで待ちぼうけ（レビューしたい） そんな あなたにDUO @2024 re:invent で先取り
60. GitLab DUO
61. みんなの学んでいるIAM IdentityCenter AWS CodeCommit へのアクセスには認証情報が必要です。これらの認証情報には、CodeCommit リポジトリなどの AWS リソー スへのアクセス権限、および Git 認証情報や Git 接続に使用する SSH 公開鍵を管理するために使用する IAM ユーザーへのアクセ ス権が必要です。以下のセクションでは、AWS Identity and Access Management (IAM)と CodeCommit を使用してリソースへのア クセスを保護する方法について詳しく説明します。
62. AWS を今一度 すべてを提供する （息切れ、追いつき） 最低限を包括する （必要なものを好きなだけ追加できる）
63. おすすめ自分でハンズオンの題材 CloudFormationテンプレート1枚がちょうどいいです。 テキストなのでdi が見やすく、 「コンフリクトをわざと起こして解決する」が自然にできて、 ff そのままCodePipelineに繋がる導線もまなべる。
64. あいてがわかるまで教えることが大事 おしえること はまりどころ、メモを追加して代々引き継いでいく それはお互いに、リスペクトすること