Git is something that can be pretty confusing at times, especially to new programmers. It can be super easy to get overwhelmed by the different workflow models you should use to contribute code to a repository. Mistakes will definitely happen, but when using Git correctly it will act as a safety net from these mistakes. In this article I'll try to break down the basics on using Git with a team, and what to do in certain situations.

Basic workflow

Forking and pulling code is something that you will most likely do many times when working on repositories with other people. A fork is essentially your own personal copy of the repo for you alone to work on. To fork a repo you simply click on the "fork" button on the the right hand side of the main repo page.

git clone https://github.com/<username>/<repo>.git <REPO NAME>

git remote add https://github.com/<username>/<repo>.git

After the repo is forked you will then clone your fork. You can clone the repo into any directory you'd like using the code from the first snippet above in your terminal. The last parameter in the first snippet is optional for when you want to save the clone with a new name. The second snippet will set the main repo as your fork's upstream, which you will need to pull changes and keep your master current. Once you have your cloned repo you should create a new branch to start coding. Working in a new branch is beneficial for multiple reasons, with the main reason being that is keeps your master branch safe.

Once you have successfully cloned your repo you can safely work on it without affecting the main master branch. It's good practice to commit your changes every time you add a new feature using the command git commit. Committing your code essentially saves a 'snapshot' of your changes, and you can use these saves to also look back and revert to older stages of your code. Once you have completed you addition you can then upload that code to your remote fork's master branch using the git push command.

Finally, once all your changes are good to go and everything is pushed to your master, you can submit a pull request to the main repo. On the GitHub page of your remote fork, click the “pull request” button. One you submit your PR you'll wait for the repo owner to merge or comment your changes. If the owner suggests some changes before merging, you can simply push these changes into your fork by repeating the last steps. Pushing your updated changes will automatically update your pull request.

The steps listed above walk you through the basic workflow for using git, but sometimes things can get a little more complicated. When working on a team you will often have other programmers simultaneously working on the same repo you are. To make sure that you have the most up to date version of the main repo's master code, there are a few more commands you should familiarize yourself with.

Keeping your fork current

Each time the main repo is updated you should also update your forked repo's master branch. Since we already set the main repo's master to our forked master's upstream, we can fetch changes and stay current using git fetch upstream. We then want to merge the changes from the upstream repo into our fork using git merge upstream/master. Doing this will ensure that we are always working on the most up to date code, and will lessen the chance of having merger conflicts when we make a pull request.

Working on multiple features

If you find yourself working on multiple features at once, you'll want to push them separately from each other. Its best practice to create a separate pull request for each feature. A pull request should always be bound to its own branch in a git repo, so you will need to create a separate branch for each feature.

To start, you should always switch to your fork's master when creating a new branch. This will ensure that your master will serve as the feature branch's source branch. To switch to your master you will use the command git checkout master or git co master for short. You'll then want to create a new branch for the feature that you are about to work on using git checkout -b <feature_branch>. This will not only create a new branch for you, but it will also switch directories into your new branch. To upload the changes in that branch to the remote fork you will use git push --set-upstream origin <feature_branch>. You can also switch between feature branches using the same git checkout command we used to switch to our master branch above.

Hopefully this git tutorial will help you get the basic workflow of git down. There are plenty of other git commands out there to help you as well. When running into trouble it is best not to panic, since there are git commands to fix ALMOST any git error you can make.