At my current employer, we are using an open-source project hosted on Github as a component of our application. I have been working on this project to both add some features that we need and to integrate it with our build systems. My manager and I are in agreement that we would like to submit as much of our work on this component as is reasonable back to the open-source project. My question is about what the best workflow/technique is to maintain my Git commits in such a way that I can easily seperate out things that make sense to add back to the open-source project – bug fixes and new features that are sufficiently general – from things that are specific to our project, like build locations and application constants.
What I have been doing so far is to maintain a private Git branch where I commit all of my changes, with appropriate granularity. I then use cherry-pick to add the open-sourceable commits to the master branch, and submit those back to Github.
It seems like I ought to be using merge to do this, so that I don't keep creating separate commits with identical contents, but I'm not sure how to do this while excluding the company-specific commits and keeping a reasonable workflow.
For example, I suppose I could commit open-sourceable things on master and company-specific things on the private branch, and then merge master into that branch as needed, leaving the master branch pointing at the commit before the merge, such that I could commit open-sourceable things to it again and then merge again. What seems awkward about this workflow is that I would need to decide in advance for everything I do which branch it belonged on, work on that to what seemed like completion, then commit it and merge before testing. One of the things that I really like about Git is how easy it is to just do whatever you need to make your application work, and then decide later how and where to commit your changes. As far as I can tell, if you're currently on a branch and have some work done, there's no easy way to just submit some of that work to another branch, since changing to that branch would require a clean working directory.
Is what I'm doing a reasonable workflow for long-term contributions? Can anybody recommend a different workflow that might be better, and why it's better?
Best Answer
Here's a strategy that might work for you:
Create 2 private git repos, with one repo being for company work and the other being the general (I'd like to commit back) repo.
In order to make this system work, you need to do this (which I consider the most important strategy): Define what is "general" and can be used by everyone else in the community
By having this definition, you can separate out what you will commit back and what you don't need to commit.
It makes sense that what you code for the community be in a general form, as too specific a piece of code will benefit nobody (and might not even make it to the master branch).
Now that you know what you're going to commit to the community, you can do most "give-back" work in the repo dedicated to it. Then you simply fork that repo over to your work-based repo and do any work-specific work on top of that.
I suspect that you will spend a lot more time in the "give-back" repo, so just remember to provide valuable comments, etc (maybe even documentation) for people who would use that project in the future.
I also believe that git can do a lot more than you think. I watched this video on Vimeo: http://vimeo.com/46010208 and she did a brilliant job of explaining a lot of wacky things git can do.
My strategy isn't the only one out there, but it can definitely be a starting point for you to think of 1 that suits you specifically.