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
【地域おこし勉強会 第2回】Git勉強会【2023/10/18】
Search
hirotask
October 10, 2023
0
30
【地域おこし勉強会 第2回】Git勉強会【2023/10/18】
hirotask
October 10, 2023
Tweet
Share
More Decks by hirotask
See All by hirotask
【備忘録】ニューラルネットワークとはなにか
hirotask
0
17
【地域おこし勉強会】仮想化技術入門
hirotask
0
41
【地域おこし勉強会 第3回】ソフトなソフトウェアを作る【2023_10_25】
hirotask
0
22
【Tech Community LuMo】第1回 バックエンド勉強会
hirotask
0
24
【2023/04/28 東北Tech道場】東北Tech道場に入ったら いつの間にかAndroiderになっていた話
hirotask
0
72
エンジニアもパワポを使って アウトプットしたほうが良い
hirotask
0
120
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
50
7.2k
What's in a price? How to price your products and services
michaelherold
243
12k
Happy Clients
brianwarren
98
6.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Writing Fast Ruby
sferik
627
61k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
890
Site-Speed That Sticks
csswizardry
0
26
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
4 Signs Your Business is Dying
shpigford
180
21k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Transcript
Git勉強会 波紫寛斗(はし)
目次 1. 本勉強会の目的 2. 諸注意 3. 入門編(リポジトリ~プッシュ) 4. 発展編(ブランチ~プルリクエスト) 5.
参考文献
本勉強会の目的 • 以下のようなGitの基本用語を学ぶ ◦ リポジトリ ◦ コミット ◦ プッシュ ◦
プル ◦ ブランチ etc … • Git-Flowを学ぶ • VSCodeを用いてGitの基本操作が行える
諸注意 • 開発環境はVSCodeを使う • GitHubでは2要素認証が推奨されているため、後日設定必須 • 本勉強会ではCloneの際にHTTPS通信を用いるが、SSH接続のほうがセキュリティ 上は良いため、実際の開発の際はSSHを用いる • GitHubのアップデートの際にUIが変わる可能性があるため、演習のスライドは操作
が若干変わる可能性がある
1.入門編(リポジトリ~プッシュ)
Gitとは • プログラムのバージョン管理ツール ◦ ファイルの「第〇版」とか、ソフトの「 Ver.◦◦」みたいなものをラクに管 理 できるツール • 制作者はLinuxカーネルの生みの親の
リーナス・トーバルズさん • Gitで管理しているプログラムを公開するサイトがGitHubや GitLab
なぜGitが必要なのか? • ファイルで管理していると以下のことが起こる ◦ 無秩序に名前を付けてしまった場合、どのファイルが最新のものか区別できない ◦ チームで共有している場合、作業内容を一目で把握できない ◦ 二人同時に同じ名前でファイルをアップロードした場合、先にアップロードした人の変更が消える 引用:サル先生のGit入門(https://backlog.com/ja/git-tutorial/intro/01/)
履歴を管理するリポジトリ(Repository) • リポジトリ(Repository):状態を保存しておくための場所 • リポジトリは以下の2種類にわけられる ◦ ローカルリポジトリ:ユーザ一人ひとりが利用するために、自分の手元のマシン上に配置 するリポジトリ ◦ リモートリポジトリ:専用のサーバに配置して複数人で共有するためのリポジトリ
• そのため、GitHub上で作成するのはリモートリポジトリ 引用:サル先生のGit入門(https://backlog.com/ja/git-tutorial/intro/02/)
ワークツリーとインデックス • ワークツリー:作業者が作業しているディレクトリ • インデックス:コミットするファイルを一時的に保持しておくための場所
変更を記録するコミット(Commit) • コミット(Commit):ファイルの追加・変更をリポジトリに記録すること • コミットを実行すると、直前のコミットからの差分(diff)が作成される • コミットは下図のように時系列でリポジトリ上に管理されている • コミットを遡ることで、過去の変更履歴やその内容の把握が可能
【コラム】分かりやすいコミットメッセージ • コミットをする際には、その変更内容を「コミットメッセージ」に記す必要がある • コミットメッセージはプロジェクトによって書き方が異なる • 以下のような書き方が存在する 1行目:[add]: hoge.pyを追加 1行目:変更内容の要約
2行目:空行 3行目:変更した理由
【コラム】過去のコミットを書き換える • revert:過去のコミット打ち消す • reset:過去のコミットを捨てる • cherry-pick:過去のコミットから抜き取る • rebase -i:コミット履歴を書き換える
リモートリポジトリにプッシュ(Push)する • プッシュ(Push):リモートリポジトリに変更履歴をアップロードする • Pushを実行すると、リモートリポジトリに自分の変更履歴がアップロードされて、リ モートリポジトリ内の変更履歴がローカルリポジトリと同じになる
リモートリポジトリをクローン(Clone)する • クローン(Clone):リモートリポジトリを丸々ダウンロードして、ローカルリポジトリとし て利用すること • Zip形式でダウンロードする場合と違う点: ◦ コミット履歴が保持されている ◦ プル(後述)が可能
◦ ブランチ(後述)もダウンロードできる
リモートリポジトリからプル(Pull)する • プル(Pull):リモートリポジトリからローカルリポジトリを更新すること • プルを行うことで、リモートリポジトリから最新の変更履歴をダウンロードしてきて、 自分のローカルリポジトリにその内容を取り込む
演習
GitHubのアカウントを作成する 以下のサイトの手順に従ってGitHubのアカウントを作成する https://reffect.co.jp/html/create_github_account_first_time/
VSCodeのインストール 以下のサイトを参考にして、Stable版のインストールを行う https://www.javadrive.jp/vscode/install/index1.html#section1 【注意】VisualStudioとVisualStudioCode(VSCode)はアイコンが似ているから注意!
ディレクトリの作成をして、VSCodeで開く • 今回はデスクトップ上に「Benkyoukai」という名前 のディレクトリを作成 • ディレクトリ名は以下のルールに基づいて作成す る ◦ 日本語を含まない ◦
スペースを使用しない ◦ 全角文字を使用しない • 作成後、右クリックを押してCodeで開くをクリック
リポジトリの初期化 左サイドバーの上から2番目のアイコンをクリックし、 「リポジトリを初期化する」をクリックする
ファイルを追加する • 一番上のアイコンをクリックし、左側のス ペースで右クリックを押し、ファイルを追加 する • 今回追加するファイルは「README.md」 (Markdown記法で書かれたREADMEファ イル)
ファイルをインデックスに追加し、コミット • 2番目のタブに移動し、対象ファイルにカーソルを合わせて「+」ボタンを押すことで ファイルをインデックスに追加できる • 追加後、上の入力欄にコミットメッセージを入力し、「コミット」ボタンを押すことでコ ミットできる
GitHubにリモートリポジトリを作成する • 「Repositories」タブの「New」ボタンをクリックする • 以下の項目を入力する ◦ Owner:リポジトリのオーナー(普通は変更不要) ◦ Repository Name:リポジトリ名(今回は
Benkyoukaiがいいかも) ◦ Description:リポジトリの説明(記入は任意) ◦ Public/Private:リポジトリを他のユーザーに公開するか否か
リモートリポジトリのURLをコピーする 作成後、画像の赤線の位置にあるURLをコピーする
リモートリポジトリの設定をする • 再度VSCodeを開き、2番目のアイコンをクリックする • 「・・・」ボタンをクリックし、リモート→リモートの追加をクリックする • 先ほどコピーしたURLを貼り付けてEnter • その後、リモート名を「origin」と入力してEnter
プッシュする • 「ブランチの発行」ボタンをクリックすることでプッシュできる • プッシュが完了したらGitHubの画面は以下の画像のようになっているはず
2.発展編(ブランチ~プルリクエスト)
ブランチ(Branch) • ブランチ(Branch):コミット履歴の流れを分岐して記録していくためのもの • 分岐したブランチは他のブランチの変更の影響を受けない ◦ →同じリポジトリ内で並行作業が可能 • 各ブランチで変更後、それらをマージ(merge: 統合)すれば一つにまとまる
ブランチの運用とGit-Flow • ブランチを適切に分けるには、運用ルールを決 める必要がある ◦ ルールなしにブランチを分けると、どの変更がどのブラ ンチか分からなくなりカオス • Git-Flow:Gitにおけるブランチ分岐モデル ◦
master: プロダクトとしてリリースする用のブランチ。リリースした らタグ(後述)を付ける ◦ hotfix: リリース後の緊急対応(クリティカルなバグフィックスなど) 用。 ◦ release: プロダクトリリースの準備用ブランチ ◦ develop: 開発用ブランチ ◦ feature: 機能の追加用。developから分岐し、developにマージす る https://cloudsmith.co.jp/blog/efficient/2020/0 8/1534208.html
ブランチの切り替え • チェックアウト(Checkout):ブランチを切り替えること • チェックアウトを行うと、まず移動先のブランチ内の最後のコミットの内容がワークツ リーに展開 • HEAD:現在使用しているブランチの先頭を表す名前 • チェックアウトする→HEADが切り替わる
ブランチの統合(mergeとrebase) • マージ(merge):二つのブランチを統合し、統合コミットを追加する merge • リベース(rebase):統合先ブランチの次に、統合元ブランチの変更履歴を加える rebase
【コラム】mergeとrebaseの使い分け マージ(merge)とリベース(rebase)はどちらもブランチを統合するが、性質が異なる • マージ ◦ 変更内容の履歴はそのまま残るが、履歴が複雑になる • リベース ◦ 履歴は単純になるが、元のコミットから変更内容が変更される。そのため、元のコミットを動かない
状態にしてしまうことがある。 例えば、featureブランチにdevelopブランチの内容を取り込む時は、developブランチの 環境で新機能を動作させたいため、その場合はあえてrebaseを使う
マージでの競合とその解消 • ブランチAとブランチBで作業を行い、それらを一つのブランチにマージする場合、 同じファイルを変更していたらどちらのブランチの変更を取り込めば良いか問題に なる • 競合(Conflict):ブランチを統合する際に起こる変更箇所の重複 • 競合の解消方法: ◦
どちらか一方の変更履歴をすべて取り込み、もう一方は消去する ◦ 2つの変更履歴をミックスさせて取り込む
タグ • タグ(Tag):特定のコミットを参照しやすくするために名前を付けること。よくバージョ ン名を付けるのに使われる。 • タグの種類 ◦ 軽量タグ:名前をつけるだけ ◦ 注釈付きタグ:名前&コメント&著名をつけられる
プルリクエスト • プルリクエスト(PR: Pull Request):ブランチをマージする前に、変更内容を他の開 発者に通知する機能(マージの前段階) • プルリクエストを行うことで、他の開発者がレビューしてくれるので品質を担保でき る •
プルリクエストはGitの機能ではなく、GitHub独自の機能 プルリクエストを使わない開発プロセス プルリクエストを使う開発プロセス
イシュー • イシュー(Issue):そのプロジェクト内のタスク(やること)を管理する機能 • プルリクエストと併せて利用することが多い ◦ Issueを確認→開発→プルリクエストを提出 →レビュー→マージ • IssueはGitの機能ではなく、GitHub独自の機能
演習
ブランチを作成する • 左下の「main」と書かれている箇所をクリックする • 上部に出現する入力欄に「develop」と入力し、Enterを押すことで、mainブランチか らdevelopブランチを作成できる
ブランチで作業をしてコミット • 左下が「develop」の場合に新たにコミットをすると、developブランチ上にコミットし たことになる • README.mdを編集して、コミットしてみよう
作業内容をプッシュする • 「Branchの発行」を押すと、ブランチをリモートリポジトリ上に作成し、今までのコミッ ト履歴をプッシュすることができる
プルリクエストを発行するー① • mainブランチ以外に更新があった場合、画像のような表示が出ているはず • 「Compare & Pull Request」をクリックするとプルリクエストを作成画面に遷移する
プルリクエストを発行するー② ←Pull Requestのマージ先の設定 ←レビュー依頼する人 ←作業者 ←ラベル ←プロジェクト ←関連するマイルストー ン 詳細な内容→
タイトル→
参考サイト • https://backlog.com/ja/git-tutorial/ • https://qiita.com/fruscianteee/items/6ab6d4381a88269ce336