Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have two git branches with almost the same code, but some minor changes in order to support different platforms.

I need to maintain these changes because I need them to run the software on different computers. So there is no master and development branch, both are equally important.

Nevertheless, I need to "synchronize" the core code base of the branches. So I would like to somehow apply the commits from one branch in a sort of patch fashion to the other branch and vice versa, without merging them, in order to maintain the different setups.

Is this possible with git? If yes, how can I accomplish this?

Edit: can I merge only some files and leaves others out, but maintain the two branches?

share|improve this question
add comment

6 Answers

up vote 2 down vote accepted

Can you have three branches instead of two?

  • branch work, with all platform-independent code, which is 99% in your case;
  • branch platform-A with code specific to platform A;
  • branch platform-B with code specific to platform B.

Your main work happens on work branch. You periodically merge changes from it into platform-A and platform-B, tweaking platform-specific aspects if needed.

This way, things specific to platform A never unintentionally seep into platform B code, and vice versa. You can also easily keep the bulk of your tests platform-agnostic.

share|improve this answer
If the platform-specific code is not big I'd probably just have a single patch with it, and keep rebasing it on top. –  Balog Pal Jun 4 '13 at 22:32
add comment

I don't think the question makes sense.

In git, every repository is essentially a branch. There is no form of code inclusion that is not merging. You either need to synchronize them and in the process, manually perform the merge, or you need to let the software do the merge itself.

share|improve this answer
well, can I merge only some files and leaves others out but maintain the two branches? –  user92716 May 31 '13 at 16:30
add comment

This sounds like a task for a build system, not a version control system.

share|improve this answer
sounds like a good idea, but without elaboration on how it answers the question asked it looks more like comment, not an answer –  gnat May 31 '13 at 21:09
I think it is pertinent. He gave no further information that would allow me to elaborate on an approach. Thanks for the downvote, I guess. –  radium Jun 1 '13 at 1:13
add comment

You should be able to do this using patches. Take a look at this post:

How to create and apply patches

and this SO question:

Generate a patch for a specific commit

Googling for git patches also provides plenty of information.

share|improve this answer
add comment

This can be done with the git cherry-pick command, but that's really intended to be used sparingly. Making it a regular part of your process is going to eventually get painful.

A slightly better option is to create a master branch with all the common code, then have each configuration's custom changes done in their own branches. That lets you merge from master down to the individual configuration branches.

However, the best option is to refactor your code so you can just use a build flag or a config file to switch between the different configurations. Keeping two configurations in separate branches is reasonable, but as your needs grow, it will become unwieldy very quickly. It's better to bite the bullet now when it's easier to refactor.

share|improve this answer
add comment

There are various ways to do this with git, as others have lined out - cherry-picking, introducing another branch, manually applying patches, etc.

I seems though that this is not what you really should do. You are managing a codebase that is to be deployed on different platforms; the different "versions" are not different development states of your code tree, but rather different products derived from it, a.k.a. builds.

So, set up a build system if you haven't already (can be as simple as a shell script running a few rsync or cp -r jobs). Make it so that you can pass it an argument that determines for which platform to build, and based on that argument, the build system decides which files to include in the release package. With just a bit of good structure, you spend a day or so getting the build scripts right, and then never worry about it again.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.