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).

My2Cents

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]