GitでRebase運用してたら血を吐きそうになった話。GitHubのメリットをGitLabとも比較して技術検討する。

2019, Nov 14

アジェンダ

• 経緯
• _draftsから_postsに送ったはずなのに復元される
• 開発の歴史をどうやって維持するか？
• GitLabはGitHubより便利なのか？
• どうしてもGitLabを使いたい
  • GitLabで.gitをどうやって管理しているのか？
• GitLabのマイグレーションで学んだこと

たまには真面目に技術ネタと雑考など。
技術系の話は非常にテンションが上がりますね、楽しい！

今回も運用をばっちり固めているわけではないですが、思いついたことをちょいちょいにまとめてます。

まさしくこのrebaseケースに当たってしまいました。 具体的には_draftsから_postsに移動したファイルがある場合、rebaseにより_draftsに移動したファイルが復活してしまいます。 これの変更をなかった事にするため、git reflogで削除する事も考えたんですが、もう面倒くさいのでいいやと。

jekyllで_draftを使うならrebaseはおすすめできません。

経緯

バカ正直にrebaseすればいいんですが、draftsからpostsに移行するまでの間はずっと競合し続けるので、これをなんとかしないといけない。

同じコミットメッセージが複数あることでなんとなく察せるかと思いますが、同じことをやっているので履歴の内容としては不適当です。 履歴を正すところから始めないと（開発はともかく）運用としてはどうにもならないです。 こういう事をやると運用負荷がハネ上がるんですが、管理でどうにかするしかないのも実際の話。 もちろん、業務でやるならこんな雑な対応はしませんがgitのために運用を悩まされたくないのでforce pushで押し切ります。

_draftsから_postsに送ったはずなのに復元される

顕著なのがこれ。 競合解決で漏れるのが、移動（削除）に気付きにくいことにあります。 削除という行動に対して抵抗がすごく高いので、とりあえず足しとけってなります。 そうすると削除した記録の後ろに追加されるようにmergeされてしまうと、探さないと気付かないでしょう。

今回は_drafts以下と分かりやすい場所にあるのですぐに発見できましたが、実践だとこうは行かないでしょう。

開発の歴史をどうやって維持するか？

そこで、force pushを前提とした運用を考えます。 つまり、git logで管理するのではなく、githubで管理するというアプローチです。 そのために、小規模なコミットログをプルリクエストで管理することで、githubに履歴を作っていくという寸法です。

今回は基幹部分を全部GitHubにもたせているので、force pushしてもGitHubに履歴は残っています。 しかしあまりにもGitHubに依存し続ける事になるので、サービスが変更になったらそれも使えなくなる可能性があります。

では、ホスティングサービスを自前で持っておけば良くない？という考え方に対応できるものがあります。 それがGitLabです。

GitLabはGitHubより便利なのか？

使い方次第、と思いますがGitLabが便利かどうかはGitのスキル感によります。 エンジニアリングはできるけどGitは苦手、という人だと、まずはGitの運用から学ぶ必要があるためです。 GitLabだと、運用を考慮してシステムを設計する事になります。

きっかけはGitlabのメジャーアップデートのマイグレーションを業務で行っていた事です。 当時Gitlab Version6系をVer9にアップデートしたい、というすんごい要件にぶち当たった時の問題でした。 github privateであればそういった細かい話は全部投げられたんですが、gitlabは全部こちらで管理しなければならないため、 gitのlogは消したくない、という問題もあります。

どうしてもGitLabを使いたい

まず、先のGitLabのメンテナンスで問題になったのが、あまりにも古すぎて通常の移行手段では失敗するという現象があったことです。 通常の移行手段とは、yum update gitlab-ceとかその辺りですね。 GitLabのアップデートが面倒なのは未だ健在らしいので、管理コストを考えるとGitHubですよ……。

そもそも、無料でプライベートリポジトリを持ちたい、という要望を満たせるのがGitLabしかなかった、という時代背景があります。 今だとカスタマイズしないならGitLabを敢えて採用するメリットは薄いです。Gitコマンドさえ知っていれば良いGitHubと、これに加えてGitLab自体の教育コストや管理方法検討する必要があります。 個人で使うなら、勉強目的でもない限りGitHubで良いと思います。

それでもGitLabを採用する場合に向けて、ハマった時のナレッジを残します。

GitLabで.gitをどうやって管理しているのか？

実態はDBにあります。 メジャーバージョンアップによりDBのマイグレーションが必要になります。 このマイグレーションがクセモノで、そこまで古くない（２世代とか）なら結構なんとかなります。 ３世代以上だともうサポートされていないレベルです。それでも何とかなるようにされているのは素直にすごい。

gitlabを移行（ソース＞Ommunibus、6.8＞8.11、mysql＞postgresql、CentOS６＞７）した話

ここにある手順でうまくいくかどうかは分かりませんが、うまいことやればDBを保持した状態でなんとかできます。

GitLabのマイグレーションで学んだこと

とはいえ、このために頑張るんじゃなくて運用環境を整備する方に手を尽くしたほうが前向きな対応かなと思います。 難しいものを難しく使おうとすると、いずれシステムを捨てる時に、捨て方が分からなくて困ります。

GitLabが教えてくれたのは、他のシステムはサポートが切れたバージョンからの移行に対してここまで健全ではないですよ。 管理できないシステムを運用するのは良くないですので、プロジェクトにジョインした時は現場で使っているツールの把握や習得に努めましょう。 とりあえず動くから、使えるからでは仕事になりませんよ。