Difference between revisions of "Software Repository"

From edegan.com
Jump to navigation Jump to search
imported>Harsh
 
(45 intermediate revisions by 6 users not shown)
Line 1: Line 1:
==Background==
+
[[Category: McNair Admin]]
 +
For a listing of all software tools and scripts see [[Software Repository Listing]].
 +
 
 +
==Quick Connection Instructions==
 +
 
 +
All of the following links go to the same place. Https is preferred as otherwise passwords are passed plain text.
 +
*From the RDP: https://localhost/codebase/
 +
*From the anywhere: https://rdp.mcnaircenter.org/codebase/ or https://128.42.44.182/codebase/
 +
 
 +
==Our Git Server==
 +
 
 +
We have our git server on the RDP machine.
 +
 
 +
===Access through a web browser===
 +
 
 +
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. '''You 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.
 +
 
 +
===Using a Git Client===
 +
 
 +
We have Git.exe and Sourcetree installed on the RDP. To run Git through the command line, follow the instructions below (ignore the section that says ''installing'').
 +
 
 +
==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.
 +
 
 +
#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.
 +
 
 +
#After feature development is complete merge your feature-branch into next.
 +
 
 +
#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==
 +
 
 +
You can also use [https://www.sourcetreeapp.com/ SourceTree] which is a free 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. To use SourceTree you should have basic understanding of git (like branches,commits etc).
 +
 
 +
*''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 [https://git-scm.com/ git scm website]
 +
** If you use ubuntu then all you need to do is type <code><big>sudo apt-get install git</big></code>
 +
* Check your installation by typing <code><big>git</big></code> in terminal or windows powershell
 +
*Basic git operations:
 +
<div style="text-align: left; direction: ltr; margin-left: 2em;">
 +
* to checkout code from remote repository, use the <code><big>git clone</big></code> 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:
 +
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git clone http://128.42.44.182/codebase/Matcher.git</big></code></div>
 +
* to update your repository to include others' work in your project use the <code><big>git pull</big></code> 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:
 +
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git pull <optional folder path></big></code></div>
 +
* to commit your changes to your local repository use the <code><big>git commit</big></code> command. Committing your changes is an essential step whether you are adding/removing items from the repository or changing existing items. See example :
 +
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git commit -m "mandatory commit message"</big></code></div>
 +
 
 +
* to push your changes to remote repository use the <code><big>git push <optional file/folder name></big></code> 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 <code><big>git add</big></code> command. After that you must commit to ensure that your repository actually has the new file. See example:
 +
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git add <filename/folder name></big></code></div>
 +
 
 +
* to remove items from your repository use the <code><big>git rm</big></code> 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:
 +
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git rm <filename></big></code></div>
 +
<div style="text-align: left; direction: ltr; margin-left: 2em;">
 +
''Note'': if removing a non empty folder use the -r flag to recursively remove all contents of that folder as well :
 +
</div>
 +
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git rm -r <foldername></big></code></div>
 +
</div>
 +
 
 +
==Useful Links==
 +
 
 +
* [http://learngitbranching.js.org/ A cool interactive tutorial for git]
 +
* For those who are experienced with svn check out the [http://git.or.cz/course/svn.html svn-git comparison]
 +
[[admin_classification::IT Build| ]]
 +
 
 +
==Build Notes==
 +
 
 
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.).
 
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.).
  
Line 22: Line 92:
 
*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.
 
*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'''
 
**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==
+
Here are the admin credentials:
We have already done the set up of the git server on the RDP machine. Here are the admin credentials:
+
*Username: '''boss'''
*Name: '''father'''
+
*Name: '''Ed'''
*Surname: '''mcnair'''
+
*Surname: '''Egan'''
 
*Email: '''Edward.Egan@rice.edu'''
 
*Email: '''Edward.Egan@rice.edu'''
*Password: '''WhyHarshWhy?'''
+
*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.
 

Latest revision as of 15:06, 13 March 2017

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

Quick Connection Instructions

All of the following links go to the same place. Https is preferred as otherwise passwords are passed plain text.

Our Git Server

We have our git server on the RDP machine.

Access through a web browser

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. You 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.

Using a Git Client

We have Git.exe and Sourcetree installed on the RDP. To run Git through the command line, follow the instructions below (ignore the section that says installing).

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.
  1. After feature development is complete merge your feature-branch into next.
  1. 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

You can also use SourceTree which is a free 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. To use SourceTree you should have basic understanding of git (like branches,commits etc).

  • 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:
  • 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>

Useful Links


Build Notes

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.

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