Git/GitHub入門

Git/GitHub入門早稲田大学菅野研究室エンプラ資料

目次 1. Git/GitHubの紹介 2. 基本操作 3. 応用編

こんな経験ありませんか？ない？多分これから経験します最新版どれ？何が違うの？ (つーかyamadaって誰だよ......) コメント内に変更内容とその担当者が直接書かれている名前と日付から一概に判断できない 1人が変更コメントつけ忘れるだけで全く意味を為さなくなるチーム制作で各自が編集した
ファイルを統合するとき統合する人が大変すぎる → Gitを使えば全て解決！ mina, Git入門, https://speakerdeck.com/silmin_/gitru-men JOB SUPPORT, “新人SE・PG教育にも使える！ソースコード(Java)のコメントの書き方 ①”, https://job-support.ne.jp/blog/java-training/howto3

ざっくりしすぎた説明の例 GitやGitHubの名前を聞く機会は増えているが，「ソースコードをやりとりする感じのサイトなんだよね？」ぐらいの認識の人が多い．研究開発を行う上では避けて通れないので今日学ぼう．まずGitとGitHubは混同されることも多いが，別モノ． Git/GitHubとは Gitは元々Linux（macOSやUbuntu，Androidなど Windows以外のほとんどのOSの骨格）の開発に用いられていた．オープンソースであることも相まって急速に普及し，
この種のツールとしてはデファクトスタンダード． (他にApache Subversionなどもあるが触れません) Git: GitHub: ファイルのバージョンを管理・共有するツール． Gitのリポジトリ（ソースコード等の保存場所）を Web上で管理・公開するWebサービス． Gitの利便性を高めるためのものとして捉えると良い．クローズドな開発に特化したGitLabというツールもありますが，今回は特に触れません．今日使われるほとんどのOSの基礎となっているLinuxだが，Linus Torvaldsによる修士論文に端を発する． Linus率いるチームは元々BitKeeperというバージョン管理ツールを用いてLinuxを開発していたが，法的なトラブルにより使えなくなってしまったため，Gitの開発に着手することとなった． TIPS IT media NEWS, “GitHubは「設計図共有サイト」？日経記事の見出しが話題にその後修正”, https://www.itmedia.co.jp/news/articles/1806/05/news069.html

「別にDropboxとかGoogle Driveとかでもチームメイトとファイル共有できるやん」と言う人も多いが，本日の講義を聞けば「ソースコード管理はGit/GitHubしか勝たん」になる．ファイル共有サービス Git/GitHub ファイルのやりとりフォルダに保存したものが自動的にクラウド上のストレージと同期．明示的にプル/プッシュという操作を行うことで
同期．変更履歴の保存誤ってファイルを上書き・削除することもあるが，期間（サービスによるが30~90日）内であればゴミ箱から復活できる．ゴミ箱からもデータが消えてたら，ほぼ詰み．変更して同期する都度に，その変更内容を記録（コミット）するので，誰がいつ変更したか・どれぐらい前のバージョンまで戻すかをファイル内の行単位で管理できる．変更が食い違った場合新しい方で上書きするか，(1)(2)など連番形式で別ファイルが作成される．自動的に両者の変更を生かし，無理そう（行単位で内容が被る等）な場合には，どちらの変更を採用するか明示的に指定する．複数人の作業を支援する機能サービスにより異なる．かなり多様な操作に対応．バイナリファイルの扱いテキストファイルと同等．テキストファイルは細かく変更を追跡できるがバイナリファイルの内容は管理できない．巨大なファイルの扱い比較的大きなサイズのファイルも扱える．基本的に1つのファイルは100MB程度が限界で，それ以上のファイルを扱うには特別な設定が必要．あくまでもソースコード特化型のバージョン管理・共有ツール

(変数名が型名になっていて良くないコード......) 具体的にバージョン管理ってどんな感じなの？誰がどのファイルに，いつどんな変更を加え，どういう感じに統合してるかわかる．「前の状態に戻したいなぁ......」となったときに，以下の枝状のグラフを操作することで復元できる．直観的にどんな変更が施されたのかが見やすい．左が旧版で右が新版を表し，赤いハイライトが「削除された行」で，緑のハイライトが「追加された行」を意味する．

