Understanding Git and The Development Server
If you don't have any experience with Git, we recommend checking out this [tutorial] (https://www.atlassian.com/git/tutorials/what-is-version-control) for a comprehensive understanding. And some practice. It is essential that you know Git well. And make sure you already have Git installed before you do anything on your local machine!
Cam2 is developed and hosted on machines running Ubuntu 14.04 LTS and thus it is best to have access to this OS on your personal machine. If you are unfamiliar with Linux and Ubuntu try reading this guide. If you already have Ubuntu or would prefer to use an SSH client on your machine to work, you can skip this section.
There are two ways you can access Ubuntu, through a virtual machine like Virtual Box or VMWare or by dual booting Ubuntu alongside your current OS. Dual booting means that Ubuntu will be running natively on your machine's hardware and using it will likely be faster and smoother than using a virtual machine. If you are running Windows 7 or 8, follow this really straightforward guide to dual boot Ubuntu 14.04 and you will be up and running in no time. This is the setup your author uses. Mac OS X does not technically support booting Linux with Boot Camp but you can find a guide for how to do this here.
Your author has also used Virtual Box to run Ubuntu on Windows and it is fairly nice, although there are some steps you should take to make it as fast as possible. You can follow this guide from How-To Geek to get optimum performance.
Now that you are familiar with Git, we will setup a local repository and learn how to use it.
- On your local machine, navigate to or make a new directory and create a local repository.
git init
- Make a clone of the remote repository and you are ready.
git clone <SSH key or HTTPS>
- Diagram below illustrates the basic uses of pulls, adds, commits, and pushes.
Pull: Get the updated version on Github to your local machine. Note that Pulls and Pull Requests are different things.
Add: Adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn't really affect the repository in any significant way. Changes are not actually recorded until you run git commit.
Commit: Commits the staged snapshot to the project history.
Push: Transfer commits from your local repository to a remote repo and becomes visible to everyone.
Some general rules:
- If you're working on the same branch with few other people, first add and commit, then pull to fix merge conflicts on your end, and then finally push to remote repository.
- Do not keep branches to your own for more than a week. The longer it takes for you to merge, and more painful it gets to fix merge conflicts.
The diagram below explains everything that goes in between you writing code till cameras appearing on our CAM2 site!
- Now all the code that you and your team worked on should eventually be pushed to the development branch once they are considered bug-free and ready to be tested.
- Code from the development branch will be deployed to the development sever to be tested. If testing failed, do the fixing on GitHub and deploy once more to make sure GitHub is in sync with the server.
- Once code have been tested, data from output text files will be added to the camera database.
- When everything is ready, the development branch on GitHub will be merged to the master branch, and then deployed to the public server from the master branch, along with data from the database to make sure that GitHub is in sync with the public server.
Other general information:
- some old parsing scripts that no longer work could probably be due to changes on the websites
- cron runs on the public server periodically to check if existing links are working properly