My main role at iWeb is development and maintenance on some of the company’s older legacy websites. Many of these websites were written before we started using version control (VC) seriously and so they either don’t exist in VC at all, or have only been added recently. Often a codebase will go untouched for a few years until a new feature is added, a client discovers an issue/bug with the code or a server upgrade causes something to break. When I do need to work on the code I simply don’t know if what’s on the server is the same as in our repository – or if it is version controlled at all.
Initially I log in to the server (via Secure Shell (SSH), naturally) and check the git status:
If the site was ever set up in a repository and also deployed using git then we’re good to go. Next step is to check which remote repository the codebase is tracking. To do this I use the remote command:
git remote -v origin firstname.lastname@example.org:path-to/project.git (fetch) origin email@example.com:path-to/project.git (push)
This will show the fetch and push repositories this branch is tracking.
Adding and removing git remotes
A while ago we changed our Gitlab repository addresses and some of these older websites still track the old address. If I need to change this I need to remove the original ones and add the new one:
git remote rm origin git remote add origin firstname.lastname@example.org:path-to/project.git
Once this is done we then check the status of the repository:
Often I will find a huge list of files that have either been changed or not committed. After checking the list over I either commit any changed files and push, or simply delete the .git folder, delete the repository an start from scratch.
Creating a git repo from existing files
If there has never been a repository set up for the current website I go ahead and create one on our Gitlab install and initialise the repository on the remote server. I usually take a good look at the filesystem to determine what should be in the repo and what shouldn’t. Anything that shouldn’t be there goes into a
.gitignore file. Then I set up the repo:
git init . git add . git remote add origin email@example.com:path-to/project.git git commit -m "Initial Commit" git push origin master
Now that the website is version controlled I can then begin working on it.
My Development Workflow
Once the project is safely version controlled in our Gitlab repository I can then begin working on it.
The first step is to checkout a copy of the repository on my local machine:
git clone firstname.lastname@example.org:path-to/project.git
Cool! I can now start developing.
My workflow is based on VirtualBox and Vagrant. I generally work on a single VM with multiple websites running from it and the initial install/provisioning of the box was created using Juan Treminio‘s awesome puphphet.com.
For any new websites I simply add a new Apache virtualhost to the Puppet scripts generated by Puphpet and then run vagrant with the provision command:
vagrant up --provision
(Note: If the VM is already running you can simply run
Once the VM is up I log-in (using
vagrant ssh) and set up the database and fix any other issues that crop up. I then set my local machine’s host file to point the website’s domain name to the VM. Other people in the company have different solutions to this but I find the hosts file hack to be easy and flexible. I use a Chrome extension called Website IP which places the IP of the current website in the bottom right of the browser so I can easily tell if I’m using the live server or the VM.
How I use Git on a project
Finally, I’m ready to start work.
Firstly, I have a simple rule when working on a version controlled project:
NEVER WORK ON MASTER!
I’ve been caught out many times by starting development on the master branch, only to find I need to make another change and push that change live first. Working on master would mean I would either have to commit my current (usually unfinished) work, or git stash it and then unstash. This is messy.
Better to create a new branch for each piece of work needed, even if it is a simple text change. I often use a combination of a job type (change, feature, bugfix), the ticket ID and a brief description of the work.
git checkout -b fix/t35-cart-add-ie-fix Switched to a new branch 'fix/t35-cart-add-ie-fix'
I do my work on that branch, test it works and then commit:
git commit -am "Fixed JS on add to cart to work with older IE browsers"
Switch to master:
git checkout master
Pull on master (just in case someone else pushed new work):
git pull origin master
Merge the branch with master:
git merge fix/t35-cart-add-ie-fix
Push to the remote master branch:
git push origin master
Then delete the branch. This is optional.
git branch -d fix/t35-cart-add-ie-fix // 'soft' delete git branch -D fix/t35-cart-add-ie-fix // Full removal
Finally I log-in to the remote server and pull the latest changes:
git pull origin master
from Andrew McCombe How I use Git to work on projects at work.