Artisan
Artisan

Reputation: 4112

How to use git to manage 2 separated production versions?

I'm about to use git to help me with my new project, but I don't know how to design it.

Let's say I have a master coding, and I decide to have 2 separated UI based on master coding so I create 2 brand new branches.

  1. What do I do, If finally I would like to end up with 2 production versions?, most examples teach to merge each to master and delete the branch after the merge, but I want to end up with 2 production versions.

  2. If I changed some coding in the master while develop those 2 branches, the 2 branches will notice the changes automatically? or I have to do anything in git?

Thanks.

Upvotes: 0

Views: 290

Answers (3)

gpupo
gpupo

Reputation: 982

git checkout -b core; //Shared code
git checkout -b projectFoo;
git checkout -b projectBar;

git checkout core;
// core like a boss....
git add .;
git commit -am 'shared commit';

git checkout projectFoo;
git rebase core;

git checkout projectBar;
git rebase core;

Upvotes: 1

Paul Rubel
Paul Rubel

Reputation: 27222

There's nothing special about the name "master". You can have your two UI branches and a "master" branch where the UI ones are what you'd call production versions . If you want to get the changes from master you'd just make your changes there and then change to a UI branch and do a merge of master into that UI branch.

git checkout UI1
git merge master
git checkout UI2
git merge master

Regarding question 2, they won't automatically notice and update. You need to do that yourself. This is actually a feature so that your "production" branches don't break every time someone introduces a not-sufficiently-tested change the the branch that feeds into production.

Upvotes: 2

poke
poke

Reputation: 387677

You can just keep the branches around. It’s totally fine to have some kind of “common” branch, where you develop things that are common to both production versions, and then two production branches where each version is maintained.

Whenever you change something in the common/master branch then, the production branches are not automatically affected, as they are still based on an older version of the master branch. So if you want to enable the changes from master in those branches too (which may or may not require some additional production-specific changes anyway; so automatic is not always good), then you can just merge master into your production branches (i.e. when on your production branch, use git merge master to merge all changes from master into your current production branch).

Upvotes: 2

Related Questions