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
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)
- Only merge each other's pull requests
- Always test your new code before opening the pull request
- Always review your collaborator's code before merging the pull request
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
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.
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.
Here it is:
- You start making changes to your code while checked out into your master branch
git checkout -b branch-nameto create a branch
- You finish making changes to your code (1 and 3 order is optional)
git add .,
git commit -m 'adds this feature'and
- You open a pull request on GitHub and the other person reviews and merges it
Finally, to start over:
git checkout masterto head back to your master branch and
git pullto 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.