Git Command Cheat Sheet

Here's a handy Git Command Cheat Sheet

disclaimer: There's A LOT more commands to know but this is what we've utilized this week in data engineering!


Git init

    • Initializes a local folder to be used with git (creates .git file)

Ex. We created a folder for our python project on our local machine and added a .env file and a .gitignore file but realized we needed to link that to a github repository. You can create a new repository on github or you can use an existing repository, but in either case, the local folder you're working in must be initialized to use git.

Git remote add origin <repository url>

    • Set origin of local folder as the remote repository (linking them together)

Ex. We had a local folder and a remote repository but they weren't connected to each other so we needed to use the URL from the remote repository on github and use it in the "git remote add origin" command to tell the [git initialized] local folder that it's origin is now the remote repository

Git checkout -b <new branch name>

Git checkout <existing branch name>

    • Create a new branch or switch to an existing branch in the repository.

Ex. Since we had only recently created a remote repository, the only existing branch is the "main" branch. We could either continue to work on the main branch or we could use git checkout to create a new branch named for a specific feature

Git add .

    • Stage all changes before committing changes (replace "." with a file name to stage one file at a time if necessary)

Ex. We added a README.md file to our folder and tried to git commit but got an error message like "nothing added to commit but untracked files present (use "git add" to track)". Indicating that changes have been made but those changes need to be staged before committing.

Git restore --staged <file name>

    • Unstage staged changes (undo git add)

Git commit -m "commit message"

    • Commit changes after staging and always add a helpful message

Ex. After staging changes, committing changes will take a snapshot of the staged files and update the local repository with those changes. Each commit has a unique identifier so you are able to go back to previous versions (ie. Version control!). The commit message should be helpful to understand what changes were made and why, helping other developers (or your future self). This is a step to take once you've made meaningful changes/fixes. It's okay to commit multiple changes before pushing (keep reading for git push).

Git status

    • check the Status of your branch

Returns messages like "changes to be committed" and lists them OR "nothing to commit"

Git reset --hard <commit_id>

    • Undo changes/commits made after the specified commit ID, ie revert the changes you made in the latest commit(s)
      • --hard : it will make your local code and local history be just like it was at that commit
      • --soft : it will move your HEAD to where they were, but leave your local files etc. the same

Although I'm not totally clear on the difference between --hard and --soft, there is plenty of online resources that dive deeper into it.

Git push

    • Push your committed changes up to remote repo. This is the first time your local changes are being sent up to the remote repository.

After this, you should be able to see your new files/changes online in github in the repository in the branch you were working on. (you can use github to see all branches that have been created on that remote repo). This is a step to take after you're happy with the changes you've made.

Git push -u origin <branch_name>

    • Link the branch to the remote repo.
      • 'git push' by itself sometimes causes "no upstream branch" error so you can define the origin of the branch with this command

You can also configure this in git to do automatically but I'm not sure how to do that yet :)

Git pull

(git pull = git fetch followed by git merge)

    • Git fetch gathers any commits from remote branch BUT does NOT change any of your local branches (ie. Does not merge them)
    • Git merge reconciles diverging branches (integrates commits into your current branch).
    • Git pull automatically merges the commits without letting you review them first
      • To be safe, run git fetch and git merge separately to get the same outcome as git pull

Author:
Annie Casey
Powered by The Information Lab
1st Floor, 25 Watling Street, London, EC4M 9BR
Subscribe
to our Newsletter
Get the lastest news about The Data School and application tips
Subscribe now
© 2025 The Information Lab