Maintaining open source projects

First I’d like to thank all the folks at Thoughtbot for all their efforts on Upcase. I’ve learnt a lot on this site and through reading your open source projects and as a result released my first open source project on Github that’s picking up steam and is trending.

I’ve never managed an open source project before and whilst I’m not expecting a ton of activity on this project I’m wondering how do you merge pull requests without creating those merge ‘bubble’ commits which arise through gits 3 way commit process?

I’ve become accustomed to first rebasing feature branches on master before merging to ensure git can merge via fast forward. Does this mean I have to nag contributors to rebase on master just before they make a pull request?

Hi @robodisco, congrats on publishing some work on GitHub!

To avoid those “bubble” commits, I perform the merge in the shell. I check out the PR locally using the hub utility (hub co url-of-pr-on-github), rebase it against master, and then merge and push. This results in the least amount of noise, and keeps the PR’s contribution to a single commit (or the minimum number of desired commits). It’s useful to do the rebase in case master has moved since your contributor pushed their change up.

If your committers aren’t signing their commits (and they should consider doing so!) and your changes to their commits are just reconciling small changes, I think it’s OK to make the change while leaving their name as the committer. However, if your contributor signs their commits, it’s important to ask them to do the rebase themselves, then immediately after they do the rebase you can merge their work using the steps above.

Thats brilliant @geoffharcourt - just what i was looking for. I’ll give that a go on my next pull request. And thanks for reminding me about the hub gem - i keep meaning to check it out. Now I have another good reason.

I’ve modified the standard thoughtbot dotfiles g() function to use Hub instead. Now that Hub is written in Go, it’s very fast, and there’s not a significant performance penalty to just alias git to use hub instead. (The utility passes non-GitHub-specific commands through to Git.)

1 Like