Ask HN: Best Git workflow for small teams

No branching at all + integrated CI/CD.

We work as small team, 3-5 people max.

We just keep it simple like:

- No one pushes to master.

- For every feature (or update on a feature), create new branch.

- Send pull request for reviewing (one of us is the reviewer).

- Merge pull request into master.

---

You could try git workflow, but it's just too complicated for small team (and for large teams too?).

For 5-10 people it depends on what everyone is doing. I typically push some code out in the wild (master) for stuff that wont change and do releases or branching for incremental updates and patches. Git Branching + Git Releases should help you out mostly also bonus if you are using github throw in some good 'ol kanaban action using projects.

I've used both gitflow and the feature branch workflow which is explained here: https://www.atlassian.com/git/tutorials/comparing-workflows/...

both work well I think for small teams just depends on how well you want to organize things.

I had a lot of success with a master branch, all features built in feature branches.

Feature branches were rebased then merged with a --no-ff. This creates a merge commit on master which includes the ticket number and short description.

The rebase is done by the feature branch developer who is usually best qualified to do so.

The advantage is that changes are isolated from each other, so nothing is spread before it's reviewed. The rebase makes the history easy to follow because it becomes linear and you can always easily see exactly what was changed in the branch. You still retain the full history of the feature branches.

Disadvantages: it doesn't scale to a massive team because you need to linearize the merges back to master. So it works for upto around 20 people.

I'd recommend against Git Flow because their method of merging makes it very unclear exactly what was changed in a branch. I actually prefer no feature branches to using Git Flow.

    git checkout master
    git merge --squash some-feature-branch

GitHub flow is the ideal way to go IMO. It is simple, easy to understand, and widely used.

In the end, however, it is going to come down to the specifics of your app and environment. What sort of CI do you have set up? Do you have anything that controls when or how you are able to release code? These types of things are what generally push teams to other models.

There is the philosophical discussion, if you should rebase or not. If your team comes from CVS there is probably no bias yet. Pick for yourself if you prefer a clean or an accurate history.

Git can adapt to any workflow. Why not start with whatever they are used to from CVS and then tailor it to your needs over time?

Master, dev, feature and release. Mostly always in fact.

An admin merges a release back into Master and back through to dev after a milestone build, demo or production release.

Keep the same Workflow with other teams in your organisation if it exists - unless it is fatally flawed - so that team members moving around have the same experience. Consistency and all that

We've been using the Github flow (or some variation of it) in teams of 2-10 people for a few years now. We work on feature branches, merge after code review using the github web UI. Here's a few things that help us:

- Make a rule that anything that's in master can be deployed by anyone at any time. This will enforce discipline for code review, but also for introducing changes that f.e. require migrations. You'll use feature flags more, split db schema changes into several deployments, make code work with both schema version, etc. All good practices that you'll need anyway when you reach larger scale and run into issues with different versions of code running concurrently during deployments.

- If you're using Github, check out the recently added options for controlling merging. Enable branch protection for master, so that only pull request that are green on CI and have been reviewed can be merged. Enable different dropdown options for the merge button (eg rebase and merge), these are useful for small changes.

- It takes some time to get used to those constraints. Make sure that everyone is on board, and do a regular review of the workflow just as you would review your code. It takes some time to get used to, but I think it's worth it in the long run.

