GitLabと仲良くなる

Pleromaの開発はGitLabが使われている。本稿では、GitLabの使い方情報と、Pleromaの開発に固有の事情を織り交ぜてやっていく。

developブランチとfeatureブランチ

まず超実践Gitは強いのでみんな読むといい。ところで、超実践Gitの既存の戦略を知るという節によると、Git界隈で使われているブランチの名前には、以下のような流派がある。

  • git-flow: development, features, hotfix, releases, master
  • github-flow: master

さて、PleromaのGitLabがどうなっているかというと、develop がデフォルトのブランチであり、feature/XXX というブランチと fix/XXX というブランチが大量に作られている。masterブランチは、存在するがまったく使われていない。

Pleromaの開発体制は、ブランチの名前はgit-flowだが、実際にやっていることはgithub-flowである。Pleromaのdevelopブランチは、github-flowにおけるmasterブランチと同じように使われている。そのため、インスタンスを運営したい人はdevelopブランチからコードを持っていくことになっている。

余談だが、ブランチの名前に / を含めることが普及しているのは、初心者にとっては割と驚きがある。

ブランチをいっぱい作る

開発者にとって最終的な目標の一つがマージリクエストを出すことだ。GitHubにおけるプルリクエストのことをGitLabではマージリクエストと呼ぶ。

マージリクエストの実体は2個のブランチの組である。これらのブランチは別のレポジトリに置かれていてもよい。いずれかのブランチに新しいコードがコミットされれば、マージリクエストの内容も変化していく。そのたびに、マージが成功したりコンフリクトしたりするし、テストが通ったり通らなかったりする。

マージリクエストを出すことを想定して、1個のブランチには1個のテーマのコードのみをコミットする。このようなブランチを特にトピックブランチと言うこともある。

トピックブランチとは別に、インスタンスで実際に稼動しているコードを入れるブランチも必要である。AGPLにより、インスタンスが独自機能を持つならば、コードを公開する義務があるからである。私はdistsnという名前のブランチにしたが、deploy/distsn のような説明的な名前のほうがわかりやすいかもしれない。

本稿の読者の知識をどのように想定すればよいかわからないが、クローンとは以下のようなコマンドをやっていくことである。-b のあとの feature/who-to-follow-panel はブランチの名前であり、最後の who-to-follow-panel はローカルのディレクトリ名である。

git clone https://git.pleroma.social/hakabahitoyo/pleroma-fe.git -b feature/who-to-follow-panel who-to-follow-panel

本家のdevelopブランチに追従する

インスタンスを運営しているならば、新機能を取り入れることは欠かせない。また、トピックブランチにおいては、他の開発者による変更と衝突がないようにするために、きりのいいところで本家のdevelopブランチに追従する必要がある。

この作業はGitLabではなくローカルのgitコマンドでやっていく。Pleromaのレポジトリにはpleromaとpleroma-feがあり、ここでは例としてpleroma-feの方でやっていく。

git remote add official https://git.pleroma.social/pleroma/pleroma-fe.git
git fetch official
git merge official/develop

git remote add はレポジトリをクローンしたときに1回やればよく、git fetch と git merge は本家のdevelopブランチに変化があったときにはやるべきである。余談だが、git remote add でスペルミスをやらかしたときの直し方は git remote set-url である。

応用としては、レポジトリをクローンしたときには、自分のレポジトリが origin という名前で登録されている。これに対して fetch と merge をやっていくことにより、トピックブランチから機能を取り込むことができる。

git fetch origin
git merge origin/feature/who-to-follow-panel

pleroma.distsn.org は本番環境が開発環境を兼ねているので、この方法でトピックブランチを取り込んで動作確認をやっている。

ESLintを倒す

PleromaのGitLabレポジトリでマージリクエストを出すと、自動的にテストが走る。マージリクエストではなく普通のコミットでも自動的にテストが実行される。pleroma-fe は JavaScript 的なもの (Vue.jsとwebpackあたり) で書かれているので、ESLintでチェックされる。Lintとは人類にコーディングスタイルを強制するプログラムで、ESLintはそれのJavaScriptのやつである。

ESLintを倒さないと気分が悪いので、倒す。JavaScript Standard Styleという偉そうな名前のやつが相手なので、あらかじめ読んでおくと倒しやすい。

ユニットテストを倒す

pleromaレポジトリはElixirで書かれているので、それ用のユニットテストフレームワークが作動する。ただし、テスト環境が壊れていることも多い。テストの結果を見て、自分が書いたコードとは関係なさそうなところがエラーになっていたら、マージリクエストのコメントあたりで発言すれば、強い人たちが直してくれそうである。

広告

投稿者: Hakaba Hitoyo

墓場一夜

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください