November 17th, 2018


Git is a Communication Tool

Historically there has been a number of complaints on the way git allows people to change history. There are continued discussions on using rebase, merge, and/or squash. I want to bring focus to the point of all these choices, communicating. I'm not looking at providing new suggestions, someone has already written about why you should do one thing or another.

Who might you want to be communicating with? 

  • Future self
  • Other Developers
  • QA member
  • Project Management

What is it you might want to communicate?

  • That a feature is complete (to the best of your ability at this time)
  • This code change is needed to fix bug X
  • I have this important documentation update
  • I was doing some work and my editor decided to change these files and I don't know why.
  • I don't like the formatting of this document, here is my recommendation
  • I completed X, Y, or Z and think it is important to get these upstream for everyone to benefit.
  • Can we please upgrade our visual studio project files to the latest version of .net?

Now as a developer, wouldn't it be great if this is actually how you developed your work? Nice clear goals, good discipline in only doing one thing, ignoring that bug you found because it isn't the task at hand? Well, no it wouldn't be good you'll forget about that bug, or you will be so busy documenting that it needs fixed you forgot where you were in your task, it's just much better to get those changes into the code base and move on. And this is why Git's history rewrite is so valuable.

Collapse )

Git and Other Communication Tools

My last post on Git tried to focus on an end goal for your history. But I can already hear the nagging reply's "We have other tools which we use to communicate these things."

Most likely you're utilizing some form of bug tracking system, these systems help you to organize what is changing and communicate back what has been completed. These tools are very important as they provide external input, records of future work needed, and facilitate planning efforts. They can also facilitate pretty graphs and development cycles.

In my view, these tools make the reality of clearly communicating changes in your commit history even more important. In all likelihood your git commits can be integrated with your bug tracking system, not only to leave comments on the issue/bug but to cause resolution/closure of them.

If your read my last post, I referenced that during work on one feature some additional bug may be identified and fixed. When you break this fix out into its own commit, you'll start to wonder, "What issue number do I reference in this commit?" The answer to this question will likely result in, "I need a new issue number to assign this commit to." Otherwise if you're doing code reviews, the reviewer will look at your commits and ask, "Where is the record this work was done, I don't see an issue number assigned?"

By communicating we have better checks and balances and expectations on what and where we communicate.