「操作に関わる概念」+「それを実行するためのコマンド」 Andrew Morton (Linux開発の中心人物の1人) Gitが便利そうなのは分かった．だけど覚えるべきことが多すぎて...... 「自分の頭が自分の思うほど良くない」って感じさせるために意図的にデザインされてんだろこれ... 「超絶天才な人間だけのツール」と言われユーザーを遠ざけてしまっている要因の1つ
コレは覚えないとダメ Wikipedia, “Andrew Morton (computer programmer)”, https://en.wikipedia.org/wiki/Andrew_Morton_(computer_programmer)

Gitが便利そうなのは分かった．だけど覚えるべきことが多すぎて...... 「操作に関わる概念」+「それを実行するためのコマンド」コレは覚えないとダメコマンドなんて覚えなくてOK！イマドキはVSCode上で大抵の操作をボタン操作で行えます！

・ブランチ(branch) Git/GitHubを扱う上で覚えとくべき概念・リポジトリ(repository) ・ステージ(stage) ・ステータス(status) ・プッシュ(push) ・プル(pull) ・クローン(clone) ファイルやディレクトリの状態（ソースコード，変更履歴，コメント）を管理する場所．
ファイルに対する変更をブランチに記録すること．記録した情報自体もコミットと呼ぶことがある．コミット対象のファイルを登録すること．・フォーク(Fork) 他のユーザーが公開するリモートリポジトリを丸ごと自分のアカウントにコピーすること．(GitHub特有の機能) リモートリポジトリを元にローカルリポジトリを複製すること．メインの開発ラインから独立した開発ラインを作成し，別ルートで作業する機能．「どのファイルがステージ状態にあるか」など，現在の開発ラインの状態を表示する機能．・マージ(merge) ローカル側からリモート側へリポジトリの内容を送ること．リモート側からローカル側へリポジトリの内容を取り込むこと．複数のブランチの内容を統合すること．・コンフリクト(conflict) コードの統合時にGitから自動で解決できない「変更の衝突」・プルリクエスト(Pull Request, PR) 開発者がコードに対して行った変更を採用してもらうよう，他の開発者へ依頼すること．(GitHub特有の機能) ・フェッチ(fetch) リモートリポジトリの内容を参照すること．・コミット(commit)

リポジトリ(repository) ファイルの変更履歴を管理する場所．リモートリポジトリをユーザーのローカルストレージ(=各自のPC)へ複製したもの．リポジトリのデータを各所へ分散させる構造から分散型と言われる(⇔集中型) リモートリポジトリが吹き飛んでも誰かのローカルリポジトリから復元できるユーザー１ (ノートPC)
ユーザー２ (ノートPC) ユーザー３ (デスクトップPC) ローカルリポジトリリモートリポジトリインターネット(Gitサーバ)上で管理されるリポジトリ． GitHubやGitLabなどはリモートリポジトリの実装の1つ． Version data Version data Version data Version data サーバー

フォーク(Fork) ユーザーA (GitHubアカウント) ユーザーB (GitHubアカウント) ユーザーAさんが公開してるリポジトリの使い心地がしっくりこないんだよなぁ...
俺が改造したろ！他のユーザーが公開しているリモートリポジトリを丸ごと自分のアカウントにコピーすること(GitHub特有の機能)

フォーク(Fork) ユーザーA (GitHubアカウント) ユーザーB (GitHubアカウント) 他のユーザーが公開しているリモートリポジトリを丸ごと自分のアカウントにコピーすること(GitHub特有の機能) ユーザーA (GitHubアカウント) ユーザーB
(GitHubアカウント) フォークよっしゃ！アレンジして配布するぞ～

