DWS入社後、私が使えるようになったGitコマンド

はじめに

DWS歴がもうじき9ヵ月になるshumpeiです。

当社の採用ページではDWSで働くメリットの一つとして、「”超実践的”なAWSスキルの習得」を掲げておりますが、習得できるのはAWSスキルに限りません。
システム開発・運用に関連するスキル全般を身につける環境があると私は感じております。
DWSでのスキルアップ環境を少しでも明確にイメージいただく一助とするため、本ブログではDWS入社後に私が使えるようになったGitコマンドを紹介いたします。
あくまで私個人の経験・状況に関する記述となりますが、同等のスキル感でDWSへの入社を検討されている方の参考になれば幸いです。

DWS入社前

約2年間、プログラマとして働いていました。
DWS入社前にも業務でGitを使う経験はありましたが、現場で用意された使用マニュアルに従い、変更したファイルをadd・commit・pushするくらいしかしていませんでした。

DWS入社後

DWS入社後、Gitで使えるようになったコマンドがグッと増えました。
その要因を私なりに分析してみると、2つあるように思われます。

1つ目の要因は、同僚たちがGitを当たり前に使いこなしている環境があることです。
DWS入社前にもGit使用経験があると書きましたが、私が参画していた現場では元々Subversionを使用しており、私の参画中にGitに移行した、という状況でした。
現場ではGitの使用に不慣れな人がほとんどでしたので、多くのプログラマは有識者が作成したマニュアルに沿ってオペレーションしていたように思います（なので、コンフリクトなどのイレギュラーが発生すると、多くの場合その有識者に問い合わせが飛ぶような状況でした）。
他方、DWSではGitを当たり前に使用しています。
また、コミットの粒度やコミットメッセージのベストプラクティスなど、Git運用ルールが社内wikiにまとめられており、入社時にはそれを読んで理解することが求められます。

2つ目の要因は、システムの開発からデプロイまで、幅広い業務に携わるようになったことです。
DWS入社前に参画していた現場では、自分が担当するのはコーディングまでで、検証環境や本番環境へのデプロイはお客様が実施するという分業体制でした。
他方、DWS入社後にアサインされたプロジェクトではデプロイオペレーションも任せていただいています。
その際に、ある特定の変更だけをデプロイする必要や、一度デプロイしたけれども元に戻す必要が発生することがあります。
こういったケースに対応する中で、後述するcherry-pickやrevertといったGitコマンドを習得することができました。

以上２つの要因から、入社前と比べて多少なりともGitを使えるようになったと考えています。
開発ツールの使用法含め、技術力向上のためには個人の意志や業務外での自己研鑽も必要ではありますが、働く環境によっても大きく左右されることは事実と思います。
その点、DWSの環境は恵まれているように思います。

さて、以下では、私がDWSで働く中で使えるようになった具体的なGitコマンドを5つ紹介いたします。

使えるようになったコマンド5選

説明のためにgit-sampleディレクトリとその内部にfile-a.txt・file-b.txtを作成しました。

git-sample
├── file-a.txt
└── file-b.txt

このディレクトリ配下をGit管理下に置き、mainとdevの2つブランチを作成しました。

stash

git stashは未コミットの変更を退避するコマンドです。
私がこのコマンドをよく使うのは、開発用のブランチ上で変更を加えているつもりがうっかりmainブランチ（masterブランチ）上で作業してしまっていた、といったケースにおいてです。
たとえば、mainブランチ上でfile-a.txtを変更してしまったとします。

% git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   file-a.txt

no changes added to commit (use "git add" and/or "git commit -a")

ここでgit stashを実行すると、file-a.txtに対する変更をmainブランチ上から退避させることができます。

% git stash
Saved working directory and index state WIP on main: d473eb5 [add]file-b.txtを新規作成

% git status
On branch main
nothing to commit, working tree clean

この状態でdevブランチにチェックアウトしてgit stash applyとすると、先ほど退避させた変更をdevブランチに反映させることができます。

% git checkout dev
Switched to branch 'dev'

% git status
On branch dev
nothing to commit, working tree clean

% git stash apply
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   file-a.txt

no changes added to commit (use "git add" and/or "git commit -a")

log

後で紹介するrevert・cherry-pickを使用する前によく使うのが、git logコマンドです。
その名の通り、コミットログが表示されます。
以下では、devブランチでコマンドを実行しています（--onelineオプションを付けると1コミット1行で表示されます）。

% git log --oneline
9685ed8 (HEAD -> dev) [fix]file-a.txtの修正3
3086831 [fix]file-a.txtの修正2
9a1d825 [fix]file-b.txtの修正1
d5404a9 [fix]file-a.txtの修正1
d473eb5 (main) [add]file-b.txtを新規作成
03a827c [add]file-a.txtを新規作成
60f6efe first commit

