Best approach: 3 versions of same digital product

[Peter Knight]

Hi

I understand many of you use Git and I've started to use it more lately in conjunction with Github and GitHub Desktop app.

I was wondering what the best approach might be when you've built something you're happy with but then want to create 2 furthers versions of this.

IE in terms of git and branches, would you create 2 further branches? Would you instead make 2 local clones of your repository?

Lets call these versions Basic, Better and Best.

My core product is a PHP page which pulls in JSON data. This Basic version is ready and I have a git repo and have been making commits to a branch called 'Dev'.

I now want to create a version with enhanced features which uses the same PHP and JSON files but is called:
Better and uses

• enhanced UI V2
• more JSON data
• introduces some basic imagery

Concurrently, I want to build Best which has

• enhanced UI V3
• more JSON data
• introduces photography

Thanks
P

 

 

 

 

[elabx]

I'd think if you want to bring updates from v1 further into v2, which could seem the case, then maybe a fork could be a good idea and have the possibility to update it from upstream. Although in my personal experience when my expectations where just like I mention, I have always ended up releasing the fork from its relationship with the upstream repo lol but alas, that's more of a me problem haha.

[bernhard]

I think I don't understand your question, because from how I understand you the answer what I'd do is to just create two commits.

• v1 / commit: initial version
• v2 / commit: make it better
• v3 / commit: make it best

But I guess that's not what you where asking for?

Or are you talking about release tags? Then have a read here: 

 

Or you could also create two or three branches. For example I have some modules that I can't update on some servers, but I had to develop them further for new projects. Then on older projects some issues arise, so what to do? You are on an old commit and the current development state of the module is 17 or whatever commits ahead. "git pull" is not an option, so you can create a new branch for the old version (eg "git checkout -b 'foo.com'" - which would create the branch foo.com) and push your updates there.

So you'd have a "main" branch with the module for all current projects and you'd have the "foo.com" branch for the stale project "foo.com"