Question

Wondering if this is a reasonable approach to using git with a small team:

1. We have the “master” branch. Git creates this branch for us by default.
2. Developer A and B clone “master” to their local machines.
3. Developer A runs: [git branch devA] to create a local branch. They switch to it by running: [git checkout devA].
4. Developer B runs: [git branch devB] to create a local branch. They switch to it by running: [git checkout devB].
5. For Developer A to turn their local branch into a remote branch, they would run: [git push origin devA]. Developer B does the same thing to their local branch.
6. Now if using GitHub, we would see these two remote branches on our project page.
7. Both developers make changes to their local branches, and running [git push] will push their commits to their respective remote branches (we would see this reflected on github).

That seems like a reasonable workflow to me. Now it comes time for the developers to merge all their work for a release of the app they’re working on. My understanding:

1. Developer A wants to get Developer B’s changes into their branch. Developer A would run: [git pull origin devB].
2. We might create yet another remote branch named “dev” which acts as a central repository for everyone’s changes: [git branch dev], [git push origin dev].
3. One of the developers switches to branch “dev”. They pull everyone’s changes into it: [git pull origin devA], [git pull origin devB]. All conflicts are fixed etc.
4. After all conflicts are fixed on “dev”, we then switch to branch “master”, and pull “dev” into it: [git branch master], [git pull origin dev].

So the idea is that all developers work on their own local branches, and periodically merge stuff into “dev”. Only at release time does someone pull changes from “dev” into “master”. So “master” always contains the last-released code.

Does that seem reasonable?

Thank you!

Answer 1

This workflow would probably be fine, though it has some points that you may want to think about.

It does not reflect a common Git philosophy of having each branch represent one “feature” or “topic”-worth of work (see, for example, Junio Hamano on the purpose of branches). However, that wouldn’t stop it from being a workable workflow for your team.

A popular workflow that reflects this philosophy is git flow.

Another popular workflow is the workflow that the GitHub dev team uses which directly goes against what Junio writes about merging master into feature branches, in favor presumably of keeping the mental model simpler and avoiding having to explain about rebasing to developers.

Another issue is that this workflow discourages frequent integrations. So devA and devB may diverge significantly and the developers may have to do a lot of work to merge when the time comes.

Git itself does not care so if your developers are happy, then what you propose seems workable.