home | list info | list archive | date index | thread index

[OCLUG-Tech] another philosophical question about git -- avoiding merge problems

  • Subject: [OCLUG-Tech] another philosophical question about git -- avoiding merge problems
  • From: "Robert P. J. Day" <rpjday [ at ] crashcourse [ dot ] ca>
  • Date: Wed, 6 May 2015 06:45:31 -0400 (EDT)
  yet another process-oriented question about git ... not long ago, i
was teaching a 1-day intro git course and, early on, one of the
students mentioned that one problem they were having with their
current VCS was too many people trying to check in changes and
stepping on each others' toes and causing conflicts, and how did git
solve that?

  i briefly mentioned git's merging ability and so on and so on but,
in the end, i said that no tool was going to solve that; what she was
talking about was a workflow issue that could only be solved by their
developers *communicating* with each other; that is, *talking* about
what parts of the code base they were working on so they didn't keep
bumping into one another. and i emphasized that no level of
sophistication of a VCS could replace developers talking to each
other.

  i didn't think that was such a controversial position, but she did
*not* take kindly to that. we were only about a half hour into the
course, and she was already preparing to dislike git because of what
she understood as its first major failing. i stuck to my guns, though,
and by the end of the day, once she had a better understanding of git,
she seemed a lot happier so, crisis averted.

  but, was i wrong? the position i took was that, regardless of the
sophistication of your VCS, if you are *constantly* fighting with
merge conflicts, then the problem is not with the VCS but with your
team's workflow. and since git was a distributed VCS, that actually
had the potential for making things worse since there was (typically)
no concept of an exclusive check out that prevented others from
working in the same area.

  i did suggest that there were alternatives. one i proposed was that
all changes to the code had to relate to an existing ticket in a
ticket system, and that developers should be required to (exclusively)
check out the ticket to work on it.

  but, in the end, what are others' thoughts on this?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================