webコーダーのsaco @sacocco_sacoya です。
先日もりけん塾で、gitコンフリクト解消ができるようになるハンズオンに挑戦しました。

Gitの復習も兼ねてGitとGit Hubのツボとコツがゼッタイにわかる本を読んだので、備忘録として新しく学んだこと、復習で覚えておきたいことを記します。

読んだ感想

まず書籍の構成がとてもわかりやすく、ストレスなく読み進めることができたと思います。
Amazonのレビューもこちらの書籍がとりわけ評価が高かったです。
以下がこの本を選んで良かったと思う点です。

• Gitとは何か、GitHubなどのGitホスティングサービスとは何か、ソースコード管理の歴史をさらっと学べる
• ターミナルからgitコマンドでソースコードを管理する方法が学べる
• 実際に手を動かしながら読み進めることができる
• Gitの基礎コマンドを学べる
• プルリクエスト、イシューについて理解できる
• 開発現場でのGit/GitHub運用方法について学べる
• チーム開発での流れを理解できる
• 図解や説明文章がわかりやすいのでサクサク読める

初心者の方にはこの１冊でGit管理のおおよその流れが理解できるおすすめの１冊だと思いました。

Git / GitHubについての色々メモ

• Gitはプロジェクト全体を１つのスナップショットとして記録していく。
• GitHubはGitホスティングサービスの１つ。他にもGitLab、Bitbucket、backlogなどのホスティングサービスが存在する。
• GitHubなどのホスティングサービスを利用すればバグ追跡、タスク管理（Issue）、アクセス制御など様々な機能を使いながら効率的に開発ができる
• GitHubにはIssueというタスク管理機能があり、開発に関わる情報をすべて一元管理できる（不具合報告、議論、追加機能要望など）
• GitHubにはプルリクエスト機能があり、作成したコードを追加して問題がないかチーム内で確認の場を設けることができる。

Gitコマンドメモ

以下Gitコマンドの備忘録を記していきます。

git resotre ファイル名

指定されたファイルのワーキングディレクトリの変更を最後にコミットされた状態に戻すことができる。
（ワーキングディレクトリに加えた変更が取り消される）

git restore —staged ファイル名

誤ってステージングしてしまった場合、アンステージできる。
（ワーキングディレクトリに戻す）

git add -p

ファイル内の特定の変更だけをステージする。変更を部分的にステージングできるため、コミットを細かく管理することができる。
コマンドを入力するとStage this hunk [y,n,q,a,d,e,?]? と尋ねられるので、eを入力（eはインタラクティブモード、手動で表示されている）

以下のようなハンクと呼ばれるファイル変更の一部が表示される。

iキーでインサートモードにし、ステージングしたいコードだけ残す。

（例では「git add -pテスト１」の部分のみステージングする）
入力が終了したらescキーを押し、:wqで終了する。

git diffでステージングエリアとワーキングディレクトリの差分を確認すると以下のようになっており、「git add -pテスト１」はステージングされているが「git add -pテスト２」はステージングされていないことがわかる。

git stash

あるブランチでの作業中に、別のブランチで作業する必要に迫られた際、ワーキングディレクトリやステージングエリアに切り替え先のブランチと競合する変更が残っていると、チェックアウトに失敗してしまう。

このような場合にスタッシュコマンドを利用すれば、変更を一時的にスタッシュ格納領域に退避させることができる。

git stash pop

スタッシュを復元するときのコマンド。

git stash list

スタッシュした内容の一覧を確認することができる

git remote

登録されているリモートリポジトリの一覧を確認することができる。
-v オプションを付与することで、登録されたURLも表示できる。
↓赤枠がリモートリポジトリ名

git push -u

ローカルブランチをリモートリポジトリにプッシュする際に使用される。
-u オプションは、–set-upstreamの略で、アップストリーム（上流）関係を設定することができる。

git push -u origin <ブランチ名>

一度上記のように指定すれば、その後、git pushやgit pullコマンドを実行する際にリモート名とブランチ名を毎回指定する必要がなくなり、単にgit pushやgit pullとするだけで、リモートとの同期が可能になる。

git rm オプション ファイル名

