Managing different SSH Keys for different Hosts is well-understood.
Different keys for the same host (e.g., github.com), based on which GitHub Organization we’re working with, that’s… a bit trickier.
But, we have the technology!
We’re going to configure our SSH and Git clients to seamlessly switch SSH keys between our personal GitHub Account and our GitHub Enterprise Cloud, EMU Account.
To delete local branches which have already been merged into main:
$ git branch --merged main | grep -v "\* main" | xargs -n 1 git branch -d
You can omit the main branch argument to remove local branches which have
already been merged into the current HEAD:
$ git branch --merged | grep -v "\*" | xargs -n 1 git branch -d
We start by getting a list of local branches which have already been merged
into the current branch (i.e. HEAD)
$ git branch --merged
add_new_user_gravatar_links
assign_unique_key_to_uploads
* main
remember_the_last_activity_per_user
update_kaminari_to_thread_safe_version
We then pipe that to grep to match on the "\*" character, inverting that
match via -v to get all merged branches sans the current one.
$ git branch --merged | grep -v "\*"
add_new_user_gravatar_links
assign_unique_key_to_uploads
remember_the_last_activity_per_user
update_kaminari_to_thread_safe_version
Finally we pipe that list in to xargs so we can strip apart the input and
pass it on to a new command. We use -n 1 to ensure at most one argument is
taken from the input to be passed to the invocation of the new command. The
resulting commands that xargs will invoke are effectively
$ git branch -d add_new_user_gravatar_links
$ git branch -d assign_unique_key_to_uploads
$ git branch -d remember_the_last_activity_per_user
$ git branch -d update_kaminari_to_thread_safe_version
Pulling it all back together, we have
$ git branch --merged | grep -v "\*" | xargs -n 1 git branch -d
Deleted branch add_new_user_gravatar_links
Deleted branch assign_unique_key_to_uploads
Deleted branch remember_the_last_activity_per_user
Deleted branch update_kaminari_to_thread_safe_version
And there you have it. Go forth and clean up!
I’ve created visualizations for Git repositories before – the one tracked a product from its first commit through launch. And while I still think there is some information and insight to be gleaned from such visualizations, the real reason I like to make them is… I think they’re neat.
To celebrate launching the latest incarnation of VersionOne, I made another visualization! This one tracks all changes made in our Git repository that occurred between our last major release (in late February) right through the very last commit that made it into the Spring 2011 release.
Wow… that really sounded like a sales pitch, didn’t it? I hate sales pitches!
Enough of that. Enjoy!
To rebase, or not to rebase - for me its not really a question. I
generally prefer a clean, linear commit history. Why? Because merge bubbles make
history confusing, noisy, and can break git bisect.
Don’t believe me? Check out the pretty log to the right. See all
those merge bubbles in there? Eww!
The workflow that caused those merges was as follows:
git pull (to bring local up to date)git commitgit pullgit pushBy default git pull will fetch any new commits from the remote, and
then merge any local changes in, resulting in the merge bubbles.
A few months back I gave little talk on the darling SCM tool of the Open Source world, Git. After the conference, the organizers asked for a copy of the presentation materials I’d used - something I usually find little value in as the content of a discussion is far more than just the collateral used.
At any rate, I obliged, sent off a PDF, and have opened the talk up for others to use and improve. You can find the source (Keynote presentation, images, etc.) on GitHub. Fork and modify the talk to your heart’s content. ♡
Oh, and the PDF is there too.
Enjoy!
I don’t know about you, but I like pretty things. Things that engage me. Shiny things. I enjoy seeing the same old thing in new and interesting ways. I suppose I’m just a visual kinda’ person.
Unfortunately, the desire for visual representation is at odds with the high bandwidth flood of information we’re subjected to these days. Even if we manage to trim the overwhelming flood of information down to a laser-focused stream, it takes an immense amount of effort to make sense of it.
For years the primary way we’ve looked at the activity or interaction within various source control management systems is via log files. Yep… plain, text-laden, indecipherable logs chock full of entries each a similitude of it’s predecessors.