GIt Workflow dev and production - where should I create the repos?

Question

I've read somewhere* a setup like this would be nice:

Two main branches, one for each server.

Pushing to master sends changes on to live;

Pushing to dev/stage (or whatever you call it) sends changes to staging;

Workflow:

• Create branch from dev;

• work locally until you're ready to test;

• merge back to dev;

• push to Hub, which sends changes to dev/staging server.

Once you're ready with those to go live:

• merge from dev to master,

• then push master to Hub, which sends those changes on to the live server.

Two main branches, one for each server.

So I have one branch "production" on "webroot/myliveapp/" and another branch "development" on "webroot/devapp/"

Where should the repository be ?

UPDATE:

I mean:

We will have, according to this flow:

• Prime repo;

• Bare repo hub;

• Clones;

The development and production branches should belong to one repository, right ?

If this is correct, then were should we issue the FIRST git init command ? On our Prime repo ?

So we will have:

"webroot/myliveapp/" - production branch;

"webroot/devapp/" - development branch;

"webroot/.git" - Prime repository;

Does this make sense ?

Or should the Prime repository correspond to our production branch location ?

*Note: if you need a context about what workflow I'm trying to implement, is this one: http://joemaller.com/990/a-web-focused-git-workflow/

Answer 1

Thanks for the update on your question, it is more clear now.

I believe the problem you're having is based on a misunderstanding of Git workflow; Git doesn't equate directories to branches, it equates a view of your filesystem to branches. This is powerful - but easy to shoot yourself in the foot. Let me explain.

Git acts more like a database-backed, differentially-versioned, history tracking filesystem in itself. It is "above" your filesystem, not "part of" it. It doesn't use your filesystem to represent branches, rather, when you check out a different branch, all the files in your filesystem will change to be the files in that branch. You are asking Git to make your filesystem represent the alternate reality of that branch.

If you are on branch master, and it has a file root/foo.txt committed, and you check out branch experiment, which does not have root/foo.txt committed, you will find that file gone when you look for it. It is a part of master, not experiment, and so it is not present in your filesystem. This is why Git is really picky about your current branch being committed before it lets you switch branches - if you have unstaged changes on your filesystem that Git doesn't know about, it refuses to blow them away by overwriting them with a different reality. You have to intervene to make things right first.

So, to answer the quesiton, don't create subdirectories for "myliveapp" and "devapp" - create different branches. Just have your one codebase under "webroot". Then, hack away on, say, the "unstable" branch, committing your changes as usual. You can then switch all of the files in your repository to be at the version of your dev server's files by switching to the "devapp" branch, and you can similarly switch back to "unstable" at any time.

When you want to update a branch, e.g. doing an update of your dev server, you can merge "unstable" into "devapp". This will make all of the files of "devapp" look like those of "unstable", bringing it up to date.

One other thing to note: the difference between a prime repo, a bare repo, and clones is almost nil. There is virtually no difference in the software; rather, it's a human convention to say "Linus' kernel is the canonical Linux kernel". With that understanding:

• A prime repo is just one repository that everyone agrees holds the "canonical" version of the software. That is, whenever a developer has made a change they want everyone to see, rather than saying, "Pull my version of devapp", they can say, "I've published my changes to our prime repo." It's simply an easy convention for people to rally around.
• A clone is a copy of some other repo. I could clone the prime repo, make changes, and then you can clone my repo. If you make changes, you can push them either onto the prime repo or onto mine, as long as the merge is valid and you have permissions on the computer.
• A bare repo simply has no "working copy" - there is no "webroot" directory on that computer. It's empty with only the .git directory - which is fine for servers where nobody needs to alter the files.

Finally, the .git dir doesn't hold the files of your repo, it holds the git configuration and database. It's your entire repository history in database form, which is used to populate the rest of the repo with a particular version of your software. That's why I made the comment: you can locally check out any version of any alternate reality of the repository, with no network communication, at any time - because it's all there in the .git dir. The only network communication necessary is for when you want to sync your local repository to some other repository, using push or pull.