Tags: version control


Why Communicating with Git Helped You Version

In my previous postings about Git I talked about communication, and now that you've been communicating well we can get into what that means from a strategy standpoint.

Versioning is a large topic area and I do favor the idea of supporting several versions, but encourage limitations on that and discourage indefinite version support. But I want to focus on the idea of supporting the development versions: production, in flight, and new work.

New work is simple, you're preparing for the next release and you want to get everything you can into it.

The trouble comes when you're wanting to now make a change to production or an in flight release. If it is production the change should make it into all three, if it is in flight then it should go to new work also. Generally you will want to make the change to the oldest version first and cherry-pick and port into the later versions, but that is not always the case. Sometimes the bug you identified during new work becomes a desired fix in those older versions. Since you've been diligent about your communication you should now have a issue number and specific changes all ready to go and place into the older versions.

QA will be much happier if you're utilizing the original changes stored in your version history than recreating the changes through copy/paste or other manual means. You will also be happy if the changes are more complex than a few line changes.

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.


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 )