If you want one technical skill that every employer looks for, it's experience using source control. They specifically look for experience with:
- git, an application that you use to track and manage changes to code
- a cloud service that lets you store git repositories (repos) on the Internet for backup and easy access by your team and the client
Versions of git exist for Linux, Windows, and MacOS.
The most popular cloud services are github, Bitbucket and GitLab. Numerous comparisons of the three exist. Be sure to look at recent comparisons, as services compete and change features frequently. Also, be skeptical of comparisons that come down strongly on one side, since all three services are good for different situations.
In my classes, I use github because it's very stable, easy to manage for classes, and private repositories are not a major requirement.
If your client for the client project wants a private repo, their best option is for them to purchase a private Github micro repo. These are cheaper than Bitbucket. This way, the client owns the repo and maintains control when the project ends. If the client does this, they need to add both the team and me to the repo.
Setup
There are many tutorials on using Github. The basic actions you need to take for this class are:
- Go to the github site to get started. It will point you to the best places to get git.
- Create an account for yourself if you don't have one, and share it with your team.
- Create a repository for your project, with just a README file
- Verify complete team access to the repo. Everyone
on the team should
- clone the repo to their local machine
- add their name to the README file
- commit and push the changes, with a message
- pull and verify they have the current readme with all team members
Tips and Warnings
Be careful with the git for Windows GUI.
Some teams in Fall 2012 had synchronization issues with this GUI when swarming and making frequent commits. They had better luck just using the command line.
Use .gitignore
Keep .gitignore up to date in order
to
- avoid storing things like compiled binary source files that can slow down push and pull operations
- make sure all important files, including installation scripts, to-do lists, etc., are available to everyone on the team, and even the client
Pull often.
Don't work with out of date code.
Branch briefly, push often.
Keep branches to a day or so. Otherwise, you will have integration problems at the worst possible time, when you're trying to deliver to the client or end users.
Never push untested code.
Break big scary changes into harmless little ones.
For example, adding the ability for users to have multiple email addresses by replacing an "email" column in the user table with a new "user email" table. This is a classic scary change to database structure that can break a lot of your code. But you can easily make the changes in a series of safe, non-disruptive, testable substeps, any one of which could be rolled back easily. Remember to pull often.
- Add the new table, but change no existing code, remove no columns. Run existing tests and push.
- Write code to copy data from existing column to new table. Still change no existing code or columns. Write tests to verify data matches. Run tests and push.
- Change existing code that updates existing column to also update new table. Run tests and push.
- Change existing code that reads existing column to instead read new table. Run tests and push.
- Drop existing column. Run tests and push.
For some more good tips, see Alyson La's 5 GitHub tips for new coders.