2023年4月下旬現在、入社から5ヶ月が経過。
今回は、僕が入社後5ヶ月目にどのような業務に取り組んでいたのかということと、5ヶ月間やらかし続けていたことについて、まとめてみました。
(後述しますが、実は「5ヶ月間やらかし続けていた」と思っていたことは勘違いで、そこまでやらかしていなかったことが記事投稿後に分かりました。)
どんな業務に取り組んでいるのか？
主に、「サイト更新作業」と「サイト解析作業」を行なっていました。
内容は3ヶ月目に行っていたこととほとんど変わらないです。
以前までは、1つ1つのタスクで「作業のどこかで詰まって自力で進められなくなり、チームの人に教えや助けを乞う」という状況が発生していました。しかし最近はその頻度が減り、「自力でタスクを完結させられる」ことが増えてきたように感じています。
まぁ、あくまで「以前と比べたら」という話なんですけどね。
また、3月にコーディングを行なった新規案件のWebサイトに関しては、現在、先方からのチェックバックに対応している段階です。本公開はまだ先になりそうです。
sourcetreeを使ったgit操作でやらかしていた
先日、自分が今までgitでやらかし続けていたということに気づきました。
gitというのは「分散型バージョン管理システム」のことで、チームで開発作業を進めるための管理システムです。
gitをそのまま使うとなると「キーボード入力でコマンドを打つ」というエンジニアっぽい操作が必要になるため、社内では「sourcetree」という感覚的に操作しやすいツール(GUIツール)を使っています。
僕はそのツールで誤った使い方をしていたことに入社5ヶ月目で初めて知りました。知らないうちにチームの人に迷惑をかけていた可能性が高く、今更気づいてしまったことに「申し訳なさ」「惨めさ」「恥ずかしさ」を感じています。
(繰り返しになりますが、「やらかし続けていた」と思っていたことは勘違いで、そこまでやらかしていなかったことが後で分かりました。)
gitで何をやらかしていたのか？
gitを使うことによって、たとえばサイト更新などの作業をするときに、「既存データ情報」と「自分の作業によって更新される情報」を切り分けることができます。
(専門用語で「ブランチを切る」と言います)
そして作業した後、本アップ(本公開)まで終えることができれば、「既存データ情報」と「自分の作業によって更新される情報」を合体させることができます。
(専門用語で「マージする」と言います)
しかし、チームで作業をする場合、それら情報を合体させる前に、他のメンバーに作業を引き継ぐことがあります。
本来、情報を合体させる(マージする)前に作業データを引き継ぐとき、「自分の作業によって更新される情報」をチーム全体で共有できる状態にしなければいけません。
(専門用語で「プッシュする」と言います)
にも関わらず、僕はその作業(プッシュ)が正確にできていなかった上に、自分ができていなかったことに気づけていませんでした。
そのせいで、作業を引き継ぐときに、次に作業する人が更新前の状態から作業を始めることになるため、僕が作業をして更新したはずの情報が巻き戻ってしまっているという現象が起こっていた可能性が高いです。(と思っていたのですが、後日そこまでやらかしてなさそうだということに気づきました。)
gitについて基礎から学び直そう
入社して間もない頃の僕はgitに関して今以上に無知だったので、gitについて基本的なことを知っていく必要があったのですが、僕は書籍などを使わず、Quiitaでgitに関する記事を読んだりしてgitの理解に努めていました。
当時はなぜか「書籍を使って体系的に学ぶよりも、実践しながら分からないことを調べていったほうが効率的だろう」という考えで、書籍を使った学習は一切行いませんでした。
冷静に考えると、gitのようなチーム開発をするうえで欠かせないシステムは積極的にトライアンドエラーを起こして学ぶようなものではないので、基本知識を獲得する段階では「体系的に学ぶ」ことがかなり重要なのですが、今までgitについて体系的に学ぶということを一切せずにここまで来てしまいました。
そこで、先日、慌てて git と sourcetree について学べる書籍があるかどうかネットで調べてみたら、基礎から学ぶのに適切な本だと思われるものが2冊出てきました。
この2冊はどちらも、アマゾンで高評価が得られていて、評価人数もそれなりに多く、信頼できる学習本だと判断しました。
「サルでもわかるGit入門」に関しては現在Kindle Unlimitedで読み放題の対象になっているため、一旦、普段使っているKindleで「サルでもわかるGit入門」を読み進めて、gitとsourcetreeの使い方について復習していきたいと思います。
【追記】実はそこまでやらかしてなかった
この記事を投稿してから気づいたのですが、僕がやらかしていたのは、ここ2週間ほどの、ある特定の場面でのプッシュ操作であり、それ以前は誤ったプッシュ操作をしていなかったようです。
ふぅ。よかったよかった。
【追記】sourcetreeにおけるコミットとプッシュ
普段の業務でコードを編集する作業を行うとき、「main(master)ブランチ」から「develop_○○ブランチ」という名前のブランチを切ってから作業を開始し、作業した部分を本公開させた後に「develop_○○ブランチ」を「main(master)ブランチ」にマージします。
この「ブランチを切ってからマージを行うまで」の間に、コミットやプッシュを行うことで作業履歴を残していくことになります。
業務ではsourcetreeというGUIツールを使ってgit操作を行うのですが、sourcetreeにはコミットとプッシュという2つの操作をまとめて1回の操作で行うという機能があり、僕は5ヶ月近く、その機能を使うことでプッシュを行なっていました。
コミットとプッシュをまとめて行える機能は便利ではあるのですが、状況に応じて使い分けないと「プッシュすべきではないところでプッシュしてしまった〜」という事態になりかねません。
そのため、sourcetreeを使ったgit操作においても、コミットとプッシュは基本的に分けて実行することにしました。
自宅で使用しているMacBookではSourcetreeが使えないので、スクショを使った説明が出来なかった〜
【追記】sourcetreeでの誤ったプッシュ操作
僕は「sourcetreeでコミットとプッシュを分けて行う」ように作業手順を変更したのですが、それ以降、コミットとプッシュを分けたときのプッシュ操作である過ちを犯していました。
それは、作業用に切ったブランチがローカルでしか存在していない状態、つまりリモートにまだ反映させていない状態のときに、「リモートブランチを作成したうえでプッシュを行えてなかった」ということです。
そもそも「プッシュ」というのはコミット情報をリモートブランチへ反映させる操作であるはずなのに、リモートブランチがない状態で「プッシュ」のボタンを押していたため、「リモートブランチへ反映させる」が出来ていなかったようです。
なぜこのような過ちを犯してしまったのかというと、コミットやプッシュといったgit操作それぞれについての本質的なところの理解が抜けていたことで、sourcetreeを使った操作についての自分の勘違いに気づけなかったからだと思われます。
「プッシュができていなかった」のはおそらく2回ほどで、そのうち1回は社内の方の指摘で気づくことができました。そのため、「5ヶ月間やらかし続けていた」わけではなさそうです。
とはいえ、今回じぶんが誤ったgit操作をしていたことから、自分自身のgitに対する理解度の低さが分かったので、gitについて基礎的なところから見直していきたいと思います。
今回は、僕が入社後5ヶ月目にどのような業務に取り組んでいたのかということと、誤ったgit操作をしていたことについて、赤裸々に紹介してきました。
毎月、「職業訓練修了して入社後○カ月目の振り返り」という記事を書いているのですが、毎回じぶんの無力さについて振り返ってばかりなので、来月くらいにはポジティブな内容が書けるようにやっていきたいなぁと思います。