On 16 February 2016 3:35:55 PM NZDT, Steve Litt <slitt@???> wrote:
>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?
>
Yes. But that is no excuse for not using private branches to develop on. If you have to revert a commit your probably doing it wrong. Please keep master branches for merging tested and release ready branches only.

For Devuan packaging projects, devuan/<release> branches should be marked protected and changes proposed via merge requests. And the owners/masters should be the only ones to merge changes and set release tags.

Daniel