Old School Part Time Procedural PHP Dev here - Trying to figure out how to implement Git into my projects.
 

I build a lot of web based tools that aren't exposed to the internet that work with databases.

I come from the era where a lot of the tooling that modern development uses wasn't common place. If you wanted a tool that did something specific, you often built it yourself.

With that said, I'm trying to break away from this habit and get comfortable with Git. Git itself seems pretty straight forward, what I'm unsure of is how to actually use it in my day to day.

Most of my servers are setup using three sub domains, live.domain, dev.domain, test.domain. I have tools that that will rsync the roots or databases of each subdomain to and from the other. I do my development on the dev.domain, then I will sync the live.domain to the test.domain, then move my changes into the test.domain, and if all is good, I move those updates to the live.domain. Backups are taken regularly.

All three of the subdomains reside on the same physical machine and I do my editing and programming directly on the dev.domain, I do not have a local environment and I'd like it to stay this way.

So my question, how do I incorporate Git into this kind of setup? Is it even compatible? What changes would I need to make? What would my programming flow be like for new features or bug fixes? I'm open to ideas.

Edit: I forgot to mention the main reason for trying to switch to Git is so I can work on multiple features at the same time and have a system that clearly lays out conflicts between the features.

 

One of the benefits of Git is how it can be adapted to any workflow.

If you try and introduce a new tool and a new workflow, it's two things to learn, and if you picked a workflow that doesn't work well for you, it'll just be frustrating, and make it harder to learn Git.

So better to mostly stick with your current system for the time being, which is effectively a single branch with rsync replaced by git push/pull. You might also want to consider using Git just between your dev/test environments, and sticking to what you currently know and do with the live environment until you're more comfortable.


To get the current code into Git repos, there's no way around reading docs to figure out what commands/options do, but some pointers...

Convert one of the directories to a git repo, using "git init" one of the directories, adjust the ".git/config" and ".git/info/excludes" files as necessary, then "git commit --all -m 'Initial commit'" to store the initial files.

To setup a second repo, the standard method is to clone - but you already have the files there and can't clone into a non-empty directory, so instead you can manually copy the ".git" directory to the second location (using rsync or scp), and then you'll then be able to use git status to see if there are any differences, which you can commit or revert accordingly.

(If the .git directory would reside inside a public webroot, you'll probably want to first configure any live servers to block such paths, if they don't do it by default.)

Once you have both/all directories as repos, connect them with "git remote add NAME PATH" (on each repo) and use "git fetch" to sync changes, and "git status" will say you're up to date, and "gitk --all &" will tag the first commit with the remotes.

Whilst learning Git, I would occasionally zip entire directories before doing push/pull/merge operations so if I screwed up I could easily copy everything back - e.g. "tar -cvzf ~/backups/reponame_timestamp.tgz /path/to/repo" - though I don't recall if I ever needed those backups, since most situations can be recovered, but it can be reassuring to have an escape plan.


After you've worked with Git for a while, then you can decide if it makes sense to try out a more structured workflow, such as using feature branches or whatever.

You can use “rsync.” Or, you can clone the repo on the other machines, “git pull,” and then “checkout” the latest revision. Typically, I just sync.

“git” is very easy to use for local development because it doesn’t involve “a server.” Everything is done with local files.

I forgot to mention the main reason for trying to switch to Git is so I can work on multiple features at the same time and have a system that clearly lays out conflicts between the features.

I have updated my main post.

Basically instead of just dev.domain, I want to "essentially" be able to have dev-featurename.domain, dev-featurename2.domain, I am confused how Git would work in this scenario.

The most obvious thing to me is to somehow be able to symlink an entire directory containing the feature branches into dev.domain which makes me feel like I'm not really utilizing Git in the way it's meant to be used. It seems like Git is most commonly used with local environments, that makes total sense to me.

Btw, really appreciate the responses guys. Thank you.

 

In that case, go with a branch per major feature.

Git Flow can provide useful structure. It can also be excessive bureaucracy for an individual, but understanding the reasoning allows one to come up with something more suitable.

Don't waste time trying to do wildcard/arbitary domains - just switch branch depending on what you're currently working on. If you really must work on different branches in tandem, having primary and secondary dev repos (with static domains) might be worthwhile, but trying to deal with more than that will rapidly send one round the bend.