GitLab: is there a way to assign a status/comment

问题:

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.

回答1:

We've come a long way since "put what everyone is doing in a big file that they always forget to maintain". What you're doing seems redundant with an issue tracker and pull request system. GitLab has those, so let's use them.

• Make an issue for each task.
  • Name the issue after the task, something human readable.
  • Put the task's description and any other information in the issue.
  • Assign the branch maintainer to the issue.
• Make a branch for that task using the issue number. git branch issue/123
  • If you want to use a fancier naming scheme, put the name of the branch in the issue (I'd recommend against it, keep it simple).
• Use the issue comment system for any discussion about the branch/task.
• Use issue labels for any status or category information.
• When it's ready to merge, make a pull request.
  • Follow the normal pull request process.
• When it's merged...
  • Delete the branch.
  • Close the issue.

This takes advantage of the GitLab issue tracker's good integration with the code. Issues are searchable, they have attached conversations, they can be referenced in commits (and vice versa) and they're archived after they're closed. The branch naming scheme is simple and allows future developers to easily track an old branch back to its development history (the branch name remains in the merge commit after deletion, so make sure you always git merge --no-ff).

回答2:

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