Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Git / 2023 ニフティ新人研修
Search
ニフティ株式会社
PRO
December 14, 2023
Technology
0
550
Git / 2023 ニフティ新人研修
2023年度ニフティエンジニア新人研修の講義資料です。
ニフティ株式会社
PRO
December 14, 2023
Tweet
Share
More Decks by ニフティ株式会社
See All by ニフティ株式会社
GitHubで育つ コラボレーション文化 : ニフティでのインナーソース挑戦事例 - 2024-12-16 GitHub Universe 2024 Recap in ZOZO
niftycorp
PRO
0
510
Grow on GitHub Collaboration Culture: Case Study of InnerSource Challenge - GitHub Universe 2024 Recap in ZOZO
niftycorp
PRO
0
22
これが俺の”自分戦略” プロセスを楽しんでいこう! - Developers CAREER Boost 2024
niftycorp
PRO
0
200
継続的な改善のためのmodulesの適切な分割単位 - NIFTY Tech Talk #23
niftycorp
PRO
0
110
Re:ゼロから始めるTerraform生活 ~IaC入門編~ - NIFTY Tech Talk #23
niftycorp
PRO
0
120
Terraformにベストプラクティスを取り入れた - NIFTY Tech Talk #23
niftycorp
PRO
0
140
AWS AppSyncを用いた GraphQL APIの開発について - NIFTY Tech Talk #22
niftycorp
PRO
0
150
「天気予報があなたに届けられるまで」 - NIFTY Tech Talk #22
niftycorp
PRO
0
170
@nifty天気予報:フルリニューアルの挑戦 - NIFTY Tech Talk #22
niftycorp
PRO
0
160
Other Decks in Technology
See All in Technology
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
32k
「完全に理解したTalk」完全に理解した
segavvy
1
210
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
250
非機能品質を作り込むための実践アーキテクチャ
knih
6
1.7k
TypeScript開発にモジュラーモノリスを持ち込む
sansantech
PRO
3
760
watsonx.ai Dojo #5 ファインチューニングとInstructLAB
oniak3ibm
PRO
0
250
React Routerで実現する型安全なSPAルーティング
sansantech
PRO
2
340
サイボウズフロントエンドエキスパートチームについて / FrontendExpert Team
cybozuinsideout
PRO
5
39k
型情報を用いたLintでコード品質を向上させる
sansantech
PRO
2
160
事業貢献を考えるための技術改善の目標設計と改善実績 / Targeted design of technical improvements to consider business contribution and improvement performance
oomatomo
0
170
ハイテク休憩
sat
PRO
2
190
[Oracle TechNight#85] Oracle Autonomous Databaseを使ったAI活用入門
oracle4engineer
PRO
1
160
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
32
6.3k
Bash Introduction
62gerente
609
210k
The Cult of Friendly URLs
andyhume
78
6.1k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Done Done
chrislema
182
16k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
3
310
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Designing for Performance
lara
604
68k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Transcript
Copyright © NIFTY Corporation All Rights Reserved. 初めてのバージョン管理(Git) 2023年度 エンジニア定例
Copyright © NIFTY Corporation All Rights Reserved. バージョン管理システムについて
Copyright © NIFTY Corporation All Rights Reserved. バージョン管理システムについて 3 バージョン管理って何︖
バージョン管理⽅法 バージョン管理とは、⼀つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するというものです。 例)発表スライドなどの資料を修正するたびに上書き保存するのではなく、新規に保存するとどこを変更したかが⽬に⾒えて分かりま す。 • ファイル名 • ソフトウェア構成管理(SCM︓Source Control Management)
Copyright © NIFTY Corporation All Rights Reserved. バージョン管理システムについて 4 ファイル名のバージョン管理
ファイル名にバージョンを付与して管理する ファイル名に更新者をプラスして管理する ファイル名に変更内容もプラスして管理する →だれが更新したのか不明 → 変更箇所が不明 → ⾒づらい・⻑い
Copyright © NIFTY Corporation All Rights Reserved. 5 複数⼈で同じファイルを 編集している時を考える
Copyright © NIFTY Corporation All Rights Reserved. 6 Aさんがローカルで編集中のファイルをBさんがダウンロードする
Copyright © NIFTY Corporation All Rights Reserved. 7 Bさんがローカルで編集中にAさんがファイルを更新する
Copyright © NIFTY Corporation All Rights Reserved. 8 Aさんがファイルを更新したことを知らずにBさんがファイルを更新すると...
Copyright © NIFTY Corporation All Rights Reserved. 9 Aさんの変更内容が消滅してしまう
Copyright © NIFTY Corporation All Rights Reserved. ファイル名での管理は⼤変︕︕ 事故が起こりやすい︕ 10
SCMを使おう
Copyright © NIFTY Corporation All Rights Reserved. SCMとは? 11 さっきの開発の流れをSCMで説明してみる
ファイルや設定を保管する場所のこと
Copyright © NIFTY Corporation All Rights Reserved. 12 Aさんがファイルを更新、ファイルとAさんの変更履歴を保存する
Copyright © NIFTY Corporation All Rights Reserved. 13 Aさんの更新後Bさんがファイルを更新、ファイルとBさんの変更履歴を保存 変更の衝突が起こらない︕︕
Copyright © NIFTY Corporation All Rights Reserved. SCMのメリット 14 •
ファイル名が煩雑にならない ◦ リポジトリで全てのバージョンの履歴を保持しているため、ファイル名 が同じでも変更内容を確認することができます • 変更内容の履歴をたどれる ◦ リリース後に何か問題が発⽣した際、どこで問題が発⽣したか追跡しや すい ◦ 問題が発⽣する前のバージョンに戻せば、すぐにシステムを復旧できる • 素早い開発が可能になる ◦ バージョン管理が効率的に⾏われており、素早い開発に貢献
Copyright © NIFTY Corporation All Rights Reserved. Gitの特徴とメリット 15 特徴
• 分散型バージョン管理システム • Linuxのような⼤規模プロジェクトにも対応できる設計 • 動作速度に重点が置かれている メリット • 動作が軽い • ブランチ(後から説明します)が容易に使える • 分散開発がしやすい
Copyright © NIFTY Corporation All Rights Reserved. GitのGUIとCLI 16 VScodeの拡張機能など
GUIツール • VSCode <- 今回紹介 • TortoiseGit ◦ 社内でも使われているらしい • 各種IDE ◦ 開発環境にGitの機能が組み込まれている場合もある • Git Graph <- 今回紹介 • GitLens • GitHub Pull Requests
Copyright © NIFTY Corporation All Rights Reserved. GUIとCLIのメリット、デメリット 17 GUI
• メリット ◦ 操作が直感的でわかりやすい ◦ 視覚的にもわかりやすい場合がある ▪ 変更差分の確認 ◦ コマンドを覚えなくて良い • デメリット ◦ どのGUIツールを使うかによ って操作⽅法が変わる CLI • メリット ◦ The Engineer感があってCOOL!!で ある ◦ 基本的にどの環境でもコマンドの内 容は変わらない • デメリット ◦ 場合によってはわかりずらい ▪ コンフリクトの解消やGit ツリーの確認など ◦ コマンドを覚えなければなら ない
Copyright © NIFTY Corporation All Rights Reserved. Gitの基本的操作
Copyright © NIFTY Corporation All Rights Reserved. リモートリポジトリとローカルリポジトリ 19 ローカルリポジトリ
リモートリポジトリ • サーバー上に配置して複数⼈で共有するリポジトリ • 他の⼈と共有するために存在する • 開発者⼀⼈⼀⼈が⾃分のマシン上に配置するリポジトリ • リモートのファイルをローカル(個⼈のPC)に持ってきて作業を⾏い、 更新をリモートへ共有するイメージ
Copyright © NIFTY Corporation All Rights Reserved. 20 ファイル名のバージョン管理 ローカルリポジトリ内のファイルは2つの状態に分けられる
trackedのファイルは3つの状態に分けられる • 追跡されている(tracked) ◦ 変更内容を保存するファイル • 追跡されていない(untracked) ◦ 変更内容を保存してないファイル • 変更されていない(unmodified) • 変更されている(modified) • ステージされている(staged)
Copyright © NIFTY Corporation All Rights Reserved. ローカルリポジトリに変更内容を記録するまで 21 リポジトリ内にindex.txtというファイルを新規作成
• index.txtは追跡されていない(untracked)状態のファイル ◦ VSCodeの場合「U」が付く index.txtを追跡(tracked)状態にして、ステージする • 左側のマークからもステージできる(右図) ◦ 未追跡のファイルが表⽰されているので カーソルを重ねると出る「+」マークをクリック • ステージされている変更に移動すればOK︕ git add index.html
Copyright © NIFTY Corporation All Rights Reserved. 22 index.txtの変更内容をコミットする •
コミットとは ◦ 変更内容をリポジトリに記録し保存すること git commit -m 'ここにコミットメッセージを書く' • こういう変更をしたよ ◦ ex ) 削除機能の追加 • ⾃分がやってるタスクの名前 ◦ 何のタスクのための削除機能なのか、わかりやすくなる コミットメッセージを書く • ①コミットメッセージを書き、②チェックボタンを押すことでもコミットできる(右下図) コミットメッセージの例
Copyright © NIFTY Corporation All Rights Reserved. 23 index.txtを編集する •
変更(modified)状態になる ◦ VSCodeの場合保存するとファイル名の⾊が変わって「M」が付く
Copyright © NIFTY Corporation All Rights Reserved. .gitignoreについて 24 Git上で管理したくないファイル
• Gitでは基本的に全てのファイルを管理する • ⼀⽅で、開発の中ではGit上で管理したくないファイルがある ◦ パスワードの記述されたenvファイルなど • Git上で管理したくないファイルをGitに教えるためのファイルがgitignoreファイル
Copyright © NIFTY Corporation All Rights Reserved. .gitignoreファイルの書き⽅ 25 基本の書き⽅
コメントアウト 相対パスで指定されるファイル or ディレクトリを無視する • .gitignoreという名前のファイルを作り、中に無視したいファイル名を記述 # "#" で始まる⾏はコメント # binファイルとbinディレクトリを無視する /bin # binディレクトリを無視する /bin/ • .gitignoreが置いてあるディレクトリがカレントディレクトリとなる
Copyright © NIFTY Corporation All Rights Reserved. 26 gitignore内の全サブディレクトリ下にあるこの名前のディレクトリを無視する #
以下のように頭に/(スラッシュ)をつけずに記述する bin/ • トップにあるディレクトリだけではなく 以下のような深い層にあるディレクトリも無視される • /test/bin/ • /src/bin/
Copyright © NIFTY Corporation All Rights Reserved. 27 !以降のパターン⽂字列が⽰すファイル or
ディレクトリを無視しない① # 以下のように書くとsrcディレクトリを無視しないことを設定できる !/src/ • !は全てのファイルとディレクトリを無視する対象から除外できないパターンがある ◦ 例えば以下の例ではhoge/hoge.txtファイルは除外されない # hogeディレクトリを無視する /hoge/ # hoge.txtを無視から除外できない !/hoge/hoge.txt
Copyright © NIFTY Corporation All Rights Reserved. 28 • このようなことを処理として行いたい場合、
ディレクトリ以下のファイル全体を無視する対象にして記述する必要がある。 # ディレクトリではなく、ディレクトリ以下のファイル全体を無視するように指定 # *はワイルドカード(次のページで説明) /hoge/* # 上記のファイルの中のhoge.txtは無視しない !/hoge/hoge.txt • hoge/ディレクトリを無視しまっている場合は その階層以下のファイルやディレクトリを無視する対象から除外できない !以降のパターン⽂字列が⽰すファイル or ディレクトリを無視しない②
Copyright © NIFTY Corporation All Rights Reserved. 29 ワイルドカード *.exe
• gitignoreでは*と? 、**、[]がワイルドカードとして使⽤できる ◦ 「*」︓ /以外の0⽂字以上の⽂字列にマッチ ◦ 「?」︓/以外の1⽂字にマッチ ◦ 「[0-9]」︓/以外の指定した1⽂字にマッチ ◦ 「**」︓0個以上のファイル or ディレクトリにマッチ package/**/*.ts • ex1)特定の拡張子の無視 • ex2)特定のディレクトリ内の特定の拡張子を無視
Copyright © NIFTY Corporation All Rights Reserved. 30 エスケープ •
「¥」を使うことでエスケープ可能 gitignoreの注意点 • gitignoreは記載された時点でGitの追跡対象から除外されるわけではない ◦ まだ追跡されていないファイルが指定されている場合に、追跡を開始しないようになる # ?をエスケープしている ¥?*# → ⼀度追跡に⼊れてしまった場合は、追跡対象から外した後にgitignoreで指定する必要があ る
Copyright © NIFTY Corporation All Rights Reserved. 31 Gitの基本的操作 演習
Copyright © NIFTY Corporation All Rights Reserved. 演習を進める事前準備 32 Gitの準備
• Git for Windowsをインストールしましょう ◦ インストールが完了したら Launch Git Bash にチェック ◦ Git Bashが開いたら以下のコマンドでバージョンが表⽰されることを確認 git --version VSCodeの準備 • VSCodeをインストールしましょう • 以下の拡張機能を⼊れると便利 ◦ 「Japanese Language Pack for Visual Studio Code」︓⽇本語化 ◦ 「Git Graph」︓主にコミット履歴の確認
Copyright © NIFTY Corporation All Rights Reserved. Gitの初期設定 33 ⾃分の情報を設定する
• ちゃんと設定できたか確認するには次のコマンドを⼊⼒ $ git config --global user.name "名前" $ git config --global user.email "メールアドレス" $ git config --global core.autocrlf input $ git config user.name //⼊⼒した名前が表⽰される $ git config user.email //⼊⼒したメールアドレスが表⽰される $ git config core.autocrlf //inputが表⽰される
Copyright © NIFTY Corporation All Rights Reserved. ローカルリポジトリを作ってみよう① 34 任意の場所にディレクトリを作成し、VSCodeで開く
$ mkdir git-lesson1 $ ls //git-lesson1があればOK $ cd git-lesson1 //「cd g」まで⼊⼒してtabを押すとパッと出て来るはず $ code . //VSCodeで開き直す 任意の場所にディレクトリを作成し、VSCodeで開く
Copyright © NIFTY Corporation All Rights Reserved. ローカルリポジトリを作ってみよう② 35 任意の場所にディレクトリを作成し、VSCodeで開く
$ git init Initialized empty Git repository in /UsersPath/git-lesson1/.git/ リポジトリの初期化 • 右図の⾚丸で囲まれたマークを押して 「リポジトリを初期化する」をクリック • git initでgitの初期化 • .gitディレクトリが作成されたことを確認 $ ls -la GUI操作で初期化する場合
Copyright © NIFTY Corporation All Rights Reserved. ファイルを追加して、コミットしてみよう 36 任意の場所にディレクトリを作成し、VSCodeで開く
やってみよう • index.html、.gitignore、ignore.txtというファイルをディレクトリ直下に作成 • .gitignoreファイルの中に以下のように記述 ignore.txt • 作成した3つのファイルをステージしようとしてみる ◦ ignore.txtがステージ出来ないことを確認 • コミットメッセージを書いてコミットする
Copyright © NIFTY Corporation All Rights Reserved. ファイルを編集して、コミットしてみよう 37 任意の場所にディレクトリを作成し、VSCodeで開く
やってみよう <!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf- 8"> <title></title> </head> <body> </body> </html> git log index.htmlを以下で上書きしコミット 今までのコミット履歴を⾒てみる • 上に表⽰されているものほど新しいコミット • vscodeの⼈は「Git Graph(拡張機能)」 を ⼊れて⾚丸で囲まれたマークから確認
Copyright © NIFTY Corporation All Rights Reserved. Gitのブランチについて
Copyright © NIFTY Corporation All Rights Reserved. Gitのブランチについて 39 ブランチとは
• 開発の本流から分岐し、本流の開発と切り離した状態で作業ができる機能のこと • 他の開発者に影響なく作業を⾏える。 • 機能単位・改修単位で作業を分割できる。 Main 例 Develop Feature 1 Feature 2 Ver1.1 Ver1.2 Ver2.0 本番環境 開発環境 機能追加開発⽤ ブランチ
Copyright © NIFTY Corporation All Rights Reserved. 40 主要な操作 $
git branch ブランチ⼀覧を確認する ブランチを作る $ git branch {ブランチ名} ブランチを切り替える(チェックアウト) $ git checkout {ブランチ名} $ git switch {ブランチ名} • switchはまだ実験的な機能で、今後動作が変わるかもしれない ブランチを合流する(マージ) ※親となっているブランチにチェックアウトしておくこと $ git merge {ブランチ名} or
Copyright © NIFTY Corporation All Rights Reserved. 41 コンフリクト(変更点の競合) •
同じファイルの同じ場所に異なる変更が加えられたとき、 コンフリクト(競合)が発⽣ ◦ どの変更を採⽤するかを⼀つ⼀つ⽬視確認し指定しなければいけない ◦ 開発中にコンフリクトを起こすと対応が必要になる
Copyright © NIFTY Corporation All Rights Reserved. 42 Gitのブランチについて 演習
Copyright © NIFTY Corporation All Rights Reserved. 実際にブランチを触ってみる 43 任意の場所にディレクトリを作成し、VSCodeで開く
$ git branch *main developブランチを作って切り替えてみよう • 今いるブランチを確認する • developブランチを作る $ git branch develop $ git branch develop * main • developブランチを切り替える $ git switch develop Switched to branch 'develop'
Copyright © NIFTY Corporation All Rights Reserved. 44 任意の場所にディレクトリを作成し、VSCodeで開く developブランチで修正を加える
• Gitの基本操作 演習で作ったindex.htmlを修正する ◦ titleタグの中⾝をhogeに修正 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>hoge</title> </head> <body> </body> </html>
Copyright © NIFTY Corporation All Rights Reserved. 45 任意の場所にディレクトリを作成し、VSCodeで開く 差分を確認してコミット
• 「-」が削除箇所、「+」が追加箇所 • 差分を確認して問題なければコミット(忘れた⼈は22ページへ) ◦ コミットする前に差分を確認する癖をつけましょう︕ $ git diff <html lang="ja"> <head> <meta charset="utf-8"> - <title>hoge</title> + <title>feature/A</title> </head> <body> コマンドで差分を確認 vscodeで差分を確認 • git diffで確認 • コミットできる画⾯でファイルをクリック
Copyright © NIFTY Corporation All Rights Reserved. 46 任意の場所にディレクトリを作成し、VSCodeで開く mainブランチに戻って、ファイルを確認
• 先ほどコミットしたのはdevelopブランチ ◦ mainブランチにはtitleの変更が反映されていないはず • mainブランチに戻り、index.htmlを確認してみよう $ git checkout main $ view index.html <!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title></title> </head> <body> </body> </html>
Copyright © NIFTY Corporation All Rights Reserved. 47 任意の場所にディレクトリを作成し、VSCodeで開く ブランチを合成(マージ)
• developブランチの変更をmainブランチへマージする $ git merge develop <!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>hoge</title> </head> <body> </body> </html> • index.htmlに、developブランチで⾏ったtitleの変更が反映されているのを確認
Copyright © NIFTY Corporation All Rights Reserved. 変更内容の⼀時退避を知る 48 任意の場所にディレクトリを作成し、VSCodeで開く
$ git checkout develop $ git switch -c feature/A featureブランチを作る • developブランチから派⽣するfeature/Aブランチを作り、切り替える • titleタグの中⾝をfeature/Aに変更 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="utf-8"> <title>feature/A</title> </head> <body> </body> </html>
Copyright © NIFTY Corporation All Rights Reserved. 49 任意の場所にディレクトリを作成し、VSCodeで開く git
stashで変更内容を⼀時的に退避する • git stash saveでキープ ◦ メッセージは後からわかるような内容にしよう︕(戒め) $ git stash save "stash message" • git stash listでキープ内容を確認 $ git stash list stash@{0}: On A: stash massage • 別ブランチに切り替えると、コミットしていない変更内容は消えてしまう ◦ ⼀時退避をすることで変更内容をコミットせずに残すことができる • index.htmlのtitleがhogeになっている(退避された)ことを確認 ⼀時退避してみる
Copyright © NIFTY Corporation All Rights Reserved. 50 任意の場所にディレクトリを作成し、VSCodeで開く 退避したものを戻す
$ git stash apply stash@{0} • ⼀時退避した内容を再度適⽤したい場合は以下のコマンドを叩く • index.htmlのtitleがfeature/Aになっている(適⽤された)ことを確認 • ⼀番上(stash@{0})の変更であれば以下のようにして適⽤することも可能 $ git stash pop $ git diff
Copyright © NIFTY Corporation All Rights Reserved. リモートリポジトリと その関連コマンドについて
Copyright © NIFTY Corporation All Rights Reserved. リポジトリを分ける理由 52 開発した内容の公開
リモートリポジトリ ローカルリポジトリ 履歴 履歴 ファイル ファイル 普段の開発作業と 他の⼈に公開するファイルを 分離することができる
Copyright © NIFTY Corporation All Rights Reserved. ホスティングサービス 53 GitHub
GitLab AWS CodeCommit • ホスティングサービスで最⼤⼿ • 多くのOSSが利⽤している • 社内でもGitHub Enterpriseを導⼊している ◦ GitHub Enterprise • 無料版でも使える機能が多い ◦ GitHubがほぼ全⾯的に無料化 • 無料で使える範囲はGitHubよりも広い • AWSが提供するホスティングサービス • AWSの他サービスとの連携が容易にできる ニフティでは主にGitHubを使⽤しています
Copyright © NIFTY Corporation All Rights Reserved. Pull Push Clone
リモートリポジトリに関わるGitコマンドの説明 54 リモートリポジトリのコピーとし て⼿元のPCにローカルリポジト リを作成すること ローカルリポジトリの作業内容を リモートに反映すること ローカルリポジトリに最新の内容 を反映すること git clone git push origin main git pull origin main
Copyright © NIFTY Corporation All Rights Reserved. 【余談】その他のコマンド 55 git
rebase git cherry-pick git filter-branch コミットの取り消し、変更の削除などを⾏うコマンド git reset 履歴をきれいにする。まとめてコミットを取り込む 直前のコミットを取り込む(他のブランチの余計なコミットを取り込まず、特定のコミットを取り込む) gitの履歴の削除を⾏う
Copyright © NIFTY Corporation All Rights Reserved.