Use vimdiff as git mergetool

Ruslan Osipov has a very handy tutorial on how to setup Vim text editor as git merge tool, for resolving git conflicts.

Basically, run the following commands to tell git to use Vim as a merge tool (don’t forget the –global flag if you want it for all your projects, not just the current one):

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

With that, running “git mergetool” after a conflict was reported, will result in something like this:

The three way split window will show local version (–ours) on the left, the remote version (–theirs) on the right, and the base version with the conflict in the middle.  You can then get changes from one window into another using the following Vim diffget commands:

:diffg RE  " get from REMOTE
:diffg BA  " get from BASE
:diffg LO  " get from LOCAL

Awesomeness!

Check a few of Ruslan’s other vim-related articles.

composer-patches – Simple patches plugin for Composer

composer-patches is a plugin for Composer which helps with applying patches to the installed dependencies.  It supports patches from URLs, local files, and from other dependencies.

I think this is absolutely brilliant!

It’s quite often that one finds bugs and issues in external dependencies.  Once the bug (or even the pull request with the fix) is submitted to the vendor, it can take anywhere from a few hours to a few weeks to be resolved and a new version to be released.

If you have a fix for the problem and need it in your project right away, and can’t wait until the vendor releases the new version, your best choice is to fork the dependency, fix the problem, and use your repository instead of the vendor’s package.  This works, but it’s messy.

With the patches plugin to composer, you can still use the vendor’s package and just apply a patch with composer, until the new version is available.  Clean and simple.

This also helps with testing things and working with different changes by different people, if you want to try things out – no need to choose between multiple repositories.  Just select the patches that you want and apply them at the environment you need.

Given that most development work is happening on GitHub these days, this composer plugin is even more useful than what I might think at first.  You see, GitHub provides patch and diff URL for each commit – all you need to do is add the extension to the URL.  For example, take this recent commit to my dotfiles repository.

Commit screen

If you add a “.patch” extension to this URL, you’ll get a patch output, which is useful for git am, and other commands (more on using git with email):

Patch screen

 

If you add a “.diff” extension to this URL, you’ll get a unified diff output, which you can either apply with diff and patch utils, or use with the composer-patches plugin.

Unified diff screen

So, this gives you a way of applying any commit on GitHub (and other repositories) via composer to any of your dependencies.  This is mind blowing!

 

BitBucket : tag from source

BitBucket has implemented one of the most frequently requested features, which was outstanding for more than three years now – creating tags from the source browser (as in BitBucket web interface, rather than from the local repository, using git and then pushing it to remote).

I didn’t see the announcement in the BitBucket Blog, so I thought I’d post it here.

In order to create a new tag, navigate to the Commits page of your repository, then click on the hash of the commit that you want to tag, and then create the new tag from the upper right corner interface as per this screenshot:

It’s not the most obvious place to have this functionality, and the other feature – the equivalent of the GitHub releases – is still missing, but it’s better than having to use the local repository.

Update (January 23, 2017): BitBucket Blog carries the post now.

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–browse.sh means “trace the evolution of lines 155 to 155 in the file named git-web–browse.sh“.

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

PR-focused-dashboard

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

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:

diff-so-fancy

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.

cd "${DEPLOY_TREE}"
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.