Software Repository

Background

Given the amount of software that has been written by past computer science interns and more being written, we felt the need to have some kind of source code management system put into place so that developers can work without ever being in fear of breaking production and facing Ed's wrath (you do not want that dude angry! Wherever you go, he will find you! No escape.).

To enforce efficient source control we(Ed) chose to host our own git server on the RDP machine using Bonobo Git Server that makes use of the windows IIS platform and is open source.

Installing Bonobo git server is pretty simple:

• dowload the zip file from the Bonobo website.
• extract its contents. It should be a single folder containing directories like App_Data, bin etc.
• rename that folder to anything you want. I used the name "codebase"
• copy the codebase folder to C:\inetpub\wwwroot\
• Allow IIS User to modify C:\inetpub\wwwroot\codebase\App_Data folder. To do so:
  • select Properties of App_Data folder,
  • go to Security tab,
  • click edit,
  • select IIS user (in my case IIS_IUSRS) and add Modify and Write permission,
  • confirm these settings with Apply button.
• Convert codebase to Application in IIS
  • Run IIS Manager and navigate to Sites -> Default Web Site. You should see Bonobo.Git.Server.
  • Right click on 'codebase' and convert to application.
  • Check if the selected application pool runs on .NET 4.0 and convert the site.
• Enable Anonymous Authentication in IIS and disable the others. To do so, select the application in the left pane, double-click on the authentication icon in the right pane and set the value to of Anonymous Authentication to Enabled
• Launch your browser and go to http://localhost/codebase. Now you can see the initial page of the Bonobo Git Server and everything should work.
  • default credentials are username: admin, password: admin

Our Git Server

We have already done the set up of the git server on the RDP machine. Here are the admin credentials:

• Username: boss
• Name: Ed
• Surname: Egan
• Email: Edward.Egan@rice.edu
• Password: you_seriously_thought_Id_write_that_in_here??

To access this from your computer and not the RDP you can go to http://128.42.44.182/codebase where it will prompt you for your username and password.

Our Git workflow

We chose a simple git workflow.

Our aim is not to break things in the master branch. All commits on the master should work.

1.
When adding a new feature or fixing a bug (well, why fix it, was that not a feature?), ALWAYS check out a new feature branch from the master.
NEVER checkout a feature branch from next (see below). The feature branch should be named user/feature_name. 

2.
After feature development is complete merge your feature-branch into next.

3.
The next branch is intended for testing and confirm things do not break. So, after feature branches are merged into next and conflicts resolved, if things work we push it to master.
You can end the feature branches if you want.  

Quick and dirty github tutorial

• Installing - Depending on your operating system you can install git in three different ways:
  • If you are a windows or a mac user user, you can simply download & install the latest release from git scm website
  • If you use ubuntu then all you need to do is type sudo apt-get install git
• Check your installation by typing git in terminal or windows powershell
• Basic git operations:

• to checkout code from remote repository, use the git clone command. This will create a local repository on your disk as well as download the source code of the project you wish to work on. Here's an example:

git clone http://128.42.44.182/codebase/Matcher.git

• to update your repository to include others' work in your project use the git update command. Its always a good practice to update your code before you commit to ensure that others' code doesn't break yours. Also, you cannot push to remote unless your local repository is up to date. If you commit on a stale local repository that is fine, just that this would mean you are likely to have more trouble merging your code with others later on thanks to all the conflicts that you'll face when you actually try to update your repository later. See example:

git update <optional folder path>

• to commit your changes to your local repository use the git commit command. Committing your changes is an essential step whether you are adding/removing items from the repository or changing existing items. See example :

git commit -m "mandatory commit message"

• to push your changes to remote repository use the git push <optional file/folder name> command. Whatever you need to be pushed to the server must be committed to your local repository first. By default this command will push everything from current folder if no item is specified.

• to add new files to your repository use the git add command. After that you must commit to ensure that your repository actually has the new file. See example:

git add <filename/folder name>

• to remove items from your repository use the git remove command. After that you delete the file that you wanted removed from the repository and commit to ensure that your repository actually has the change persisted. Finally, you push to server to make sure the server has those items removed as well and that nobody in your team works under the assumption that those items are stills there. See example:

git remove <filename>

Note: if removing a non empty folder use the -r flag to recursively remove all contents of that folder as well :

git remove -r <foldername>