I have been using git for about nine years, and these are easily 80% of the commands I ever use. I will describe each one and when and how it is useful, followed by some other addendums I deem important. This post also represents what I consider to be a basic git workflow. It is not really a workflow. It is just how git works at a basic level.
I do use other features of git in particular circumstances, but they are either not part of my normal workflow, or else I use them via a GUI like Sourcetree or VS Code.
Placeholder text is denoted by angle brackets (<>).
git clone <url>Of course, you’ll run this to clone a repo from GitHub, BitBucket or another code repository hosting website (“origin server”).
git initRun this command from your project root if you do not have the git code repository on a hosting site yet and need to initialize a git repository locally.
git fetch --allThis command is a little tricky to understand at first. It fetches all changes from the remote repo(s) so that you can see what has been changed remotely (as with the git log command I discuss bellow), but it doesn’t actually merge them into your corresponding local branches.
git pullThis command actually merges what is on your origin branch with what is on your local branch, for the branch you are currently checked out on.
git checkout <branch-name>This command switches you to an already-existing branch or else a branch that already exists on origin. If it doesn’t exist locally it will set up a local branch to track the origin branch of the same name.
git checkout -b <branch-name>Use this command to create a branch that doesn’t already exist. It will be based on whatever branch you are currently checked out on.
git add .This will add all the changed or newly created files to your git “staging area,” that is, all the files whose changes will be committed to version history when you next run git commit. This does not add files that are in the .gitignore of course.
git statusUse this command to see what changes have been made to the project that have not yet been committed. This is particularly good to run before running checkout to make sure you were not in the middle of any changes when you last left off the project.
git commit -m "Your commit message"Run this command to commit all the changes that you have staged in the previous steps.
git pushRun this command to push the changes you have committed to your origin server.
git push -u origin <branch-name>Run this command to push a new branch to your origin server (the remote repository) that does not yet exist there. (If you try to run git push by itself, git will actually remind you of this and show you the above command, so you don’t really have to memorize it.)
git merge <branch-name>Run this command from the branch that you want to merge changes into. For example, git merge dev while on the main branch will merge changes from dev into main.
git log --oneline --decorate --graph --allUse this command to visualize the latest commits in the terminal. Sometimes it is still not great because the terminal is the terminal. To go further here I would recommend downloading the free Sourcetree app that BitBucket offers. When I want to delete branches, I also use Sourcetree for that. I don’t even know what the command for that is, but its not difficult to look up.
Git conflicts are a common part of working with git, especially if you are on a team. Below is the way that I tend to deal with them.
Sometimes you will run git merge <branch-name> and there will be a git conflict in one or more merged files. Sometimes this also happens when running git pull, which is actually a shortcut for fetching changes to the origin branch and running something like git merge origin/<branch-name>.
If there is a conflict, it will show you something like this in the terminal, an example of a test project I set up in which I made a change to the file index.html on two different branches and then tried to merge one into the other:
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
In this case, it’s only one file — index.html — but in real-world situations, it might be multiple files, but hopefully not too many; otherwise, it can get tricky to resolve the conflicts. If you have way more conflicts than you expected, or think you may have merged in error, you can run the following to abort the merge.
git merge --abort
Otherwise, you will need to go look at each file with a conflict(s). A conflict is denoted by special markup that gets added to the file that looks something like this:
<<<<<<< HEAD
<h1>Matt Watson some change 3</h1>
=======
<h1>Matt Watson some change 2</h1>
>>>>>>> test-change
First is the line in question as it appears in the HEAD branch (which in this case is master). On this branch, I had changed this heading to end in 3. Then after the equal sign, you have the version of the line that is "incoming" — from the branch you specified with git merge <branch-name>. In this case it is a branch I named test-change. On this branch, you can see that I updated the same heading to end in 2. This is a conflict, and we have to decide whether or not the heading should end in 3, 2, or something else altogether. We can do literally anything we want to here as long as we get rid of all that git conflict markup, so that git knows that this is not a conflict anymore and will let us move along with the commit.
Let’s change it to:
<h1>Matt Watson</h1>
… and save the file.
Then in the terminal, add the file to the staging area:
git add index.html
When you have done this with all of the files that have conflicts to resolve, you can then commit the merge:
git commit -m "Merge branch test-change"
It will then display something like this in the terminal:
[master 13e3684] Merge branch test-change
And of course don’t forget to run git push to push your changes to your remote repository.
.gitconfigUnder the [alias] line in the ~/.gitconfig file on your computer, I recommend the following:
graph = log --oneline --decorate --graph --all
co = checkout
ci = commit
st = status
br = branch
fa = fetch --all
Also, While I’m discussing git config, don’t forget to add your name and email when you are using git for the first time or when on a new computer. You can update those by putting them under the [user] line in the .gitconfig, or you can run the following commands from the terminal, which will add those lines for you.
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git rebaseNEVER RUN IT!!!
In fact, you should never really run anything that’s going to retroactively change your history/commits in an unnecessary way. I don’t like squashing commits either. I know some people really care about these things and want to do them and I guess that’s fine. But personally I hate it and don’t see the point of it. If you committed something and then you realize you want to change it, just change it and commit it. That’s the point of version history.