フォーク(Fork) 他のユーザーが公開しているリモートリポジトリを丸ごと自分のアカウントにコピーすること(GitHub特有の機能) Q. 他人の成果物を勝手にコピーしちゃっていいの！？しかも改造や再配布とか流石にダメでは......？ A. 元のプロジェクトにオープンソースライセンスが記されていれば大抵の場合はOK．（ライセンスによっては改変等が許可されていないのでよく調べること）そもそもLinuxやGit，VSCodeを含む多くのソフトウェアは「プロジェクトのソースコードは誰でも触れるよう（=オープンソース）にして，みんなでドシドシ改善していこう」という文化で発展してきた．
むしろ誰かにフォークしてもらえる方が名誉であるとされる． (科学も論文というプラットフォームで，ある意味同じことをやっている) MITライセンスがおそらく最もオーソドックス．「著作権の表示は必要だが，商用利用, 修正, 配布, サブライセンス全部やってOK」という緩めの内容． TIPS 筆者が個人的に好きなのはWTFPLライセンス． ”Do What The Fuck You Want To Public License”の略で，文字通り「どうぞお好きなようにしやがれ」ただし，大幅な根本的改変でなく，機能の追加程度の変更内容であれば，後述するプルリクエストにより元の開発者に還元することが推奨される．

小話: ソースコードのパクり？「放置少女～百花繚乱の萌姫たち～」を運営する会社(原告)が「戦姫コレクション～戦国乱舞の乙女たち～」の運営会社(被告)に対し著作権侵害の訴訟を起こした事件「放置少女」事件事実関係として・利用規約が会社名以外同一
・特定機能のプログラムのソースコードの類似度が90.66% ・「戦姫コレクション」(被告ゲーム)のソースコード上に「放置少女」(原告ゲーム)の開発担当者の名前が残されていたなどあったものの，著作権法上の権利侵害が無いとされた →ソースコードはあくまでシステムを成立させるための「アイデア」であり，表現上の創作性がないため著作権侵害とはいえない 2024年現在，生成AIの学習元が問題になりがちだが，他にも「任意のイラストレーターの絵柄を模倣する生成AI」を取り巻く議論も尽きない．法的に著作性が肯定されるのはあくまで「絵」そのものである．「絵柄」はアイデアに該当するため，著作権法による保護対象に当たらない．しかしイラストレーターにとっては「絵柄」こそアイデンティティ．長年かけて培ってきた技術を生成AIによってコモディティ化されることが是となる状況への不満から，AI規制を掲げるイラストレーターも多い．どこからどこまでがパクり判定か等に興味があれば「〈ケース研究〉著作物の類似性判断: ビジュアルアート編」という本がオススメですクリエイターとプログラマーの文化の違いを表すミーム reddit, thanksForTheFork, https://www.reddit.com/r/ProgrammerHumor/comments/14qohwj/thanksforthefork/

クローン(clone) リモートリポジトリを元に，ローカルリポジトリを複製すること．プロジェクトの完全なコピーが自分のローカルマシン上に作成されるローカルリポジトリリモートリポジトリ Version data Version data クローン
これでネットの接続とか気にせずに開発できるぜ！

プッシュ(push) プル(pull) ローカルリポジトリ内の現在のブランチ (チェックアウトしているブランチ)の内容を送信すること．ブランチ(branch)は次ページにて解説．ローカルリポジトリリモートリポジトリ Version data
Version data プルプッシュリモートリポジトリ内の現在のブランチ (チェックアウトしているブランチ)の内容を取り込むこと．リモートリポジトリの内容が更新された際に行う．

ブランチ(branch) メインの開発ラインから独立した開発ラインを作成し，別ルートで作業する機能．ブランチを切る(=枝分かれを行う)ことにより，互いに干渉しない並行世界線をつくるイメージ．今までの開発体制 TIPS 「枝分かれを発生させているのに”ブランチを切る”？」と思う人も多いだろうが，「伝票を切る」が由来とされる．たしかに伝票はミシン目から切り離して書き込むものだが，この動詞をブランチ(枝)に適用させるセンスは如何なものか...... mainのbranch func1開発のための branch
func2開発のための branch 分岐発生=ブランチを切る Gitでの開発体制 mina, Git入門, https://speakerdeck.com/silmin_/gitru-men

