Software Repository

For a listing of all software tools and scripts see Software Repository Listing.

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
  • [6-22-2016]: Can also use https://localhost/codebase which is preferable, otherwise username/passwords are transmitted plain text. The browser will show a security error because we have a self signed certificate. This is ok if we are restricted to intranet. If we want to allow public access, we probably need to get a certificate from a Certificate Authority like Verisign etc.

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??
• Repository Location on Disk: C:\inetpub\wwwroot\codebase\App_Data\Repositories

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.

• • [6-22-2016]: Can also use https://128.42.44.182/codebase which is preferable. The browser will show a security error because we have a self signed certificate. This is ok if we are restricted to intranet. If we want to allow public access, we probably need to get a certificate from a Certificate Authority like Verisign etc.

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, 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 confirming things do not break. So, after feature branches are merged into next and conflicts resolved, we merge into master.
After this, you can end the feature branches if you want.

Quick and dirty github tutorial

For a cool interactive tutorial see http://learngitbranching.js.org/.

***
You can also use SourceTree which is a GUI interface for git-client. This is installed on the RDP.
Like using git from CLI (see below), SourceTree constructs appropriate commands. But the good thing
is it automatically generates all error check/logging options with each command that are difficult
to recall from memory. SourceTree is freely available from Altassian at https://www.sourcetreeapp.com/
***

To use SourceTree you should have basic understanding of git (like branches,commits etc). The interactive tutorial above is very good for this purpose.

• 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 pull 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 pull <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 rm 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 rm <filename>

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

git rm -r <foldername>