As you may have heard by now, the default git branch name is changing from master to main in most git software (GitHub, BitBucket, GitLab, etc.) to drive out some divisive terminology. A lot of tutorials I see include scripts and aliases that depend on the default branch name being master, and those tools may be broken now, leaving you and your users with some issues after the migration is completed server-side.

The good news is that the default branch isn’t just a “thing you know”, it can be extracted dynamically from a git repo. Doing so is a very simple piece of code:

git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'

You can integrate this into any other aliases or scripts you have. For example, in my .bashrc, I’ve replaced these branch-specific aliases:

alias updatemaster='git checkout master && git fetch origin --prune && git fetch origin --tags && git pull origin master'
alias updateprod='git checkout production && git fetch origin --prune && git fetch origin --tags && git pull origin production'

with this single non-specific alias:

alias updateorigin='git checkout $(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@') && git fetch origin --prune && git fetch origin --tags && git pull origin $(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')'

And for my VS Code setup on Windows, where I use a PowerShell terminal instead of WSL/bash, my .gitconfig contains an alias for git up:

[alias]
up = !"git checkout $(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'); git fetch --prune; git pull"

Regardless of whatever system you use, now is a good time to start replacing any hardcoded instances of master and replace it with a more dynamic reference so that changes to the default branch are transparent to you. Share this information with your coworkers and update your training and new hire documents and your whole company can make the transition smooth, too.

Over the 12 days of #Commitmas, you may have submitted a Pull Request (PR) to Matt Brender’s 12-days-of-commitmas repository. I’ve done the same thing. Once the PR is merged, your fork is out of sync with the main repository. If you do more development on your fork, you may start to run into conflicts when you submit the next PR.

Adding additional remotes

When you set up your fork, github (bitbucket, etc.) helpfully provides you with the repository’s remote information in HTTPS or SSH format (see Jonathan Frappier’s article on forking for more information). After you clone your fork’s repo, you’ll have a single remote called origin. You can see your remotes with git remote -v.

We can handle PRs through the github interface, but that doesn’t help us keep things in sync (well, you could delete your fork and make a new one, but that’s a lot of work and wipes out any pending changes you’ve made, so we’ll consider that unfeasible). The best way to manage this is to add the original repo as another remote. The remote can be called anything you want. We will call it upstream, a common pattern with github users.

As you may remember, you provide the keyword origin to your push statement. That’s not a magic word, it’s referring to the remote to which you are pushing your commit history to. Most of the time you don’t have rights to push to someone else’s repo, but git push upstream <branch> is a legitimate git command. You can also use the upstream remote with other commands.

Fetch and Pull

You can fetch the latest information from the remove with git fetch upstream. This will pull down all references and branch names. You can then git pull upstream master to fast-forward apply all changes in the upstream’s master branch to your current branch. I made sure to make sure I’m in my own master branch before I began, but you could do this in any branch – great if you started some edits based off master and a few PRs have been applied since.

Once you’re done, don’t forget to push changes to YOUR remote. You don’t technically need to do it, but if you work on another machine, you’d have to perform the whole clone/remote add/fetch/pull process again.

Now you’re able to see all the changes made in the repo and you’re able to base new branches off the up-to-date contents of your master branch!

Now that you know how to rewrite your git history with rebase, let’s take a look at amending your commits. An amend is much simpler and, for the case of typos or other minor corrections you discover immediately after a commit, sometimes much more appropriate.

For the setup, we’re going to add some markdown to the 12-days-of-commitmas repository’s README.md, but with incorrect tags. A URL is of the format “[text to display](url://to/visit)”. It’s easy to get this backwards or to use the same tags on both sides of the URL. Here, I’ve used square braces for the URL and commited it anyway. Whoops!

Continue reading →

As part of The 12 Days of #Commitmas, we’re all practicing our git-fu. I’ve learned a bit about rebasing that I’d like to show you now.

Why are we rebasing?

The definition, from man git-rebase, is “Forward-port local commits to the updated upstream head.” Clear as mud, if you ask me. Another way of putting it is that a rebase moves a branch to a new base commit. Let’s say you create a new branch from master on the 1st of the month and make two changes, then a week goes by. A half dozen changes have been made to master and your branch doesn’t have it. You can rebase your commits against the current master rather than the original master. Underneath the hood, git is rewriting the project history to achieve all of this. All the commits are actually new. This means the checksums for commits are unique (we’ll look at why that matters in a moment).

This is great for integrating your feature against the master and maintaining a linear history. There’s another reason we might want to rebase, though – maintaining a clear history.

Continue reading →