ブランチ(branch) 元々メインのブランチ名は「master」だったが，「奴隷制度を彷彿とさせる」との指摘から近年「main」に改められた．工学分野で長く用いられてきた「マスター(master)/スレーブ(slave)」呼称は減りつつあり，電子工作でのSPI通信では「SDO(Serial Data Out)/SDI(Serial Data In)」，ロボットの遠隔制御では「リーダー(Leader)/フォロワー(Follower)」呼称が推奨されている．コミット(commit) マージ(merge) ファイルに対する変更を
ブランチに記録すること．記録した情報そのものを指すこともある．メインの開発ラインから独立した開発ラインを作成し，別ルートで作業する機能．ブランチを切る(=枝分かれを行う)ことにより，互いに干渉しない並行世界線をつくるイメージ．ブランチの内容を統合すること． mainブランチは「いつでもコードを動かせる」状態に保つ必要があり，中途半端な開発ブランチをマージしてはダメ． mainのbranch func1開発のための branch func2開発のための branch HEAD マージコミット (コミットオブジェクト) コミットオブジェクト記録した情報そのものの正式名称 HEAD チェックアウトしているブランチの先頭のコミットオブジェクト． Gitはここからブランチの各コミットの差分を読んで最新コミットの内容を算出する．チェックアウト特定ブランチへ移動することチェックアウト TIPS

コンフリクト(Conflict) コードの統合時にGitから自動で解決できない「変更の衝突」．複数人が同じファイルの同じ場所を修正した際などに発生．マージする人が責任を持って取捨選択する． mainのbranch app.pyを編集したブランチ1 app.pyを編集したブランチ2 コンフリクトどっちを
採用したらいいんだ...!?

コンフリクト(Conflict) コードの統合時にGitから自動で解決できない「変更の衝突」．複数人が同じファイルの同じ場所を修正した際などに発生．マージする人が責任を持って取捨選択する． mainのbranch app.pyを編集したブランチ1 app.pyを編集したブランチ2 ブランチ2の変更を採用で！

フェッチ(fetch) リモートリポジトリの内容を参照すること．取り込むまではしない．複数人で開発するプロジェクトの場合，リモートリポジトリの内容が絶えず更新されるので，定期的にローカルリポジトリに変更内容を取り込む必要がある．いきなりプルで取り込むと，自分が触っているコードがリモートリポジトリのものに上書きされてしまう可能性がある．コンフリクトの早期発見や問題の有無を確認するため，まずフェッチ(fetch)して内容を精査した上でマージを行うことが推奨される． (個人開発ならリモートリポジトリが知らぬ間に勝手に変更されることは無いので，一発プルで良いかも) (→ プル
= フェッチ + マージ) リモートローカル「main」ブランチ「origin/main」ブランチ「main」ブランチマージフェッチプルリモート寄りのブランチ（勝手に作成される）

ローカルリポジトリ（チェックアウト中のブランチ）リモートリポジトリ（チェックアウト中のブランチ）クローン (最初にローカルへ複製) フォークプル(フェッチ+マージ) プッシュブランチを切る

プルリクエスト(Pull Request, PR) 開発者がコードに対して行った変更を採用してもらうよう，他の開発者へ依頼すること(GitHub特有の機能) 個人開発ではまず使わないが，チーム開発で使うかもしれんので一応知っておくと良い． TIPS 「こっちの変更をプッシュしているのに”プル”リクエスト？」と思うかもしれないが，元々GitはLinux開発に用いられており，世界中の開発者たちがLinus Torvaldsに対して「こういう機能を開発したから是非ともアンタのLinuxに統合(=プル)してくれよ」とリクエストしたことに由来．あくまで主語は「プッシュする開発者側」でなく「それをプルする元リポジトリやmainブランチ側」なので，プルリクエストという名称となる．
フォーク後にコード(機能)を追加してプルリクエスト(PR)を出す事で，元リポジトリのプロジェクトに貢献できる．オープンソースソフトウェア(OSS)開発で主流の方式．レビュアーはPRの内容をチェック(コードレビュー)し，バグや悪意あるコードなどの問題が無ければプルする． 2024年3月末，Linux開発において悪意あるコードがPRを通過し， Linuxの一部にバックドアが仕込まれる事件が発生した．不特定多数が関わるオープンソースのプロジェクトは，たびたびハッカーを寄せ付けるので，PRは特に慎重に行う必要がある． (オープンソースだからこそ大衆の目に晒されて発覚した事件ともいえるので必ずしもOSS=悪でもない) メインとなるブランチと他のブランチで分け，権限を持つ者へPRして承認を受けないとmainブランチへマージをできないようにする手法．企業等が機密を保持するためにリポジトリを非公開(=フォーク出来ない設定)とする際に主流となる方式．メイン用・開発用の2種のブランチを用いる「GitHub Flow」と，用途や緊急度などに応じ5種類のブランチを用いる「git-flow」がある．・小規模~中規模開発 → GitHub Flow ・大規模開発 → git-flow

