Git work flow for pull request in large team

[VinayBalajiRajputh]

Hello everyone,

Currently I am a part of around 10 developer team and follow scrum. We use Git for version control system. Our work flow looks as following:

1. Master, develop and feature/bug/task branches.
2. At the start of the Sprint every developer is assigned a ticket and he creates a branch from develop and starts implementing.
3. Once a developer is done with implementation a pull request is created to merge back to develop.
4. Reviewer get the pull request and once everything looks good it is merged to the develop and the branch created by the developer is deleted.
5. At the end of Sprint a tag is created from the develop and delivered.

Now in the above process, sometimes the pull request changes are big and the reviewer has to review lot of code. How should this be handled so that the reviewer does not have to review large part of code in a pull request.

I see two work flow the first one is as following:

1. Create a branch for a ticket and if the developer thinks if large part of code has to be changed or implemented he creates a new branch from the current branch. For ex if developer creates featureA branch from develop, he shall create one more branch from featureA i.e. featureA1 and start implementing here.
2. Now after certain point i.e. may be 200 -300 line of changes he creates a pull request to merge featureA1 to featureA.
3. Now reviewer reviews against featureA and once the implementation looks good her merges featureA1 to featureA. Later developer deletes featureA1 and again creates new branch from featureA, for ex. featureA2 and repeats the procedure.

Second one shall be as following:

1. At the start of the Sprint if the developer thinks the ticket is big enough and large part of code has to be refactored or new code has to be added he breaks the ticket with subtasks(as in Jira). For ex. TicketA is big feature and developer or team lead breaks it into two subtask (which is two sub tickets) i.e. TicketA->SubTicketA1 & SubTicketA2.
2. Now developer creates a branch "featureA" from develop branch and additionally creates a branch subFeatureA1 from featureA.
3. Now after the developer is done with implementation a pull request to merge with featureA. Once the reviewer finishes the review he merges the branch.
4. Now the developer deletes the subFeatureA1 and creates new branch from featureA as "subFeatureA2" and follows the same as mentioned.

Is there any other work flow (or Best practices) to handle the above problem if not which one of the above is a better choice?

Thank you

[Aron Gombas _Midori_]

IMO pull requests should be related to one user story or to one sub-task, with the issue and the code changes forming one self-containing logical unit.

If you find the diff (cumulated code change) too large to understand, then consider breaking the story to smaller units.

[b9sk]

Our small team use a similar flow. A user story is a pull request. Sub tasks of the user story are commits. Each pull request and commit should have a project key with its auto incremented number like `DEV-32 Title of a user story`, `DEV-33 Title of a sub task` respectively. It works good for small 1-5 teams at least. 

[VinayBalajiRajputh]

Thank you

[mr-t]

Hi @VinayBalajiRajputh,

We are working on a project with about 13 developers and also follow the agile method (although we customized it to our needs).

The problems you describe are very familiar and we also tried to solve it via the 2 flows you listed. We even had a convention in the naming of the branches based on the ticket nummering in jira. Our "Feature" is an Epic with stories linked to it. The "main" feature branch we named it "feature/AQR-123-summary" and the sub branches where "feature/AQR-123/ADQ-456-summary (we use different projects for our features and stories reason for the AQR vs ADQ) ... and thus in Bitbucket we always knew what branch was a sub branch and what was the "final" feature branch that eventually was going to be merged in master (we are not using an intermediate develop branch). The remaining of the flow is as you described, reviewers get to it, and when done it is merged.

But, as you probably see it coming, for us it caused a lot of issues. When there were big features, things couldn't be simply merged in master because it could not be activated on production until everything was done ... leading to long living branches that eventually required to be aligned constantly with master, and when the dev forgot to align it often it lead to merge conflicts (aka headaches :p). Not to mention that code improvements done while developing that feature took sometimes ages to hit the master branch. 👎

We solved all our problems by working with "feature flags" aka "feature toggles" (https://www.martinfowler.com/articles/feature-toggles.html) . The advantage is that you can merge in master as soon as your "small" story is finished and reviewed. I know some dev teams that don't even create (feature) branches, but we don't do that, we still create a "feature" branch, but they are always small. We only activate/enable the "feature flag" when we we know the feature is finished. Or when it's almost finished, we already activate it on our sandbox server in order to get a feeling on how it goes.

Now, working with feature flags comes with their own challenges. But in general, the trade-off is worth it.

We are coding in a way that our application can be deployed at any time while running. So if you have a relational database (like e.g. MySQL) we always make sure that the migrations are backwards compatible. This is important as a story or task requiring a change in the database will be merged before the feature is ready!

If you want an example of a library allowing to do feature flags, check this one https://github.com/FetLife/rollout. We are using an implementation that was based on this one.

I highly suggest you to try this out as I'm confident it will be a better flow for you guys!

Cheers