😺

Git講座-曖昧な理解をなくそう

2022/11/15に公開

エンジニアをするのであれば、Gitは必須ツールです。

けれど、しっかりと理解してない人も多いかと思います。

僕も実務であまり困ってはいませんが、きちんと理解できてるか微妙でした。

なので、今回はGitを使う上で、しっかりと理解しておくべき知識をまとめました。

この記事を参考にして、Gitの理解を深めてください。

また、Gitの入門的な内容はこちらの記事で解説してますので、こちらも併せてどうぞ。

https://zenn.dev/hinoshin/articles/2c60c1722bf4e7

マージとコンフリクト

最初にGitを使い始めた頃は、コンフリクトに毎回ビビりながら作業をしていました。

けれど、冷静に対処すれば何も心配はいりません。

まず、特定のブランチに他のブランチの作業内容を反映させることを「マージ」と言います。

ただ、両方のブランチで同じファイルを変更していた場合は、ファイルの修正内容に不整合が生じてしまいます。

図にすると以下のようになります。

この際に、Gitはどちらの修正を採用すれば良いか分からなくなり、「コンフリクト」を起こします。

要は、「どっちの修正内容を適用されてば良いか分からないから教えてくれ」という感じです。

なので、コンフリクトした際は、ファイルを手動で操作して採用したい変更内容を選べば良いだけです。

つまり、コンフリクトを起こした際も別にやることはシンプルなので、全く焦る必要はないということです。

ちなみに、git pullコマンドは、リモートリポジトリの内容fetchしてきてmergeするものなので、この際もコンフリクトが起こる可能性があります。

作業内容の変更

Gitでは、主に以下3つのエリアがあります。

1.Working Directory
現在作業中の内容

2.Staging Area
次のコミット対象となる作業内容

3.リポジトリ
ソースコードと変更履歴が入っているフォルダ

Gitを使うときは、これらのエリアで作業内容を適宜入れ替えながら開発を進めていくわけです。

では、どのように作業内容を移動させることができるかを解説してきます。

Working Directory ⇨ Staging Area

git add <ファイル名 or ディレクトリ名>

Staging Area ⇨ リポジトリ

git commit "コミットメッセージ"

Staging Area ⇨ Working Directory

git restore --staged <ファイル名 or ディレクトリ名>

※git statusコマンドで確認できるため、全く覚える必要はない

Working Directoryの内容を破棄

git restore <ファイル名 or ディレクトリ名>

※git statusコマンドで確認できるため、全く覚える必要はない

ちなみに、同じ操作はgit checkoutコマンドでもできます。

このコマンドを「ブランチの切り替えするコマンド」だと認識してる人も多いと思いますが、厳密には違います。

git checkoutコマンドは、指定したコミットに戻すためのコマンドです。

なので、git checkout ブランチ名とした場合は、そのブランチのHEADに移動するため、結果としてブランチの移動が起こるわけです。

そして、特定のコミットを指定しなかった場合は、HEADが採用されます。

つまり、git checkout <ファイル名 or ディレクトリ名> とすることで、それらの状態をHEADの状態に戻すコマンドとなるわけです。

Untrack File ⇨ Tracking File

ちなみに、gitにはUntrack FileとTracking Fileがあります。

Untrack Fileとは、新しく作ったファイルなどで、Gitがまだトラッキングしていないファイルのことです。

そして、Untrack FileをTracking Fileにしたい場合は、git addをするだけです。

Stash

次に、Stashについても解説していきます。

Stachは、変更内容を一時退避するための機能です。

具体例で説明すると、

「Aというブランチで作業中だけど、緊急のバグをしなければいけなくなった。けれど、Aブランチの作業はキリが悪いのでコミットしなくない」

というような時は、Stach機能を使うことで、その作業内容を一時的に退避させることができます。

具体的な使い方は以下の通りです。

git stash

まずはこのコマンドで作業内容を一時退避させることができます。

ちなみに、この際はWorking Directoryと Staging Area両方の内容が対象になります。

また、-uオプションをつけるとUntrack Fileも対象となり、save “”をつけるとタグづけができます。

git stash list

このコマンドでは、stashの内容をリストで確認することができます。

git stash show stash@{stash番号}

