
Four rules for effective collaboration – Guidelines for better commits - deiwin
https://github.com/salemove/github-review-helper/blob/master/doc/rules.md
======
C4stor
So you say to me rule 2 for effective collaboration is answering those 5
questions :

Why is this change necessary? What assumptions is it based on? Were any
alternative solutions considered? Why was this solution chosen from among the
alternatives? Are there any non-obvious implications that this change has?

But none of the proposed rules actually answer those 5 questions in their
explanation.

~~~
ozim
Also then you get people writing their life time stories in commit messages
instead of writing code, good luck with velocity.

~~~
deiwin
Thinking that providing additional context for commits is a waste of time is
short-sighted. Yes, it requires more time and effort in the short-term (i.e.
for creating the commit), but if it's a complex, long-lived project, then that
extra effort will save a lot of time in the long run.

Sometimes the extra time and effort is already made up for in the review
process, which without proper context could drag out and cause a lot of back
and forth. Sometimes it might save somebody hours and days of investigation
time. This is not to mention the benefits that both the author and the readers
of the commit get by better understanding both the problem and the solution.

~~~
ozim
People are bad at finding out what is important and what is not. Most of the
time I have to cut through not relevant stuff that others thought would be
important for fixing some issue. Lot more than some insightful commit saved my
day, but maybe that is just my environment.

Anyway good luck fixing anything trusting commit messages from long time ago.
Code is truth and if you won't investigate you still don't know how it works.

------
purple-again
Four rules for how to effectively collaborate with me and people that agree
with me.

One rule for how to effectively collaborate - talk to the people you are
trying to collaborate with about expectations and then follow them. Try to
remember along the way that you are all human.

~~~
Cthulhu_
On the other hand, using this as a baseline and evolve from there will save a
lot of time. I mean git conventions are starting to sound a bit like tabs vs
spaces, just with a lot more options.

Pick a standard example, go with that, evolve. Same with e.g. processes, pick
e.g. scrum, do it by the book at first, evolve.

I've started at half a dozen projects and every time a huge amount of time is
being spent (wasted) on reinventing the wheel, be it processes, version
control, code style, etc.

------
ozim
Maybe get your ticketing system tied to repo and add reference ticket number
form a system where whole context can be provided in a proper way.

"Every commit should be complete." and "Every commit should only do a single
thing." and then make it in a way that someone could actually review changes.
In most cases it is not possible, more often it is complete or does single
thing.

~~~
sirsuki
In my experience these assertions are untrue. Also the tickets are often the
over arching context and will have nothing to do with the code. My product
owner doesn't care if I had to try three different algorithms till I got it
right; but my colleagues and my future self sure would love to see that and
all the stack overflow links during a git bisect!

Not only that but the ticket is a full feature. Maybe it took 5 commits to get
there: "Fix bad indenting", "Extract base logic to command object", "Update
I18N entries", "Add missing tests for current behavior", "Add the feature
asked for".

~~~
ozim
From what I see you just agree with my comment. Those 5 commits you described
as example are the way I would do it.

The way it is described in article would make you do it in one commit and add
information that would be in the ticket.

~~~
deiwin
What makes you say that? The _Focused_ rule from the article is also meant to
persuade you to split the work into similarly concise and _focused_ commits.

~~~
ozim
Focused and complete are opposite. You can have focused commits or complete
commits.

------
hinkley
All of these are prescriptions for establishing a narrative for your commits.

First you must convince people that the obviousness of their commits decays
rapidly. What was obvious ten commits ago will be completely opaque three
hundred commits from now.

Then you must convince them that the descriptions of the commits are often
instrumental in fixing bugs without introducing regressions.

And to do both of these you must convince them that this code will survive for
a long time. Everyone behaves like they won’t be here for the consequences or
like they can “fix it later”. One of those tomorrows never comes.

------
jwilk
It's a bit baffling that git.git suggests using 7-characters commit
abbreviations, when they already have collisions for them:

    
    
      $ git log --oneline | cut -c 1-7 | sort | uniq -c | grep -v ' 1 '
            2 1536dd9
            2 191f241
            2 2e6e3e8
            2 3b130ad
            2 d53a350

~~~
Cthulhu_
7 characters should be enough for most repos, and iirc git can deal with
collisions already (so git co 1536dd9 in your example would bring a prompt).

How many commits is the repo you're running this on btw?

~~~
pleasecalllater
Sure. And randomly generated UUIDs should not conflict... unless they do, and
blow up a huge app in production. Yes, I have experienced that once.

~~~
msingle
the odds of truly randomly generated UUID's conflicting are .... really really
low (see
[https://en.wikipedia.org/wiki/Universally_unique_identifier#...](https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions)).
If you had a collision, then the odds are truly opposed to anyone else ever
having that problem in the foreseeable future, so thanks for taking the hit
for the rest of us!

------
chiefalchemist
This should be retitled: Reasons Why The CL is Flawed.

Long to short, why can't this be a form of some sort? Engineers / developers
have enough to worry about, why add more minutia to the pile?

The CL is not an adequate OSFA solution. If quality and quantity is a concern,
when is that going to be addressed?

~~~
jwilk
What's CL?

~~~
jakobbuis
Commit log

------
galaxyLogic
I used to work with people who didn't comment their commits at all. The
company went belly up

