6

I am on a new team, and the way of working is completely different to what I was previously used to where we would work on a feature branch, the testers would test on that feature branch and then we would run a jenkins job to merge that feature into develop when it was signed off by test, rebasing the branch against develop to keep it fresh.

A release cut was taken from develop and this was then released and presumably merged into master. This was my first ever git project and that seems to be quite an understandable workflow for anyone.

I am now on a different team and no one has a real answer for why they are working the way they do, is there a good reason to merge master back into develop after merging develop into master?

This work flow is that I create a feature branch and work on this locally, when I am happy with the feature I then create a merge request into develop. Then I deploy my change from develop and this is what is tested. Once test sign it off I create a cherry pick merge for master branch in gitlab for my commit on develop and once it is in master I release the change from master branch.

The someone always merges master back into develop. I have asked a few of the team members (its a very small team with only 5 devs) and no one really knows why, they are just doing it.

The previous project had over 100 developers working in different small development teams so the restrictions were a lot tighter.

Is this something specific to gitlabs way of working?

berimbolo
  • 3,319
  • 8
  • 43
  • 78
  • 1
    If you and your mates does not know why you do this ... why should we know it. Maybe they do it to have the develop branch on the same state as the master branch... if later one wants to have a second develop branch. But I don't think it is a gitlab way ... we use gitlab, and don't do it this way. – YesThatIsMyName Mar 08 '19 at 09:33
  • 1
    Well I am new to the team, i figured it might be something common to gitlab users or to git in general that was I unaware of. I dont understand why the develop branch wouldnt be in a 'similar' state, because the commits are going from develop into master. Based on your response perhaps the question is too broad\open and should be deleted. I put 'similar' because develop wont ever be the same as master, because as I said changes are going into develop all the time. – berimbolo Mar 08 '19 at 10:42

1 Answers1

7

Once you merge develop to master then both are already in sync with each other so there is no need to merge again master into develop. The only case I merge master with develop is when we do hotfixes on master we merge it with develop.

Harish Barma
  • 624
  • 8
  • 15