rebase - Git Workflows: Rebasing Published/Shared Branches -

our team @ work has enthusiastically adopted rebase workflow, might have gotten little carried away, point of question: judge.

using pull --rebase no-brainer me now. however, have large feature branches multiple people work on. periodically, want bring in changes happening on master. conventional wisdom have merge since it's shared branch. however, in our rebase-obsession, we've decided rebase branches. of course requires everyone's cooperation. workflow goes this:

1) rebaser coordinates make sure they're checked-in , pushed on feature branch, asks them no more work on branch until clear.

2) rebaser rebases feature branch onto master, deletes remote feature branch (git push origin :feature), , pushes new, rebased feature branch (git push origin feature)

3) rebaser has fetch, updates feature branch, delete local feature branch (git branch -d feature), create new local feature branch tracks remote feature branch. gets all-clear.

this workflow working, partially because we're small group, , work interruptions small. however, worry we're learning poor git habits (rebasing shared branch), or workflow won't scale well.

on upside, our repository history lovely.

what think, git gurus? playing fire, or rocking reasonable workflow?

update:

it's 2 years since asked question, , has our workflow changed since then. still routinely git pull --rebase, hasn't changed. it's common sense, , prevents unsightly, confusing mini-merges. (we keep in sync, there's little cost git pull --rebase).

other that, however, , occasional heroic action correct mistake, on our rebase madness. merging makes sense of time. however, wanton merging problematic, , contribute confusing, chaotic history concerned 2 years ago.

our solution has several components:

• the master branch "pristine". topic branches merged in, , once do, topic branch retired. in other words, merging topic branch in signifies that work ready production, , part of master branch. looking @ our version history, it's clear what's happening: topic branches getting merged master, , that's that.

• we use disposable integration branches when necessary. example, if have topic branches a, b, , c, , none of them ready integration master, need test them together, create qa branch (usually off of master), , merge a, b, , c in. @ point, qa branch deleted or re-used. point it's not intended permanent in way, , doesn't have same restrictions master branch (you can merge in topic branches many times want). if history gets confusing, can delete qa branch , start fresh (an approach have found natural).

• when merging, always use git merge --no-ff. such tremendous reversal our "linear commit history" obsession 2 years ago deserves comment. we've relaxed linear commit history, , seen merges , useful, we've started rely on topic branches being actual branches off of master, not series of commits becomes 1 master. git merge --no-ff ensures there's merge commit, when it's not necessary.

• we have well-understood convention commit messages , branches and, more importantly, it cross-references our issue-tracking system. our issue tracking system uses numeric issue numbers, , feature (or defect), have issue number (1234, example). if you're working on issue, create branch _1234 , start every commit message "_1234: doing blah blah". may seem little obsessive, has worked us, , reduced/eliminated confusion.

• use git wrapper encourage workflow adhesion. we're working on, we've realized entirely necessary prevent simple , understandable mistakes, branching off of wrong thing (we had complete disaster when developer created topic branch off of disposable qa branch: topic branch approved go live, merged in...and bunch of changers weren't approved go live sucked in). our git wrapper require confirmation whenever unusual (like creating branch off of master, creating branch not named _nnnn, making commit doesn't start _nnnn, etc.). occasionally, need these things, wrapper doesn't prevent it, keep people accidentally doing shouldn't.

this sounds it's overly complicated , won't scale well. it's heck of lot simpler merge master feature branch periodically, , when comes time merge master, then can rebase first (to remove intermediate unnecessary merge) , merge master (presumably --no-ff produce merge commit). requires 1 person deal rebase, , don't have coordination because nobody else needs force-update (because, presumably, branch going deleted after it's merged, rather kept around in rewritten state). may decide skip rebase entirely , leave intermediate merges in place, more accurately reflect development workflow , remove risk of producing commits don't build.