A Better Git Workflow: A Better World AKA My Induction Into The Git Police

Originally written and posted by Web Fellow Edward Leon Jasper right here.

I can’t possibly think of anything more joyous than a great Git workflow. What I thought was once so easy has proven to be not easy at all. Working with Git in a group has been a scary monster: hours of work lost in a single key stroke, app breaking bugs appearing out of thin air, forms that render twice! It’s enough to make you want to scream! I wanted to finally explore a better way to work with Git in a group setting.

So we all know that when making a new feature we should be working on a separate branch. It’s important to understand that the master should remain deployable at all times! No one works off the master once the app is fully functional. This is one of the reasons I love pull requests with Github. It allows for features to be discussed before they are integrated with the master. This also allows you to ask for help on a feature without touching the polished copy.

Tip: Feature branches should have descriptive names of their purpose such as movie-form-view.

Tip: Commit often. When doing labs, we would often wait until the end to commit and push. This is a horrible practice where we need to be committing changes very often, such as when we’ve made a measurable change. The Picklebacks(soon to be link to their project) had it right when they played Salt-n-Pepa’s “Push it” everytime they where ready to commit a change.

Once we have a feature that is ready to be merged, the two parties should discuss the changes made. Once that is ready we can run:

It’s pretty simple but important to have a firm grasp on.

Merge conflicts are easy, even a few lone line breaks can make an issue.

Tip: Work on your files only! If a grammatical error needs to be made on your home page and that is not part of your feature. LEAVE IT ALONE. Let the developer in charge of maintaining the master make those changes THEN pull those changes to your branch and continue to work. Feature branches are as simple as changing what you want when you want it. Each branch and pull request should be for its own individual issue and nothing more.

Following these simple steps will help your work flow drastically but if you need some help…just call Git-1-1 and the Git Police will be right there!

Disclaimer: The information in this blog is current as of July 16, 2014. Current policies, offerings, procedures, and programs may differ.