revert

git revertはコミット済みの変更を打ち消すコマンドです。
たとえば、「[fix]file-b.txtの修正1」のコミットを打ち消したい場合は、上記のgit logで調べたコミットIDを元に、次のようにコマンドを実行します。

git revert 9a1d825

すると、コミットメッセージがviエディタで表示されます。

Revert "[fix]file-b.txtの修正1"

This reverts commit 9a1d825d9357acc12264764aa3d1ff0c73b5aea0.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch dev
# Changes to be committed:
#       modified:   file-b.txt
#

今回はデフォルトのメッセージで保存します。
コミットログを確認すると、revertコミットが追加されたことが分かります。

% git log --oneline
e18e316 (HEAD -> dev) Revert "[fix]file-b.txtの修正1"
9685ed8 [fix]file-a.txtの修正3
3086831 [fix]file-a.txtの修正2
9a1d825 [fix]file-b.txtの修正1
d5404a9 [fix]file-a.txtの修正1
d473eb5 (main) [add]file-b.txtを新規作成
03a827c [add]file-a.txtを新規作成
60f6efe first commit

rebase

git rebaseは複数のコミットを1つにまとめるコマンドです。
今回は「[fix]file-a.txtの修正3」のコミットを「[fix]file-a.txtの修正2」にまとめてみます。
コマンド実行時に起点となるコミット（「[fix]file-a.txtの修正2」）の１つ前のコミット（「 [fix]file-b.txtの修正1」）のIDを控えておき、次のコマンドを実行します。

% git rebase -i 9a1d825

すると、次のような文言が表示されます。

pick 3086831 [fix]file-a.txtの修正2
pick 9685ed8 [fix]file-a.txtの修正3
pick e18e316 Revert "[fix]file-b.txtの修正1"

これを次のように書き換えます。

pick 3086831 [fix]file-a.txtの修正2
squash 9685ed8 [fix]file-a.txtの修正3
pick e18e316 Revert "[fix]file-b.txtの修正1"

保存するとコミットメッセージ編集エディタが立ち上がります。
今回は次のような文言に編集しました。

# This is a combination of 2 commits.
# This is the 1st commit message:

[fix]file-a.txtの修正2・3

保存すると、

% git rebase -i 9a1d825
[detached HEAD 923f02a] [fix]file-a.txtの修正2・3
 Date: Tue Feb 21 12:10:59 2023 +0900
 1 file changed, 2 insertions(+)
Successfully rebased and updated refs/heads/dev.

とコンソールに表示され、rebaseに成功したことが分かります。
コミットログも書き変わっています。

% git log --oneline
1a766fa (HEAD -> dev) Revert "[fix]file-b.txtの修正1"
923f02a [fix]file-a.txtの修正2・3
9a1d825 [fix]file-b.txtの修正1
d5404a9 [fix]file-a.txtの修正1
d473eb5 (main) [add]file-b.txtを新規作成
03a827c [add]file-a.txtを新規作成
60f6efe first commit

cherry-pick

git cherry-pickを使うと、他ブランチから特定コミットのみを取り込むことができます。
デプロイ時に、開発ブランチをmainやreleaseブランチにマージしてしまうと余計な変更まで含まれてしまうケースで使うことが多いです。
今回は、devブランチで実施した「[fix]file-a.txtの修正1」をmainブランチに取り込んでみます。
この修正のコミットIDを控えたのち、mainブランチにチェックアウトします。

% git checkout main
Switched to branch 'main'

コミットログを確認すると、まだdevブランチで実施した修正は反映されていません。

% git log --oneline
d473eb5 (HEAD -> main) [add]file-b.txtを新規作成
03a827c [add]file-a.txtを新規作成
60f6efe first commit

cherry-pickしてみます。

% git cherry-pick d5404a9
[main a75b68e] [fix]file-a.txtの修正1
 Date: Tue Feb 21 12:09:30 2023 +0900
 1 file changed, 1 insertion(+)

コミットログからも、「[fix]file-a.txtの修正1」のみが取り込まれたことを確認できました。

% git log --oneline      
a75b68e (HEAD -> main) [fix]file-a.txtの修正1
d473eb5 [add]file-b.txtを新規作成
03a827c [add]file-a.txtを新規作成
60f6efe first commit

おわりに

今回紹介するGitコマンドは以上です。
ごく基本的なコマンドばかりだったかもしれませんが、これらを使えなかったことを笑われたり馬鹿にされたりといったことはDWS入社以来なかったので、今はまだスキルに自信がなくても安心して力を伸ばしていける会社と感じています。
当社への応募を検討されている方のご参考になりましたら幸いです。

shumpei