git question: branch or tag? directory structure?

[sneakyimp]

I am doing my best to wade through O'Reilly's "Version Control with Git" but I'm still a bit short of the git awakening. I have a particular issue I need to sort out ASAP.

In particular, I have a website built on Joomla with a lot of modifications and I have a separate daemon-type project, both written in PHP. I'd like to store a snapshot of the Joomla source as it currently exists and call this snapshot V2. When I say "snapshot" I mean to say a frozen-in-time collection of files that will never change and I can always go back to it.

We have taken this code and published it to our V3 server where we expect to continue making changes to it. I am unsure whether to:
A) simply create a new repository for V3 on github
😎 simply create another directory inside the same repo that stores the V2 code like so:

repo-directory
--V2
----[source code for V2 here]
--V3
----[source code for V3 (mostly identical to V2) here]

C) Use git branch to branch the code in the repo for development of our V3 codebase. I'm still struggling with the concept of branching a bit and kind of half-understand that two branches of a code project may result in radically different directory structures or something.

I would then need to repeat the same question for how to deal with our V4 code. The V4 design will involve us migrating away from Joomla to an entirely different framework (which is being discussed in a thread elsewhere) so V4 development will likely be quite different than our V3 code but there will be a lot of file assets, etc. that are actually shared between the two versions.

If anyone could suggest a good approach to start this off, I would be greatly appreciative.

[sneakyimp]

For anyone else who is interested, this page is very helpful. In particular, this comment seems edifying:

Switching branches changes files in your working directory
It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all.

I'm starting to think I should just check in my V2 code to the root level of the repo and add a tag of "V2" and then continue development on V3 as the master branch. I am, however, questioning the wisdom of attempting to branch V4 off of the V3 tree because I expect V4 to be a pretty radical redesign.

Thoughts, anecdotes are welcome.

[laserlight]

Since you say that it will never change, a tag sounds reasonable. However, where versioning is concerned, you might want to make a tiny bugfix without having to bring V3 into production before it is ready. As such, a branch would probably be better.

The switching of branches is mainly problematic when you have made changes to the working tree without commiting. In such a case, you can either commit, reset, or stash, then switch branches.

[sneakyimp]

Thanks for your response. Always appreciated.

laserlight;11044271 wrote:

Since you say that it will never change, a tag sounds reasonable. However, where versioning is concerned, you might want to make a tiny bugfix without having to bring V3 into production before it is ready. As such, a branch would probably be better.

Agreed. I went to the #git IRC channel on freenode and asked around and your statement agrees with the help I got from those folks. They made some very helpful points:

romanovic wrote:

it is considered best practice to make the master branch always match your production version, exactly

There was some disagreement about which branch needs to match one's production system:

MotherMGA wrote:

I normally use master=bleeding edge and have a release branch that I merge from master once it has been QAed and then I tag off my release branches

But it was generally agreed that one should have one branch match exactly the code that you have running on your production system:

MotherMGA wrote:

MotherMGA re romanovic: there are two opposing views on whether master is bleeding edge, or production. It doesn't really matter as long as you have a branch that is always production.

romanovic wrote:

agreed

I therefore ended up taking my V2 source code and checking it into the master branch. I then created a branch called v2 which I will probably never touch but which is there just in case we need to for some unforeseen reason. Branches are cheap (41 bytes?) and more flexible than a tag. I also created a v3-production branch which I intend to match EXACTLY what is running on my V3 server. The idea being that if we discover a problem on the server, we can create a branch from v3-production to fix the bug and then merge it back into v3-production and then establish a mechanism to deploy the v3-production branch directly to the server via some automated process. We will use master for development, which is probably easier to get my collaborator started because the default branch used if none is specified is master.

laserlight;11044271 wrote:

The switching of branches is mainly problematic when you have made changes to the working tree without commiting. In such a case, you can either commit, reset, or stash, then switch branches.

Before yesterday, I would have been baffled by this statement but I have begun to understand. A git repo may have multiple branches with totally different contents and you can switch from one branch to the other and git will handle creating/deleting the appropriate files, possibly destroying changes you have made if you switch before saving them somewhere. Basically, using a git checkout some-other-branch command will cause your git working directory to add/remove files so that it reflects the state of the file system in some-other-branch. Realizing this is the turning point I think. I still have questions occasionally about merging and such, but I think I'm starting to get the hang of it.

[laserlight]

sneakyimp wrote:

A git repo may have multiple branches with totally different contents and you can switch from one branch to the other and git will handle creating/deleting the appropriate files

That is not really accurate though. You could read: Git bare vs. non-bare repositories.

[Bonesnap]

I have also been trying to get with the "git awakening" over the last few weeks. I have been vocal about it at my job since we don't use any version/source control... We used to use TortoiseSVN a long time ago, but it was never used properly, and was subsequently abandoned when we rebuilt our internal server.

Since my only experience with source control was with TortoiseSVN, relearning some of the terminology (like commit) with git was a little challenging. I spent about a weekend and then some just watching tutorials and other videos on Youtube. I signed up with Bitbucket (unlimited private repositories for free - in case you didn't want to spend money for private repositories with github). I have ran into some issues with the way branches are being tracked, but haven't had the time yet to fully investigate them. I've thought about heading over to /r/git on reddit and asking there.

I definitely like the git approach (especially the master/development/feature branching method), but getting there will take some time. I have a feeling that once it "clicks", I'll never want to go back.

[laserlight]

Bonesnap wrote:

I signed up with Bitbucket (unlimited private repositories for free - in case you didn't want to spend money for private repositories with github).

Truth be told, other than to access old repositories, I have stopped using Bazaar precisely because the popular code hosting services never got round to supporting it. Sad, but that's the way it works: if your tool does not have traction, it will eventually fade away. That said, I was using Bazaar with a workflow similiar to how I use Git now, i.e., switching around a single working tree with feature branches.

[Derokorian]

Bonesnap;11044303 wrote:

I signed up with Bitbucket (unlimited private repositories for free - in case you didn't want to spend money for private repositories with github).

Thank you for this wonderful piece of information!

Edit: Is there a way to transfer my private repos from github to bitbucket, hopefully without making them public to move them? I'd like to keep the whole change log, which seems possible when I imported a public repo. I tried, it asked for username and password but it didn't work.

[Derokorian]

I figured it out, it works if you don't use 2-factor authentication. Thanks again 🙂

[laserlight]

Well, glad that a transfer from GitHub to Bitbucket worked for you (I use Bitbucket too), but I note that since the repositories should have been on your local computer too, you could have pushed them to Bitbucket directly then just changed the tracked repository with git remote.