On Mon, Feb 15, 2016 at 01:05:25PM +0000, Rainer Weikusat wrote: > Edward Bartolo <[email protected]> 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 ] _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