TIPS 「Gitってブランチを切るたびにファイルが増えて，めちゃくちゃデータを食うのでは？」と思うかもしれないが，ブランチが保持するのはコミットオブジェクトであり，あくまで変更内容(差分)やコミットメッセージ等のメタデータのみ．ファイルの内容でなく差分を保存するだけなので，ブランチをドンドコ切ってもリポジトリのサイズが大幅に増えたりしない．ステージ(stage) コミット対象のファイルを登録すること（ステージングともいう）コミットツリーコミットの履歴を木構造で表現したものステージワークツリー
実際にファイル編集の作業を行うディレクトリコミットオブジェクト変更A 変更B 変更B 変更A ステージング未コミットの変更内容

コミットツリーコミットの履歴を木構造で表現したものステージ(stage) コミット対象のファイルを登録すること（ステージングともいう）ステージワークツリー実際にファイル編集の作業を行うディレクトリコミットオブジェクト変更A
変更B 変更B 変更A ステージングコミット TIPS 「Gitってブランチを切るたびにファイルが増えて，めちゃくちゃデータを食うのでは？」と思うかもしれないが，ブランチが保持するのはコミットオブジェクトであり，あくまで変更内容(差分)やコミットメッセージ等のメタデータのみ．ファイルの内容でなく差分を保存するだけなので，ブランチをドンドコ切ってもリポジトリのサイズが大幅に増えたりしない．

小話: コミットオブジェクトの中身って？コミット = ステージされた変更内容を40文字のSHA1(発音: シャーワン)ハッシュに変換したものコミット + メタデータ= コミットオブジェクト
変更後のハッシュ値変更前のハッシュ値変更担当者タイムスタンプコミットコメント 393e373424ec28e112a29f94a7f6f63218cc1bce 38988eef0331afb9f374ccc124ebfbaf4ae2e7bf ハッシュ値によりファイルを一意に識別している．各コミットのハッシュ値の差を見ることで，数学的に高い効率性でファイルの差分を管理できる(かしこい...) コミット各種情報 (メタデータ) TIPS SHA-1は「Secure Hash Algorism 1」の略で，任意長の文字列を160ビット(16進数では40文字)長の文字列に変換する暗号化アルゴリズム． 1995年にSHA-0の後継として米国国家安全保障局(NSA)により設計された．ファイルの真正性や改ざんを検知することを目的として開発されたが，その後に衝突攻撃による脆弱性が指摘されたことから米国国立標準技術研究所(NIST)はSHA-2やSHA-3への移行を推奨している．

ステータス(status) 「どのファイルがステージ状態にあるか」など，現在の開発ラインの状態を表示する機能． Gitのファイルステータスは主に下図の通りだが， VSCodeのGit拡張機能はUIデザインが良いので図を意識しなくてもまあ分かるようになるブランチ内のファイルは全て追跡されている(Tracked)と追跡されていない(Untracked)ものの2通り．追跡されているファイルは常にUnmodified，Modified，Stagedのいずれかの状態にある． THE LINUX FOUNDATION, The
Greatness of Git, https://www.linuxfoundation.org/blog/blog/the-greatness-of-gitの図を邦訳

これらの拡張機能を入れることコードの任意の行が「いつ」「誰によって」変更されたのかをコード上から直接的に確認できるコミット（コードの変更）をグラフ表示する機能もあるが，有料なので↓のGit Graphで補完する GitLens Git Graph
Gitの変更履歴をGitHubと同様の操作感でコミットを追跡ができる．まだGit/GitHubについて後半に教えるので，とりあえず入れとくと便利っす

① <New>を押してリポジトリ作成画面に移る ② リポジトリ名を設定 private設定にしておくと他人に公開されずに済む ③ Public/Private設定この辺は後からでも
設定できるので無視でOK ④ 空っぽのリポジトリが完成するリポジトリの作成

