54
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【やらかし】git mergeしすぎた話

Posted at

はじめに

名刺の肩書きに“エンジニア”と書かれる仕事に就いたのは丁度1年前、細々と色んな業務をこなしてきた。
そして最近ようやく念願のコーダーとして案件に参加する事になった。

そんな私がgitで悪戦苦闘するお話。

こんな失敗もあるんだな、と誰かの知識に繋がれば私の失敗も成仏されると思う👼

git mergeってやればやるほど良い?(いいえ)

gitを使うのはこれが初めてという事はなく、複数人でのgit管理は3回ほど経験がある。ただどれも大きな規模のものではなく、コミットログを(強く)気にする必要がないレベル。

これまでずっと私はgit mergeはやればやるほど良いと思っていた。理由下記の通り。

  • git mergeすればするほど、コンフリクトを発生させずに済み、他メンバーに迷惑をかけないはず。
  • git mergeすればするほど、ローカルの開発環境でエラーが出にくいはず。だって最新だもん。

git mergeすればするほど、コンフリクトを発生させずに済み、他メンバーに迷惑をかけないはず。

いや、コミットログ汚してるからコードレビューする人、見づらくて堪らんのよ!!!!

人から指摘されて気付いたが、自分の作業ブランチのコミットログに自分以外の人たちのコミットログがてんこ盛り。
もうどれが私の作業か、全く分からないカオスな状況。

自分のコードをマージする時にコンフリクトの解消すればいいやん!!!!

本当うっかりしていた。developブランチが最新になり次第、都度git mergeしてた。大袈裟目に考えると、developブランチが最新になると毎回コンフリクト解消してたという…無駄…。自分のコードをマージするときにコンフリクト解消すれば1回で済むよねっていう話。

git mergeすればするほど、ローカルの開発環境でエラーが出にくいはず。だって最新だもん。

いや意味分からん!!!

当時の私の考えは、
『最新developブランチをmergeすれば、これまでずっとエラーだったところが開発が進んで、エラー出なくなるよね!』
だったが、冷静に考えて自分の開発部分と関係なかったら、他の画面がエラー出してても問題ない。

おわりに

コードレビューしてもらう先輩の苦い顔をされてた。git mergeはしまくるもんじゃない。最後でいいんだ、最後で。
もし開発途中でdevelopブランチを取り込みたい時は、git rebase等もっと良い方法がある。しっかりgitも勉強して、適切な行動をとっていきたい…。

54
40
10

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
54
40

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?