Signs That You’ve Outgrown Github, Part 3: Merges

This is part 3 in a series about the limitations of Github, and how they might be holding your team back from its full potential. If you want to go back and catch up, here’s Part 1 and Part 2.

Go ahead, I’ll wait right here.

Done? Okay, let’s move on.

Today’s discussion is about getting code merged. It’s one of the most fundamental things any software team has to do. If your team is anything like ours, it’s something you do many times every day. It might even be the kickoff for your Continuous Integration/Delivery process, as it is for us.

Reliable merging is the key to getting multiple things done at once

Getting things out quickly is important, but preventing outages from bad code is even more important. You probably want an easy way to review and even test code that doesn’t distract too much from the work you’re already doing.

Once again, Github has a wonderful system for promoting code from one repository or branch to another — the Pull Request (PR herein). In particular, the PR is great for open-source projects where people might want to contribute, even if they’re not members of the main project. The proposed contributions can be examined by the main project member(s) and be pulled in only if they’re helpful.

Typical Github pull request — you can see the code changes and their purpose, all in one place

But like many other Github features, you may find the PR process to be mis-aligned to your needs, in a way that creates a little extra delay and a bit of confusion every time you use it.

Pull Requests 101

For those who haven’t tried one yet, a pull request (PR) is a special kind of task, asking someone to merge a set of changes (commits) from one place to another. In more general terms, you can think of it as promoting a chunk of work from one level to another — such as from a development branch to test and then to production, or from a hotfix branch to long-term-support.

A simple example of promotion — taking a specific change from one environment to another

Because it’s a request, it doesn’t involve any access to the project repository from any non-members. The project team can review the proposed changes and take them, ask for revisions, or ignore them. It’s a great model for open-source or otherwise loosely-coupled groups to share ideas and improvements.

Keep It In One Place

But that flexibility comes at a cost. Pull Requests are opened and managed separately from individual tasks, so you’re basically creating another task to review each task’s work. The open or closed status of each task can be independent of the status of the related PR. Additionally, there’s nothing stopping someone from submitting changes for multiple tasks in one PR, which can be confusing and difficult to review.

For software teams that aren’t open-source, this loose coupling actually creates more process, more overhead, and time thinking that could be spent doing instead.

Ask yourself — wouldn’t it be a lot easier to merge the code as an integral part of the task itself?

Singularity Of Purpose

Let’s start with an assumption — that in order to change your code, there should be a defined reason for doing so.

You’re writing code because something needs to be added or fixed. There’s a use case. A story. A bug. A feature. A customer who wants something. There’s a reason to change what you already have.

You probably also want to do two things with your tasks:

  1. You want to create a plan ahead of time, for which things will be done, by whom, in what order.
  2. You want to keep track of progress as things move along.

Once you start depending on tasks for planning and tracking, you can begin to improve your overall process, reducing the number of steps and the distance between idea and working code. As you do, separate PRs may start to lose their appeal. Asking developers to open a separate kind of ticket to get code merged is a hassle. Allowing them to put multiple bug fixes into one merge is asking for confusion and mistakes.

If you’re delivering code using a well-defined workflow, PRs can actually cause problems:

  • Audit trail — It’s difficult (or impossible) to know later which code changes went with which task.
  • Larger merges — the code review itself becomes much more complicated, since there are more commits, more changes files.
  • All or nothing — If you like the changes for task #1, and for task #2, but there are problems with the tests for task #3, the whole PR is sent back for rework. This means you’re likely sitting on changes for longer.
  • More conflicts — Pretty simple math: (Larger merges) + (All or nothing) = More conflicts.

Since there’s no way in Github to limit the content of a PR, there’s no good way to prevent this kind of behavior. Creating a PR for every single bug becomes a tedious time-sink that doesn’t add value to your day.

Now, you might argue that a Github PR can act as the task itself, and it does — but not really. PRs are only retrospective, meaning that you create one after (or while) doing the work. If you don’t create tasks before doing the work, then you’ll never have any way of planning or tracking progress.