このコマンドで、stashの詳しい内容を確認することができます。

git stash apply stash@{stash番号}

このコマンドで、stashの内容を今いるブランチに反映させることができます。

また、この時はstash時にStaging Areaにあった変更内容も、Working Directoryに戻されます。

git stash drop stash@{stash番号}

このコマンドは指定したスタッシュを削除するこたできます。

git stash pop stash@{stash番号}

このコマンドではapplyとdropを同時に行うことができます。

コミット履歴の変更

Gitは、複数のコミットを繋げることで変更履歴を残すシステムです。

ただ、時には「過去のコミット履歴を修正したい」という場合もあると思います。

なので、今回はコミット履歴の変更方法を解説していきます。

Revert

Revertは、前のコミットを打ち消すコミットを作るコマンドになります。

つまり、前のコミットでAというファイルを作成するという作業をした場合は、Aというファイルを削除するというコミットを作ることになります。

前のコミットの状態を戻すには、このRevertかResetコマンドを実行する必要がありますが、基本的にこのRevertコマンドを使いましょう。

Reset

このResetは、単純に前のコミットに状態を戻すコマンドになります。

このコマンドは、チームの他の人が使ってるブランチなどでは、絶対に実行しないようにしましょう。

理由は簡単で、他のチームの人とコミット履歴の整合性が取れなくなってしまうからです。

強いて言えば、パスワード情報などの履歴に残したくない情報をあげてしまった場合に使うのですが、それらはgitignoreに設定されているためほぼありえない状況でしょう。

ただ、自分しか使ってないブランチで一旦過去の状態に戻したい時は結構あるので、一応覚えておきましょう。

また、この際に指定するオプションが3つあり、それを図にすると次のようになります。

cherry-pick

こちらは、他のブランチのコミット履歴を今いるブランチに反映させるコマンドになります。

こちらも使う機会はほとんどありませんが、たまに使うので知っておきましょう。

使い方は以下のコマンドを実行するだけです。

git cherry-pick commitId

Rebase

Rebaseは一言で言うと、「コミット履歴を変更するもの」ですが、使い方は多岐にわたります。

ただ、基本的にmergeの代わりに使うのが一般的です。

さらに詳しく説明すると、mergeする時はmerge commitというものが作られてしまいますが、reabaseするとそのmerge commitを作らなくてすみます。

なので、コミット履歴が見やすくなるわけです。

ここは実際にやってみないと分かりづらいと思うので、頭の片隅にでも置いておいてください。

注意点としては、すでにpushされてるコミットに対しては行わないようにしましょう。

その他

最後にいくつか知っておくべきことを解説していきます。

タグ

Gitにはタグという機能があり、特定のコミットにタグづけをすることができます。

基本的には、バージョンごとにつける場合が多いです。

タグをつけることで、単純に分かりやすくなりますし、GitHubなどではその時のファイルをダウンロードできます。

タグをつける時のコマンドは、以下の通りです。

git tag -a <tag name> <commitId>

Git flowとGitHub flow

Gitを用いた開発はほとんどの会社で行われていると思いますが、開発フローの型というものが存在します。

それが、Git flowとGitHub flowです。

Git Flow

GitHub FLow

基本的にどこの会社もこれを元にして、アレンジするなりそのまま使うなりして開発を進めてます。

Submodule

Gitプロジェクトはその配下に、他のGitプロジェクトを置くことができます。

その際は、GitHub上でリンクができるため、管理がしやすいです。

使う機会はあまりないと思いますが、頭の片隅にでも置いておきましょう。

まとめ

今回は、Gitについてある程度の知識をまとめました。

これらを理解しておけば、実務で困ることはほとんどないでしょう。

ぜひ、参考にしてみてください。

宣伝

0からエンジニアになるためのノウハウをブログで発信しています。
https://hinoshin-blog.com/

また、YouTubeでの動画解説も始めました。
YouTubeのvideoIDが不正ですhttps://www.youtube.com/channel/UCqaBUPxazAcXaGSNbky1y4g

インスタの発信も細々とやっています。
https://www.instagram.com/hinoshin_enginner/

興味がある方は、ぜひリンクをクリックして確認してみてください!

Discussion