1

What we are trying to do:

We are trying to use git to create an efficient development process as well as keep a current backup of our website. We have three machines in the loop:

  • production: Hosted on remote webserver - LAMP, git 2.0, centos
  • back-up: local workstation - windows, git Shell
  • development/testing: An on-site webserver - LAMP, git 2.0, centos 6

We want to clone a bare repository down from the Production server to my Workstation to keep a current backup.

I want to create development branches on my local machine to make changes to files which I want to pull into a repository on the Development/testing server. This way I can use this repository as the test step to merge things and be sure they work properly.

Once everything works I want to pull the new branch over to the Production server and merge to complete the update to the live site. Then once that is in place, the next backup would catch the last updates.

The Problem:

We have tried starting with a --bare repo on the production server and cloning it down to the other two machines. This works to get the repo on the machines, but doesn't pull any files that have been added and committed on the --bare repo. We also can't push changes up to the production server.

We have also tried just using git init on the production server, but the problem persists. We are using the following syntax:

git init <repo>   or   git init --bare <repo>
git add . 
git commit -m "message"
git clone ssh://user@server.com:/path/below/repo.git or repo/repo.git
git remote add <name> <repo>
git pull <remote>
git fetch <remote>

The Question:

Are we not using git properly as production tool, or are we making some syntactical or other error in using git?

mtrueblood
  • 414
  • 2
  • 11
  • 28
  • 1
    Maybe this helps? http://stackoverflow.com/questions/3382679/git-how-do-i-update-my-bare-repo . The great thing about distributed version control is that it is very flexible, though by the sounds of it, you are also using git as a way to deploy. I would instead have a dedicated build server to hold the source code, run tests and deploy. This can be a central repo where you can pull from to develop and then push to, to deploy - just like github or bitbucket. (checkout https://www.atlassian.com/git/tutorials/comparing-workflows/ for some ideas for basic workflows) – Joel Gregory Feb 16 '15 at 22:45
  • That question did help, but the atlassian workflow comparison was extraordinary. It really helped me define how I wanted to work and which setup to use. – mtrueblood Mar 10 '15 at 17:51

1 Answers1

1

GIT Workflow can be a confusing thing to set up. The important thing to understand is that git "push" and "pull" work with "remotes". You are best served with a single remote in a secure location (backups can be done separately using the '--mirror' option, but don't use it for committing).

Step one; Create a "bare" repo where all development will end up;

git init --base /path/to/repo/websiterepo.git       <- this is a bare repo..

Do not use the bare repo for ANYTHING except pushing to and pulling from. Dont manipulate it, don't "git add" or "git commit" to it and you will avoid damaging it.

Step two; Convert your web site to a git repo, and make the bare repo available for pushing and pulling;

cd /path/to/website
git init
git add .
git commit -m 'Initial Commit'
git remote add origin /path/to/repo/websiterepo.git
git push -u origin master:master

Step three; Create a "backup" on the "backup server"

cd /somewhere/safe
git clone --mirror user@website:/path/to/repo/wepsiterepo.git

(in future, use the following commands to refresh the backup)

cd /somewhere/safe/websiterepo.git
git remote update

Step four; Set up your DEV location

cd /home/me/websitedev
git clone user@website:/path/to/repo/websiterepo.git website
cd website
git checkout master
git checkout -b devbranch  <- work on dev branch
git add changes
git commit -m 'my changes'
git push -u origin devbranch:devbranch

Step five; Set up your TEST location

cd /home/me/websitedev
git clone user@website:/path/to/repo/websiterepo.git website
cd website
git checkout devbranch

Workflow..

  1. Make changes in /home/me/websitedev/website
  2. git add changes, git commit, git push (will push to devbranch)
  3. Got to test machine; git checkout master; git pull; git merge devbranch; performing testing (if git pull doesn't pull down devbranch changes, use git fetch --all)
  4. Update production repo; got push origin master:master
  5. Update production; git pull

I hope this helps.

Dave
  • 3,193
  • 1
  • 16
  • 14
  • This has already helped quite a bit, but I just want to make sure we have this right. The current _production_ server will have a **bare** repo in its own directory and a **regular** repo in public_html. Or are we supposed to have a _fourth_ machine that serves as the central repo? Sorry if I seem dense, just want to be sure we are understanding you well enough. – mtrueblood Feb 18 '15 at 14:27
  • That depends on resources. In a perfect world, you have a machine dedicated to git repositories which are all bare, and are only accessed via clone/push/pull. If you can't spare the fourth machine, there is no reason not to use your production machine. Personally if your production web site was internet facing, I would cite security reasons for moving the central git repository off the machine and out of (potential) harm's way. – Dave Feb 19 '15 at 20:42