GitHub is the go-to place to host your open source projects, that much is well known. A lot of companies also use their paid plans to get the ecosystem around GitHub for their own code. Why would you want to use anything else? We took the decision to move away from GitHub and in the end we benefitted hugely!

Acts as a proxy for incoming webhooks between your Git hosting provider and your continuous integration server.

When a Git commit webhook is received, the repository in question will be mirrored locally (or updated, if it already exists), and then the webhook will be passed on to your CI server, where it can start a build, using the up-to-date local mirror.

This tutorial demonstrates how to apply changes made to a project hosted in one git repository onto a completely separate project in a different git repository: essentially, merging changes between two totally separate git repositories. If you don't use git, this will likely not interest you much.

A command-line tool that helps you clean up Git branches that have been merged into master.

In this post, I'm going to take a look at some common scenarios where you might want to "undo" a change you've made and the best way to do it using Git.

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day - often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.

There are a number of advantages to deploying so regularly. If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs. Little issues can be introduced, but then they can be fixed and redeployed very quickly. Normally you would have to do a ‘hotfix’ or something outside of the normal process, but it’s simply part of our normal process - there is no difference in the GitHub flow between a hotfix and a very small feature.

The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history:

* Removing Crazy Big Files * Removing Passwords, Credentials & other Private data

The hub subcommand for git, allows you to perform many of the operations made available by GitHub's v3 REST API, from the git commandline command.

You can fork, create, delete and modify repositories. You can get information about users, repositories and issues. You can star, watch and follow things, and find out who else is doing the same. The API is quite extensive. With this command you can do many of your day to day GitHub actions without needing a web browser.

Supposedly, git-svn can also be used to convert a Subversion repo to Git. Unfortunately, after reading the git-svn docs carefully and several useful resources (like the slightly-obscure Git FAQ, the Git Community Book, Paul Dowman’s blog and Alexis Midon’s blog), it became apparent that all the resources are piecemeal and nothing gives you the BIG HONKIN’ PICTURE. So here it is, ponies and all…

If you've ever used git bisect, you know what an incredibly useful tool this is. It allows you to do a binary search through commits to find out which commit caused a particular error. Many people seem unaware of git bisect run ... which automates this even further, but it has a limitation: it won't let you find a particular error, it detects success or failure, that's all. So I decided to do something about that.

1–10 (13)   Next >   Last >|