1

We are trying to incorporate the team build concept in a team. I do not know exactly what's the professional name it has but the scenario would be self-explanatory what we want to achieve. I've tried searching it on the portal but could not find anything relevant.

Currently, we take the following approach to move our feature from local to master.

  • We create the feature branch from the master.
  • Implement the feature and push the changes to master as a merge request.

The problem with this approach is if there are any compatibility/merge issues with the code which is overlooked at the time of merging ultimately creates issues at the time of building or deployment; affecting the number of teams who are waiting to work/test on the latest code on the environment.

So we wanted to isolate the developers from directly merging their feature branch changes into master and came up with the concept of integration branch for the sprint. With the integration branch, we would build and deploy that integration branch code to our team servers and do all the testing there. Thus, all the problems with the merging or any code compatibility issues would be catered at the team build level without impacting the environment.

All being said, I have some confusion regarding the feature branches that we would be creating.

  • On sprint start, I am creating and pushing the integration branch from master and on subsequent days I am rebasing the integration branch from the master. We are deploying this branch to our team servers.
  • After picking the feature to work we are creating the feature branch from the master, implementing the feature there and then when a feature is completed cherry-picking that commit to the integration branch.
  • Once the testing is completed on team servers we are creating the merge request from the feature branch to be merged on the master.

Is this model correct or are we missing something?

Thanks

Suraj Sharma
  • 49
  • 6

1 Answers1

1

In my understanding the gain will be minimal if at all... Let me explain:

Branches in git are no more than named pointers to some commit id and its up to you to define the policy of working with branches.

So at the beginning of sprint you create a pointer on master which (I understand from the question) moves fast and changes extensively during the sprint. The integration branch gets rebased from master and basically looks like a master + features that started and ended during the sprint (I'll call them small features for clarity).

The Feature branch that you describe is taken from master and not from the integration branch, ok, lets say at the beginning of the sprint.

The end of sprint comes and the feature is ready, so you try to cherry pick it to the integration branch. At this point the cherry pick will fail because the integration branch contains both new commits from the master branch (that were the issue in the initial approach) and other new features that were merged into integration branch and are not yet in master - they can only influence the code.

Now the maintainer of the feature will have to resolve the conflicts anyway - the same set of conflicts that you had in the initial approach + set of conflicts from the "small features"

Another concern is that if one of those small features doesn't really work you won't be able to merge into the master the big feature that is proven to be worked properly by tests.

Based on these thoughts let me propose an alternative approach:

I'll rely on the following "claims" if you wish:

  1. Git doesn't "encourage" long-living branches.
  2. Feature branches are ok, but the maintainer of the feature branch should make it up-to-date.

My approach is:

  1. Create a feature branch out of master at the beginning of the feature, assuming the master is not broken. If the master is broken for some reason, find the last commit that makes it possible to work with master and create a feature branch from there

  2. When you work on feature, rebase from master frequently and keep the feature branch "up-to-date". The more frequently you do it - the less the chance of collisions.

  3. When the branch is ready - rebase from master again to be up-to-date and push to tests or whatever then merge. Assuming you did "2", this step will be easy.

A note about "2": The feature branch is only yours (assuming only you're working on the feature) so these rebases are harmless and will affect only your local commits. If you need to store the results in the remote repo, then your commit's SHA1-s will change every time you do a rebase. In this case you can "suppress" the origin branch by using git push -f

Mark Bramnik
  • 39,963
  • 4
  • 57
  • 97
  • Mark, thanks for detailed explanation but in point 3 when you said push to tests did you mean integration branch? – Suraj Sharma Dec 04 '19 at 11:18
  • Oh, I meant to "submit" the ready branch to be merged into master. Sometimes there are tests that CI should run on the branch in order to "confirm" that this branch is eligible to be pushed to master – Mark Bramnik Dec 04 '19 at 11:48