first basic git setup: solo dev, shared hosting, side project websites - how many repos, and which is main?

Question

tl;dr: correct way to add git to existing website project with dev subdomain on same shared hosting server?

I have some side project websites. They're all on shared hosting. I've never used version control on my side projects, instead I just created a subdomain for development (like dev.myproject.com) and copied updates as hotfixes to the live site. I want to keep that basic setup but add git into the mix.

So say I have two directories on my shared hosting: public_html and dev-myproject1. Both have complete sets of identical files, until I start making changes on dev. Once I'm done with changes on dev, I copy those changes to www.

What's the right way for me to set up git to bring version control into this workflow?

Do I git init my public_html folder and git clone from that into my dev-myproject1 folder? Or the other way around?

What's the minimum number of repos I need? Can I just use two, one for public_html and one for dev-project1?

This earlier question talks about needing uncompressed versions of files:

Is it possible for a Git branch to exist on the same server as the master branch?

Do I need separate additional folders for serving the actual websites to the public, or can public_html serve my files AND be a repository?

Seems like I could do this:

cd public_html
git init
git add .
git commit -m 'adding website project to git'

cd ~/dev-project1
git init
git clone ~/public_html
git add .
git commit

(make some changes to dev-project1 files)
git add .
git commit
git push ~/public_html

Is that correct - And is that the best way to do it?

FWIW:

I don't want to work locally. I want to keep doing all my work on the shared hosting server so I don't have to worry about environment differences.

I don't want to use an external repository hosting service like Github.

Thanks for helping me out on this.

Answer 1

You need to separate version control from deployment. The real challenge appears to be creating the initial git repository. You certainly do not need different repositories. You should only need one repository with different branches.

You basically have a "developer copy" and a "production copy."

Initially, create a single repository for each environment. You would create a repo for your "developer copy" and a separate repo for your "production copy". After that, you need to merge the two master branches together, with your developer copy being considered the "new" changes.

I'm assuming ~/public_html is your production copy.

cd ~/dev-project1
git init .
git add .
git commit -m "Initial commit for development."

cd ~/public_html
git init .
git add .
git commit -m "Initial commit for production."
git tag v1.0.0
git remote add dev ~/dev-project1/.git
git fetch dev
git merge dev/master --allow-unrelated-histories
# Resolve merge conflicts, commit.
git remote add origin https://github.com/user/repo # <-- or wherever you want to push this
git push origin -u HEAD

Basically you start your git repo out with the production version, and merge the development version over top of the production version. Create tags in Git for each production release.

Now you can delete your developer copy and re-clone it:

rm -rf ~/dev-project1
git clone https://github.com/user/repo ~/dev-project1
cd ~/dev-project1
# Edit files, commit. Push.

Don't be afraid to use branches in Git. Not everything has to be done on master.

After that, deploy to your production server. The deployment could be a shell script, or simply pull and check out a tag:

cd ~/public_html
git fetch
git checkout v2.0.0

Answer 2

There are a few different concepts which you're muddling here. Admittedly, git deliberately muddles some of them, but the distinction still exists in practice.

• A repository is a source of truth for the history of some project. The project might be as wide as "Facebook", or as narrow as "Facebook privacy settings UI", depending on how you want to structure your code.
• A branch is any of several parallel versions of the same project, within the same repository. For instance, one branch might represent the live website, one an experimental redesign, etc. In git, branches are "cheap", so it's common to also have temporary branches for individual changes like "update copyright notice", just as part of the development workflow.
• A working copy is a set of files "checked out" from a repository, based on a particular branch. You make your changes in the working copy, commit them, and (in a distributed system like git) "push" them to the central repository. You could also use a working copy to serve the live website, although it's more common to export a particular version for this, without the extra metadata needed to commit changes back.
• In git, every working copy is technically also its own repository - you "clone" some other copy to begin work. However, in practice most people work with a single central repository, and local working copies are all cloned from there.

In your example, it sounds like what you primarily have is a single project, which would naturally be a single repository; and two branches, one live and one for development. When you are happy with the state of the "development" branch, you would merge it to the "live" branch.

The central repository would not normally also be serving files; it might be on a third-party service like GitHub or GitLab, or it might just be a different directory. The sub-domains would just act as working copies pointing to that source of truth.