ファイルの削除〜ステージまでを行うことができるショートカットコマンド

git rm —cached

ワーキングディレクトリにファイルを残しつつ、バージョン管理からは外すことができる。

その他メモ

gitの基本構成おさらい

git fetch

リモートブランチの内容をローカルリポジトリのリモート追跡ブランチへ反映する

git merge

ローカルリポジトリ内でリモート追跡ブランチの内容をローカルブランチへ反映する

git pull

ローカルブランチの内容をリモートブランチと追跡ブランチへ反映する

リモート追跡ブランチ

ローカルリポジトリに存在していて、リモートリポジトリのブランチの状態を反映するブランチ。
ローカルの変更とリモートの変更を同期するために使用される。
直接チェックアウトして作業することはできない。
git fetchまたはgit pullコマンドを実行することで更新され、リモートリポジトリの最新の状態を反映する。

上流ブランチ

引数なしでgit pullやpushしたときに対象となるブランチ。
上流ブランチを利用するには予め以下のコマンドでの設定が必要で、設定のないままpullやpushを行うとエラーが発生する。

git push --set-upstream origin <ブランチ名>
//もしくは
git push -u origin <ブランチ名>

設定は１度のみでOKで、設定しておけばその後リモートブランチの指定（引数）なしでpushやpullを行うことができる。

※pullコマンドには上流ブランチを設定するオプションがないため、git pull -u origin〜などとしてもエラーが発生する。
※pullコマンドには上流ブランチを設定するオプションは存在しないが、すでに上流ブランチが設定されていれば、引数なしでgit pullを実行できる。
※git pullしたときの反映の流れは、まずリモートブランチからリモート追跡ブランチ（origin/master）へ反映された後、リモート追跡ブランチからローカルブランチへの反映が行われる

pullが失敗してしまうとき

pullを行った際、リモートリポジトリの変更とPCの変更が競合した場合、コンフリクトが発生する。
（本来はこのような問題が発生しないように管理するのが望ましい）

対処方法は、PC上の変更がコミットされていない場合と、コミットされている場合で対処方法が異なる。

PC上の変更がコミットされていない場合

PC上にコミットされていない変更済みのファイルがある状態で、変更のあるリモートリポジトリをpullするとpullが失敗する。
このような場合は一度PC上の変更をなくした状態でpullを行う必要がある。
変更を一時的に退避させたい場合、stashコマンドを使用してあとから復元する流れが一般的。

PC側の変更がコミットされている場合

PC側の変更がコミットされている状態で、リモートリモートリポジトリの変更をpullしようとすると、リモート追跡ブランチとPC上のブランチでマージが行われるが、変更箇所が被っているとコンフリクトが発生する。
コンフリクトを解消してコミットし、pushを行う必要がある。

.gitignore

.gitignoreファイルへ指定したファイルやディレクトリをgitから除外してくれる。
.DS_Storeなどの自動生成されるファイルや、/node_modules/など、開発工程において直接編集したり操作する必要がないディレクトリを記述しておくとよい。
（すでにバージョン管理されているファイルは除外できない。すでに追加されているファイルをあとから除外対象とする場合は、対象ファイルの削除コミットを行う必要がある。）

デフォルトブランチ設定

developブランチなど、開発の本線となるブランチをデフォルトブランチに設定しておくと以下のようなメリットがある。

• プルリクエストの際、デフォルトのマージ先として指定することができる
  （通常はmainがデフォルトブランチ。この設定をしておけば誤ってmainへプルリクエストが送られず、予期せぬコードのマージを防ぐことができる）
• リポジトリページへアクセスした際、最初にdevelopブランチが表示されるようになり、開発の最新状況を直ぐに確認できるようになる

リポジトリの設定（Settings）からDefault branchに任意のブランチを設定する（developが一般的）

ブランチを確認すると、defaultマークがついた。

まとめ

もりけん塾のGitハンズオンで勉強させていただいたことをベースに、この１冊でGitの知識が補強されたような気がします！

備忘録には記していないですが、Issueやプルリクエストなど、実際の開発の流れも復習できたので、読んでよかった一冊です。

本日は以上です。