What I’ve Learned After Using Git Daily for 6 Months
I think I 'Git' it
This article is for those who are starting to learn Git, aspire to learn Git, or have used Git but don’t use it actively. I used to be in the ‘used Git but don’t use it actively’ group.
Learning Git can seem daunting. Hopefully this list of the Git commands I’ve learned in the past 6 months will make this seem like an easier task. You can think of these as a sort of bare minimum list of Git commands that you can learn to feel confident that you know enough to contribute on a project.
To look up the uses for the Git commands that I share, here is a git reference guide I have used in the past: https://git-scm.com/docs
Here is also a helpful cheatsheet from Github that I’ve referenced in the past as well: https://education.github.com/git-cheat-sheet-education.pdf
The Git I Knew Before Switching Jobs
I started out my career as a data analyst. In my analyst role, I only used Git occasionally – so probably only a few times a month. The company I was working for just didn’t build their products using Git for version control. Instead we would have version folders where we save newer versions of code and every month/sprint I would create a new folder for the updated code (sound familiar?). I personally believe that all data professionals should use Git if they are writing code at all. And to be fair, this company was trying to implement Git as a best practice before I left, but when a company has grown their analytics department without Git version control, it can seem near impossible to get everyone to change and start using it.
After 3 years, I switched to a data scientist role. Here are the Git commands that I knew while working in my data analyst position (in the order that I learned them):
git config- You will be prompted to set up your username and password when you start using git and you will need to use git config to set them up
git clone <link to remote repository>- To copy the files of a remote repository to your local repository
git add <file name or just use . to add all files>- Stage changes to prepare them for commit
git commit -m <commit message here>- Commit or ‘save’ all of your changes and prepare for them to be pushed to the remote repository
git push- Push or ‘save’ your changes to the remote repository
git pull- Update your local repository with the changes made on the remote branch
git pull origin <branch name (typically master)>- Update your current branch with the changes from a remote branch
Basically, I knew the most basic Git commands – just enough to get started. I’ve never used git init since I typically will just create a new branch off of master or use git clone 😅
I also was using Git within VS Code, which made it so I didn’t have to use some of the terminal commands above all the time. However, the downside of using the VS Code ‘Source Control’ sidebar extension was the lack of flexibility. It was just easier eventually to use the terminal. This was especially true when I was switching between multiple Github repositories.
The Git Commands I’ve Learned in the Past 6 Months
Alright, here are the git commands that I now know (in addition to the list above). If you know these, you should know just enough to meaningfully contribute. I tried to list these in order of commands that I learned as well.
git status- This shows all the files that have changed and are ready to be staged (
git add)
git clone --branch <branch name> <repo link>- Use this to clone a specific branch within a remote repository
git branch- Show the list of branches on your local repository
git branch -d <branch name>- Delete a branch from your local repository
git checkout <branch name>- Checkout (switch to) a branch from the remote repository
git checkout -b <new branch name>- Create a new branch that is a clone of whatever branch you are currently on
git push --set-upstream origin <branch name>- Whenever I create a branch locally that is not on remote, I use this command to create the branch on the remote. Typically will use this after using
git checkout -b.
git reset- Removes all staged changes
git reset --hard- Reset your file to the last commit (be very careful when using this option since you are removing Git history)
git restore <file name>- Restore your file to the latest commit
git diff- Check the differences between your changes and the last commit
git log- Look at a history of your commits on that branch
git stash- Put all changes in a working directory to avoid having to stage and commit your changes before switching branches
git stash list- Show a list of all stashed changes
git stash pop- Apply your last stash to your current branch and remove it from the stash list
You might be surprised that git merge or git rebase aren’t on the list. I technically have used them once or twice, but I didn’t include them since I am not confident using them yet. I will typically merge using Github and so learning these hasn’t been as pertinent yet.
Git Best Practices That I’ve Learned
These best practices are what I have learned based on experience. I’ll give a quick list of things I think are important to keep in mind:
- Before you stage (
git add) your changes, save all files sincegit addwill only stage changes you’ve saved. I typically like to close out all of my tabs in VS Code before staging to make sure I’m not missing any files that need to be saved. - You don’t have to push after each commit. I typically will add a bunch of commits and then push them all at once before switching branches or logging off for the day.
- Save and commit all changes before switching branches
- When I write a commit, add a # followed by the Git issue number so your commit shows up in the relevant Git issue
- Always do a
git pullbefore creating a new branch off of master to make sure your new branch is based off of the most up to date code - If I use
git stash, I try to pop and clear the list as soon as possible - Delete old branches from my local repository as soon as they are merged to keep my local repository branch list clean
- Do not let your git branches get older than a sprint since they will become more difficult to merge the longer you leave them. If they need to go another sprint, use
git pull origin masterto merge the master branch into your branch and update it with the latest changes. - You can typically reference multiple files separated by a space in git. For example, when you use
git branch -d <branch name>you can delete multiple branches at once as long as you separate them by spaces.
What’s Next?
I think I want to learn git rebase and how to squash commits. Also I’ve heard that git revert is safer than git reset, so I’ll have to look into that as well. We’ll see if I can learn those and what else I learn in the next 6 months!
Thanks for reading! Please connect with me on LinkedIn and check out my other articles if you enjoyed reading this one.
If you’re new to Medium, consider subscribing using my referral link below 👇
References
- S. Chacon and B. Straub, Git Documentation, git-scm.com
- Git Cheat Sheet, github.com
Share This Article
Towards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program.
Write for TDS