Simplify, Simplify

For most teams, the overlap between tasks and PRs is additional work that doesn’t generate any value. What you really need is a way to automatically detect code changes, review those changes and then promote them to dev, test and production, all as part of the task.

This kind of integration means that you can go back to the task later, understand the intent of the change, and also see the code changes that went with it. Your task tracking becomes a source of institutional memory, so that people can move in and out of the team, or across different features without making old mistakes over and over again.

If your tools are preventing you from improving your process, maybe it’s time to improve your tools.

Come try GForge Next for simple, comprehensive and elegant collaboration.

On the Importance of the Team

This week, our City School District handed down an unpopular decision – to close a charter-type middle school. I have a friend whose son attends the school, and they both spent a lot of time and energy trying to change the School Board’s minds about the closure. I was very impressed with their effort but in the end, I’m not sure if anyone was really listening.

After hearing the news that the school would be closed, the thing my friend lamented first and foremost was not the uncertain prospect of another school, or a different level of challenge for her son. It was the loss of the community the school had become.

The opposite could be said of my old job with the State. I was in charge of a group of developers (among other things), and gave it as much thought and effort as I had. We delivered a lot of great things, on many tight timelines, and I often felt it was the best place for me to contribute to the world. But after eight years, I realized that the community around me was never going to be as good as I thought it needed to be. Over a long weekend, I made up my mind to leave. I was gone about a month later.

I could write many other examples from my personal experience or that of my close friends. Examples where someone sticks it out in a tough situation, or leaves an easy, high-paying job for something more difficult and less rewarding. The theme that emerges in each case is the same.

Your team is the most important asset you have.

That’s right – your disruptive product, synergistic partnerships, business model, funding stream, delivery process and technical wizardry are all secondary in importance to your team. That huge idea you’re out there making noise about? It’s very probable that someone else is already doing it, too. With more funding, six months ahead of you, and with a much trendier technology stack. Or a better corporate partner. GForge is a good example of some of these disadvantages – tools like Github and Jira are much better known and flashier-looking.

So how do you compete? If you have all that buzzword-y stuff I listed above and a bunch of superstar strangers delivering it, you simply aren’t set up to get where you want to go. No, you need to get the best (nicest, most dedicated and OF COURSE talented) people you can find, fit them together carefully, give them space and boundaries.

All of the other goals you have – making good decisions, making up for bad ones, staying late to do it right, knocking it out of the park for a big customer – all of these things flow from the team.

Fix your team. Make sure everyone belongs, and make sure they know it.

This is exactly what Tony’s been doing since he took over at GForge. It’s definitely working for us:

  • We delivered more new features in the six-month 6.2 cycle than in the previous two years.
  • Everyone on the team contributes to planning, new development, and support.
  • We all know who to lean on for Unix-y OS stuff, versus Javascript-y stuff, versus REST/SOAP/API kinda stuff.
  • All code is reviewed. Everything else (documents, mockups, plans, ideas) is at least shared out as we’re working on it.

This is the best overall team I’ve ever been part of, and that is Really Saying Something. We are definitely our biggest asset, and we are doing great things every day together. Those disadvantages I mentioned before? We’re adding more features on a weekly basis, and gaining new customers every month.

I’ll write more about our roadmap another time, soon.  Until then, let’s hear about your team. Changes, successes, problems? Leave a comment!

v6.1.0 Demo and Roadmap Planning Webinar Available

Over the past couple of weeks we had a series of three webinars where people and organizations interested GForge Advanced Server could see v6.1.0 in action and to discuss our development roadmap.  We want to thank the dozens of customers that joined one of the webinars and worked with us to make sure our development priorities are in line with their expectations.  Over the next week we will be taking the features discussed and turning them into defined released. Once that roadmap planning is done we’ll be sharing those dates and features here on our blog.  In the meantime, we wanted to share a recording of one of the webinars so that anybody that missed it could join the conversation.  As always, you feedback is welcome here in the comments or via email at