① SSHのリンクをコピーリポジトリをクローンし，ファイルをコミット ② <ソース管理>をサイドバーに開き，リポジトリの複製 ③ SSHのリンクを張り付け， <リポジトリのURL>をクリック ④
リポジトリの保存先を選択．「第1回」の授業フォルダとか． ⑤ <新しいウィンドウで開く>を選択 ⑥ 適当なファイルを作成する ⑦ <すべての変更をステージ> (ファイル名にマウスホバーすると表示される<+>マークから任意ファイル単体でもステージ可) ⑧ 作成したファイルが「ステージされている変更」に移動する（何か操作する必要なし） ⑨ 適当なコメントを書く ⑩ < コミット>を押す

リモートリポジトリにプッシュ ① ソース管理の三点リーダーを押す ② プッシュ ③ GitHubのリポジトリが更新されている ④ 念のためファイルをクリックして内容を確認してみる

作業ブランチを作成 ① GitHubリポジトリの「main」をクリックする ② 「Branches」に「main」しかないことを確認（何も操作しなくてOK） ④ 新しいブランチ名を適当に決める
③ 三点リーダーから「ブランチ」 →「ブランチの作成...」 ⑤ 「Branchの発行」を選択 ⑦ GitHubリポジトリに新たなブランチが追加されてる ⑥ アクティビティバー左に表示されるブランチ名が変わる

作業ブランチでコミット ① 作業ブランチをチェックアウト ② 適当なファイルを作成 ③ ファイルをステージする ④ コミットコメントを書いて<コミット> ⑤
<変更の同期>をクリック（書いてある数字は未プッシュのコミット数） ⑥ GitHubリポジトリの表示ブランチを変更 ⑦ 作業ブランチにだけファイルが追加されてる

さらにファイルを変更してコミット ① VSCodeの作業ブランチでなんか変更を加える．変更を加えた行の初めに青いラインが追加されるはず (ここをクリックすると変更内容が確認可能) ② 「ソース管理」の
「変更」タブにあるファイル名の部分を直接クリック ③ 差分エディターが展開される．左が旧ファイルで右が新ファイル．赤くハイライトされた行が「削除された行」緑にハイライトされた行が「追加された行」 ⑤ < コミット>を押し変更をコミット． <変更の同期>をクリックすることでリモートリポジトリの内容が変わる． ④ ファイルをステージして適当なコミットコメントを書く

作業ブランチの内容をメインブランチにマージ ① メインブランチをチェックアウト ② 先ほどの作業ブランチにあったファイルがメインブランチでは消えている．正しい挙動なので焦らずに． new_branchのファイル構成 mainブランチのファイル構成 ③
ソース管理の三点リーダーから <ブランチ> →<マージ> →変更ファイルが入ってる<作業ブランチ>を選択

作業ブランチの内容をメインブランチにマージ ④ 作業ブランチで作成したファイルが mainブランチ側にも反映されている ⑤ ソース管理の部分に<変更の同期>ボタンが追加されてるので押す．作業ブランチでのコミット内容がリモートのメインブランチにも反映される． ⑥ GitHubのリポジトリを見ると
mainブランチの内容が同期されている

リモートリポジトリの更新内容をプルするリモートリポジトリを編集 ① メインブランチをチェックアウト ② 編集対象のファイルをクリックして選択 ③ 右側のペンのアイコン<Edit this file>をクリック
④ 適当に文章を加えて右上の<Commit changes...>を押す ⑤ コミットメッセージが自動生成されるので特に何も変更せず<Commit changes> これで「リモートリポジトリが他人によりアップデートされた」状況が出来たので，プルしてローカルリポジトリも更新します

リモートリポジトリの更新内容をプルするローカルリポジトリにプル ② ローカルのファイルがまだ更新されてないことを確認 ② ソース管理の三点リーダーを押す ① mainブランチにチェックアウトしてることを確認 ③
<プル>を選択 ④ ローカルのファイルが更新されている

リモートリポジトリの更新内容をフェッチしてマージするリモートリポジトリを編集ローカルリポジトリにプル ② mainブランチにいることを確認する ① 2ぺージ前と同様にリモートリポジトリの mainブランチでファイルを編集 ③
ソース管理タブの三点リーダーから<フェッチ> ④ ソース管理タブから「origin/main」ブランチの内容が変わっていることが確認できる．「受信」タブにあるファイル名をクリックすると差分エディタが出て「どう変わったのか」が分かる．変更内容に問題が無ければ<変更の同期>を押す事で「main」ブランチに内容がマージされる．

