10 Git Commands Every Developer Needs to Master

GitLab is a great version control platform and, as we saw in part one of our series on the GitLab Certified Git Associate, has a much broader feature base than simply maintaining and collaborating on code.

We all have to start somewhere, though, and that somewhere is the basics of using Git on the command line. Every dev worth their salt knows their way around Git, so it’s a valuable use of your time to become very comfortable with it. So, for part two of this series, we’re going to learn the 10 commands you must know to master Git. There’s a lot to cover, so let’s Git going (sorry, I couldn’t help it).

1. git init

Every repo starts with `git init`. This command takes your current working directory and initializes it as a new repository. It doesn’t touch any existing files in the directory but does create a hidden .git directory that contains all the metadata related to the new repo necessary for tracking changes.

This directory becomes your working directory. After creating some files in your new repo, the next step is to add files to staging, which leads us to the next command. 

2. git add

Once you create files or make other changes to a local repo, you must stage those changes. `git add` is used to put changed files into your local staging area, which marks what files will be committed to the repo. You can use it with individual files like `git add index.html` or with entire directories like `git add my_dir/`.

Think of this workflow in three stages: the local repo before making changes (the working directory), the changed files you stage with `git add`, and finally, the changes you commit to the repo. 

3. git commit

Once you have files staged, the final step in your workflow is to commit those files to the repo using `git commit`.

Committing is a snapshot of your work, a point in time when changes were made to the repo. This makes it easy to track what changes over time and revert changes if necessary.

Another key part of maintaining history is commit messages. When you commit you should provide a meaningful comment about what the changes were for. This can be as simple as “update dependencies” or “fixed typos in docs”. In context, it will look like this: `git commit -m “fixed UI bug”`.

4. git push

Great, you have committed a change to your repository! The commit only happens locally, though. To send it to the remote repo, you must push the commit.

`git push` sends your commits to GitLab, adding your changes and commit message for all to see. Typically, the remote repo will be set up to require a pull request, which is beyond our scope today but is basically a way to run testing and require approvals from other humans before the push is added.

This command will push your commits from your local branch (“main” in this case) to the remote repo (“origin”): `git push origin main`.

5. git clone

Everything we’ve discussed so far has been in the context of creating a new repo, but what if you want to work on an existing repo in GitLab? `git clone` is the answer!

Every repo has a URL; running `git clone <repo URL>` will copy the remote repo to your laptop. If the repo is private, then you must have authentication set up. You can clone any public repo without auth though, like any open source project.

Once you have the repo cloned, your workflow is the same for adding, committing, and merging!

6. git pull

This is a simple command, but it is a good reminder of the collaborative nature of version control. If you work with a team on the same repos, others will make their own pull requests. Your local copy of a repo might go out of date as others make changes. `git pull` simply updates your local copy of the repo with any updates from the remote copy.

7. git branch

We’re introduced with this command to a new Git concept: branches. You can use branches to work on different parts of the codebase in isolation. For example, you might create one branch to work on a new feature, pushing commits to that branch as you work. While that code is in review, you could create a new branch to work on a different feature. The commits to the two branches are kept separate on your laptop. This helps manage larger changes, like those related to a new feature or larger release.

`git branch` will show you all the branches in the current repo and which you are currently working on. You can create a new branch with `git branch my-new-branch`.

8. git checkout

Creating branches is only helpful if you can use them. This command is mostly used to switch from your current branch into another, like so: `git checkout my-new-branch'.  

9. git merge

If you are done with the work on your new branch and ready to combine your branch with another, usually the main or master branch that everyone else works off of. To do this, you would use `git checkout` to switch to the main branch, then `git merge my-new-branch` to merge it.

10. git status

Our final essential command is an easy but essential one. `git status` will show any changed files that have yet to be staged and the staged files waiting to be merged to the remote repo. This is a great way to keep track of your changes.

These ten essential Git commands will help your efficiency in the terminal and form the core of what you need to know about Git for the GitLab Certified Git Associate exam. Git is a powerful tool, but that power does require a bit of practice to wield effectively.