I had a friend transition from her PhD to industry recently, and she messaged me expressing some annoyance at learning
git on the fly is hard. It certainly was a source of frustration for me as I began my career. I think there are two main barriers:
gitcan do a billion things. It’s hard to know what’s relevant and what’s not.
- There’s new terminology flying all over the place. What does PR stand for again?
Here’s a minimal explanation of everything you’d need to know to make an edit to a code base so you can continue on with the work you’re actually trying to get done. I’m going to make a few assumptions, like the fact that you have access to your companies code project which is hosted in GitHub. I’m also avoiding any technical depth. I’ve linked out to terms if you want to do additional reading.
“ssh keys” are a password. GitHub has great docs explaining this part. You’ll need to make a key for your computer, described here. You’ll also have to let GitHub know what key it should be looking for, described here.
“Repo” is short for repository. It’s a folder containing your code project. In this situation, you’ll start with a “remote repo” which is the code sitting on GitHub. You’ll want to make a copy of that repo on your computer.
“Clone” means make a copy. Let’s say you have code on GitHub at https://github.com/Jessime/youtube_history, and you want to make an edit to it. You can create a local copy of the code by running:
git clone firstname.lastname@example.org:Jessime/youtube_history.git
“Branch” is a version of the code where you can make your edits. To create a new branch, run:
git checkout -b the-name-of-your-branch
At this point, you can finally start making edits to the codebase.
“Commit” means to save the changes you’ve made to your code. You can save all the changes you’ve made with:
git add -A && git commit -am 'Write a message describing your changes.'
(I’m skipping over the concept of
staging here. I don’t think it immediately matters.)
“Push” will share your code changes back to the original repo on GitHub. To share the commits in your new branch:
git push --set-upstream origin the-name-of-your-branch
Pull Request (PR)
Now we’re back in GitHub land, and I’ll defer to their documentation again. A PR gives the other people working on your project the opportunity to review your code, make comments and suggestions, and allows you to make edits based on their suggestions. Once everyone is happy with the state of the code, you can “merge” the PR.
Congrats! You’ve made a change to the code that everyone has access to.
If you’ve made it this far and you’re wondering what to do next, you may want to sync up your local repo with the remote one. The merge of your code into the repo’s main branch only happened on GitHub. You’ll probably want to switch branches back to your main branch and “pull” the changes. Assuming you’ve followed this tutorial exactly, you should be able to accomplish this via:
git checkout - && git pull