ブランチを削除する機能追加のたびにブランチが増えると管理が大変になるため，役割を終えたブランチは削除することが基本．例えば「func1」という機能の作成を目標としたブランチに関して，実際に機能を開発してmainにマージした後は，ソース管理タブの三点リーダーから<ブランチ>→<ブランチの削除...>を選択し，対象ブランチを削除．ブランチ削除

無視ファイルの設定 ① 「hate_git.csv」「private_file」「日本語でOK.py」を作成するコミットしたくないファイルやフォルダ，拡張子などを指定できる機能．キャッシュやセキュリティ上共有したくないファイルをGitの管理下から除外できる．ただし，一度コミットして追跡対象となったファイルは無視できなくなる点に注意 ② 「.gitignore」という拡張子オンリーのファイルを作成する． (隠しファイルとなる)
TIPS 「*」は正規表現と混同されることもあるが，正しくはワイルドカードというもの． Gitの追跡対象をもっと複雑に表現したい場合は，このサイトで確認するのがおすすめ． Uマークがついていたら Unmodifiedであり，追跡対象 ③ 「.gitignore」の中身を以下のように編集し，保存する． (「*」は半角アスタリスクで「任意の文字列」の意味) ④ さっき作成したファイル名からUマークが消え追跡対象から除外される．フォルダなど細かな指定も可能なので色々試してみよう ⑤ .gitignoreファイルを <コミット>して <変更の同期>も行う

ブランチのコミットツリーを確認する ① 一番下のアクティビティバー左側にある <Git Graph>をクリック ② エディタに「Git Graph」タブが出て，過去のコミットが一覧表示される ③
適当なコミットをクリックして詳細パネルを出す．ファイル名をクリックすると変更の詳細が出る．このGit Graphにより・過去のコミットを修正・過去のコミットを削除・複数コミットを合体など複雑で便利な操作が簡単にできるようになる！．マジで便利なので必ずこのサイトに目を通しておこう．

コンフリクトを解決する変更内容が異なるコミットを各ブランチで作成 ① mainブランチで「conflict.txt」を作成する ② 「conflict_branch_1」と「conflict_branch_2」ブランチをそれぞれ作成する ③ Git
Graphでコミットツリーを見ると最新(一番上)に新たなブランチが追加されてる ④ 各作業ブランチで「conflict.txt」の内容が異なるように編集し，それぞれコミットしておく

コンフリクトを解決する mainブランチで各ブランチをマージし，意図的にコンフリクトを発生させる ① mainブランチで<ブランチ>→<マージ...> →「conflict_branch_1」を選択 ② 「conflict_branch_1」での「conflict.txt」の内容がmainブランチ側にも反映されている ③
同様にしてmainブランチに「conflict_branch_2」の内容もマージする

コンフリクトを解決する ① マージにコンフリクト(競合)が発生していると警告が出る．焦らずにを押す ② どういうコンフリクトが発生しているかの比較画面がエディターに出る． ③ <マージ
エディターで解決>を選択マージエディターでコンフリクトを解決

コンフリクトを解決する ① エディター下側に「結果」という名のパネル的なのが出てくる ② 「最終的にどんな内容であってほしいか」を下の「結果」のところに書く．「コンフリクト 2」や「コンフリクト 1」の上に表示される <どちらの変更を採用するか>的なやつを選んでもいいし，
画像例のように全く新しい内容にする事も可 ③ 最終的な内容を編集し終えたら<マージの完了>

コンフリクトを解決する ① マージが完了してファイルの内容が書き変わる ② 先ほどのマージエディターで編集した内容がコミットコメント付きで自動的にステージングされるので， < コミット>→<変更を同期>を押す

過去のコミットに戻る ① mainブランチでGit Graphを開き，過去のコミットを右クリック(画像では「.gitignoreの作成」のコミットを選択) リセット(reset)という機能で「この頃のコミットに戻したいなぁ。。。」という要望を叶えられる． ② <Reset current branch~>を選択し，
モードは「Mixed」として <Yes, reset>を選択 ④ ソース管理タブの「変更」に未ステージファイルがある状態だとマージできないので，conflict.txt の右にある<変更を破棄>を押す．「ファイルを削除するか」的なメッセージにOK ⑤ <変更の同期>を押して「origin/main」をマージすることで，リセット操作が取り消される．これで過去に戻れた．新たな作業ブランチを作るなりご自由に．今回は何もせず，リセット前の状態に戻す (=リセット操作を無かったことにする)

