Which git flow is the best for a small team where all developers work on all the projects?

Question

We are a small team of 5 developers. We have just moved from Subversion into Git and have trouble finding the right workflow for us.

We tried to stick from the beginning to the gitflow workflow following A successful git branching model article but frankly, it seems overwhelming for the small projects we work on and some of us have difficulties following it strictly since it’s quite different from the subversion model we are used to.

So right now we aren’t using release branches to make releases because it seems so unnecessary, although we do keep our master clean. In the same way, we aren’t using features branches but working directly on develop instead.

I’m not sure about releases but I feel we SHOULD be using feature branches, it’s just that I don’t know how to work with them. In the mentioned article, as well as in others we’ve read, it recommends keeping features local and squashing the commits in them before merging them back to develop. That looks easy if only one developer is working in that feature but our scenario is that anyone at any moment may want/need to take the project at its current state and continue working on it. So projects change hands a lot and all work must be pushed to the server even if it’s not finished yet, so anyone can pull it and continue working.

So with all our work in remote we find it difficult to keep things clean, our history is a looong list of small commits but, as far as I understand, we can’t squash them or rebase any branch because that will change public history.

We want to do it right but not more complicated than necessary. So any ideas of which workflow would be the best for us and how can we implement it right?

Answer 1

You can keep working on feature branches with small commits and only rebase and/or squash them before merging back to develop branch. From that on the feature branch does not have any relevance so messing up its history is not necessarily a problem.

• create feature branch
• do work, commit push on feature branch
• other developers can take it over and do more work
• when it's ready, rebase over develop, squash small commits and merge it back

It solves your issue of not 'polluting' the history with small commits. The only problem with this approach is that you don't update your feature branch very often so you'll end up having bigger merges.

In my experience the best is to aim for very short living feature branches with using feature toggles. This way you can merge back not complete but not broken feature branches eliminating huge merge struggles.

Having real commit history is not bad. It helps reviews and makes it easier to cherry pick if necessary and helps with merges as well. Your master should stay clean: one commit per release. Develop can be a little bit less clean, a commit per each feature/ticket branch. However you feature branch could contain the history properly.

Also if you do want to keep the commit graph a bit easier to follow, you can rebase often over develop and push it. It's not recommended to alter public history because if not everyone is aware this it could lead to problems. However if at a time only one, or just a few developers are working on the same branch it's acceptable as long as everyone that is working on that specific branch is aware of the rebase (it can be a scheduled thing, or thing you do every time after the develop branch gets updated)