I generally like GitHub Flow (https://guides.github.com/introduction/flow/) because it gives you isolation for individuals, but with only one ceremonial branch (ie. master). It might not be sufficient if you have formal release and QA cycles where you need to batch a bunch of changes to push to a staging environment, but all else being equal I prefer to optimize for branching, merging and deploying to production quickly. And with current cloud and/or containerized setups, it becomes possible to have on-demand staging environments (or even using ngrok with dev workstations!), but YMMV.

The main cherry I like to put on top is to always rebase before merging then merge with --no-ff (which is the default with GitHub PR merge button). This gives linear history for purposes of git bisect but preserves the topic branch structure so you don't have to read the tea leaves of the individual commits to piece together the overall development timeline. That one little piece goes a long way to addressing the concern that "rebasing destroys history" (which I don't agree with anyway, but that's the topic of another post).

This might not be worth it for certain types of contributors who are not programmers by trade, but for career programmers I believe mastering git and rebase in all its flavors (-i, --onto, pull --rebase, etc) pays big dividends that your team will appreciate more as the years go by. For git beginners maybe you start without rebasing, then learn the ins and outs of rebasing with local branches only before pushing, before finally going the whole hog and rebasing topic branches with force push before merging.

One last idea I like is Zach Holman's recommendation of deploying topic branches directly and then merging if there are no issues (https://zachholman.com/posts/deploying-software) in order to have easier rollbacks. Then you have 100% guarantee master is always stable.

We use what is basically the "GitHub" flow... forks and PRs on an instance of GitHub enterprise.

This is nice because in addition to the isolation it provides when everyone is working on their own fork it's easy to code review changes BEFORE they land in the "blessed" repository.

It's also nice because junior developers aren't pushing directly to the blessed repo either.

This model is really nice for maintenance and small feature development.

For major new development (new version, major feature that multiple people will work on) we tend to revert back to the behavior of committing directly to the blessed repo.

Paul Hammant has some interesting blogs about the topic and he has been talking and promoting Trunk Based Development for a while. We use a variation of it at work, though we have several teams of ~5 working on the same repository.

http://paulhammant.com/2013/04/05/what-is-trunk-based-develo...

http://paulhammant.com/2014/09/29/shades-of-trunk-based-deve...

http://paulhammant.com/2013/12/04/what_is_your_branching_mod...

If most know CVS already just use it. The burden of switching a tool and learning a new one is not worth it if the old one is good enough. I'd just set up a CC list for patch reviews, put a TODO file in the repo and go on with whatever VCS my team is used to using.

Any advice for a workflow using Gitlab?

I am currently solving the same problem and what helped me a lot was the Git manpage about workflows:

https://www.kernel.org/pub/software/scm/git/docs/gitworkflow...

Everyone says what Git branch workflow should you use, but honestly, it can be complicated especially for junior developers.

Just commit everything to master and that's all! Sound stupid but worked best for us. I have seen a big software company using this, I learned this from them and never looked back!

We use develop branch as a pre-master. All feature branches get pushed to origin and pull requests created to merge feature branches to develop from there. Once a sprint is finished we merge to master and deploy to staging. Staging gets promoted to production using pipelines. As we are in early stages the develop branch is good but I can see us dropping it and using only master once we start doing daily releases.

Quarterly website release cycle with 3-5 developers. usually one liner bug fixes are the only thing pushed to master without a branch as in master -> master. Everything else is a branch / independent feature each developer is working on and we pull them all into a staging copy of master to pretest Which makes it easy to just delete the staging if we want to repull a feature or two and scrap what other features we pulled, once staging is well tested we merge with master on bitbucket as the new release.

The biggest change for us when we starte was do not push features for the 3 month release into master so at any moment or bug fix master is always ready to go live anywhere without some dumb new feature we don't want. Keep master clean dammit :)

Like others are saying here, the branch named "master" is always deployable.

Feature branches are named after a ticket. Pull requests are across branches in the same repo, not across repos. (It's marginally easier to collaborate on feature branches if they're all in the same repo.)

We don't (yet) do full continuous deployment, so many feature branches get grouped together before a release. Our strategy is to test* each feature independently and then merge all the tickets together to a branch named "staging". The staging branch then gets run against some extra regression/acceptance tests and whatever manual tests we may want. If they pass we merge to master, tag, and deploy.

Seems fine so far. Specifics about our tests and deployment process drive the Git workflow more than anything else.

*Run the test suite, test manually, whatever.

Continuous integration AKA trunk based development is the workflow you want to have. Ensure you meet the prerequisites first though (reliable automated tests, solid code reviews, feature flags, etc).

To be precise, small feature branches are perfectly fine. They are meant to be reviewed and squashed into master ("trunk") in a few hours to a few days maximum.

Squashing instead of merging has a big advantage of being able to quickly revert the changes if things go awry despite all best practices in place.

PS Avoid gitflow and similar workflows as they introduce leaps and thus risk. As everything in software engineering, you want your workflow to be as incremental as possible.

This is what's working for us:

  - Branch off master to make your fix/feature. Prefix branch name with "fix/" or "feature/" accordingly. We occasionally use a "script/" or "migration/" prefix too.
  - Do work. Use "git app -p" so commits are fairly small.
  - Make GH PR into master, get code reviewed. CI test are run automatically.
  - Deploy branch to staging environment and test.
  - Merge with GH, deploy to production.

Notes:

  - master is always in sync with production, and so is always deployable.
  - never commit to master.
  - we don't use a develop branch.

At my previous team (5-6 people worked simultaneously) we used CI & CD and we relied on feature flags, so we could merge our branches more often and make smaller pull requests on Github. Each part of the feature had its own branch with a clear goal and tests written for it (we never pushed to master, every time you start working on something, you create a branch prefixed with your initials, make a PR, merge after review and then do it all over again). Of course, master branch was always deployable.

Right now, I work on a smaller project, we use similar workflow - we haven't implemented feature flags yet, but I suppose we will in the future (the project hasn't been released yet actually). I personally don't like developing an entire feature in a separate branch and then merging when it's all over, because code review becomes tedious (and ineffective) and the risk of merge conflicts increases. I would suggest you invest time in writing tests, so you can become better at it (if you aren't already) and it becomes a natural part of your development. Same goes for feature flags :) I was a junior when I started working like this (I still am, kind of) and it meant the world for me :)

Your master branch really should be your master branch. A branch that represents the most up to date working version you have, that everybody works in relation to.

Only working, tested code should make it into master. Code reviews and automated tests are great tools for this, but ultimately, it's up to the individual developers to not be sloppy.

Avoid long-lived branches and big merges. If you've got big features that take a while to complete, break them into smaller things you can deploy sooner or use feature toggles.

Don't leave it too long between deployments. Small, frequent updates are far easier to manage and far less risky. A dozen deployments a day are better than a dozen a year.

Everybody should stay up to date with master. Rebase on top of master before merging instead of having awkward merge commits that only obfuscate history.

If you have people working on features that take multiple commits to implement, use feature branches. These should be rebased onto master and cleaned up before merging into master.

If you combine all of the above, you're heading down a path similar to GitLab Flow or GitHub Flow, so strongly consider using one of those instead of coming up with your own from scratch. Don't use Git Flow. It overcomplicates things and offers zero benefits over the alternatives. As far as I can see, it's only popular because a lot of inexperienced Git users were feeling like they were adrift without a workflow, and a blog post with a snappy title came along at just the right time to catch their attention.

If your team don't have good VCS habits, you need to do something about this. Small, frequent commits that do one thing and one thing only, good log messages, push and pull frequently, etc. If you can't describe the change briefly, you are doing too much in one commit. There's lots of best practices articles for Git that have been written – read them. Also read Pro Git, which is free on the Git website.