On Tue, 16 Feb 2016 10:06:35 +0000
KatolaZ <katolaz@???> wrote:

> On Mon, Feb 15, 2016 at 09:35:55PM -0500, Steve Litt wrote:
>
> [cut]
>
> > >
> > > 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?
> >
>
> Yes Steve. My point was that git is made to maintain the history of a
> project, and to help you avoiding disasters, or containing their
> impact. git is useful only if you commit fairly often, otherwise it is
> better to use a backup system, rather than a revision control
> system...
>
> So, there is no point into committing "only working stuff", because
> this is the best way to mess things up and/or to lose hours of
> precious work.

I didn't understand the context of the question before, but now that I
do, it makes perfect sense. Also, besides tagging releases, can't you
also tag working versions, like "works22143", so anyone can git clone
something that works? Or...

> As it has been suggested by several others, whenever
> you need to have the master branch to always be "working", it's far
> better to do development in other branches, committing there as
> frequently as needed (i.e., even if things don't work), and then
> merging to the master when the development branch "works".

Where would you suggest I find out more about the practicalities of
git? I use it for my own stuff quite a bit, but don't know how to do
branches and all that.

Thanks,

SteveT

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