I’m very new in using GIT as a versioning system and despite a lot of searches, I can’t seem to really understand how to handle my scenario.
I have this web project that needs to be developed in two versions:
- the first is a general version used for demos
- the second is a customized version for my client.
As for now, the second versions differs in minor things, mainly branding (i.e. icons, some titles) and database connections.
The idea is to enhance its code with suggestions and real use cases provided by the client and, as we progress with bugfixes and new features, port the changes to the “general/unbranded version” – but keeping those minor differences.
In the future the “general” version could be forked and enhanced more with some independent features.
Are branches an useful way to deal with this scenario? I think they’re not, as (at least so I understood) they’re more meant to make changes to be merged back in short- or mid-term.
Take a look here:
https://stackoverflow.com/questions/19840921/override-configured-user-for-a-single-git-commit/19841122#19841122
Although the question is somewhat different, the answers provided by myself and others explain how you can create 2 separate/local git versions of the same system.
Based on what you’re trying to do, I would think of a “Master/Slave” scenario, where the demo (=Master) is where most of the work will be done. You can then fork over the demo into a separate folder and run git on that, where you can do work on it (meaning a you will need to see .git in each custom folder where work is being done)
Now when you do updates to the demo and would like to see these updates in your “slave” custom work, you will need to merge the new “master” with the “slave” on the custom-work(=slave) folder.
That way:
- The demo project always remains a demo
- Custom work is kept separate
- You can create as many different customs as you like, each with their
own version control - You can merge updated demo work to each custom,
without mixing up the core demo (you need to remember and learn how
to merge onto the slave)
Take a look at this video for using git: http://vimeo.com/46010208
Somebody once referred it to me for learning git and I found it very useful, that is why I am referring it to you.
1
Push/pull and forking…
Having thought about this for a while, I believe that “forking” pattern – with a push/pull system for specific features you wish to migrate – might be your best option.
It is this pattern that is used by large open source communities to have a single ‘master’ (official copy?) and many many development branches/repos etc.
It is possible to do this using only git (eg adding an upstream remote and also this). It is extremely easy to do it within Github however, so for simplicity I shall describe only the Github workflow.
Setup:
- You create your ‘master’ repository
- this is your ‘polished’ / ‘demo copy
- You ‘fork’ this repository
- this is your ‘development’ copy
Development workflow:
You develop in this second repository, and then when you are ready to “push” features to your ‘demo’ repository, you can submit a pull request from your development repo (containing the desired changes) to your demo repo.
Branches?
This can all be done via branches however, in my mind at least, I prefer to keep the two much more distinct.