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

You’re closer than you think to a career in tech. Our grads have launched rewarding new careers — you can too.

View Our Jobs Report

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.

Blog post image: tumblr_inline_n8td2aVVkn1rtan47.png

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.

Blog post image: tumblr_inline_n8td43WkPm1rtan47.gif

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:

Blog post image: tumblr_inline_n8td5rf6ve1rtan47.png

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!

Blog post image: tumblr_inline_n8td7sClck1rtan47.gif
Headshot of Flatiron School

Flatiron School

Blog Post Author

Read More Flatiron School Articles

Since we opened our doors in 2012, thousands of students have joined Flatiron School to launch new careers in tech.

Explore our Courses

Find the perfect course for you across our in-person and online programs designed to power your career change.

Explore Our Courses
Join a Community

Connect with students and staff at meetups, lectures, and demos – on campus and online.

Join the Community
Schedule a Chat

Have a question about our programs? Our admissions team is here to help.

Schedule a Chat