We have 2 branches (master/dev) + some feature branches and 2 environments (production/dev). Our team is a very small people. What are the best practices of merging dev to master?

  • Every morning?
  • After integration tests?
  • How about merging master with dev and then testing (hotfixes) then merging master to dev?
  • Some release branches?

I don't want to create anything too complicated.

  • There isn't any right answer for that. It depends on your workflow. As Vasily says, it's a good practice to use git flow. We work in the same way, merging to master dev branch and the end of each sprint. Also if you need to create a hotfix, that will be inmmediately merged into master an deployed in production as soon as it's finished (with all test passed)
    – RuBiCK
    Commented Mar 15, 2019 at 8:27
  • Yeah I always wanted to use gitflow. So probably we will move into direction of gitflow. Does gitflow also work well for repos that are dependent on each other?
    – sacherus
    Commented Mar 15, 2019 at 15:04
  • With git flow you manage the workflow and branching for a single repo. You should use the same flow for each git repo, including the submodules
    – RuBiCK
    Commented Mar 18, 2019 at 9:48
  • You should explain why you have those branches (what do you want to use them for). IMHO the branch structure and merge strategy are the result of picking a workflow/development strategy, not the other way around... Commented Mar 22, 2019 at 7:16

3 Answers 3


You can use "git flow" or more simple "gitlab flow".

Our small team merge into master on release or sprint ends.

  • funny how this is a comment really, but the most upvoted answer that doesnt really answer anything
    – 4c74356b41
    Commented Mar 21, 2019 at 16:07
  • 1
    Thats cuz it answers everything 🤔 Commented Mar 22, 2019 at 7:54
  • which is the equivalent of nothing
    – 4c74356b41
    Commented Mar 22, 2019 at 7:54
  • Depends on what you wish to see ;) Commented Mar 22, 2019 at 10:44

There are many theories about git branching models. You know about "git flow" https://nvie.com/posts/a-successful-git-branching-model/

But in practice that will slow you down in most cases. Remember Amdahl's law - put the effort where the usage is. At my workplace we only branch when making a merge request. This way we won't have to work for days with sham work like "merge to master" which will create impediments just because somebody was branching for the sake of branching. That works for us.

So I suggest that you commit to master and only branch when making a merge request. This is almost controversial in some cases, but I am all open for discussion.

  • At least somebody posted that link so I did not need to. I think that Vasiliy above nailed it though. Just pick something and stick with it. Keep it simple.
    – Randy L
    Commented Mar 22, 2019 at 14:54

It depends, pull request reviews should be done before merging to master. If you are using CI/CD, that would occur as often as you can schedule releases. I prefer the fork and pull request workflow, keeping the base repository cleaner. The devs can organize how they choose on their ends in their forks as long as they are routinely fetching from the base master branch.

If a dev quits, no one wants to be confused by what he/she was working on, so there is a plus with fork and pull there as well. Likely the next guy will start over from the approved master branch anyway.

Integration tests happen after merge to master, then there are conditions that must be met prior to release within the CI/CD pipeline that if not met will break the build. Use the same branch for all environments, with environment variables if there are differences in environments. You can use labels or the merge requests themselves to describe what’s released. You don’t necessarily need feature branches. It just depends on the complexity of your project(s) and your team. More branches = more complicated from my perspective, particularly with dependencies on multiple repositories. Don’t tell the devs how to work, if you can avoid it, just set the requirements for approvals, rollbacks, and workflows necessary to guarantee you can report effectively to your management. Keep it simple. Good devs will figure out how to work together on their own.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.