gitlab mr wip 怎么弄成,GitLab：有没有办法给分支分配状态/评论？

I'm planning to use GitLab to manage Git repositories (mainly Linux kernels from various hardware vendors).

Currently, I'm using Gitolite to manage users on Git server and MediaWiki to have what a call a "branch table"; in other words, a table where the single users report:

branch name (e.g. xboard-feat-i2c2)

branch maintainer

short branch description (e.g. "started from rev 2.0.0, feature branch to implement i2c2 driver on custom hostboard X")

branch status (WIP, testing, ready to merge, aborted)

branch longer informations (e.g. "to build this branch you have to change this and do that (in respect to the default instruction). We currently have a problem on this.." and so on). On this section I also usually write reference to the test bed/test suite used to test this specific software.

The main problem here is that the above table is created manually, and sometimes, users forget to add branches or rename them.

I'm wondering whether there's a place in GitLab (or a similar tool) to insert this piece of information.

I'm currently planning to force the user create a README (or a BRANCHREADME, to avoid conflicts) on the root of the repository as explained here with all the required information and I'm wondering whether there's a way to create a new page in GitLab project to show all the README informations for the various branches.

解决方案

My solution to my own problems, after working daily for a couple of year with GitLab to manage many project is as follows:

create an issue for everything (bug, new feature ecc). Describe the problem/idea and not how you're solving it

when start working create a new MR (this can be done with the button into the issue itself). This generate both a working branch and the MR (as WIP)

explain what you're doing into the MR

once the work is done, remove the WIP from the title and, either:

merge the MR and delete the branch

or: close the MR and delete the branch if it's not useful.

Please note that, even if you close the MR and delete the branch, the commit will stay there (even if not "directly" accessible via git), so you're not loosing anything of your work.

You can also use the same workflow when "reworking" a branch: I don't want to miss the original implementation (because I can add bugs/issue during the rework) so:

- create a new branch, with a suffix of revision (e.g. -v1, -v2 and so on)

- create a new MR for this branch, writing down what your rework/review

- comment the original MR or the new one (it doesn't really matters) with a reference to the other MR (so they are "linked")

- close the original MR and delete its branch

This allows me to both have a low number of open branch per project (usually are merged or closed) but have documentation about the work done and never loose a single commit