特定コミットだけmainブランチに取り込む複数段階に分けてコミットする ② 新たなブランチで「memo_1.md」~「memo_4.md」の連番形式でファイルを作成する ③ 「memo_1.md」の右側にある <+>マークから，このファイルのみをステージ． ④
「memo 1作成」のように分かりやすいコミットコメントを書き，< コミット>． ⑤ 他の連番ファイルも同様に”単体で”，それぞれ区別がつくコミットコメントを付けて< コミット>をする．チェリーピック(cherry-pick)で特定コミットだけマージできる．「開発ブランチの最新コミットは未完成だけど，少し前のこのコミットだったら今すぐリリース可能」という場面で役立つ ① mainブランチから新たなブランチを切る

特定コミットだけmainブランチに取り込む ⑥ ソース管理タブがこんな感じになっていると思う． <変更の同期>は別に何時でもいいんですが，もうこのタイミングで押しちゃいましょう． ⑦ mainブランチに戻る．エクスプローラー上には当然「memo_1.md」等のファイルが無い mainブランチからチェリーピックする

特定コミットだけmainブランチに取り込む ⑧ mainブランチでGit Graphを開く． <Show Remote Branches>のは外しておく． ⑨ 「memo_2.md」のコミットを右クリックして
<Cherry Pick...>を選択普通にマージしたら「memo_4.md」までの全てのファイルがmainブランチに取り込まれてしまうが，今回は「memo_2.md」のコミットだけを取り入れる ⑩ 何もチェックをつけずそのまま<Yes, cherry pick>を選択．オプションの内容はココから確認してください．

特定コミットだけmainブランチに取り込む ⑪ 現在のGit Graphの状態．一番上に「memo_2.md」のコミットがきている． ⑫ エクスプローラーを見ると「memo_2.md」だけが追加されている． <変更の同期>もやっておこう

作業内容を一時退避させるスタッシュ(stash)により作業内容をコミットせず一時退避できる．「Aブランチで機能の開発に取り掛かっていたけど，急遽Bブランチで別の機能を開発しないといけなくなった！」というときに役立つ． ① 適当なファイルに変更を加える ② 「ソース管理」タブで三点リーダーを押して <スタッシュ>→<スタッシュ>を選択 ③
スタッシュに際して，分かりやすいメッセージを書いてEnter 変更をスタッシュ

作業内容を一時退避させる ④ 先ほど編集した内容が消えている。当たり前だが一時退避してるだけなので焦らない．スタッシュをポップする（一時退避させた変更を取り出す） ⑤ ソース管理タブの三点リーダーから <スタッシュ>→<スタッシュをポップする...> ⑥
ポップ対象を選択 ⑦ スタッシュ前の内容に戻る

・mina, Git入門, https://speakerdeck.com/silmin_/gitru-men ・IT media NEWS, “GitHubは「設計図共有サイト」？日経記事の見出しが話題にその後修正”, https://www.itmedia.co.jp/news/articles/1806/05/news069.html
・JOB SUPPORT, “新人SE・PG教育にも使える！ソースコード(Java)のコメントの書き方①”, https://job-support.ne.jp/blog/java-training/howto3 ・reddit, thanksForTheFork, https://www.reddit.com/r/ProgrammerHumor/comments/14qohwj/thanksforthefork/ ・THE LINUX FOUNDATION, The Greatness of Git, https://www.linuxfoundation.org/blog/blog/the-greatness-of-git ・wann, “【初心者向け】git fetch、git merge、git pullの違いについて”, https://qiita.com/wann/items/688bc17460a457104d7d ・Git, Recording Changes to the Repository, https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository 参考文献・URL ・リブロワークス (2023) ,『ノンプログラマーのためのVisual Studio Code 実線活用ガイド』, 株式会社技術評論社

Git/GitHub入門

Git/GitHub入門

Tai YAMADA

Other Decks in Programming

Featured

Transcript