Git repositories created and how to work with them

[Andreas Pakulat]

On 04.05.10 11:34:32, Milian Wolff wrote:
> Andreas Pakulat, 04.05.2010:
> > I've pushed all 5 repositories to gitorious.org/kdevelop (and the
> > project page also works now): kdevplatform, kdevelop, quanta, php,
> > php-docs. They're open for comitting, hence I'd like to talk a bit about
> > our workflow with that. (this is not set in stone of course)
> > 
> > I've created a 4.0 branch already from master, thats our stable branch
> > and should get all bugfix commits on it. We'll than have to make sure
> > that its merged once a week (or more often for important fixes) into
> > master so that master also gets the bugfixes. I don't want to be
> > responsible alone for that, so if anybody notices no merge on sunday
> > evening if there's been commits to 4.0 branch in the week, please just
> > do the merge.
> > 
> > The master branch is open for any kind of commits, but only
> > single-commit-change should be pushed to it directly. Everything else
> > should be done in a local branch and the branch then merged into master.
> > I'm thinking it makes sense to use --no-ff when doing the merge so that
> > even if a fast-forward is possible we'll get a merge-commit.
> > 
> > For the commits themselves its important to make them self-contained,
> > that is after each commit, even in a series of related commits, the code
> > should be buildable. The simple reason for that is git bisect, it makes
> > finding regressions really easy, but it depends on a buildable codebase
> > after each commit.
> 
> Please bear with me on this one: I'm a total noob when it comes to the more 
> advanced features of git.
> 
> But: Why can't we simply continue as before, just profiting from git where 
> possible?
> 
> I mean: work solely on master like we did in SVN. Backport fixes where 
> possible and necessary, like we do in KDE SVN. Just as soon as we work on 
> something bigger that might break something (e.g. SmartRange -> MovingRange, 
> Project*Item rework) or some new plugin / feature, work in a branch and merge 
> as soon as possible.

Because then the stable-branch will simply die after the first release.
Thats something I'm still seeing a lot on kdelibs and other main modules,
people often need a poke to backport stuff and the mentioned workflow makes
that unecessary as every bugfix will always be on the stable branch and at
some point it'll always be on the master branch.

Also the "work in master" should be really limited, with gits branch
support you should almost always create a branch instead of working in
master.

And once you fix something in stable branch you can simply merge the stable
branch into whatever branch you currently 'work on' to get the commit into
it. You don't have to wait for master to get the fix.

I suggest that everybody tries to read a bit about how git and its branches
can be used, for example here:
http://kerneltrap.org/Linux/Git_Management
http://www.nvie.com/git-model
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
Or simply look at other projects (like amarok, konversation or even Qt).

Andreas

-- 
You will be attacked by a beast who has the body of a wolf, the tail of
a lion, and the face of Donald Duck.