Git is a wonderful tool for managing your code. Many code repositories, like GitHub (obvi), BitBucket, Azure DevOps, and others, support git. We covered the basics of git in this post, review that before starting here.
Fundamentally, knowing how to do the routine tasks of pull, push, commit, etc. is all you really need to know for your day to day. You’re doing great if you know these commands. However, there are a few more tips and tricks I think every developer should know to help improve their git-savi-ness and possibly improve their git experience.
This is far from a comprehensive list of everything, that’s well documented in on git’s page. If you have other tips, leave them below in the comments and I’ll see about adding them in!
Take the basics one step further with shortcuts
Take what we know thus far one step further and get quick about your fundamentals. Many of these commands can be combined to help expedite your typing.
Creating new branches
If you’d like to create a new branch, instead of
git branch name
and then doing
git checkout name
to then start using it; you can simply do
git checkout -b name
This will create the branch and switch you over to that branch, all in one quick command.
Quick comments on commits
Previously we would use
git commit
to commit our changes. This command opens up the full text editor and we can enter in our comments, as much as we want. You can also enter in quick commit messages using
git commit -m "your message here"
Stage and commit
When you’re done working and want to stage and commit your work, instead of
git add filename.html
and then
git commit
you can do this in a single line
git commit -am "message"
The a switch adds anything modified or deleted to be staged. However, anything newly added to your folders still needs to be added separately. I recommend git add . if you want it all added, otherwise git add filename.html for each individual file.
More commands to be aware of
Other than shortcuts, there are some other useful commands we can use to help our git experience.
Updating your branch from the root branch
You should update your branch from the branch you branched from. For example, update your branch yourBranch from develop. We call this rebasing, or basing the branch, again.
As best practice:
- If you’re on a 5+ person dev team, with many features and bugs being worked during your sprint (your backlog averages 15+ items) I suggest doing this at least once a day, in the AM before you start working, so you know you have the latest work.
- If you’re on a 2-3 person dev team, with a slower backlog, I suggest doing this every 2-3 days. If you’re able to get all your work done in a day or so, you may not need to do it at all.
- If you’re a team of 1, don’t worry about it, unless you yourself are working on multiple branches and are merging them frequently enough, then rebase after each merge.
You can handle this by doing something like:
git checkout develop
git pull
git checkout yourBranch
git merge develop
This will work, although not a real rebase. However, this is a useful way to merge yourBranch with herBranch and visa versa.
Rebasing basically removes all of your commits since you branched it, applies all of the commits applied to the root branch, then applies all of your commits on top of those changes, thus, rebasing your branch.
git rebase develop
Undo everything I’ve done
As a developer, we may spend some time working through an issue, trying different variations of code and methods. We may edit many files and then decide this approach is not valid, it no longer applies, it’s not working well. We just want to start over. From here, I like to run
git reset --hard
This will remove ALL modifications and deletions made since the last commit. If you added files and did not stage them, those files will continue to exist since git doesn’t know about them. You’ll have to delete those manually.
Delete the branch
Alternatively, you can just delete this branch, if you truly don’t want anything in it. This will permanently delete your branch from your local repo. If you already pushed this branch to the shared repo, then the brach lives on there.
To delete:
git branch -D yourBranch
You will have to be on a different branch, you can’t delete yourBranch while your in that branch.
You can then run git branch to see a list of all of your branches, if there’s more than what you’re working on, consider cleaning them out.
I suggest keeping your local workspace as clean as possible. If you have a branch that you’ve already pushed up and it’s merged and deleted in your repo, why keep it locally? Trust git, it has all of your history, remove it from your local repo.
“Cut” and “Paste” changes from branch to branch
Sometimes I find I am in the wrong branch and I’ve done a load of work already. If I’m in the develop branch, I can simply run git checkout -b newBranch and it will create the new branch and move my changes over.
Sometimes I’m in a feature branch, and realize I want to be in another branch. Before I commit my changes, I can use
git stash
This command removes all of my uncommitted changes from my current branch and throws them somewhere magical. Your current branch is then reset to normal, no changes.
I can then git checkout otherBranch and then run
git stash pop
to apply those changes to the current branch.
Replacing a branch
Sometimes we’ve done some work in the wrong branch, then we make commits to it. We may have been working in develop for the past several hours, after a handful of commits, and then realize ‘oops! I didn’t create a branch!’. Now your develop is out of sync, it’s considered ahead of the shared repo’s develop branch, which is a bad state to be in.
My recommendation is to git checkout -b newBranch to move everything you’ve done to a new branch. Then git branch -D develop to remove your version of the develop branch. It’s okay, this delete does NOT remove it from the shared repo. Then do a git pull to pull down the branch again from the shared repo. Now all is right with the world.
View the history of your branch
Every so often I forget what I just committed, or I’m taking over someone else’s branch and I need to see what’s been going on in there. Using
git log
will allow me to see the history of commits on the branch. This is one reason commit messages are really important to help explain what’s been done. You will see all commits on the branch, even those of the branch you branched from.
When you run git log, you will be in a paging mode, use down arrow to navigate. When you’re done, press q to quit it.
Flatten all of those commits
You may notice when you run the git log or when you’re reviewing your PR, you may have a HUGE long list of commits, just all piled up. Before you push your branch to the repo, you can squash these commits into a single commit:
git rebase -i HEAD~5
The 5 indicates how many commits backwards to squash.
After this is run, you’ll be prompted to edit the commit message, which it has automatically consolidated the last 5 commit messages. Running this will remove 5 commits and consolidate into a single commit, all of your changes are there.
Keep those commits flat
You can do the quick rebase as mention above, squashing the last bunch of commits. However if you’re hopping in and making a quick change (like fixing a typo or removing the notorious console.log), it may be easier and faster to amend your commit.
git commit --amend
This will prompt you to also edit the commit message. This will keep the same commit and add your changes to it. After you do this, you will get a warning when you try to push this to the repo. The problem is you now have an exactly same commit id but with different content, that’s bad, but not a problem. You have two options:
- You could do a
git push -f. This will force push it up and overwrite the repo’s copy. IMPORTANT If you’re the only one working on this branch, that should be fine. If you have others who could be working on this same branch, then you could overwrite their changes. - Alternatively, you can perform a
git pull, which will merge your branch to what’s in the repo, and I think it does some other magic in the background, and then agit pushwill work as expected.
Create your own shortcuts with aliases
Git supports shortcut commands, or as they call them aliases. An alias allows you to shorthand the commands, like go from git status to git st, git commit to git ci, and so on. These are real easy to setup and are customizable.
This is the list of my go to shortcuts
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
Stolen, er, referenced from git aliases.
Now all of the commands above can be even easier and shorter using these aliases:
git br -D yourBranch
git ci -am "message"
and so on.
Is that it?
Ha, no. There is so much in git to learn and explore. Check out Git’s reference documentation, each command has a slew of options. I hope this post will widen some peoples’ perspectives and give them a few more tools in their toolbox.
What am I missing? What are your go to commands for git? Share below! I’d love to learn from you and add to this list!
RSS - Posts