I am by no means an expert, but I've been using Git for years at this point. Over that time I've picked up some tips, tricks and habits I use daily that I think could help you too.
1. Switching back to the previous branch
I swap between main/master, my feature branch and back to main/master constantly. Rather than typing out the name of branch you want to switch to, Git provides a nice alias to switch back to your previous branch:
git switch -
This might look familiar as it mirrors cd -
which navigates to your previous directory in the terminal in the same way.
I use this all the time to ping pong between main/master and whatever feature branch I'm working on. For example:
$ git branch
* main
$ git checkout -b feature-branch
Switched to branch 'feature-branch'
$ git switch -
Switched to branch 'main'
$ git switch -
Switched to branch 'feature-branch'
$ git switch -
Switched to branch 'main'
2. Pushing to a remote branch of the same name
When working on a feature branch you'll often need to push your changes to a new remote branch before creating a PR. Typically, the remote branch has the same name as your local.
Its tedious having to copy/paste (or god forbid type out) your branch name. What if there was a better way?
$ git push origin HEAD
It pushes and creates a branch on the remote using the same name as your local branch. It doesn't matter how long or tedious your branch name is. Using the HEAD
alias will pick it up from your local branch, like so:
$ git checkout -b feature-branch
Switched to a new branch 'feature-branch'
$ git push origin HEAD
...
To github.com:company-name/project-name.git
* [new branch] HEAD -> feature-branch
I find this useful as at work we have conventions for branch names. They're often long and include ticket numbers, for example feature/123456/great-new-feature-that-will-triple-revenue
.
By using HEAD
I never have to care about the branch name. It works every time. In fact, I use an alias of git poh
on all my feature branches when pushing.
Speaking of aliases...
3. Git aliases
Git allows you to specify aliases to effectively create your own Git commands.
You probably have some shell aliases set up already, you might even have some aliases specific to Git. I prefer to use git aliases rather than shell aliases as they're scoped to Git and feel like real Git commands.
To create one open up ~/.gitconfig
and add your commands under the [alias]
section like so:
...
[alias]
deploy = push production master
...
This will create a new command git deploy
which is as if you wrote git push production master
.
I have a bunch of these and I've published my .gitconfig to as a gist if you're looking for some inspiration. Some of my favourites are:
# Cleans your working copy, resetting everything to the previous commit creating a blank slate. Stolen from Jeffrey Way
nah = "!f() { git clean -d -f; git reset --hard; }; f"
# git status, but shorter
st = status -s
# Removes the last commit, but keeps the changes so you can make any changes or deletions
undo = reset HEAD~1 --mixed
# Unstages any changes
unstage = restore --staged
4. Open the current project in GitHub
A couple of shell aliases (not git aliases) I like are:
gh
ghu
These open up the current directory's project in GitHub in the browser.
gh
opens the origin remote and ghu
opens the upstream remote, depending on whether I'm working on a fork or not.
I find these useful when I'm working on a project and want to take a look at the GitHub issues or PRs.
If you'd like to use them too, open up your shell's config or alias file (~/.zshrc
/~/.bashrc/etc)
and add the following:
function gh() {
local repo_url=`git remote get-url origin | sed -e 's/git@//' -e 's/.git//' -e 's/:/\//'`
open "https://$repo_url"
}
function ghu() {
local repo_url=`git remote get-url upstream | sed -e 's/git@//' -e 's/.git//' -e 's/:/\//'`
open "https://$repo_url"
}
Top comments (0)