Github Setup Tips
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
- github, 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.
A popular alternative to github is Bitbucket. Bitbucket lets you have private repos for free, but limits you to five team mates. Since your code needs to be available to me, your team, the class, and your clients, do not use Bitbucket. Even if you think this might be the germ of the next great app, open-source your startup. If you have to hide your idea, it's not a good one.
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.
There are lots of tutorials. 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.
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
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.