On Mon, 15 Feb 2016 14:00:46 +0000
KatolaZ <katolaz@???> wrote:

> On Mon, Feb 15, 2016 at 01:05:25PM +0000, Rainer Weikusat wrote:
> > Edward Bartolo <edbarx@???> writes:
> > > I need to avoid having to "git commit -m ..." every time I
> > > add/modify code. I need to 'git buildpackage' without committing
> > > changes. The reason is to make sure new code works before
> > > committing.
> >
> > In my opinion, that's an unfortunate way to use a SCM because it's
> > than not used as a change management system but more like a release
> > tracking system. I usually commit every somewhat self-contained
> > unit of work, eg, every new function or signficant change to an
> > existing function without even knowing if the code compiles, let
> > alone works (this requires private branches if more than one person
> > works on a codebase). This means I get a detailed and commented
> > history of all changes I made which makes it easy to determine why
> > something was changed/ written in a particular way and also means
> > that I can always throw the current working files away (instead of
> > trying to reconstruct them after an ill-advised change, be it some
> > idea which just didn't work out or accidentally damaging a file)
> > without losing a lot of work.
>
> +1
>
> Try to use git for what it was conceived: revision management. And a
> revision is not a release. The strategy suggested by Rainer,
> i.e. maintaining personal branches where every consistent set of
> changes is fixed into a commit, is usually the easiest way out.
>
> Commit often. Branch whenever needed needed. Merge when it
> works. Release when "perfect" (the last one should be really
> considered with a pinch of salt :P).

When a version is a release, don't you just give it a tag?

SteveT

Steve Litt
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key