この記事は，東京大学工学部電子情報工学科・電気電子工学科(通称EEIC)の3年後期実験の一つである「大規模ソフトウェアを手探る」のレポートとして，書かれたものです。

OSS開発初めかた (GitLabにある本家にマージ)

「大規模ソフトウェアを手探る」という実験で私たちの班はOSSのお絵かきソフトであるinkscapeを題材として選択し、バグを修正してマージするところまでできました。この記事ではGitLab上でOSSのIssueを直したMRが承認されるまでを書きます。環境構築、バグの直しかたについては以下の概要記事から参照してください。
Inkscapeを手探る - Qiita

また直したいバグがないけどOSS活動がしたい方はそれぞれのOSSのIssue一覧をみると良いです。OSS開発初めかた (Issueの見つけ方) - Qiita
inkscapeへのバグの修正のマージの経験を例にOSSへのMRが承認されるまでを書きます。本家という単語を何度か使いますがこれは貢献するOSSのリモートリポジトリを意味します(この投稿ではinkscape)。

自分のアカウントのリモートリポジトリにForkする

本家のリポジトリに直接branchをはやすことはできないので、自分のリモートリポジトリにForkする必要があります。

本家のページの右上にあるForkボタンを押すと自分のアカウントのリモートリポジトリにコピーが作られる。

以下が自分のリポジトリにForkされたもの。

cloneして仕事にかかる！

forkしたリポジトリをローカルにclone

cloneと書いてあるところからurlをコピー。

ワーキングディレクトリを、ディレクトリをクローンしたい場所へ移動してクローンする。

$ git clone コピーしたURL

例

$ git clone https://gitlab.com/自分のアカウント名/リポジトリ名.git

上流リポジトリとして本家リポジトリを設定する。

Forkした自分のリポジトリからcloneしただけだと、ローカルで作業中に本家で変更があった時にそれを取り込めないため、上流リポジトリとして本家ディレクトリを設定します。
まずgit remote -vで現在のリモートリポジトリの一覧を確認。

例

$ git remote -v
> origin  https://gitlab.com/自分のアカウント名/リポジトリ名.git (fetch)
> origin  https://gitlab.com/自分のアカウント名/リポジトリ名.git (push)

git remote add upstream　本家url リモートリポジトリとして、本家のリポジトリを upstream という名前で設定します。本家って名前の方がわかりやすいならgit remote add honkeとかでも別にいい。

$ git remote add upstream https://gitlab.com/本家アカウント名/リポジトリ名.git

再度git remote -vと入力して,フォークの URL が origin として、本家のリポジトリの URL が upstream として表示されていることを確認。

これで本家に変更があった場合に以下の手順で本家と同期させることができる。

$ git fetch upstream
$ git checkout master
$ git merge upstream/master

※GitLab Docsを読んでいたらRepository mirroringというのを用いれば、upstream設定をしなくてもForkしたリポジトリが自動的に本家に同期できるらしい。

これでローカルで作業できる！
ローカルでバグを直したり、新機能実装などができたら自分のリポジトリにpushしてMRを出しましょう。

MRだす。 (本題)

自分のリモートリポジトリの上の➕マークから New merge request のところをクリック。

自分のリポジトリのどのbranchから本家のどのbranchにmergeするか確認。(今回開発したinkscapeは全てのmergeがmasterにされていたためmasterにmergeしたがプロジェクトによってはdevelopブランチにMRを出すところもあるので、それぞれのOSSのcontributing guidelines を確認しよう。)

Tile と Descriptionを書く。

Titleはどのような変更をしたかわかりやすいように。

今回はIssueにあったバグを直したのでそのIssue番号をのせた。I fixed #1921
番号を載せるだけで自動で該当Issueへのリンクがつき、該当IssueのページにもそのIssueを直すMRが提出されたことが自動で言及される。
Yusuke Ebihara @ebiyuu1121 mentioned in merge request !2401 (merged) 2 weeks ago

自動でこのコメントがついたため自らコメントする必要はなかったかもしれないが、一応礼儀(?)ということでI fixed this issue here.と一応コメントも残した。

MRがマージされるまで

pipelineテスト

GitLab上にコードをpushするとそのリモートリポジトリ上に設定されているテストが作動します。動作は.gitlab-ci.ymlに記述されています。これはpushしたコードがきちんとビルドするかのテストや、clang-tidyによるエラーチェック、codequalityによるコーディングスタイルチェックがされます。codequality意外のテストでfailとなった場合はコードに問題があることが予想されるためMRを出してもレビューされない可能性があるため、テストをパスしているか気をつけましょう。(failするとgitlabからメールが来るので気づく)

参考：https://www.ospn.jp/osc2019-fall/pdf/OSC2019_TokyoFall_Yano.pdf

権限ある人の目に留まる。

Merge許可をだす権限の人の目に留まり、コードに問題がなければmergeされます。

同時にこのMRにより直されたバグのIssueもクローズされました。

完了！

今回はマージリクエストを出しマージされた事によりInkscape上のIssue #1921を解決することができた。数日間でMRオープンからマージまでいきました。

今回例として使ったMRの他に不要なコメント削除をお願いするMRも提出しました。こちらは１日でマージされました。inkscapeは活動が盛んのようですぐに承認されました。

これからもOSSにコミットしていきたいと思いました。