Re: git-repo branching strategy

101 views
Skip to first unread message

Magnus Bäck

unread,
Jan 9, 2017, 2:10:42 AM1/9/17
to Gor Is, Repo and Gerrit Discussion
On Thursday, January 05, 2017 at 21:40 CET,
Gor Is <gor....@gmail.com> wrote:

> I am trying to come up with a branching model for git-repo
> (something like "successful git branching model", but for git-repo).
> I am trying to figure out the process used by google to manage AOSP,
> but I cannot find no documentation at all; just the brunches and tags
> from https://android.googlesource.com/
> I spent quite some time trying to make the git branching model to work
> for git-repo as well, but I would like to know if there are best
> practices, etc. For example:
> - Should I keep a snapshot of the manifest in a separate branch for
> every release?

It's a good idea to store manifest snapshots in the manifest git, but
exactly how you organize them doesn't matter that much. You could e.g.
use a fixed name for the manifest file but store them on different
branches or name the files after the release and store all files on
the same branch. The only thing I'd be careful about is having too
many branches. Either way you'll be able to initialize a workspace by
supplying "repo init" with -m and/or -b options.

> -- Should it be containing hashes (repo manifest -o) or
> -- Should it has a default revision referring to appropriate git
> branches in sub projects (or tags?)

Pointing to branches isn't very useful as they are mutable, but using
'repo manifest -r -o' or using a homebrew method to point to tags is
fine. I've always used the former since it works out of the box.

> - Should every release also create branches (or tags) under each git
> project?

For release branches you have two options:

- Branch every git and adjust the default revision in the manifest.
Simple but could lead to lots of unused branches that just select
a point in time from the parent branch.
- Lock each git to a SHA-1 (or a tag) in the manifest and branch as
necessary. Requires more initial setup and extra work every time
a new git is branched but doesn't litter gits with branches.

What's best depends on various factors. How many gits do you have?
How many release branches? How burdensome is it to change the manifest
every time a new git is branched for a release?

Should you tag every release in each git? Maybe. It's certainly
convenient but if you make many releases it'll clutter the gits
and make e.g. gitk usage less enjoyable (and slow down "git fetch"
operations, especially over slow network links). At a previous job
we made up to a handful of builds every day per branch, amounting
to thousands of builds each year. For gits with limited activity
we probably would've had hundreds of tags on many commits if we
had tagged all commits going into each build.

> -- What about hotfixes?

Why should they be treated differently from planned releases?

--
Magnus Bäck | Software Engineer, Software Tools
magnu...@axis.com | Axis Communications
Reply all
Reply to author
Forward
0 new messages