0

This seems like a simple enough question, but it's generated a surprising amount of conversation in the office. Should developers share a branch, e.g. while working on a feature? Or should each developer use their own branch and if collaboration with other team-members is required, then a separate branch (something like a release branch) should be used for the purpose?

I haven't seen any of the major branching strategies address this directly (Git Flow, GitHub Flow, or GitLab Flow). Sharing a single feature branch lets multiple developers easily collaborate, and any cleanup of the commits/messages can be done when a pull-request is created and/or merged. However, even 2 developers can butt heads when working on the same branch, e.g. if one of them uses merges and the other uses rebases. Is there a best practice recommendation here?

Everett
  • 8,746
  • 5
  • 35
  • 49
  • We share branches at work. We coordinate force pushes after rebases via other channels. For a larger change, you can open a pull request into the shared branch from your fork. – choroba Oct 08 '19 at 20:21
  • Sharing feature branches is certainly done, you might want to see [this question](https://stackoverflow.com/questions/3817967/correct-git-workflow-for-shared-feature-branch) – robsiemb Oct 08 '19 at 20:21
  • Really wish I could answer... yeah, we know the question is opinion based... if it wasn't opinion based, why would we ask it? Otherwise we could look it up in dictionary or other definitive source. All questions have opinion based answers when dealing with humans 1 plus 1 doesn't equal 2, it equals 5 minus 3. – gunslingor Oct 10 '22 at 20:54

1 Answers1

3

While I believe this question is subjective, I think it more comes down to what you deem to be a 'feature'. For example, if you have a 'feature' that is broad enough for two or more developers to be tackling it at the same time, I don't consider that to be a feature, I consider it to be an epic.

I would break such work right down to the extent where each 'feature' is restricted to only one developer. That way these features can be worked on independently on their own feature branch by a single developer, and then merged back to develop once the work is complete.

Work should be split (and projects should be structured) in such a way that developers almost never need to work on the same files at the same time, though If two developers are required to work in tandem on the exact same area, developer B can always merge develop back into their feature branch to get the latest changes.

However, I would advise against merging developer A's feature branch directly into developer B's feature branch. In doing so, you're essentially saying that feature B is dependent on feature A. I would also advise against using a 'joint' branch for the same reason.

In such a scenario, I suggest simply delaying work on feature B; you're introducing unknown risk into the development of feature B, and rushing the development of feature A. This can lead to inadequate testing of feature A (which can be resolved by shifting to the left, where the testing is done on the branch itself, before it is deployed back to develop).

Obsidian Age
  • 41,205
  • 10
  • 48
  • 71