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?

8 Answers 8


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.

  • 1
    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, 2013 at 22:32

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

  • 1
    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, 2013 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.
    – kenchilada
    Jun 1, 2013 at 1:13

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.

  • well, can I merge only some files and leaves others out but maintain the two branches?
    – user92716
    May 31, 2013 at 16:30
  • You're thinking of clones, not branches. And there's rebasing and cherry-picking to pull code without merging
    – Izkata
    Jul 5, 2014 at 4:01

If the changes are very minor, like just different command-line arguments, this should be done with configuration files.

Otherwise, as @radium alluded to, you should make separate modules, include everything in source control, and have the build system determine which module is included.

Using Git to maintain two different branches is brittle and error-prone, because you have to always remember to make your changes in both branches.

You can use a .gitignore file to make sure that configuration files are ignored by git, store them somewhere in the repo, and have your build script copy the correct file into the designated location.

For example:

Repo contains: meta/windows.properties meta/mac.properties

.gitignore file says to ignore user.properties

Build script copies either meta/windows.properties or meta/mac.properties to user.properties.

Then you compile, build, run.


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.


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.


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.


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

Your are trying to use a version control system to solve a design problem.

I don't know the details of your systems but this "minor changes per platform" can be easily designed with a little abstraction and polymorphism if you use a OO language. In other paradigms, like structured or functional programming, there are other ways to achieve polymorphism, but its off course posible.

If you give more details on you systems you can get much better responses.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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