A (Very) Simple Git Workflow

This is a quick on-the-court example of what a (very!) simple Git workflow might look like for two people working on a personal project together.

Hey: You might see notes for absolute beginners like this

Jump to:

• Basics
• Adding a Collaborator
• A Note on Branches
• Common Pitfalls
• A (Very) Simple Workflow

Basics

Before you do anything, you need to create your Git repository. I wrote a tutorial on that here, but regardless of how you do this the rest of this tutorial assumes you've done this.

Next, find someone you want to build something with!

In setting up this workflow with your collaborator, you want to first define some rules. Here are some suggestions (don't worry if anything here doesn't make complete sense yet)

1. Only merge each other's pull requests
2. Always test your new code before opening the pull request
3. Always review your collaborator's code before merging the pull request

Bottom line is: establish some groundwork here and agree on how to handle any conflicts or updates to the procedure as you go. Working with humans is different than working with computers!

Adding a Collaborator

Now, add the person you're working with as a Collaborator.

Here's a quick run-down on how to do it on GitHub, but there are obviously other Git hosting services out there.

Just like in my previous tutorials on this, it's really not hard:

• Navigate to the repository in GitHub
• Click Settings, Manage Access, and Invite a Collaborator
• You can send them an invitation by username, full name, or email address
• Finally, have your new collaborator Accept your invitation by following the instructions in the invitation in their email

You're in business! Have your collaborator clone and then pull the remote repository into their local repository.

A Note on Branches

When working with someone else on a repository, it's extremely important to keep your main branch of code clean.

More on this later, but let's talk about branches for just a moment.

Let's say you're working on an application and you want to add tags to your posts. You start work on the code in your local repository, but now you have a problem: the other person on your project is also writing code. What if what you're doing starts to overlap?

This is part of what branches are for. As part of this workflow, you want to make sure that when you make any change to your code base, you don't push up to the master branch. Again, more on that in a moment.

Instead, make sure you're creating a branch each time you add a feature or make a change.

Common Pitfalls

Let's handle some common pitfalls in working with a collaborator on a project.

Scene: You're working on a killer new feature for your app. You need to change some of the basic structure of your app, but nothing major. Maybe you changed a custom property in the application's main stylesheet - no big deal, right?

You push your change up to the master branch of your application. Oops, your collaborator was using that custom property (or whatever structure you changed) in the features they built before. One angry phone call later, you're reversing some of your changes.

Pitfall: not using pull requests to merge new code. In this case, you'd want to let your collaborator review the code, and they would catch the breaking change you made.

Scene: You just fixed a gnarly bug in the comments section of your new app. You open the pull request and your collaborator merges it. You do git checkout master to head back to the master branch and start working on the next bug. No problem.

Uh oh. Problem. You didn't git pull to grab the changes you just made to the remote repository and copy them to the master branch on your local repository. If you branch from here, you'll wind up regressing the changes you just made.

Pitfall: not keeping your local master branch up-to-date. However you organize this is up to you, but you want to be aware of where your local master branch is against the remote master branch.

A (Very) Simple Workflow

Here it is:

1. You start making changes to your code while checked out into your master branch
2. You git checkout -b branch-name to create a branch
3. You finish making changes to your code (1 and 3 order is optional)
4. You git add ., git commit -m 'adds this feature' and git push
5. You open a pull request on GitHub and the other person reviews and merges it

Finally, to start over:

• git checkout master to head back to your master branch and git pull to localize the changes you just made

That's literally it! Keep in mind this is a very basic example, but it could get you thinking on how to organize your workflow when it isn't just you working on a personal project.

If this helped you, if you think I'm completely wrong, or think ducks should be allowed to cross the street without being filmed without their consent, leave a comment below.