DISCLAIMER: Expressed views on this blog are my own.
It appears my last post was somewhat well received, so I think I'll follow up with the things I did.
Imagine that you are me and you'd like to figure out how you imagine updating code from server to server. That's right version control is the first thing to come to mind. Well, which one should I pick? SVN? Git? CVS? Usually, i'd say SVN because TortoiseSVN makes it really simple to connect and update your repositories (refer to my SVN post), but I've been in the git mood, so I decided git would be the perfect option right now. Anyway, without further ado.
1. Install git-core on to your server with apt-get or yum or whatever package manager you have. If you don't want to do this on a server yet just download virtualbox or any other virtualization package and a linux distro.
2. Now you might want to add a new user or use your existing user. sudo adduser git or whatever name of your choosing. Run sudo passwd git to give it a password, unless you'd like to use Public/Private Key in that case means you have to configure ssh for that and add your public key from wherever you are going to be pushing data to your server into the authorized_keys file. Take the time to ssh user@server.com to see if it worked.
Issue you may face: The .ssh folder and authorized_keys file needs to be given certain permissions. sudo chmod 0700 on the .ssh folder and sudo chmod 0600 on authorized_keys file. If authorized_keys is a directory for some reason, rename the folder to something else and change the name of the file inside of it to authorized keys and move it out of that folder into the .ssh folder. Make sure you chmod it or else ssh will not authenticate!
3. You want to run git init in a project directory on your server. If you have a linux group like I do, then add --shared=group and use chgrp groupname ./reponame to change the group owner to your group. You may need to give write permission to the group.
4. Now you want to run git add . to add all of the files and then git commit -m "First commit!". This should have created the master branch.
5. Let's create a staging branch with git checkout -b staging. Now we should be in the staging branch. To go back to master, do git checkout master.
6. You can either create a staging directory somewhere or go to your staging server and do git clone gituser@server.com:projectname.git -b staging. Now you should have the staging branch only. Check with git branch.
7. Then you want to create a symlink to the .git folder in your staging project directory. ln -s /folder/to/staging_project/.git/ ~/home/git-user/projectname.git
Here you are creating a link to your staging directory because in the next steps you will be cloning from this and pushing to this area. I guess it would be more of a step 6.1 if that makes the relation clear.
8. Depending on what you did, if you have a staging server, you may have to do all of that user/ssh stuff again if you have not already. I will assume you have a staging directory on the same server as the production. Create a dev branch in the staging area.
9. Do git clone of the dev branch onto your development machine (remember the directory from step 7?). You should be able to make changes, add, commit, and push.
10. Now we'd like to push changes to the staging. Once you have a dev branch in your staging area, you can easily push upstream, since your staging area will always be on the staging branch. Once changes are pushed to the dev branch from your dev machine, you can do git merge dev to get changes from the dev branch.
11. To update the general repository's staging branch, do git push -u. This should update your staging area.
12. Okay, good let's push up the changes to master. Same process from step 10, except we replace dev with staging.
Hopefully, this works. Any errors? Just email me and I'll try to help.
