Search code examples
gitmergegitlabgit-workflow

GIT: more than one developer working on the same feature

I have a question regarding on what's the best workflow for the following scenario.

Currently there are 2 branches:

  • master
  • development

master only accepts code via approved merge requests.

Given 2 developers working on the same feature, different pieces, what would be the best way to create a merge request for this feature:

  1. each developer creates his own? (they both have each others code because in order to progress they've pushed and pulled from each other directly)
    • wouldn't this cause issues since the first creating the merge request would have the others changes? pushing one commit at a time would be really tedious. Maybe keeping a branch with only local changes and creating an integration branch? But then the merge request doesn't work on its own, nor makes much sense.
  2. one of them creates a "complete" merge request for both?
    • reviewing it becomes a much bigger job since it's a lot more code and we can't have 2 owners of the merge request at once
Solution

  • If both developers part isn´t independently I would suggest you go for approach number 2, one developer creates a merge request containing both jobs. However, you can make this little less hard by:

    -Make each developer to conduct code reviews on their part of the job in smaller pieces. While this would not avoid a code review on the entire work going to main branch, it will for sure makes rejection less like.

    -For big features, whenever possible, each developer should generate smaller pieces of the job ("atomic commits") that are not dependent on the others job, this piece could then be merged into development branch and pulled from the other developer to continue his work. This way, when the feature is done it is already living in development branch and not on developer´s topic branch.

    Per your description I believe your developers would have topic branches containing all work. You cannot separated both easily from topic branches standpoint. So go for approach number 2 and do sign by both developers.