Git: How to maintain two branches of a project and merge only shared data?
Asked Answered
Q

4

3

Suppose I have two branches of a project IMClient-MacOS and IMClient-Windows, and their code only differs by (let's say) one directory main/. All the other directories contain system-independent code and are interchangeable.

Some workers work on the Windows version, and some work on the MacOS version. How do they prevent overwriting changing into the main/ directory when they merge from their counterparts' branch? Is there a way to merge in Git that will always ignore the OS-dependent directory?

Quillen answered 10/1, 2009 at 16:5 Comment(0)
F
7

You can probably solve your problem with git, but your life will be vastly simpler if you put the system-dependent code in different directories and deal with the cross-platform dependencies in the build system (Makefiles or whatever you use). Or is there some good reason I've overlooked to have code from different systems share one directory?

Flinn answered 10/1, 2009 at 19:9 Comment(3)
You can do this in git with cherry picking, but that taxes the developers to keep an eye on each others branches. This alternative is much better as in to keep system dependent code as seperate as you can (put in seperate directories, namespaces, switches, etc) and let automatic builds do the rest.Libenson
In Git, it doesn't matter whether the code shares the same directory or not. This is a good answer if you're using SVN. See gitster's answer.Adigranth
though gitster's answer is good, Norman is not talking about using folders for branches as in SVN, @Paul. It's just structuring folders inside the GIT project to separate what Jake wants, rather than using branches. Makes sense for Jake's usage.Jedediah
B
6

Do not use just one branch per platform (windows and mac).

Instead, have at least three branches: Generic, windows and mac. The generic branch does not have any system dependent code, and a platform branch does not have any generic code, hence none of the branches will build by itself. Instead, a mac developer always creates a throw-away branch that is a merge between generic and mac in order to build.

Then, develop and commit generic features to generic branch, with associated platform support code on platform branches.

Even better would be to have a single codebase that will be buildable on both platforms by the build system (makefile variables and conditional compilation). Then a mac developer will add a generic feature and platform support code for the new feature only for mac while adding a non-working stub for other platforms, and hand the result to developers on other platforms to fill in the stubs.

Buke answered 11/1, 2009 at 7:52 Comment(1)
Exactly! Structuring the codebase these ways supports collaboration on the project by the separate teams, without them stepping on each other's code.Adigranth
S
2

An alternative to trying to filter merges would be to split the common and OS-specific parts into two repositories. You can then set up the one as a submodule for the other. Whether to have the common part set up as a submodule of the OS specific parts, or the other way around probably depends a bit on where do most of the commits go.

Skip answered 10/1, 2009 at 19:1 Comment(0)
K
1

There's an option for ignore the whole file or directory structure, but then those file won't get added to the repo at all. I think you already know that, by using .gitignore file

What I think is having a separate branch for Windows and OS X's code, as you said. Then you'll merge the change by cherry-picking the code from the other branch (the syntax is git cherry-pick refspec) However, those developers should always watch for a 'change' on other os's branch.

I would also suggest that always make a separate commit for files in main, so that it won't be mix-up when you're cherry-picking the branch.

Kimbra answered 10/1, 2009 at 18:34 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.