---
title: 'Request for comments: GitLab flow'
tags: untagged
categories: company
status: draft
type: post
published: false
meta:
  _wpas_skip_1532919: '1'
  publicize_reach: a:2:{s:7:"twitter";a:1:{i:1532919;i:40;}s:2:"wp";a:1:{i:0;i:1;}}
  _wpas_done_1532919: '1'
  _publicize_done_external: a:1:{s:7:"twitter";a:1:{i:776273100;b:1;}}
  geo_public: '0'
---
GitHub flow is great but it is missing issue integration and rebasing. Issue == Branch name == First merge request == Second merge request Rebase on merge (if commits are not in other branches) Multiple merges possible (reopen merge request: request/merge/deny) Always delete the merged branch (so it the second merge request can reuse it) Want to know if other people like this, if so we will integrate it into Gitlab Advantages: Branch issue relation is clear Merge request issue history is clear Rebasing makes the master history clearer Rebasing makes it easier to revert the merge in master Solves: Wanting to check out an issue and not knowing the branch. Second merge request is different than the first. Seeing branches but not knowing their status. [http://layervault.tumblr.com/post/33781162425/divergence](http://layervault.tumblr.com/post/33781162425/divergence) branch name => subdomain Auto create changelog based on merged branch. Use an annotated tags to store them instead of a file. Changelog is created on each release (gem, etc.) or deploy (saas). Do something with storing the issues in the repo too? Make it easy to find the issue nr. everywhere (native tool, select and hotkey) [hybridgroup.github.com/](http://hybridgroup.github.com/gitnesse/) store issues in repo? Instead of rebasing master when pulling (can't share with coworkers) use --no-ff: From git flow: "The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. Compare: In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used." And see "Reverting a Merge" http://git-scm.com/book/ch5-3.html#largemerging\_workflows Store issues just like a wiki  [https://coderwall.com/p/vuy3nq](https://coderwall.com/p/vuy3nq) already an option for  [http://ditz.rubyforge.org/](http://ditz.rubyforge.org/) see Documentation point 2. Need uuid for the issue number, readable name needs to be the same as a subject branch name, can just agree to put the bug in a an Issue file in the root. Issue is opened when the branch is pushed. Issue is closed when the branch is merged into master. But a decentralized bug tracker might not be very convenient, how to work with duplicate bugs? Also a proposal to store branch information  [https://gist.github.com/4526768](https://gist.github.com/4526768)