A (Very) Simple Git Workflow
Tags: beginners, git
Published: 2020-08-24 19:17:30

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](#basics)
- [Adding a Collaborator](#collaborator)
- [A Note on Branches](#branches)
- [Common Pitfalls](#pitfalls)
- [A (Very) Simple Workflow](#workflow) <a name="basics"></a>

#### Basics
Before you do anything, you need to create your Git repository. <a href="https://dev.to/afteralec/creating-a-new-git-repository-for-the-absolute-beginner-25bn">I wrote a tutorial on that here</a>, 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!_ <a name="collaborator"></a>

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

<a href="https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository">Here's a quick run-down on how to do it on GitHub</a>, 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 name="branches"></a>

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

<a name="pitfalls">More on this later</a>, 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. <a name="pitfalls"></a>

#### 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 name="workflow"></a>

#### 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.