-3

Right now I'm in a small-sized team where we work on changes in our own feature branches and then push to a central repository for review before finally merging into a branch which will later be integrated into master.

I have a colleague who seems to have strange notions about how git works. For example, when reviewing a pull-request of his and insisting that his change required an updated submodule, he was adamant that I was not able to build his code because I was not on his branch, even though my commit was at the HEAD of his branch's commit (I can't remember the workflow, I probably did a 'git fetch' and then a checkout on his latest commit ID).

Many times we have found that he had not rebased his changes or had not updated submodule references. It doesn't matter to me that there was a lack of attention to detail since we all make mistakes, but how can I make him grok how git really works?

I have other colleagues which don't entirely understand how rebasing or other git commands work either, but they for the most part only need to be shown to understand.

closed as unclear what you're asking by Lilienthal, gnat, scaaahu, Masked Man, Draken Feb 13 '17 at 12:31

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Do you have a document that specifies your Git flow? Just pointing at the steps he missed when creating a branch/pushing his changes may be helpful – BgrWorker Feb 13 '17 at 9:33
  • 1
    Have a continuous integration engine process all your branches (including the emails to the committers) This tend to do wonders. – Thorbjørn Ravn Andersen Feb 13 '17 at 11:14
  • 2
    The problem with git is that it accommodates many different workflows. People make assumptions about how others should work with it and the profoundly counterintuitive command line makes understanding what is going on very difficult. Your team needs to make sure everyone gets trained on daily usage and also how to deal with the inevitable train wrecks that occur. Most importantly someone who is patient and empathetic should be available to answer any and all questions, without judgment, as folks get up to speed. – teego1967 Feb 13 '17 at 11:54
  • @teego I completely agree, the problem is that (I think) he doesn't believe he lacks understanding - and so he won't ask questions. My other colleagues are a little better, they understand that to improve they must. Maybe this question should have been more about how to get colleagues to find areas for self-improvement to benefit the team. – atx Feb 13 '17 at 12:00
  • As the XKCD comic pointed out, almost nobody really groks git, we just figure out how to do what we need... – keshlam Feb 13 '17 at 13:10
4

tl;dr: Offer a non obligatory seminar, showing how technology X is to be used.

I would suggest the same procedure for any technology that team members need to know to a certain degree: offer a non obligatory seminar for anyone who may does not feel so confident with technology X. With enough common sense, your colleague will attend this seminar. Also the other colleagues having problems with X will join this seminar.

Wrap it all up in a document / cheat sheet for easy reference when your colleages use technology X at their computers.

The following agenda points seem reasonable:

  • explain how you would like the other team member to use X
  • explain common mistakes (inlcude those that really happened) and what should have been done instead in each situation
  • hands on session
  • Q&A session afterwards
  • offer to answer any questions that come up in the following time.

Make sure this seminar is being held during work hours, each team member can freely choose whether they want to attend this in-house seminar. We greatly benefited from those seminars, each time a new technology came up.

  • Hi, Thanks for your answer. I thought of this also, but as I am newer to this current workplace this seems like it could be taken the wrong way or ignored. I also don't believe that the colleague in question considers that he has any misunderstanding about git, nor do I think he cares even if he knew so. He is a person who is very much thinking about the final product or just 'making it work'. – atx Feb 13 '17 at 10:21
  • explain how you would like the other team member to use X : i don't agree on that : explain how git was designed to be used in your case to X is better. Facts, no opinions. – Walfrat Feb 13 '17 at 10:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.