git: history of a source code line

git is one of those tools that no matter how much you know about it, there is an infinite supply of new things to learn.  Here’s a handy bit I’ve discovered recently, thanks to this StackOverflow comment:

Since Git 1.8.4, git log has -L to view the evolution of a range of lines.


And you want to know the history of what is now line 155.

Then, use git log. Here, -L 155,155:git-web– means “trace the evolution of lines 155 to 155 in the file named git-web–“.

Absolutely brilliant!  I used to suffer through this via an iteration of git blame and git show to the point of custom bash scripts.

Git Workflow Basics

git workflow

Git Workflow Basics” is yet another take on the git workflow.   This subject has been covered in a variety of ways before (here, here, and here, for example), but I think it’s super important for every developer to understand, so if all the other attempts left you puzzled and confused, have a look at this one.  It’s pretty straight forward.

One thing in particular that I would like to emphasize:

And hey: remember to review your own pull request before asking for reviews of your teammates. You’ll spot a lot of small things you didn’t notice (style issues, typos, etc) and will allow your colleagues to focus on what really matters.

Pull Request focused dashboards for BitBucket


A few days ago BitBucket announced the re-worked dashboards, which are now much more focused on the Pull Requests that you’ve created or need to review, rather than lists of repositories that you have access to.  I’ve enabled the feature for my team and it looks super awesome!

If you’ve been suffering from being lost in dozens or hundreds of projects and missing out on the Pull Requests activity, check them out.  You’d be surprised.

Git from the inside out


Git from the inside out – must be the best thing I’ve ever seen on how git works.  Everybody knows that git is awesome.  Most know that git is implemented with graphs.  But not many know how exactly git stores the project history and how it is affected by different git commands.

And if you are feeling adventurous, there is this:

After reading, if you wish to go even deeper into Git, you can look at the heavily annotated source code of my implementation of Git in JavaScript.

Which, among other things, includes  “Git in six hundred words“.

diff-so-fancy – the best-lookin’ diffs

Here is a cool tool to spice up your regular boring looking diffs – diff-so-fancy.  Don’t get spooked by the npm installation instructions – the meat of it is all in perl/shell and you can install it as any other ~/bin/ script.  Have a look at what you are missing:


Git 2.9

Git 2.9 has been released a few days, bringing in some very useful functionality, such as showing renamed files in git diff and git log, forbidding the merge of two branches that have no common ancestors, configurable path to hooks, and more.  All are welcome changes, making the life of a developer easier.

But what I found interesting is how two largest git companies – GitHub and BitBucket – reflect on it.  Surely, the new release is important to both, but it’s insightful to see which features each of them looks at first.  Have a look:


Deploying with git

Git is an excellent version control, but it’s more than just that.  A lot of people use it to deploy their projects as well.  Most suggestions (for example, this tutorial from Digital Ocean) around the web employ the post-commit (or other) hooks to push the code to a remote server.  While this works well, I prefer to do it differently.  I like the pull model better, where the deployment is triggered outside of git, and relies on git to fetch the code updates and run some sort of a build script, which handles database schema changes, cache resets, filesystem permissions, etc.  Such approach also allows to limit remote access to the servers (especially the production ones), and separate responsibilities of a developer and a deployer.

With the many pull, merge, fetch, and update options that git provides, it is sometimes difficult to choose what’s the right set of commands to use.  I’ve figured it out via a rather lengthy trial-and-error process.  But if you don’t want to go through all the pain of that, here’s a nice blog post that tells you exactly how to do that.  I’m copy-pasting the commands here just for the future reference.

git fetch --all
git checkout --force "${TARGET}"
# Following two lines only required if you use submodules
git submodule sync
git submodule update --init --recursive
# Follow with actual deployment steps (run fabric/capistrano/make/etc)

And I suggest you read the full article for the explanation of why this is a better way and what are some of the issues with other strategies.


Useful git commands (and GitHub integration)

Garrett Holmstrom’s blog /dev/zero has a nice collection of useful git commands, especially for those people who work a lot with GitHub.  Here are a few links to get you started:

Very handy stuff!

Git rebase and the golden rule explained

Git rebase and the golden rule explained” – is an excellent explanation of what happens when you do rebase in git repository.  If you know already, or don’t care, at least remember the golden rule:

Never, NEVER, NEVER, rebase a shared branch. By shared branch I mean a branch that exists on the distant repository and that other people on your team could pull.