Pages

Tuesday, February 16, 2016

FBOA Module: Technical Expertise - Git workflow

As part of the CS3281/2 module requirement I am currently taking in NUS, I have to establish myself as an expert in a topic/field/technology of my choice. Because version control systems are going to stay, and Git is currently (arguably) the most popular version control systems out there, and I have had some experience in it, and I have friends who are good at it (I have one too many and's), it is just natural that I choose Git to fulfil that requirement. This is going to be the first of the series of Git tips and tricks that I will post in this blog, so stay tuned!

Officially, my tech expertise is "Git workflow" because if I declare as just "Git", apparently I am expected to know Git inside out or something. Nevertheless, my Git-related blogposts will not be limited to just Git workflow, but also Git tips and tricks in general.

Some topics that I plan to write about in the next 1-2 months (which is basically the rest of the semester):

1. Git workflow best practices
2. Git rebase + push --force safely
3. Git rebase vs merge, and what is happening in the background

To get the ball rolling, here's a neat trick I got from @rauchg's Retweet on Facebook if you need to find the first commit where a given string first appeared in the source code.

git log --source --all -S <string>
What it returns is basically a list of all commits that contains the string you input as changes (both as addition and deletion). The first  commit where it appears is of course, the one at the bottom of the list. If you only need the commit's hash, you can shorten the output by adding the --one-line option to the command. Also, if you want a string longer than one word, you can put the string within quotation marks.

If you want to know what each option actually does, you can refer to git-log documentation page.

That is all for now. Stay tuned for more Git workflow goodness! Happy coding!

No comments:

Post a Comment