Next Steps with Git: Establishing a Cohesive Work Flow

Question

I am new to git and distributed version control but have managed, without much stumbling, to init my own local source, setup a private remote repository (origin) via ssh on my own web host, and do the basic pull and push from master to origin. (I even testing a clone!)

I think I have the single-direction, git work flow under control. Now, however, I'm starting to think about how I handle moving things between development, beta, and production. Most tutorials I've found talk about different users merging and cloning and pulling and pushing, but in my case, it's just me, handling things from different sources.

Am hoping an experienced git user could provide some insight into my work flow and provide some suggestions on how they would handle merging, branches, etc (things I am not too familiar/comfortable with, yet).

Here are the different machines/locations I will have:

1. Remote main git store: ssh://[email protected]/git/myproject.git
2. Home web server, main development box (where I sit, privately, and do most of the work)
3. Remote web server, beta testing (public facing): http://beta.example.com (test my dev work before production)
4. Remote web server, production site: http://example.com (where real people, hopefully, use the site)
5. (Occasionally) traveling around on a laptop (running its own local web server).

How would you handle this? Thanks in advance.

Answer 1

i don't see a point in creating a overly complicated work flow here, a "central" setup will do just fine IMHO.

so you have a main remote which should be your central point that holds all the development, remote name "origin". you work on your devel box, do your commits and from time to time you push your stuff to "origin". once you think it's time for a release you tag your stuff (probably as beta), push it to origin, go to your beta server and pull that tag from there for public testing. repeat until you have a release that you can pull to your production machine ...

regarding your A/B question (probably your devel machine and laptop): of course that can be done but not by simply pushing your changes from A or B into origin. Lets assume you just pushed your work on machine A to "origin", lets call that state "17". Now your work further, creating local states "18" to "20". If "origin" is still at "17" you can push your changes 18-20 to origin without problems as each step is a direct descendant of the previous state. thats called a "fast forward" in git.

However, if a push from B comes in between, then the line of "direct descendants" is broken, and a push from A would fail. The solution is simple, though: A has to pull from origin, merging all changes introduced by B into A, and then it can push ...

hope that clarifies things ..

Answer 2

If you're working by yourself then you don't really ever have to branch or merge if you don't want to. Git just makes doing so a little easier than some other version control systems, so you can use branches the way you might use tags elsewhere. I'd strongly recommend the O'Reilly book on the subject--it's pretty well written.

Answer 3

Yes, it can handle a change from A, another from B, having both pushed. However, one of the two will have to pull from origin before it can push. Because one of the two would be "out of date" with origin, because the other had pushed to origin.