• 9
• 10
• 10
• 11
• 17

# Git Usage: Multiple Versions And Platform Builds

This topic is 622 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello forum!

Currently, I'm trying to get my head around using Git (BitBucket, if that even matters).

However, I have a few questions on how to cleanly invoke my current project into Git.

How would I organise multiple versions? Branches seem wrong for that, as they strive for the purpose of eventually being merged.

On the other side, alpha and stable version seem branchable, as the alpha can be merged to the stable branch in the end?

But where would I store my old stable version?

Another point that keeps me a bit confused is, how do I structure multiple builds for different platforms (e.g. Windows, Linux, ..).?

Well, I could of course provide file_windows and file_linux, but that would end up in ugly checking for what kind of operating system I'm currently using while compiling/building.

Therefore, should I maintain one rep for every OS? That sounds weird, as it would stray apart the project. Just imagining what happens when I have x more projects supporting y different platforms... that would result in a mess.

If you have nice tools, tips or example Git reps, I would be really thankful!

Though, if you link a Git rep example, I would appreciate a brief explanation of what actually is done there / is to look at in particular - elaborate on the strategies used. That would really help me I assume : )

I'm using Windows 7, Visual Studio. I compile my code and then it gets pushed to my Git utilising the "Team Explorer". That is pretty much what my current work-progress is yet.

##### Share on other sites

When you say multiple versions, you mean that you want to check-point a particular release so that you can get back to it, correct? For example, you want to be able to get back version 1.0.0 to fix a critical bug and release it as 1.0.1 -- but in the meantime you want to be free to continue working on new features to be released in version 1.1.0?

What you probably want for that are called tags -- its just a point in your project history that you tag with a friendly name like "version 1.0.0" -- you can continue working towards 1.1.0 in 'master' (or on your developer branch, depending on the workflow you've adopted), but you can always go back to "version 1.0.0" and branch off bug fixes from there. If the bug fix needs to be applied to both version 1.0.0 (because you have customers using the software already that need the fix) and version 1.1.0 then you have some different options depending on what else has gone on in your 1.1.0 code, but its beyond the scope of what you're asking (just know you can make fixes in one version and selectively pull them into another). Anyways, if the fix only applies to 'version 1.0.0' then you just maintain an separate development branch for that version parallel to the version you're actively developing -- IMO, you want to tag proper releases 'version 1.0.0' and keep another tag that tracks the most-current release of version 1.0, something like 'version 1.0.current'.

If you're going to start seriously tracking multiple versions, do yourself a favor and adopt something like Semantic Versioning -- If not semantic versioning itself, then take a look at the thought behind it and come up with a versioning scheme that will be similarly consistent and works with your circumstances (it looks to me that semantic versioning is defined relative to APIs/web services, but the reasoning behind it transfers mostly-laterally to applications themselves (after all, what is a closed application if not an internal-facing API?)

Regarding multiple platform targets, you definitely don't want a separate repository for each platform -- that would be a nightmare to maintain. It might sound difficult to "provide file_windows and file_linux, but that would end up in ugly checking for what kind of operating system I'm currently using while compiling/building" but that's exactly what Build systems like Make are for. A tool like Make basically lets you define different targets (which might include a different set of files and directories, or define different pre-processor symbols to direct conditional compilation) and then builds the target. Configuring Make is done with a kind of mini programming language all its own--its something more to learn, but its a good skill to have.

What I usually do is have separate folders for each platform's specific code -- 'win32', 'linux', 'macos' -- and then I define a Make variable that gets set to the correct platform based on the target -- so instead of telling Make to build "win32/windowing.cpp" directly just like that, my Makefile defines the release target to effectively say "build $PLATFORM/windowing.cpp". The release target doesn't get built directly, it only gets run by (or after) a platform-specific target that sets the$PLATFORM variable correctly. Depending on how your code is structured your approach may need to be more elaborate, but the basic idea is the same -- but this approach more or less works as-is if you have a clearly defined abstraction layer that all platforms share.

##### Share on other sites

Oh! Sorry, I think I've been unclear when I was talking about:

Well, I could of course provide file_windows and file_linux, but that would end up in ugly checking for what kind of operating system I'm currently using

First, just for the record, I'm using C++. I was talking about ifdef-switches - once you mentioned using C/Make "switches", I realised that this would make more sense to use.

Thanks a lot for your elaboration! It made things clearer for me : )

Edited by Angelic Ice