Everyday Git Commands
Once you’ve set up your repo, it’s time to get to work. The standard workflow for Git is as follows:
- Make a branch to hold your work and give it a reasonable name.
- Make your changes.
- Stage files you want to add to the repository.
- Commit the changes with a useful commit message.
- Merge the branch.
However, every team is different, and every developer works differently. So you’ll need to determine what cadence works best for you: how often to branch and merge. But the flow will generally follow the steps above.
Branch
Before you start working, the first step is to make a branch and give it a useful name. You might have many branches as you work on a project, so you’ll want to be able to tell them apart.
If you’re a solo developer, you’ll be tempted to make commits on the main branch as you work. Be careful, that’s a trap!
Making branches is how you give yourself the freedom to experiment and to manage when a set of changes goes into your project. If you only make commits directly on the main branch, you’ll hinder your ability to easily roll back changes. It’s best to get into the habit of making a branch at the start of your work.
A branch takes a snapshot of the entire repository and gives you a clean working directory so you can start to make changes. Remember from the previous lesson that the working directory is the main directory of your repository where your files are. Any changes to the working directory files only affect the repository once you commit them. Once you make a branch, all the commits only apply to that branch; no other branches will get the changes. This is one of Git’s considerable strengths. Making branches quickly lets you try out ideas, even ones that require radical changes, knowing you can throw away the idea or save it for later without hurting any of your other files in the repository.
Branching is a two-step process. First, you create the branch. Then, you switch to the branch. You could create a few branches and then switch to the one you want to start working on, knowing that all the branches are identical to start.
git branch <new_branch_name>
Here’s something important to note: If you try to branch on a newly initialized Git repository with no commits, you get an error. Usually, you will commit a README or some initial files directly to main rather than a branch. By convention, this commit’s message is usually initial commit or something similar. This is the only exception to the directive: “Don’t start working without a branch”.
To see a list of all the branches in a repository, use the branch command without a name at the end.
git branch
If branches other than the main branch exist, this shows you a list of them all and puts an asterisk beside the current branch.
After you’ve created a branch or two, you can switch to one of them using the switch command:
git switch <new_branch_name>
If you know you’re just going to create one branch and switch to it, you can combine the two actions, using -c to create and then immediately switch to it.
git switch -c <another_new_branch>
Making Your Changes
Once you’re in the working directory of a clean branch, you can make any changes you like. You can add, delete, rename, or edit files, anything you want. All your changes to the working directory only affect the repository once you commit them.
Staging Changes
Don’t put all of your changes in a single commit. Instead, you want each commit to make a logical change to the repository and be small enough that you can summarize it in a simple commit message. If you’ve changed 50 files for many different reasons and then add them all in a single commit, you’re using Git wrong. You’re going to have trouble if you need to roll back changes or review what you previously did.
Git provides a staging area where you mark files — and in more advanced setups, individual chunks of files — to go into a commit. This way, you can add and remove files from the staging area until you’re happy that you’ve grouped the files logically and that the commit will be a coherent unit.
After you’ve started changing files, you can see what’s available for staging by checking the working directory’s status.
git status
The status shows you three things:
- New files that aren’t in the repository.
- Files that have been changed but aren’t staged.
- Files that are staged and will be in the next commit.
Helpfully, the status tells you what commands to use to move files into and out of the staging area. You can add a single file with:
git add <name_of_file>
If you want to add a few files, put more names in the command, separated by a space.
git add <name_of_file> <name_of_another_file>
The add command also accepts wildcard patterns. To add all of the jpg files, for instance, type:
git add *.jpg
Finally, you can add everything:
git add .
If you decide to remove something from staging, you can restore the staged file:
git restore --staged <name_of_file>
Git restore can use the same filename patterns as git add for removing groups of files. If you look online, you’ll likely find instructions to use git reset to remove files from staging. This method works, but wiping out all your changes with a few finger slips is easy. So the makers of Git created the restore command. The git reset command still has uses, but using restore when you want to remove a file from the staging area is safer.
If you have a complex working directory with many changed files, using a graphical Git client to manage staging is often easier.
Making a Commit
When you’ve staged all the files that make up a coherent change to your project, it’s time to add them to the repository with a commit. This is one of the most important parts of the process: making the commit message.
Unhelpful messages are ones like “changed stuff”, “changes”, and “added files”. More helpful messages might be “added submit button”, “changed recipe measurements to metric”, or “fixed defect #1943”. Remember, the message’s purpose is to allow someone, maybe even future you, to read through the Git log in a few months and find which commits are responsible for which changes to the project.
If your team uses an issue tracker like Jira, Azure DevOps, or GitHub, there are usually some key shortcuts that will link your commit to tickets or even close tickets. Usually, the pattern is something like “fixed”, “fixes”, or “close”, and the ticket number. Alternatively, your team may prefer a particular Git message format, to make it easier for your system and teammates to understand what you did.
A basic commit command takes this form:
git commit -m 'Your commit message goes here'
A good rule of thumb is to make the message 50 or fewer characters. Remember, it’s going to appear in the Git logs. If you want to go into more detail, you can add a second message:
git commit -m 'Your commit title' -m 'A more detailed description'
Although the description is more detailed, 72 characters is about as long as you want it.
If you don’t like adding the descriptions on the command line, Git will open an editor for you so you can take a little more care in crafting your messages.
git commit
Using the command without any arguments opens the default text editor and reminds you what files will be in the commit. As soon as you save and exit out of the editor, Git makes the commit. If you don’t type any message and exit the editor, Git aborts the commit.
Now, imagine you carefully get all of your files into staging and make a commit. Then, as soon as you do, you realize you forgot a file or see a small change you need to make. You can add these to the previous commit instead of making a new one. You wouldn’t want a new commit anyway because the changes wouldn’t be logically grouped with the others. To do this, you stage the changes and then git commit --amend. Whew! :]
Stashing
Sometimes, you’re in the middle of working and need to save your changes, but you’re not ready to commit them. In this case, you can clean the working directory using git stash. Stash lets you store your work in progress. Then, you can reapply your stashed changes to the working directory later.
Because it’s similar to a commit, the stash command has a similar form:
git stash -m 'some message about the changes'
If you don’t include a message, Git makes one for you. A common use of stash is when you’ve made some changes but realize you’re on the wrong branch. You can stash your changes, switch to the right branch, and then apply your changes. Stash uses an index method, not hash numbers, to identify each stash, and index 0 is the most recent stash. In this example, after you’ve stashed and switched to the correct branch, you can apply the changes:
git stash apply 0
Using apply preserves your stash so you can apply it elsewhere. If you don’t want to save the stash, you can drop it from the list:
git stash drop 0
As with other commands, combining the two steps is possible. The pop command applies the most recent stash and then drops it.
git stash pop
You can see all the stashes you’ve made using git stash list. If you can’t tell which stash you’re interested in from the titles, you can use git stash show <index> to see the high-level changes in a particular stash. If you want to see the actual changes, add the -p option.
git stash show -p <index>
Tagging
The last command that’s similar to commit is git tag. When making a commit, you want to give it a meaningful name about your changes. Later, if you want to mark a particular commit as important, you tag it. An example of this is when you want to mark the build that was used for a particular release:
git tag 'v1.2-release' <some_abbreviated_hash>
Two things to note:
- The name of a tag follows the same form as the name of a branch. This generally means no spaces.
- You don’t need to type the entire commit hash. Just the first five or eight characters are fine. In fact, Git complains if you use the entire 40-character hash.
If you omit the hash, Git applies the tag to the most recent commit on the current branch. If you omit both the tag and the hash, Git lists all the tags.
The other great use of tagging is when you want someone to look at some changes. The tags show up in the git log, and it’s a lot easier to tell someone to look at the “new button” tag than to give them the 40-character hash. When you use tags this way, you probably don’t want them to live in the logs forever. When you finish with a tag, you can remove it:
git tag -d <tag_name>
The last step in the regular workflow is to merge changes from a branch back into the main branch. Merging and moving changes from one branch to another is a large topic. Before diving in, the next section uses our demo repository to review these commands and see how GitHub Desktop manages them.