On Mon, 15 Feb 2016 14:00:46 +0000 KatolaZ <kato...@freaknet.org> wrote:
> On Mon, Feb 15, 2016 at 01:05:25PM +0000, Rainer Weikusat wrote: > > Edward Bartolo <edb...@gmail.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
