{"id":28,"date":"2022-11-09T17:45:17","date_gmt":"2022-11-09T17:45:17","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/awanf\/?p=28"},"modified":"2022-11-09T17:46:11","modified_gmt":"2022-11-09T17:46:11","slug":"git-tricks","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/awanf\/2022\/11\/09\/git-tricks\/","title":{"rendered":"Git Tricks"},"content":{"rendered":"\n

Git is confusing af<\/em>. There I said it. In my brief experience using developer tools so far it’s one of the most clunky (albeit powerful) tools out there for software development and something we all have to learn how to use. Throughout the course of our capstone project I’ve come across a few tricks\/hacks that might make your life a little easier.<\/p>\n\n\n\n

Switching back and forth between branches quickly<\/em><\/strong><\/p>\n\n\n\n

Oftentimes I find myself checking out some branch, some other branch, then switching back and having to type out all this stuff out. When your branch names are like utilities\/audio-processor-improvements<\/code> it gets a bit tedious.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

A trick is to use git checkout -<\/strong> <\/code>to switch back and forth between the two last branches quickly. Example:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Navigate to the repo home dir<\/strong><\/p>\n\n\n\n

This takes your shell to the repo’s home directory of the working tree which is especially useful in our project’s monorepo since our services are often deeply nested:<\/p>\n\n\n\n

cd $(git rev-parse --show-toplevel)<\/strong><\/code><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Note: I did not come up with this myself. See this SO answer<\/a>.<\/p>\n\n\n\n

Using git for-each-ref<\/code><\/strong><\/p>\n\n\n\n

As the documentation states, <\/p>\n\n\n\n

Iterate over all refs that match <pattern><\/code> and show them according to the given <format><\/code>, after sorting them according to the given set of <key><\/code>. If <count><\/code> is given, stop after showing that many refs. The interpolated values in <format><\/code> can optionally be quoted as string literals in the specified host language allowing their direct evaluation in that language.<\/p>https:\/\/git-scm.com\/docs\/git-for-each-ref<\/cite><\/blockquote>\n\n\n\n

<\/p>\n\n\n\n

Ok well that basically means nothing to me so let’s work through an example of using this. Say we want to get an overview of whatever remote branches exist currently. Use git for-each-ref refs\/remotes<\/code>.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Cool that’s relatively useful, but it would be more useful to know WHEN were these commits that are listed made. We can do that by using custom --format<\/code> arguments for our command. Say we want to visualize some of the previous information with the date added in:<\/p>\n\n\n\n

git for-each-ref refs\/remotes --format='%(committerdate:relative) ---- %(authorname) ---- %(refname:short)'<\/code><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Unfortunately the --format<\/code> flag requires us to specify all the information we want so adding additional information to this command would require us to add it individually. More options are available in the documentation<\/a>. Finally, we can sort the information ascending or descending (I prefer descending) by adding the --sort<\/code> flag as so as well as viewing only the unmerged branches.<\/p>\n\n\n\n

git for-each-ref refs\/remotes --sort=-committerdate --format=\"%(committerdate:relative) ---- %(authorname) ---- %(refname:short)\" --no-merged<\/code><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

There’s options to add color and styling but that’s all I have for now! You can add these commands as aliases to your gitconfig<\/code> or whatever dotfiles you’re using. Onto finishing up the project!<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Git is confusing af. There I said it. In my brief experience using developer tools so far it’s one of the most clunky (albeit powerful) tools out there for software development and something we all have to learn how to use. Throughout the course of our capstone project I’ve come across a few tricks\/hacks that […]<\/p>\n","protected":false},"author":12668,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-28","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/posts\/28","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/users\/12668"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/comments?post=28"}],"version-history":[{"count":3,"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/posts\/28\/revisions"}],"predecessor-version":[{"id":37,"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/posts\/28\/revisions\/37"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/media?parent=28"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/categories?post=28"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/awanf\/wp-json\/wp\/v2\/tags?post=28"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}