Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/final S1455

2014-12-16T17:21:05Z

Vpiddem: /* Design Principles */

Please read the "README" file provided in expertiza. This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on their Central African Republic deployment.

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
====About Sahana Eden====
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few. It is highly configurable so that it can be used in a wide variety of different contexts and is easy to modify to build custom solutions. Different levels of support are available from both the voluntary Sahana Eden community and professional companies. Sahana focuses on Community and Professional Support.

====Getting to know the domain====

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

====Installation & tutorials====

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

Below is a high level overview to begin contributing to Sahana-

The code is in the folder: web2py/applications/eden

Inside that folder are folders for Models (define the data structure), Controllers (provide URLs to enable access to the data) & Views (HTML templates).

Each module within Sahana Eden will normally consist of one of each of these files:

Model: modules/s3db/modulename.py
Controller: controllers/modulename.py
View: views/modulename/index.html

In order to know which file to edit in order to change a particular function, you need to look at the URL. The Web2Py web framework maps URLs as follows:

http://host/application/controller/function

So, if you want to edit the Home page with the URL:

http://host/eden/default/index

This implies that you should look at the file eden/controllers/default.py and the index function within it which can be found by searching for the function title "def index():"

Tip: Sahana Eden makes heavy use of integrated resource controllers so the typical mapping is:

http://host/eden/module/resource

The resource refers to a table with the name module_resource in the file modules/s3db/<module>.py

==Introduction to project==

====Overview====
In the Central African Republic page, some data needs new models, and some models need tweaking. The purpose of this project is to identify any such requirement and make necessary changes. The general steps to follow in Sahana development are mentioned below-

1. Add/modify the core models in modules/s3db

2. Add REST controllers for new models

3. Check basic operations using automatic CRUD interface- tweak list_fields to the most-relevant fields perhaps

4. Add menu entries (modules/s3menus.py)

5. Develop XSLT & CSV templates (static/formats/s3csv) to bulk import the data

6. Convert the data to these CSV templates- use ogr2ogr for this

7. Add layers to the map (private/templates/<TEMPLATE>/gis_layer_feature.csv. Look at default for now) including Markers and tooltips (popup_format)

8. Provide some report_options to make a meaningful report

====Scope====
Four modules related to this deployment are-

1. Health - modules/s3db/hms.py

2. Transport - modules/s3db/transport.py

3. Water - modules/s3db/water.py

4. School - There is no separate module for education.

We took up the Health module and worked on the Magnu template of Sahana. The key point for the core module is to ensure that we can capture all of the data that is available. There was a need to hide some of this complexity from the Magnu template which is used by CAR.

- Currently, Sahana is keen to show people how it could be used.

- An approach to this is to add one or two deployment_setting to be able to easily switch on/off chunks of functionality like this without needing to resort to custom code.

Another thing on a to-do list is adding markers to hospital overlay, and making them vary by type of hospital.

====Reference Material====

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-health Hospital Model]

[http://geonode.wfp.org/layers/geonode:wld_poi_bcp_wfp Border Control Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-roads Roads], [http://geonode.wfp.org/layers/geonode:wld_trs_supplyroutes_wfp Routes], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-aerodromes-airports-airfields Airports]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies Water Bodies], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies-0 Water Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-courses Rivers]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education Education]

==System Overview==

Sahana Eden Framework:

The Sahana Eden Software Platform has been built around a Rapid Application Development (RAD) Framework. This provides a high level of automation to ensure that new solutions can be quickly and effectively developed. Once a database table is defined, the Sahana Eden Framework automatically generates HTML pages to handle CRUD (Create, Read, Update, Delete) as well as Search, Map and Pivot Reports. Web Services are available to import and export in XML, CSV, JSON and EXtensible Stylesheet Language (XSL) transforms are supported to produce other data standards.

The Sahana Eden Framework has flexible authorization policies which can be configured to grant permissions for different modules, tables as well as the ability to have multiple Organizations control their own data on a single Sahana Eden installation.

Sahana Eden can be downloaded and run locally from a flash drive. Synchronization functionality allows data to be entered then keep up to date between different installations, including online servers and local flash drive installations. The Sahana Eden Framework also includes a scheduler for running tasks at a specific time, in regular intervals or as asynchronous tasks which are triggered by users.

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

Our focus is on Controllers, Models, Modules and views. For every action on various pages on Sahana Humanitarian website, there are set of controllers defined. As mentioned above, we want to focus on 4 models- health, transport, water and school.

<table class="wikitable">
<tr>
<th> Unicef Key
</th>
<th> Unicef value (number)
</th>
<th> OSM tag
</th></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">amenity=hospital</tt>
</td></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">source=UNICEF</tt>
</td></tr>
<tr>
<td> ID
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> WPT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> FOSA_CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAT_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LONG_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PAYS
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PREF, SOUS_PREF, COMM, VILLE_VILL, QUARTIER
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">addrːfull=*</tt>
</td></tr>
<tr>
<td> VILLE_VILL
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">addr:city=*</tt>
</td></tr>
<tr>
<td> POP_VILLE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Public (306)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">operator:type=government</tt>
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Prive (37)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">private</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Poste de sante (204)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=dispensary</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Centre de sante (with beds) (118)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=health_center</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital prefectoral (7)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=prefectoral_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital regional (3)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:typeregional_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Clinique privee (1)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=private_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> No attribut (1)
</td>
<td> not to upload
</td></tr>
<tr>
<td> NOM_FOSA
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">name=*</tt>
</td></tr>
<tr>
<td> NB_LITS
</td>
<td> numbers 0-179
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">capacity:beds=*</tt>
</td></tr>
<tr>
<td> NB_PERS_SO
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> NB_PATIENT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> COMITE_WAS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> NB_PERS_WA
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LTA
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP_PLEIN
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> LATRINES_S
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAVE_MAINS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> INCINERATE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> BAC_A_ORDU
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> TOTAL_LATR
</td>
<td> numbers 0-23
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">toilets:number=*</tt>
</td></tr>
</table>

==System Architecture==
The basic Sahana Eden architecture is as follows:

<table style="width: 100%; border: 1px dotted rgb(0, 0, 0); border-collapse: collapse;" cellpadding="5"><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Server</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Apache</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Other web servers can also be used, such as Cherokee.</td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Application</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Sahana Eden</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Application Framework</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Web2Py</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Programming Language</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Python & Java Script</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Database</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">MySQL, PostgreSQL, or SQLite</td>
<td style="border: 1px dotted rgb(0, 0, 0);"><p>MySQL, PostgreSQL, and SQLite are supported.</p><p>Other databases should be usable without major additional work since Web2Py supplies many connectors.</p></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Operating System</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Linux (Debian recommended)</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Windows and Mac OS X are possible, but only recommended for single-user environments.</td>
</tr></table>

==Requirement Analysis==

The requirements state that some of the data needs new models. Also, the school database states that there is no module for education. Even on the [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education education website] of Central African Republic, it says that the data is incomplete. Addition of new module, say edu.py in s3db module, will solve this problem.

For the purpose of this project, we will need to follow these steps-

1. Installation and setup- Follow the installation guidelines provided by Sahana to build the system on individual machines. Then, do the setup for Git repository, i.e. forking Sahana eden repo and adding the original as remote branch.

2. Identify properties for "edu.py" and define the basic data model in the models/ folder.

3. Add corresponding controller which provides access to this resource. Create another new file, this time in the controllers/ folder.

4. Define Field Types- By default fields are created with type string, however we may wish to use other data types. All fields have both client-side widgets & server-side validation automatically added based on their data type.

5. Customize and Internationalize field labels- Field labels are automatically generated from the field names, however we are able to customize these by adding a 'label' attribute.

6. Add Links to other Resources.

7. Override default CRUD Strings.

8. Update the Menus- There are two levels of menu within the system: The top-level 'Modules Menu' is visible in all modules. Underneath that, each module has its own menu for for module-specific navigation.

9. Test the changes.

=== GIS Requirements ===
==== Understanding OpenLayers & GeoExt ====
OpenLayers is an open source, client side JavaScript library for making interactive web maps, viewable in nearly any web browser. Since it is a client side library, it requires no special server side so beware or settings—you can use it without even downloading anything.Originally developed by Metacarta, as a response, in part, to Google Maps, it has grown into a mature, popular framework with many passionate developers and a very helpful community.
*OpenLayers.Map
Here is an example that will create a page containing a full screen OpenLayers map. This is not the most basic of maps, but will work if you copy and paste the html content.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<style>
html,body {
height: 99%;
width: 99%;
}
#map {
width: 100%;
height: 100%;
border: 1px solid black;
}
</style>
<script src='http://openlayers.org/api/OpenLayers.js'>
</script>
</head>
<body>
< div id="map"></ div>
<script type="text/javascript">
var map = new OpenLayers.Map('map',{maxResolution: 0.703125} );
var wmscURL = [
"http://wmsc1.terrapages.net/getmap?",
"http://wmsc2.terrapages.net/getmap?",
"http://wmsc3.terrapages.net/getmap?",
"http://wmsc4.terrapages.net/getmap?"
];
var terrapagesStreetLayer = new OpenLayers.Layer.WMS( 'TerraPages Street',wmscURL, {layers: 'UnprojectedStreet', format: 'image/jpeg' }, {buffer: 1, isBaseLayer: true} );
map.addLayer(terrapagesStreetLayer);
map.zoomToMaxExtent();
</script>
</body>
</html>

*OpenLayers.Layer.Markers

Below is an example of how to create a Markers Layer, and add a single marker on that layer at the specified lon and lat. This will also apply an offest to the icon image, so that it can be aligned horizontally centered, vertically bottom over the position.

var markersLayer = new OpenLayers.Layer.Markers("My Marker Layer");
var iconSize = new OpenLayers.Size(20,20);
var iconOffset = new OpenLayers.Pixel(-(iconSize.w/2), -iconSize.h);
var marker = new OpenLayers.Marker(
new OpenLayers.LonLat(<<lon>>,<<lat>>),
new OpenLayers.Icon(<<iconURL>>,iconSize,iconOffset)
);
markersLayer.setVisibility(true);
markersLayer.addMarker(marker);
map.addLayer(markersLayer);

==== Add layers to the map ====
Sahana Eden makes use of Openlayers and GeoExt for its GIS module. A map is basically a combination of several stitched tiles which are rendered on the web page upon request. The overall map functionalities include displaying various hospital types, locations, heliports and other map related data.We are focusing on adding a new overlay layer to the existing map layers and as well using a customised image icon for displaying marker symbol for our overlay layer.

[[File:Map-screen.png]]

==Design Principles==

For our project, the best design principle applicable is "Open Close Principle". Since we are introducing a new module, there will definitely be extensions to it, but very few modifications.

The common features/functions will be encapsulated to ensure that the code is "DRY".

Further, we have followed the MVC(Model-View-Controller) architectural pattern to separate applications concerns.

Model - Model represents an object carrying data. It can also have logic to update controller if its data changes.

View - View represents the visualization of the data that model contains.

Controller - Controller acts on both Model and view. It controls the data flow into model object and updates the view whenever data changes. It keeps View and Model separate.

==Proposed Test Cases==

For end-user performance gains, Sahana Eden minimizes and compresses the CSS and JavaScript. While this approach works well for optimized end-user performance, to debug the CSS and JavaScript we shall enable debug mode in models/000_config.py in our Sahana Eden server with the following setting:

settings.base.debug = True

Once any changes to the CSS and JavaScript are working, then we can minimizes and compresses the CSS and JavaScript using:

static/scripts/tools/build.sahana.py

Although this uses a web service, you get better results by downloading a local version of the Closure Compiler (a tool for making JavaScript download and run faster) to static/scripts/tools. It is also possible to quickly view a single page in debug mode by adding the ?debug=1 variable to the end of a URL.

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

[http://sahanafoundation.org/sahana-launches-eurosha-humanitarian-data-site/ Sahana Launches EUROSHA Humanitarian Data Site]

[http://sahanafoundation.org/eurosha-volunteer-diary/ A EUROSHA Volunteer Diary]

[http://en.flossmanuals.net/sahana-eden/user-stories/ User stories]

[http://www.un.org/apps/news/story.asp?NewsID=49300#.VGLHHo_wbK8 Central African Republic: UN urges support to meet basic needs in hard-hit province]

[https://www.packtpub.com/books/content/what-openlayers OpenLayers]

[https://en.wikipedia.org/wiki/Central_African_Republic Wiki Page]

[https://www.youtube.com/watch?v=VoQAxQgevEA War in the Central African Republic (Full Length Documentary)]

CSC/ECE 517 Fall 2014/final S1455

2014-12-16T17:20:30Z

Vpiddem: /* Design Principles */

Please read the "README" file provided in expertiza. This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on their Central African Republic deployment.

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
====About Sahana Eden====
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few. It is highly configurable so that it can be used in a wide variety of different contexts and is easy to modify to build custom solutions. Different levels of support are available from both the voluntary Sahana Eden community and professional companies. Sahana focuses on Community and Professional Support.

====Getting to know the domain====

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

====Installation & tutorials====

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

Below is a high level overview to begin contributing to Sahana-

The code is in the folder: web2py/applications/eden

Inside that folder are folders for Models (define the data structure), Controllers (provide URLs to enable access to the data) & Views (HTML templates).

Each module within Sahana Eden will normally consist of one of each of these files:

Model: modules/s3db/modulename.py
Controller: controllers/modulename.py
View: views/modulename/index.html

In order to know which file to edit in order to change a particular function, you need to look at the URL. The Web2Py web framework maps URLs as follows:

http://host/application/controller/function

So, if you want to edit the Home page with the URL:

http://host/eden/default/index

This implies that you should look at the file eden/controllers/default.py and the index function within it which can be found by searching for the function title "def index():"

Tip: Sahana Eden makes heavy use of integrated resource controllers so the typical mapping is:

http://host/eden/module/resource

The resource refers to a table with the name module_resource in the file modules/s3db/<module>.py

==Introduction to project==

====Overview====
In the Central African Republic page, some data needs new models, and some models need tweaking. The purpose of this project is to identify any such requirement and make necessary changes. The general steps to follow in Sahana development are mentioned below-

1. Add/modify the core models in modules/s3db

2. Add REST controllers for new models

3. Check basic operations using automatic CRUD interface- tweak list_fields to the most-relevant fields perhaps

4. Add menu entries (modules/s3menus.py)

5. Develop XSLT & CSV templates (static/formats/s3csv) to bulk import the data

6. Convert the data to these CSV templates- use ogr2ogr for this

7. Add layers to the map (private/templates/<TEMPLATE>/gis_layer_feature.csv. Look at default for now) including Markers and tooltips (popup_format)

8. Provide some report_options to make a meaningful report

====Scope====
Four modules related to this deployment are-

1. Health - modules/s3db/hms.py

2. Transport - modules/s3db/transport.py

3. Water - modules/s3db/water.py

4. School - There is no separate module for education.

We took up the Health module and worked on the Magnu template of Sahana. The key point for the core module is to ensure that we can capture all of the data that is available. There was a need to hide some of this complexity from the Magnu template which is used by CAR.

- Currently, Sahana is keen to show people how it could be used.

- An approach to this is to add one or two deployment_setting to be able to easily switch on/off chunks of functionality like this without needing to resort to custom code.

Another thing on a to-do list is adding markers to hospital overlay, and making them vary by type of hospital.

====Reference Material====

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-health Hospital Model]

[http://geonode.wfp.org/layers/geonode:wld_poi_bcp_wfp Border Control Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-roads Roads], [http://geonode.wfp.org/layers/geonode:wld_trs_supplyroutes_wfp Routes], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-aerodromes-airports-airfields Airports]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies Water Bodies], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies-0 Water Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-courses Rivers]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education Education]

==System Overview==

Sahana Eden Framework:

The Sahana Eden Software Platform has been built around a Rapid Application Development (RAD) Framework. This provides a high level of automation to ensure that new solutions can be quickly and effectively developed. Once a database table is defined, the Sahana Eden Framework automatically generates HTML pages to handle CRUD (Create, Read, Update, Delete) as well as Search, Map and Pivot Reports. Web Services are available to import and export in XML, CSV, JSON and EXtensible Stylesheet Language (XSL) transforms are supported to produce other data standards.

The Sahana Eden Framework has flexible authorization policies which can be configured to grant permissions for different modules, tables as well as the ability to have multiple Organizations control their own data on a single Sahana Eden installation.

Sahana Eden can be downloaded and run locally from a flash drive. Synchronization functionality allows data to be entered then keep up to date between different installations, including online servers and local flash drive installations. The Sahana Eden Framework also includes a scheduler for running tasks at a specific time, in regular intervals or as asynchronous tasks which are triggered by users.

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

Our focus is on Controllers, Models, Modules and views. For every action on various pages on Sahana Humanitarian website, there are set of controllers defined. As mentioned above, we want to focus on 4 models- health, transport, water and school.

<table class="wikitable">
<tr>
<th> Unicef Key
</th>
<th> Unicef value (number)
</th>
<th> OSM tag
</th></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">amenity=hospital</tt>
</td></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">source=UNICEF</tt>
</td></tr>
<tr>
<td> ID
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> WPT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> FOSA_CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAT_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LONG_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PAYS
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PREF, SOUS_PREF, COMM, VILLE_VILL, QUARTIER
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">addrːfull=*</tt>
</td></tr>
<tr>
<td> VILLE_VILL
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">addr:city=*</tt>
</td></tr>
<tr>
<td> POP_VILLE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Public (306)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">operator:type=government</tt>
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Prive (37)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">private</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Poste de sante (204)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=dispensary</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Centre de sante (with beds) (118)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=health_center</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital prefectoral (7)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=prefectoral_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital regional (3)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:typeregional_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Clinique privee (1)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=private_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> No attribut (1)
</td>
<td> not to upload
</td></tr>
<tr>
<td> NOM_FOSA
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">name=*</tt>
</td></tr>
<tr>
<td> NB_LITS
</td>
<td> numbers 0-179
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">capacity:beds=*</tt>
</td></tr>
<tr>
<td> NB_PERS_SO
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> NB_PATIENT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> COMITE_WAS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> NB_PERS_WA
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LTA
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP_PLEIN
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> LATRINES_S
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAVE_MAINS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> INCINERATE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> BAC_A_ORDU
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> TOTAL_LATR
</td>
<td> numbers 0-23
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">toilets:number=*</tt>
</td></tr>
</table>

==System Architecture==
The basic Sahana Eden architecture is as follows:

<table style="width: 100%; border: 1px dotted rgb(0, 0, 0); border-collapse: collapse;" cellpadding="5"><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Server</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Apache</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Other web servers can also be used, such as Cherokee.</td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Application</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Sahana Eden</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Application Framework</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Web2Py</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Programming Language</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Python & Java Script</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Database</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">MySQL, PostgreSQL, or SQLite</td>
<td style="border: 1px dotted rgb(0, 0, 0);"><p>MySQL, PostgreSQL, and SQLite are supported.</p><p>Other databases should be usable without major additional work since Web2Py supplies many connectors.</p></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Operating System</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Linux (Debian recommended)</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Windows and Mac OS X are possible, but only recommended for single-user environments.</td>
</tr></table>

==Requirement Analysis==

The requirements state that some of the data needs new models. Also, the school database states that there is no module for education. Even on the [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education education website] of Central African Republic, it says that the data is incomplete. Addition of new module, say edu.py in s3db module, will solve this problem.

For the purpose of this project, we will need to follow these steps-

1. Installation and setup- Follow the installation guidelines provided by Sahana to build the system on individual machines. Then, do the setup for Git repository, i.e. forking Sahana eden repo and adding the original as remote branch.

2. Identify properties for "edu.py" and define the basic data model in the models/ folder.

3. Add corresponding controller which provides access to this resource. Create another new file, this time in the controllers/ folder.

4. Define Field Types- By default fields are created with type string, however we may wish to use other data types. All fields have both client-side widgets & server-side validation automatically added based on their data type.

5. Customize and Internationalize field labels- Field labels are automatically generated from the field names, however we are able to customize these by adding a 'label' attribute.

6. Add Links to other Resources.

7. Override default CRUD Strings.

8. Update the Menus- There are two levels of menu within the system: The top-level 'Modules Menu' is visible in all modules. Underneath that, each module has its own menu for for module-specific navigation.

9. Test the changes.

=== GIS Requirements ===
==== Understanding OpenLayers & GeoExt ====
OpenLayers is an open source, client side JavaScript library for making interactive web maps, viewable in nearly any web browser. Since it is a client side library, it requires no special server side so beware or settings—you can use it without even downloading anything.Originally developed by Metacarta, as a response, in part, to Google Maps, it has grown into a mature, popular framework with many passionate developers and a very helpful community.
*OpenLayers.Map
Here is an example that will create a page containing a full screen OpenLayers map. This is not the most basic of maps, but will work if you copy and paste the html content.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<style>
html,body {
height: 99%;
width: 99%;
}
#map {
width: 100%;
height: 100%;
border: 1px solid black;
}
</style>
<script src='http://openlayers.org/api/OpenLayers.js'>
</script>
</head>
<body>
< div id="map"></ div>
<script type="text/javascript">
var map = new OpenLayers.Map('map',{maxResolution: 0.703125} );
var wmscURL = [
"http://wmsc1.terrapages.net/getmap?",
"http://wmsc2.terrapages.net/getmap?",
"http://wmsc3.terrapages.net/getmap?",
"http://wmsc4.terrapages.net/getmap?"
];
var terrapagesStreetLayer = new OpenLayers.Layer.WMS( 'TerraPages Street',wmscURL, {layers: 'UnprojectedStreet', format: 'image/jpeg' }, {buffer: 1, isBaseLayer: true} );
map.addLayer(terrapagesStreetLayer);
map.zoomToMaxExtent();
</script>
</body>
</html>

*OpenLayers.Layer.Markers

Below is an example of how to create a Markers Layer, and add a single marker on that layer at the specified lon and lat. This will also apply an offest to the icon image, so that it can be aligned horizontally centered, vertically bottom over the position.

var markersLayer = new OpenLayers.Layer.Markers("My Marker Layer");
var iconSize = new OpenLayers.Size(20,20);
var iconOffset = new OpenLayers.Pixel(-(iconSize.w/2), -iconSize.h);
var marker = new OpenLayers.Marker(
new OpenLayers.LonLat(<<lon>>,<<lat>>),
new OpenLayers.Icon(<<iconURL>>,iconSize,iconOffset)
);
markersLayer.setVisibility(true);
markersLayer.addMarker(marker);
map.addLayer(markersLayer);

==== Add layers to the map ====
Sahana Eden makes use of Openlayers and GeoExt for its GIS module. A map is basically a combination of several stitched tiles which are rendered on the web page upon request. The overall map functionalities include displaying various hospital types, locations, heliports and other map related data.We are focusing on adding a new overlay layer to the existing map layers and as well using a customised image icon for displaying marker symbol for our overlay layer.

[[File:Map-screen.png]]

==Design Principles==

For our project, the best design principle applicable is "Open Close Principle". Since we are introducing a new module, there will definitely be extensions to it, but very few modifications.

The common features/functions will be encapsulated to ensure that the code is "DRY".

Further, we have followed the MVC(Model-View-Controller) architectural pattern to separate applications concerns.
Model - Model represents an object or JAVA POJO carrying data. It can also have logic to update controller if its data changes.

View - View represents the visualization of the data that model contains.

Controller - Controller acts on both Model and view. It controls the data flow into model object and updates the view whenever data changes. It keeps View and Model separate.

==Proposed Test Cases==

For end-user performance gains, Sahana Eden minimizes and compresses the CSS and JavaScript. While this approach works well for optimized end-user performance, to debug the CSS and JavaScript we shall enable debug mode in models/000_config.py in our Sahana Eden server with the following setting:

settings.base.debug = True

Once any changes to the CSS and JavaScript are working, then we can minimizes and compresses the CSS and JavaScript using:

static/scripts/tools/build.sahana.py

Although this uses a web service, you get better results by downloading a local version of the Closure Compiler (a tool for making JavaScript download and run faster) to static/scripts/tools. It is also possible to quickly view a single page in debug mode by adding the ?debug=1 variable to the end of a URL.

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

[http://sahanafoundation.org/sahana-launches-eurosha-humanitarian-data-site/ Sahana Launches EUROSHA Humanitarian Data Site]

[http://sahanafoundation.org/eurosha-volunteer-diary/ A EUROSHA Volunteer Diary]

[http://en.flossmanuals.net/sahana-eden/user-stories/ User stories]

[http://www.un.org/apps/news/story.asp?NewsID=49300#.VGLHHo_wbK8 Central African Republic: UN urges support to meet basic needs in hard-hit province]

[https://www.packtpub.com/books/content/what-openlayers OpenLayers]

[https://en.wikipedia.org/wiki/Central_African_Republic Wiki Page]

[https://www.youtube.com/watch?v=VoQAxQgevEA War in the Central African Republic (Full Length Documentary)]

CSC/ECE 517 Fall 2014/final S1455

2014-12-16T04:51:37Z

Vpiddem: /* System Overview */

Please read the "README" file provided in expertiza. This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on their Central African Republic deployment.

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
====About Sahana Eden====
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few. It is highly configurable so that it can be used in a wide variety of different contexts and is easy to modify to build custom solutions. Different levels of support are available from both the voluntary Sahana Eden community and professional companies. Sahana focuses on Community and Professional Support.

====Getting to know the domain====

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

====Installation & tutorials====

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

Below is a high level overview to begin contributing to Sahana-

The code is in the folder: web2py/applications/eden

Inside that folder are folders for Models (define the data structure), Controllers (provide URLs to enable access to the data) & Views (HTML templates).

Each module within Sahana Eden will normally consist of one of each of these files:

Model: modules/s3db/modulename.py
Controller: controllers/modulename.py
View: views/modulename/index.html

In order to know which file to edit in order to change a particular function, you need to look at the URL. The Web2Py web framework maps URLs as follows:

http://host/application/controller/function

So, if you want to edit the Home page with the URL:

http://host/eden/default/index

This implies that you should look at the file eden/controllers/default.py and the index function within it which can be found by searching for the function title "def index():"

Tip: Sahana Eden makes heavy use of integrated resource controllers so the typical mapping is:

http://host/eden/module/resource

The resource refers to a table with the name module_resource in the file modules/s3db/<module>.py

==Introduction to project==

====Overview====
In the Central African Republic page, some data needs new models, and some models need tweaking. The purpose of this project is to identify any such requirement and make necessary changes. The general steps to follow in Sahana development are mentioned below-

1. Add/modify the core models in modules/s3db

2. Add REST controllers for new models

3. Check basic operations using automatic CRUD interface- tweak list_fields to the most-relevant fields perhaps

4. Add menu entries (modules/s3menus.py)

5. Develop XSLT & CSV templates (static/formats/s3csv) to bulk import the data

6. Convert the data to these CSV templates- use ogr2ogr for this

7. Add layers to the map (private/templates/<TEMPLATE>/gis_layer_feature.csv. Look at default for now) including Markers and tooltips (popup_format)

8. Provide some report_options to make a meaningful report

====Scope====
Four modules related to this deployment are-

1. Health - modules/s3db/hms.py

2. Transport - modules/s3db/transport.py

3. Water - modules/s3db/water.py

4. School - There is no separate module for education.

We took up the Health module and worked on the Magnu template of Sahana. The key point for the core module is to ensure that we can capture all of the data that is available. There was a need to hide some of this complexity from the Magnu template which is used by CAR.

- Currently, Sahana is keen to show people how it could be used.

- An approach to this is to add one or two deployment_setting to be able to easily switch on/off chunks of functionality like this without needing to resort to custom code.

Another thing on a to-do list is adding markers to hospital overlay, and making them vary by type of hospital.

====Reference Material====

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-health Hospital Model]

[http://geonode.wfp.org/layers/geonode:wld_poi_bcp_wfp Border Control Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-roads Roads], [http://geonode.wfp.org/layers/geonode:wld_trs_supplyroutes_wfp Routes], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-aerodromes-airports-airfields Airports]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies Water Bodies], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies-0 Water Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-courses Rivers]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education Education]

==System Overview==

Sahana Eden Framework:

The Sahana Eden Software Platform has been built around a Rapid Application Development (RAD) Framework. This provides a high level of automation to ensure that new solutions can be quickly and effectively developed. Once a database table is defined, the Sahana Eden Framework automatically generates HTML pages to handle CRUD (Create, Read, Update, Delete) as well as Search, Map and Pivot Reports. Web Services are available to import and export in XML, CSV, JSON and EXtensible Stylesheet Language (XSL) transforms are supported to produce other data standards.

The Sahana Eden Framework has flexible authorization policies which can be configured to grant permissions for different modules, tables as well as the ability to have multiple Organizations control their own data on a single Sahana Eden installation.

Sahana Eden can be downloaded and run locally from a flash drive. Synchronization functionality allows data to be entered then keep up to date between different installations, including online servers and local flash drive installations. The Sahana Eden Framework also includes a scheduler for running tasks at a specific time, in regular intervals or as asynchronous tasks which are triggered by users.

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

Our focus is on Controllers, Models, Modules and views. For every action on various pages on Sahana Humanitarian website, there are set of controllers defined. As mentioned above, we want to focus on 4 models- health, transport, water and school.

<table class="wikitable">
<tr>
<th> Unicef Key
</th>
<th> Unicef value (number)
</th>
<th> OSM tag
</th></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">amenity=hospital</tt>
</td></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">source=UNICEF</tt>
</td></tr>
<tr>
<td> ID
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> WPT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> FOSA_CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAT_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LONG_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PAYS
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PREF, SOUS_PREF, COMM, VILLE_VILL, QUARTIER
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">addrːfull=*</tt>
</td></tr>
<tr>
<td> VILLE_VILL
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">addr:city=*</tt>
</td></tr>
<tr>
<td> POP_VILLE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Public (306)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">operator:type=government</tt>
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Prive (37)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">private</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Poste de sante (204)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=dispensary</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Centre de sante (with beds) (118)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=health_center</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital prefectoral (7)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=prefectoral_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital regional (3)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:typeregional_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Clinique privee (1)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">health_facility:type=private_hospital</tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> No attribut (1)
</td>
<td> not to upload
</td></tr>
<tr>
<td> NOM_FOSA
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">name=*</tt>
</td></tr>
<tr>
<td> NB_LITS
</td>
<td> numbers 0-179
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">capacity:beds=*</tt>
</td></tr>
<tr>
<td> NB_PERS_SO
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> NB_PATIENT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> COMITE_WAS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> NB_PERS_WA
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LTA
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP_PLEIN
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> LATRINES_S
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAVE_MAINS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> INCINERATE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> BAC_A_ORDU
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> TOTAL_LATR
</td>
<td> numbers 0-23
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr">toilets:number=*</tt>
</td></tr>
</table>

==System Architecture==
The basic Sahana Eden architecture is as follows:

<table style="width: 100%; border: 1px dotted rgb(0, 0, 0); border-collapse: collapse;" cellpadding="5"><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Server</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Apache</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Other web servers can also be used, such as Cherokee.</td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Application</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Sahana Eden</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Application Framework</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Web2Py</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Programming Language</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Python & Java Script</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Database</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">MySQL, PostgreSQL, or SQLite</td>
<td style="border: 1px dotted rgb(0, 0, 0);"><p>MySQL, PostgreSQL, and SQLite are supported.</p><p>Other databases should be usable without major additional work since Web2Py supplies many connectors.</p></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Operating System</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Linux (Debian recommended)</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Windows and Mac OS X are possible, but only recommended for single-user environments.</td>
</tr></table>

==Requirement Analysis==

The requirements state that some of the data needs new models. Also, the school database states that there is no module for education. Even on the [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education education website] of Central African Republic, it says that the data is incomplete. Addition of new module, say edu.py in s3db module, will solve this problem.

For the purpose of this project, we will need to follow these steps-

1. Installation and setup- Follow the installation guidelines provided by Sahana to build the system on individual machines. Then, do the setup for Git repository, i.e. forking Sahana eden repo and adding the original as remote branch.

2. Identify properties for "edu.py" and define the basic data model in the models/ folder.

3. Add corresponding controller which provides access to this resource. Create another new file, this time in the controllers/ folder.

4. Define Field Types- By default fields are created with type string, however we may wish to use other data types. All fields have both client-side widgets & server-side validation automatically added based on their data type.

5. Customize and Internationalize field labels- Field labels are automatically generated from the field names, however we are able to customize these by adding a 'label' attribute.

6. Add Links to other Resources.

7. Override default CRUD Strings.

8. Update the Menus- There are two levels of menu within the system: The top-level 'Modules Menu' is visible in all modules. Underneath that, each module has its own menu for for module-specific navigation.

9. Test the changes.

=== GIS Requirements ===
==== Understanding OpenLayers & GeoExt ====
OpenLayers is an open source, client side JavaScript library for making interactive web maps, viewable in nearly any web browser. Since it is a client side library, it requires no special server side so beware or settings—you can use it without even downloading anything.Originally developed by Metacarta, as a response, in part, to Google Maps, it has grown into a mature, popular framework with many passionate developers and a very helpful community.
*OpenLayers.Map
Here is an example that will create a page containing a full screen OpenLayers map. This is not the most basic of maps, but will work if you copy and paste the html content.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<style>
html,body {
height: 99%;
width: 99%;
}
#map {
width: 100%;
height: 100%;
border: 1px solid black;
}
</style>
<script src='http://openlayers.org/api/OpenLayers.js'>
</script>
</head>
<body>
< div id="map"></ div>
<script type="text/javascript">
var map = new OpenLayers.Map('map',{maxResolution: 0.703125} );
var wmscURL = [
"http://wmsc1.terrapages.net/getmap?",
"http://wmsc2.terrapages.net/getmap?",
"http://wmsc3.terrapages.net/getmap?",
"http://wmsc4.terrapages.net/getmap?"
];
var terrapagesStreetLayer = new OpenLayers.Layer.WMS( 'TerraPages Street',wmscURL, {layers: 'UnprojectedStreet', format: 'image/jpeg' }, {buffer: 1, isBaseLayer: true} );
map.addLayer(terrapagesStreetLayer);
map.zoomToMaxExtent();
</script>
</body>
</html>

*OpenLayers.Layer.Markers

Below is an example of how to create a Markers Layer, and add a single marker on that layer at the specified lon and lat. This will also apply an offest to the icon image, so that it can be aligned horizontally centered, vertically bottom over the position.

var markersLayer = new OpenLayers.Layer.Markers("My Marker Layer");
var iconSize = new OpenLayers.Size(20,20);
var iconOffset = new OpenLayers.Pixel(-(iconSize.w/2), -iconSize.h);
var marker = new OpenLayers.Marker(
new OpenLayers.LonLat(<<lon>>,<<lat>>),
new OpenLayers.Icon(<<iconURL>>,iconSize,iconOffset)
);
markersLayer.setVisibility(true);
markersLayer.addMarker(marker);
map.addLayer(markersLayer);

==== Add layers to the map ====
Sahana Eden makes use of Openlayers and GeoExt for its GIS module. A map is basically a combination of several stitched tiles which are rendered on the web page upon request. The overall map functionalities include displaying various hospital types, locations, heliports and other map related data.We are focusing on adding a new overlay layer to the existing map layers and as well using a customised image icon for displaying marker symbol for our overlay layer.

[[File:Map-screen.png]]

==Design Principles==

For our project, the best design principle applicable is "Open Close Principle". Since we are introducing a new module, there will definitely be extensions to it, but very few modifications.

The common features/functions will be encapsulated to ensure that the code is "DRY".

==Proposed Test Cases==

For end-user performance gains, Sahana Eden minimizes and compresses the CSS and JavaScript. While this approach works well for optimized end-user performance, to debug the CSS and JavaScript we shall enable debug mode in models/000_config.py in our Sahana Eden server with the following setting:

settings.base.debug = True

Once any changes to the CSS and JavaScript are working, then we can minimizes and compresses the CSS and JavaScript using:

static/scripts/tools/build.sahana.py

Although this uses a web service, you get better results by downloading a local version of the Closure Compiler (a tool for making JavaScript download and run faster) to static/scripts/tools. It is also possible to quickly view a single page in debug mode by adding the ?debug=1 variable to the end of a URL.

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

[http://sahanafoundation.org/sahana-launches-eurosha-humanitarian-data-site/ Sahana Launches EUROSHA Humanitarian Data Site]

[http://sahanafoundation.org/eurosha-volunteer-diary/ A EUROSHA Volunteer Diary]

[http://en.flossmanuals.net/sahana-eden/user-stories/ User stories]

[http://www.un.org/apps/news/story.asp?NewsID=49300#.VGLHHo_wbK8 Central African Republic: UN urges support to meet basic needs in hard-hit province]

[https://www.packtpub.com/books/content/what-openlayers OpenLayers]

[https://en.wikipedia.org/wiki/Central_African_Republic Wiki Page]

[https://www.youtube.com/watch?v=VoQAxQgevEA War in the Central African Republic (Full Length Documentary)]

CSC/ECE 517 Fall 2014/final S1455

2014-12-02T04:59:39Z

Vpiddem: /* Further Reading */

Please read the "README" file provided in expertizza. This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on their Central African Republic deployment.

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
====About Sahana Eden====
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few. It is highly configurable so that it can be used in a wide variety of different contexts and is easy to modify to build custom solutions. Different levels of support are available from both the voluntary Sahana Eden community and professional companies. Sahana focuses on Community and Professional Support.

====Getting to know the domain====

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

====Installation & tutorials====

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

Below is a high level overview to begin contributing to Sahana-

The code is in the folder: web2py/applications/eden

Inside that folder are folders for Models (define the data structure), Controllers (provide URLs to enable access to the data) & Views (HTML templates).

Each module within Sahana Eden will normally consist of one of each of these files:

Model: modules/s3db/modulename.py
Controller: controllers/modulename.py
View: views/modulename/index.html

In order to know which file to edit in order to change a particular function, you need to look at the URL. The Web2Py web framework maps URLs as follows:

http://host/application/controller/function

So, if you want to edit the Home page with the URL:

http://host/eden/default/index

This implies that you should look at the file eden/controllers/default.py and the index function within it which can be found by searching for the function title "def index():"

Tip: Sahana Eden makes heavy use of integrated resource controllers so the typical mapping is:

http://host/eden/module/resource

The resource refers to a table with the name module_resource in the file modules/s3db/<module>.py

==Introduction to project==

====Overview====
In the Central African Republic page, some data needs new models, and some models need tweaking. The purpose of this project is to identify any such requirement and make necessary changes. The general steps to follow in Sahana development are mentioned below-

1. Add/modify the core models in modules/s3db

2. Add REST controllers for new models

3. Check basic operations using automatic CRUD interface- tweak list_fields to the most-relevant fields perhaps

4. Add menu entries (modules/s3menus.py)

5. Develop XSLT & CSV templates (static/formats/s3csv) to bulk import the data

6. Convert the data to these CSV templates- use ogr2ogr for this

7. Add layers to the map (private/templates/<TEMPLATE>/gis_layer_feature.csv. Look at default for now) including Markers and tooltips (popup_format)

8. Provide some report_options to make a meaningful report

====Scope====
Four modules related to this deployment are-

1. Health - modules/s3db/hms.py

2. Transport - modules/s3db/transport.py

3. Water - modules/s3db/water.py

4. School - There is no separate module for education.

====Reference Material====

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-health Hospital Model]

[http://geonode.wfp.org/layers/geonode:wld_poi_bcp_wfp Border Control Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-roads Roads], [http://geonode.wfp.org/layers/geonode:wld_trs_supplyroutes_wfp Routes], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-aerodromes-airports-airfields Airports]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies Water Bodies], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies-0 Water Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-courses Rivers]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education Education]

==System Overview==

Sahana Eden Framework:

The Sahana Eden Software Platform has been built around a Rapid Application Development (RAD) Framework. This provides a high level of automation to ensure that new solutions can be quickly and effectively developed. Once a database table is defined, the Sahana Eden Framework automatically generates HTML pages to handle CRUD (Create, Read, Update, Delete) as well as Search, Map and Pivot Reports. Web Services are available to import and export in XML, CSV, JSON and EXtensible Stylesheet Language (XSL) transforms are supported to produce other data standards.

The Sahana Eden Framework has flexible authorization policies which can be configured to grant permissions for different modules, tables as well as the ability to have multiple Organizations control their own data on a single Sahana Eden installation.

Sahana Eden can be downloaded and run locally from a flash drive. Synchronization functionality allows data to be entered then keep up to date between different installations, including online servers and local flash drive installations. The Sahana Eden Framework also includes a scheduler for running tasks at a specific time, in regular intervals or as asynchronous tasks which are triggered by users.

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

Our focus is on Controllers, Models, Modules and views. For every action on various pages on Sahana Humanitarian website, there are set of controllers defined. As mentioned above, we want to focus on 4 models- health, transport, water and school.

<table class="wikitable">
<tr>
<th> Unicef Key
</th>
<th> Unicef value (number)
</th>
<th> OSM tag
</th></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:amenity" title="Key:amenity">amenity</a>=<a href="/wiki/Tag:amenity%3Dhospital" title="Tag:amenity=hospital">hospital</a></tt>
</td></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:source" title="Key:source">source</a>=<a href="/w/index.php?title=Tag:source%3DUNICEF&action=edit&redlink=1" class="new" title="Tag:source=UNICEF (page does not exist)">UNICEF</a></tt>
</td></tr>
<tr>
<td> ID
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> WPT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> FOSA_CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAT_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LONG_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PAYS
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PREF, SOUS_PREF, COMM, VILLE_VILL, QUARTIER
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:addr%CB%90full&action=edit&redlink=1" class="new" title="Key:addrːfull (page does not exist)">addrːfull</a>=*</tt>
</td></tr>
<tr>
<td> VILLE_VILL
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:addr:city" title="Key:addr:city" class="mw-redirect">addr:city</a>=*</tt>
</td></tr>
<tr>
<td> POP_VILLE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Public (306)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dgovernment&action=edit&redlink=1" class="new" title="Tag:operator:type=government (page does not exist)">government</a></tt>
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Prive (37)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dprivate&action=edit&redlink=1" class="new" title="Tag:operator:type=private (page does not exist)">private</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Poste de sante (204)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Ddispensary&action=edit&redlink=1" class="new" title="Tag:health facility:type=dispensary (page does not exist)">dispensary</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Centre de sante (with beds) (118)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dhealth_center&action=edit&redlink=1" class="new" title="Tag:health facility:type=health center (page does not exist)">health_center</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital prefectoral (7)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprefectoral_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=prefectoral hospital (page does not exist)">prefectoral_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital regional (3)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dregional_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=regional hospital (page does not exist)">regional_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Clinique privee (1)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprivate_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=private hospital (page does not exist)">private_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> No attribut (1)
</td>
<td> not to upload
</td></tr>
<tr>
<td> NOM_FOSA
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:name" title="Key:name">name</a>=*</tt>
</td></tr>
<tr>
<td> NB_LITS
</td>
<td> numbers 0-179
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:capacity:beds&action=edit&redlink=1" class="new" title="Key:capacity:beds (page does not exist)">capacity:beds</a>=*</tt>
</td></tr>
<tr>
<td> NB_PERS_SO
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> NB_PATIENT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> COMITE_WAS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> NB_PERS_WA
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LTA
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP_PLEIN
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> LATRINES_S
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAVE_MAINS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> INCINERATE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> BAC_A_ORDU
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> TOTAL_LATR
</td>
<td> numbers 0-23
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:toilets:number&action=edit&redlink=1" class="new" title="Key:toilets:number (page does not exist)">toilets:number</a>=*</tt>
</td></tr>
</table>

==System Architecture==
The basic Sahana Eden architecture is as follows:

<table style="width: 100%; border: 1px dotted rgb(0, 0, 0); border-collapse: collapse;" cellpadding="5"><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Server</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Apache</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Other web servers can also be used, such as Cherokee.</td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Application</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Sahana Eden</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Application Framework</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Web2Py</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Programming Language</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Python & Java Script</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Database</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">MySQL, PostgreSQL, or SQLite</td>
<td style="border: 1px dotted rgb(0, 0, 0);"><p>MySQL, PostgreSQL, and SQLite are supported.</p><p>Other databases should be usable without major additional work since Web2Py supplies many connectors.</p></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Operating System</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Linux (Debian recommended)</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Windows and Mac OS X are possible, but only recommended for single-user environments.</td>
</tr></table>

==Requirement Analysis==

The requirements state that some of the data needs new models. Also, the school database states that there is no module for education. Even on the [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education education website] of Central African Republic, it says that the data is incomplete. Addition of new module, say edu.py in s3db module, will solve this problem.

For the purpose of this project, we will need to follow these steps-

1. Installation and setup- Follow the installation guidelines provided by Sahana to build the system on individual machines. Then, do the setup for Git repository, i.e. forking Sahana eden repo and adding the original as remote branch.

2. Identify properties for "edu.py" and define the basic data model in the models/ folder.

3. Add corresponding controller which provides access to this resource. Create another new file, this time in the controllers/ folder.

4. Define Field Types- By default fields are created with type string, however we may wish to use other data types. All fields have both client-side widgets & server-side validation automatically added based on their data type.

5. Customize and Internationalize field labels- Field labels are automatically generated from the field names, however we are able to customize these by adding a 'label' attribute.

6. Add Links to other Resources.

7. Override default CRUD Strings.

8. Update the Menus- There are two levels of menu within the system: The top-level 'Modules Menu' is visible in all modules. Underneath that, each module has its own menu for for module-specific navigation.

9. Test the changes.

=== GIS Requirements ===
==== Understanding OpenLayers & GeoExt ====
OpenLayers is an open source, client side JavaScript library for making interactive web maps, viewable in nearly any web browser. Since it is a client side library, it requires no special server side so beware or settings—you can use it without even downloading anything.Originally developed by Metacarta, as a response, in part, to Google Maps, it has grown into a mature, popular framework with many passionate developers and a very helpful community.
*OpenLayers.Map
Here is an example that will create a page containing a full screen OpenLayers map. This is not the most basic of maps, but will work if you copy and paste the html content.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<style>
html,body {
height: 99%;
width: 99%;
}
#map {
width: 100%;
height: 100%;
border: 1px solid black;
}
</style>
<script src='http://openlayers.org/api/OpenLayers.js'>
</script>
</head>
<body>
< div id="map"></ div>
<script type="text/javascript">
var map = new OpenLayers.Map('map',{maxResolution: 0.703125} );
var wmscURL = [
"http://wmsc1.terrapages.net/getmap?",
"http://wmsc2.terrapages.net/getmap?",
"http://wmsc3.terrapages.net/getmap?",
"http://wmsc4.terrapages.net/getmap?"
];
var terrapagesStreetLayer = new OpenLayers.Layer.WMS( 'TerraPages Street',wmscURL, {layers: 'UnprojectedStreet', format: 'image/jpeg' }, {buffer: 1, isBaseLayer: true} );
map.addLayer(terrapagesStreetLayer);
map.zoomToMaxExtent();
</script>
</body>
</html>

*OpenLayers.Layer.Markers

Below is an example of how to create a Markers Layer, and add a single marker on that layer at the specified lon and lat. This will also apply an offest to the icon image, so that it can be aligned horizontally centered, vertically bottom over the position.

var markersLayer = new OpenLayers.Layer.Markers("My Marker Layer");
var iconSize = new OpenLayers.Size(20,20);
var iconOffset = new OpenLayers.Pixel(-(iconSize.w/2), -iconSize.h);
var marker = new OpenLayers.Marker(
new OpenLayers.LonLat(<<lon>>,<<lat>>),
new OpenLayers.Icon(<<iconURL>>,iconSize,iconOffset)
);
markersLayer.setVisibility(true);
markersLayer.addMarker(marker);
map.addLayer(markersLayer);

==== Add layers to the map ====
Sahana Eden makes use of Openlayers and GeoExt for its GIS module. A map is basically a combination of several stitched tiles which are rendered on the web page upon request. The overall map functionalities include displaying various hospital types, locations, heliports and other map related data.We are focusing on adding a new overlay layer to the existing map layers and as well using a customised image icon for displaying marker symbol for our overlay layer.

[[File:Map-screen.png]]

==Design Principles==

For our project, the best design principle applicable is "Open Close Principle". Since we are introducing a new module, there will definitely be extensions to it, but very few modifications.

The common features/functions will be encapsulated to ensure that the code is "DRY".

==Proposed Test Cases==

For end-user performance gains, Sahana Eden minimizes and compresses the CSS and JavaScript. While this approach works well for optimized end-user performance, to debug the CSS and JavaScript we shall enable debug mode in models/000_config.py in our Sahana Eden server with the following setting:

settings.base.debug = True

Once any changes to the CSS and JavaScript are working, then we can minimizes and compresses the CSS and JavaScript using:

static/scripts/tools/build.sahana.py

Although this uses a web service, you get better results by downloading a local version of the Closure Compiler (a tool for making JavaScript download and run faster) to static/scripts/tools. It is also possible to quickly view a single page in debug mode by adding the ?debug=1 variable to the end of a URL.

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

[http://sahanafoundation.org/sahana-launches-eurosha-humanitarian-data-site/ Sahana Launches EUROSHA Humanitarian Data Site]

[http://sahanafoundation.org/eurosha-volunteer-diary/ A EUROSHA Volunteer Diary]

[http://en.flossmanuals.net/sahana-eden/user-stories/ User stories]

[http://www.un.org/apps/news/story.asp?NewsID=49300#.VGLHHo_wbK8 Central African Republic: UN urges support to meet basic needs in hard-hit province]

[https://www.packtpub.com/books/content/what-openlayers OpenLayers]

[https://en.wikipedia.org/wiki/Central_African_Republic Wiki Page]

[https://www.youtube.com/watch?v=VoQAxQgevEA War in the Central African Republic (Full Length Documentary)]

CSC/ECE 517 Fall 2014/final S1455

2014-12-02T03:44:07Z

Vpiddem: /* Add layers to the map */

Please read the "README" file provided in expertizza. This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on their Central African Republic deployment.

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
====About Sahana Eden====
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few. It is highly configurable so that it can be used in a wide variety of different contexts and is easy to modify to build custom solutions. Different levels of support are available from both the voluntary Sahana Eden community and professional companies. Sahana focuses on Community and Professional Support.

====Getting to know the domain====

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

====Installation & tutorials====

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

Below is a high level overview to begin contributing to Sahana-

The code is in the folder: web2py/applications/eden

Inside that folder are folders for Models (define the data structure), Controllers (provide URLs to enable access to the data) & Views (HTML templates).

Each module within Sahana Eden will normally consist of one of each of these files:

Model: modules/s3db/modulename.py
Controller: controllers/modulename.py
View: views/modulename/index.html

In order to know which file to edit in order to change a particular function, you need to look at the URL. The Web2Py web framework maps URLs as follows:

http://host/application/controller/function

So, if you want to edit the Home page with the URL:

http://host/eden/default/index

This implies that you should look at the file eden/controllers/default.py and the index function within it which can be found by searching for the function title "def index():"

Tip: Sahana Eden makes heavy use of integrated resource controllers so the typical mapping is:

http://host/eden/module/resource

The resource refers to a table with the name module_resource in the file modules/s3db/<module>.py

==Introduction to project==

====Overview====
In the Central African Republic page, some data needs new models, and some models need tweaking. The purpose of this project is to identify any such requirement and make necessary changes. The general steps to follow in Sahana development are mentioned below-

1. Add/modify the core models in modules/s3db

2. Add REST controllers for new models

3. Check basic operations using automatic CRUD interface- tweak list_fields to the most-relevant fields perhaps

4. Add menu entries (modules/s3menus.py)

5. Develop XSLT & CSV templates (static/formats/s3csv) to bulk import the data

6. Convert the data to these CSV templates- use ogr2ogr for this

7. Add layers to the map (private/templates/<TEMPLATE>/gis_layer_feature.csv. Look at default for now) including Markers and tooltips (popup_format)

8. Provide some report_options to make a meaningful report

====Scope====
Four modules related to this deployment are-

1. Health - modules/s3db/hms.py

2. Transport - modules/s3db/transport.py

3. Water - modules/s3db/water.py

4. School - There is no separate module for education.

====Reference Material====

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-health Hospital Model]

[http://geonode.wfp.org/layers/geonode:wld_poi_bcp_wfp Border Control Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-roads Roads], [http://geonode.wfp.org/layers/geonode:wld_trs_supplyroutes_wfp Routes], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-aerodromes-airports-airfields Airports]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies Water Bodies], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies-0 Water Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-courses Rivers]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education Education]

==System Overview==

Sahana Eden Framework:

The Sahana Eden Software Platform has been built around a Rapid Application Development (RAD) Framework. This provides a high level of automation to ensure that new solutions can be quickly and effectively developed. Once a database table is defined, the Sahana Eden Framework automatically generates HTML pages to handle CRUD (Create, Read, Update, Delete) as well as Search, Map and Pivot Reports. Web Services are available to import and export in XML, CSV, JSON and EXtensible Stylesheet Language (XSL) transforms are supported to produce other data standards.

The Sahana Eden Framework has flexible authorization policies which can be configured to grant permissions for different modules, tables as well as the ability to have multiple Organizations control their own data on a single Sahana Eden installation.

Sahana Eden can be downloaded and run locally from a flash drive. Synchronization functionality allows data to be entered then keep up to date between different installations, including online servers and local flash drive installations. The Sahana Eden Framework also includes a scheduler for running tasks at a specific time, in regular intervals or as asynchronous tasks which are triggered by users.

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

Our focus is on Controllers, Models, Modules and views. For every action on various pages on Sahana Humanitarian website, there are set of controllers defined. As mentioned above, we want to focus on 4 models- health, transport, water and school.

<table class="wikitable">
<tr>
<th> Unicef Key
</th>
<th> Unicef value (number)
</th>
<th> OSM tag
</th></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:amenity" title="Key:amenity">amenity</a>=<a href="/wiki/Tag:amenity%3Dhospital" title="Tag:amenity=hospital">hospital</a></tt>
</td></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:source" title="Key:source">source</a>=<a href="/w/index.php?title=Tag:source%3DUNICEF&action=edit&redlink=1" class="new" title="Tag:source=UNICEF (page does not exist)">UNICEF</a></tt>
</td></tr>
<tr>
<td> ID
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> WPT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> FOSA_CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAT_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LONG_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PAYS
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PREF, SOUS_PREF, COMM, VILLE_VILL, QUARTIER
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:addr%CB%90full&action=edit&redlink=1" class="new" title="Key:addrːfull (page does not exist)">addrːfull</a>=*</tt>
</td></tr>
<tr>
<td> VILLE_VILL
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:addr:city" title="Key:addr:city" class="mw-redirect">addr:city</a>=*</tt>
</td></tr>
<tr>
<td> POP_VILLE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Public (306)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dgovernment&action=edit&redlink=1" class="new" title="Tag:operator:type=government (page does not exist)">government</a></tt>
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Prive (37)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dprivate&action=edit&redlink=1" class="new" title="Tag:operator:type=private (page does not exist)">private</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Poste de sante (204)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Ddispensary&action=edit&redlink=1" class="new" title="Tag:health facility:type=dispensary (page does not exist)">dispensary</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Centre de sante (with beds) (118)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dhealth_center&action=edit&redlink=1" class="new" title="Tag:health facility:type=health center (page does not exist)">health_center</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital prefectoral (7)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprefectoral_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=prefectoral hospital (page does not exist)">prefectoral_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital regional (3)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dregional_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=regional hospital (page does not exist)">regional_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Clinique privee (1)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprivate_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=private hospital (page does not exist)">private_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> No attribut (1)
</td>
<td> not to upload
</td></tr>
<tr>
<td> NOM_FOSA
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:name" title="Key:name">name</a>=*</tt>
</td></tr>
<tr>
<td> NB_LITS
</td>
<td> numbers 0-179
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:capacity:beds&action=edit&redlink=1" class="new" title="Key:capacity:beds (page does not exist)">capacity:beds</a>=*</tt>
</td></tr>
<tr>
<td> NB_PERS_SO
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> NB_PATIENT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> COMITE_WAS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> NB_PERS_WA
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LTA
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP_PLEIN
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> LATRINES_S
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAVE_MAINS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> INCINERATE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> BAC_A_ORDU
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> TOTAL_LATR
</td>
<td> numbers 0-23
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:toilets:number&action=edit&redlink=1" class="new" title="Key:toilets:number (page does not exist)">toilets:number</a>=*</tt>
</td></tr>
</table>

==System Architecture==
The basic Sahana Eden architecture is as follows:

<table style="width: 100%; border: 1px dotted rgb(0, 0, 0); border-collapse: collapse;" cellpadding="5"><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Server</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Apache</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Other web servers can also be used, such as Cherokee.</td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Application</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Sahana Eden</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Application Framework</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Web2Py</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Programming Language</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Python & Java Script</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Database</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">MySQL, PostgreSQL, or SQLite</td>
<td style="border: 1px dotted rgb(0, 0, 0);"><p>MySQL, PostgreSQL, and SQLite are supported.</p><p>Other databases should be usable without major additional work since Web2Py supplies many connectors.</p></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Operating System</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Linux (Debian recommended)</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Windows and Mac OS X are possible, but only recommended for single-user environments.</td>
</tr></table>

==Requirement Analysis==

The requirements state that some of the data needs new models. Also, the school database states that there is no module for education. Even on the [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education education website] of Central African Republic, it says that the data is incomplete. Addition of new module, say edu.py in s3db module, will solve this problem.

For the purpose of this project, we will need to follow these steps-

1. Installation and setup- Follow the installation guidelines provided by Sahana to build the system on individual machines. Then, do the setup for Git repository, i.e. forking Sahana eden repo and adding the original as remote branch.

2. Identify properties for "edu.py" and define the basic data model in the models/ folder.

3. Add corresponding controller which provides access to this resource. Create another new file, this time in the controllers/ folder.

4. Define Field Types- By default fields are created with type string, however we may wish to use other data types. All fields have both client-side widgets & server-side validation automatically added based on their data type.

5. Customize and Internationalize field labels- Field labels are automatically generated from the field names, however we are able to customize these by adding a 'label' attribute.

6. Add Links to other Resources.

7. Override default CRUD Strings.

8. Update the Menus- There are two levels of menu within the system: The top-level 'Modules Menu' is visible in all modules. Underneath that, each module has its own menu for for module-specific navigation.

9. Test the changes.

=== GIS Requirements ===
==== Understanding OpenLayers & GeoExt ====
OpenLayers is an open source, client side JavaScript library for making interactive web maps, viewable in nearly any web browser. Since it is a client side library, it requires no special server side so beware or settings—you can use it without even downloading anything.Originally developed by Metacarta, as a response, in part, to Google Maps, it has grown into a mature, popular framework with many passionate developers and a very helpful community.
*OpenLayers.Map
Here is an example that will create a page containing a full screen OpenLayers map. This is not the most basic of maps, but will work if you copy and paste the html content.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<style>
html,body {
height: 99%;
width: 99%;
}
#map {
width: 100%;
height: 100%;
border: 1px solid black;
}
</style>
<script src='http://openlayers.org/api/OpenLayers.js'>
</script>
</head>
<body>
< div id="map"></ div>
<script type="text/javascript">
var map = new OpenLayers.Map('map',{maxResolution: 0.703125} );
var wmscURL = [
"http://wmsc1.terrapages.net/getmap?",
"http://wmsc2.terrapages.net/getmap?",
"http://wmsc3.terrapages.net/getmap?",
"http://wmsc4.terrapages.net/getmap?"
];
var terrapagesStreetLayer = new OpenLayers.Layer.WMS( 'TerraPages Street',wmscURL, {layers: 'UnprojectedStreet', format: 'image/jpeg' }, {buffer: 1, isBaseLayer: true} );
map.addLayer(terrapagesStreetLayer);
map.zoomToMaxExtent();
</script>
</body>
</html>

*OpenLayers.Layer.Markers

Below is an example of how to create a Markers Layer, and add a single marker on that layer at the specified lon and lat. This will also apply an offest to the icon image, so that it can be aligned horizontally centered, vertically bottom over the position.

var markersLayer = new OpenLayers.Layer.Markers("My Marker Layer");
var iconSize = new OpenLayers.Size(20,20);
var iconOffset = new OpenLayers.Pixel(-(iconSize.w/2), -iconSize.h);
var marker = new OpenLayers.Marker(
new OpenLayers.LonLat(<<lon>>,<<lat>>),
new OpenLayers.Icon(<<iconURL>>,iconSize,iconOffset)
);
markersLayer.setVisibility(true);
markersLayer.addMarker(marker);
map.addLayer(markersLayer);

==== Add layers to the map ====
Sahana Eden makes use of Openlayers and GeoExt for its GIS module. A map is basically a combination of several stitched tiles which are rendered on the web page upon request. The overall map functionalities include displaying various hospital types, locations, heliports and other map related data.We are focusing on adding a new overlay layer to the existing map layers and as well using a customised image icon for displaying marker symbol for our overlay layer.

[[File:Map-screen.png]]

==Design Principles==

For our project, the best design principle applicable is "Open Close Principle". Since we are introducing a new module, there will definitely be extensions to it, but very few modifications.

The common features/functions will be encapsulated to ensure that the code is "DRY".

==Proposed Test Cases==

For end-user performance gains, Sahana Eden minimizes and compresses the CSS and JavaScript. While this approach works well for optimized end-user performance, to debug the CSS and JavaScript we shall enable debug mode in models/000_config.py in our Sahana Eden server with the following setting:

settings.base.debug = True

Once any changes to the CSS and JavaScript are working, then we can minimizes and compresses the CSS and JavaScript using:

static/scripts/tools/build.sahana.py

Although this uses a web service, you get better results by downloading a local version of the Closure Compiler (a tool for making JavaScript download and run faster) to static/scripts/tools. It is also possible to quickly view a single page in debug mode by adding the ?debug=1 variable to the end of a URL.

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

[http://sahanafoundation.org/sahana-launches-eurosha-humanitarian-data-site/ Sahana Launches EUROSHA Humanitarian Data Site]

[http://sahanafoundation.org/eurosha-volunteer-diary/ A EUROSHA Volunteer Diary]

[http://en.flossmanuals.net/sahana-eden/user-stories/ User stories]

[http://www.un.org/apps/news/story.asp?NewsID=49300#.VGLHHo_wbK8 Central African Republic: UN urges support to meet basic needs in hard-hit province]

[https://en.wikipedia.org/wiki/Central_African_Republic Wiki Page]

[https://www.youtube.com/watch?v=VoQAxQgevEA War in the Central African Republic (Full Length Documentary)]

File:Map-screen.png

2014-12-02T03:42:48Z

Vpiddem: hms module Map

hms module Map

File:Hms-mapoverlays.png

2014-12-02T03:40:07Z

Vpiddem: Sahana Overlays-Map Hms

Sahana Overlays-Map Hms

CSC/ECE 517 Fall 2014/final S1455

2014-12-02T03:38:26Z

Vpiddem: /* Understanding OpenLayers & GeoExt */

Please read the "README" file provided in expertizza. This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on their Central African Republic deployment.

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
====About Sahana Eden====
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few. It is highly configurable so that it can be used in a wide variety of different contexts and is easy to modify to build custom solutions. Different levels of support are available from both the voluntary Sahana Eden community and professional companies. Sahana focuses on Community and Professional Support.

====Getting to know the domain====

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

====Installation & tutorials====

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

Below is a high level overview to begin contributing to Sahana-

The code is in the folder: web2py/applications/eden

Inside that folder are folders for Models (define the data structure), Controllers (provide URLs to enable access to the data) & Views (HTML templates).

Each module within Sahana Eden will normally consist of one of each of these files:

Model: modules/s3db/modulename.py
Controller: controllers/modulename.py
View: views/modulename/index.html

In order to know which file to edit in order to change a particular function, you need to look at the URL. The Web2Py web framework maps URLs as follows:

http://host/application/controller/function

So, if you want to edit the Home page with the URL:

http://host/eden/default/index

This implies that you should look at the file eden/controllers/default.py and the index function within it which can be found by searching for the function title "def index():"

Tip: Sahana Eden makes heavy use of integrated resource controllers so the typical mapping is:

http://host/eden/module/resource

The resource refers to a table with the name module_resource in the file modules/s3db/<module>.py

==Introduction to project==

====Overview====
In the Central African Republic page, some data needs new models, and some models need tweaking. The purpose of this project is to identify any such requirement and make necessary changes. The general steps to follow in Sahana development are mentioned below-

1. Add/modify the core models in modules/s3db

2. Add REST controllers for new models

3. Check basic operations using automatic CRUD interface- tweak list_fields to the most-relevant fields perhaps

4. Add menu entries (modules/s3menus.py)

5. Develop XSLT & CSV templates (static/formats/s3csv) to bulk import the data

6. Convert the data to these CSV templates- use ogr2ogr for this

7. Add layers to the map (private/templates/<TEMPLATE>/gis_layer_feature.csv. Look at default for now) including Markers and tooltips (popup_format)

8. Provide some report_options to make a meaningful report

====Scope====
Four modules related to this deployment are-

1. Health - modules/s3db/hms.py

2. Transport - modules/s3db/transport.py

3. Water - modules/s3db/water.py

4. School - There is no separate module for education.

====Reference Material====

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-health Hospital Model]

[http://geonode.wfp.org/layers/geonode:wld_poi_bcp_wfp Border Control Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-roads Roads], [http://geonode.wfp.org/layers/geonode:wld_trs_supplyroutes_wfp Routes], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-aerodromes-airports-airfields Airports]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies Water Bodies], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies-0 Water Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-courses Rivers]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education Education]

==System Overview==

Sahana Eden Framework:

The Sahana Eden Software Platform has been built around a Rapid Application Development (RAD) Framework. This provides a high level of automation to ensure that new solutions can be quickly and effectively developed. Once a database table is defined, the Sahana Eden Framework automatically generates HTML pages to handle CRUD (Create, Read, Update, Delete) as well as Search, Map and Pivot Reports. Web Services are available to import and export in XML, CSV, JSON and EXtensible Stylesheet Language (XSL) transforms are supported to produce other data standards.

The Sahana Eden Framework has flexible authorization policies which can be configured to grant permissions for different modules, tables as well as the ability to have multiple Organizations control their own data on a single Sahana Eden installation.

Sahana Eden can be downloaded and run locally from a flash drive. Synchronization functionality allows data to be entered then keep up to date between different installations, including online servers and local flash drive installations. The Sahana Eden Framework also includes a scheduler for running tasks at a specific time, in regular intervals or as asynchronous tasks which are triggered by users.

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

Our focus is on Controllers, Models, Modules and views. For every action on various pages on Sahana Humanitarian website, there are set of controllers defined. As mentioned above, we want to focus on 4 models- health, transport, water and school.

<table class="wikitable">
<tr>
<th> Unicef Key
</th>
<th> Unicef value (number)
</th>
<th> OSM tag
</th></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:amenity" title="Key:amenity">amenity</a>=<a href="/wiki/Tag:amenity%3Dhospital" title="Tag:amenity=hospital">hospital</a></tt>
</td></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:source" title="Key:source">source</a>=<a href="/w/index.php?title=Tag:source%3DUNICEF&action=edit&redlink=1" class="new" title="Tag:source=UNICEF (page does not exist)">UNICEF</a></tt>
</td></tr>
<tr>
<td> ID
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> WPT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> FOSA_CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAT_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LONG_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PAYS
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PREF, SOUS_PREF, COMM, VILLE_VILL, QUARTIER
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:addr%CB%90full&action=edit&redlink=1" class="new" title="Key:addrːfull (page does not exist)">addrːfull</a>=*</tt>
</td></tr>
<tr>
<td> VILLE_VILL
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:addr:city" title="Key:addr:city" class="mw-redirect">addr:city</a>=*</tt>
</td></tr>
<tr>
<td> POP_VILLE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Public (306)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dgovernment&action=edit&redlink=1" class="new" title="Tag:operator:type=government (page does not exist)">government</a></tt>
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Prive (37)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dprivate&action=edit&redlink=1" class="new" title="Tag:operator:type=private (page does not exist)">private</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Poste de sante (204)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Ddispensary&action=edit&redlink=1" class="new" title="Tag:health facility:type=dispensary (page does not exist)">dispensary</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Centre de sante (with beds) (118)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dhealth_center&action=edit&redlink=1" class="new" title="Tag:health facility:type=health center (page does not exist)">health_center</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital prefectoral (7)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprefectoral_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=prefectoral hospital (page does not exist)">prefectoral_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital regional (3)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dregional_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=regional hospital (page does not exist)">regional_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Clinique privee (1)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprivate_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=private hospital (page does not exist)">private_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> No attribut (1)
</td>
<td> not to upload
</td></tr>
<tr>
<td> NOM_FOSA
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:name" title="Key:name">name</a>=*</tt>
</td></tr>
<tr>
<td> NB_LITS
</td>
<td> numbers 0-179
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:capacity:beds&action=edit&redlink=1" class="new" title="Key:capacity:beds (page does not exist)">capacity:beds</a>=*</tt>
</td></tr>
<tr>
<td> NB_PERS_SO
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> NB_PATIENT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> COMITE_WAS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> NB_PERS_WA
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LTA
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP_PLEIN
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> LATRINES_S
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAVE_MAINS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> INCINERATE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> BAC_A_ORDU
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> TOTAL_LATR
</td>
<td> numbers 0-23
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:toilets:number&action=edit&redlink=1" class="new" title="Key:toilets:number (page does not exist)">toilets:number</a>=*</tt>
</td></tr>
</table>

==System Architecture==
The basic Sahana Eden architecture is as follows:

<table style="width: 100%; border: 1px dotted rgb(0, 0, 0); border-collapse: collapse;" cellpadding="5"><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Server</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Apache</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Other web servers can also be used, such as Cherokee.</td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Application</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Sahana Eden</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Application Framework</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Web2Py</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Programming Language</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Python & Java Script</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Database</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">MySQL, PostgreSQL, or SQLite</td>
<td style="border: 1px dotted rgb(0, 0, 0);"><p>MySQL, PostgreSQL, and SQLite are supported.</p><p>Other databases should be usable without major additional work since Web2Py supplies many connectors.</p></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Operating System</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Linux (Debian recommended)</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Windows and Mac OS X are possible, but only recommended for single-user environments.</td>
</tr></table>

==Requirement Analysis==

The requirements state that some of the data needs new models. Also, the school database states that there is no module for education. Even on the [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education education website] of Central African Republic, it says that the data is incomplete. Addition of new module, say edu.py in s3db module, will solve this problem.

For the purpose of this project, we will need to follow these steps-

1. Installation and setup- Follow the installation guidelines provided by Sahana to build the system on individual machines. Then, do the setup for Git repository, i.e. forking Sahana eden repo and adding the original as remote branch.

2. Identify properties for "edu.py" and define the basic data model in the models/ folder.

3. Add corresponding controller which provides access to this resource. Create another new file, this time in the controllers/ folder.

4. Define Field Types- By default fields are created with type string, however we may wish to use other data types. All fields have both client-side widgets & server-side validation automatically added based on their data type.

5. Customize and Internationalize field labels- Field labels are automatically generated from the field names, however we are able to customize these by adding a 'label' attribute.

6. Add Links to other Resources.

7. Override default CRUD Strings.

8. Update the Menus- There are two levels of menu within the system: The top-level 'Modules Menu' is visible in all modules. Underneath that, each module has its own menu for for module-specific navigation.

9. Test the changes.

=== GIS Requirements ===
==== Understanding OpenLayers & GeoExt ====
OpenLayers is an open source, client side JavaScript library for making interactive web maps, viewable in nearly any web browser. Since it is a client side library, it requires no special server side so beware or settings—you can use it without even downloading anything.Originally developed by Metacarta, as a response, in part, to Google Maps, it has grown into a mature, popular framework with many passionate developers and a very helpful community.
*OpenLayers.Map
Here is an example that will create a page containing a full screen OpenLayers map. This is not the most basic of maps, but will work if you copy and paste the html content.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<style>
html,body {
height: 99%;
width: 99%;
}
#map {
width: 100%;
height: 100%;
border: 1px solid black;
}
</style>
<script src='http://openlayers.org/api/OpenLayers.js'>
</script>
</head>
<body>
< div id="map"></ div>
<script type="text/javascript">
var map = new OpenLayers.Map('map',{maxResolution: 0.703125} );
var wmscURL = [
"http://wmsc1.terrapages.net/getmap?",
"http://wmsc2.terrapages.net/getmap?",
"http://wmsc3.terrapages.net/getmap?",
"http://wmsc4.terrapages.net/getmap?"
];
var terrapagesStreetLayer = new OpenLayers.Layer.WMS( 'TerraPages Street',wmscURL, {layers: 'UnprojectedStreet', format: 'image/jpeg' }, {buffer: 1, isBaseLayer: true} );
map.addLayer(terrapagesStreetLayer);
map.zoomToMaxExtent();
</script>
</body>
</html>

*OpenLayers.Layer.Markers

Below is an example of how to create a Markers Layer, and add a single marker on that layer at the specified lon and lat. This will also apply an offest to the icon image, so that it can be aligned horizontally centered, vertically bottom over the position.

var markersLayer = new OpenLayers.Layer.Markers("My Marker Layer");
var iconSize = new OpenLayers.Size(20,20);
var iconOffset = new OpenLayers.Pixel(-(iconSize.w/2), -iconSize.h);
var marker = new OpenLayers.Marker(
new OpenLayers.LonLat(<<lon>>,<<lat>>),
new OpenLayers.Icon(<<iconURL>>,iconSize,iconOffset)
);
markersLayer.setVisibility(true);
markersLayer.addMarker(marker);
map.addLayer(markersLayer);

==== Add layers to the map ====
Sahana Eden makes use of Openlayers and GeoExt for its GIS module. A map is basically a combination of several stitched tiles which are rendered on the web page upon request. The overall map functionalities include displaying various hospital types, locations, heliports and other map related data.We are focusing on adding a new overlay layer to the existing map layers and as well using a customised image icon for displaying marker symbol for our overlay layer.

==Design Principles==

For our project, the best design principle applicable is "Open Close Principle". Since we are introducing a new module, there will definitely be extensions to it, but very few modifications.

The common features/functions will be encapsulated to ensure that the code is "DRY".

==Proposed Test Cases==

For end-user performance gains, Sahana Eden minimizes and compresses the CSS and JavaScript. While this approach works well for optimized end-user performance, to debug the CSS and JavaScript we shall enable debug mode in models/000_config.py in our Sahana Eden server with the following setting:

settings.base.debug = True

Once any changes to the CSS and JavaScript are working, then we can minimizes and compresses the CSS and JavaScript using:

static/scripts/tools/build.sahana.py

Although this uses a web service, you get better results by downloading a local version of the Closure Compiler (a tool for making JavaScript download and run faster) to static/scripts/tools. It is also possible to quickly view a single page in debug mode by adding the ?debug=1 variable to the end of a URL.

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

[http://sahanafoundation.org/sahana-launches-eurosha-humanitarian-data-site/ Sahana Launches EUROSHA Humanitarian Data Site]

[http://sahanafoundation.org/eurosha-volunteer-diary/ A EUROSHA Volunteer Diary]

[http://en.flossmanuals.net/sahana-eden/user-stories/ User stories]

[http://www.un.org/apps/news/story.asp?NewsID=49300#.VGLHHo_wbK8 Central African Republic: UN urges support to meet basic needs in hard-hit province]

[https://en.wikipedia.org/wiki/Central_African_Republic Wiki Page]

[https://www.youtube.com/watch?v=VoQAxQgevEA War in the Central African Republic (Full Length Documentary)]

CSC/ECE 517 Fall 2014/final S1455

2014-12-02T03:35:00Z

Vpiddem: /* Requirement Analysis */

Please read the "README" file provided in expertizza. This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on their Central African Republic deployment.

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
====About Sahana Eden====
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few. It is highly configurable so that it can be used in a wide variety of different contexts and is easy to modify to build custom solutions. Different levels of support are available from both the voluntary Sahana Eden community and professional companies. Sahana focuses on Community and Professional Support.

====Getting to know the domain====

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

====Installation & tutorials====

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

Below is a high level overview to begin contributing to Sahana-

The code is in the folder: web2py/applications/eden

Inside that folder are folders for Models (define the data structure), Controllers (provide URLs to enable access to the data) & Views (HTML templates).

Each module within Sahana Eden will normally consist of one of each of these files:

Model: modules/s3db/modulename.py
Controller: controllers/modulename.py
View: views/modulename/index.html

In order to know which file to edit in order to change a particular function, you need to look at the URL. The Web2Py web framework maps URLs as follows:

http://host/application/controller/function

So, if you want to edit the Home page with the URL:

http://host/eden/default/index

This implies that you should look at the file eden/controllers/default.py and the index function within it which can be found by searching for the function title "def index():"

Tip: Sahana Eden makes heavy use of integrated resource controllers so the typical mapping is:

http://host/eden/module/resource

The resource refers to a table with the name module_resource in the file modules/s3db/<module>.py

==Introduction to project==

====Overview====
In the Central African Republic page, some data needs new models, and some models need tweaking. The purpose of this project is to identify any such requirement and make necessary changes. The general steps to follow in Sahana development are mentioned below-

1. Add/modify the core models in modules/s3db

2. Add REST controllers for new models

3. Check basic operations using automatic CRUD interface- tweak list_fields to the most-relevant fields perhaps

4. Add menu entries (modules/s3menus.py)

5. Develop XSLT & CSV templates (static/formats/s3csv) to bulk import the data

6. Convert the data to these CSV templates- use ogr2ogr for this

7. Add layers to the map (private/templates/<TEMPLATE>/gis_layer_feature.csv. Look at default for now) including Markers and tooltips (popup_format)

8. Provide some report_options to make a meaningful report

====Scope====
Four modules related to this deployment are-

1. Health - modules/s3db/hms.py

2. Transport - modules/s3db/transport.py

3. Water - modules/s3db/water.py

4. School - There is no separate module for education.

====Reference Material====

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-health Hospital Model]

[http://geonode.wfp.org/layers/geonode:wld_poi_bcp_wfp Border Control Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-roads Roads], [http://geonode.wfp.org/layers/geonode:wld_trs_supplyroutes_wfp Routes], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-aerodromes-airports-airfields Airports]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies Water Bodies], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-bodies-0 Water Points], [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-water-courses Rivers]

[http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education Education]

==System Overview==

Sahana Eden Framework:

The Sahana Eden Software Platform has been built around a Rapid Application Development (RAD) Framework. This provides a high level of automation to ensure that new solutions can be quickly and effectively developed. Once a database table is defined, the Sahana Eden Framework automatically generates HTML pages to handle CRUD (Create, Read, Update, Delete) as well as Search, Map and Pivot Reports. Web Services are available to import and export in XML, CSV, JSON and EXtensible Stylesheet Language (XSL) transforms are supported to produce other data standards.

The Sahana Eden Framework has flexible authorization policies which can be configured to grant permissions for different modules, tables as well as the ability to have multiple Organizations control their own data on a single Sahana Eden installation.

Sahana Eden can be downloaded and run locally from a flash drive. Synchronization functionality allows data to be entered then keep up to date between different installations, including online servers and local flash drive installations. The Sahana Eden Framework also includes a scheduler for running tasks at a specific time, in regular intervals or as asynchronous tasks which are triggered by users.

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

Our focus is on Controllers, Models, Modules and views. For every action on various pages on Sahana Humanitarian website, there are set of controllers defined. As mentioned above, we want to focus on 4 models- health, transport, water and school.

<table class="wikitable">
<tr>
<th> Unicef Key
</th>
<th> Unicef value (number)
</th>
<th> OSM tag
</th></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:amenity" title="Key:amenity">amenity</a>=<a href="/wiki/Tag:amenity%3Dhospital" title="Tag:amenity=hospital">hospital</a></tt>
</td></tr>
<tr>
<td> all objects
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:source" title="Key:source">source</a>=<a href="/w/index.php?title=Tag:source%3DUNICEF&action=edit&redlink=1" class="new" title="Tag:source=UNICEF (page does not exist)">UNICEF</a></tt>
</td></tr>
<tr>
<td> ID
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> WPT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> FOSA_CODE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAT_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LONG_DD
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PAYS
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> PREF, SOUS_PREF, COMM, VILLE_VILL, QUARTIER
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:addr%CB%90full&action=edit&redlink=1" class="new" title="Key:addrːfull (page does not exist)">addrːfull</a>=*</tt>
</td></tr>
<tr>
<td> VILLE_VILL
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:addr:city" title="Key:addr:city" class="mw-redirect">addr:city</a>=*</tt>
</td></tr>
<tr>
<td> POP_VILLE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Public (306)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dgovernment&action=edit&redlink=1" class="new" title="Tag:operator:type=government (page does not exist)">government</a></tt>
</td></tr>
<tr>
<td> STATUT_FOS
</td>
<td> Prive (37)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:operator:type" title="Key:operator:type">operator:type</a>=<a href="/w/index.php?title=Tag:operator:type%3Dprivate&action=edit&redlink=1" class="new" title="Tag:operator:type=private (page does not exist)">private</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Poste de sante (204)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Ddispensary&action=edit&redlink=1" class="new" title="Tag:health facility:type=dispensary (page does not exist)">dispensary</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Centre de sante (with beds) (118)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dhealth_center&action=edit&redlink=1" class="new" title="Tag:health facility:type=health center (page does not exist)">health_center</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital prefectoral (7)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprefectoral_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=prefectoral hospital (page does not exist)">prefectoral_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Hopital regional (3)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dregional_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=regional hospital (page does not exist)">regional_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> Clinique privee (1)
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:health_facility:type&action=edit&redlink=1" class="new" title="Key:health facility:type (page does not exist)">health_facility:type</a>=<a href="/w/index.php?title=Tag:health_facility:type%3Dprivate_hospital&action=edit&redlink=1" class="new" title="Tag:health facility:type=private hospital (page does not exist)">private_hospital</a></tt>
</td></tr>
<tr>
<td> TYPE_FOSA
</td>
<td> No attribut (1)
</td>
<td> not to upload
</td></tr>
<tr>
<td> NOM_FOSA
</td>
<td>
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/wiki/Key:name" title="Key:name">name</a>=*</tt>
</td></tr>
<tr>
<td> NB_LITS
</td>
<td> numbers 0-179
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:capacity:beds&action=edit&redlink=1" class="new" title="Key:capacity:beds (page does not exist)">capacity:beds</a>=*</tt>
</td></tr>
<tr>
<td> NB_PERS_SO
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> NB_PATIENT
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> COMITE_WAS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> NB_PERS_WA
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LTA
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> VIP_PLEIN
</td>
<td>
</td>
<td> not tagged because unknown meaning
</td></tr>
<tr>
<td> LATRINES_S
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> LAVE_MAINS
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> INCINERATE
</td>
<td>
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> BAC_A_ORDU
</td>
<td> Oui/Non
</td>
<td> not tagged because not relevant
</td></tr>
<tr>
<td> TOTAL_LATR
</td>
<td> numbers 0-23
</td>
<td> <tt style="background-color:#dde; white-space:pre;" dir="ltr"><a href="/w/index.php?title=Key:toilets:number&action=edit&redlink=1" class="new" title="Key:toilets:number (page does not exist)">toilets:number</a>=*</tt>
</td></tr>
</table>

==System Architecture==
The basic Sahana Eden architecture is as follows:

<table style="width: 100%; border: 1px dotted rgb(0, 0, 0); border-collapse: collapse;" cellpadding="5"><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Server</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Apache</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Other web servers can also be used, such as Cherokee.</td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Application</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Sahana Eden</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Web Application Framework</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Web2Py</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Programming Language</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Python & Java Script</td>
<td style="border: 1px dotted rgb(0, 0, 0);"></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Database</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">MySQL, PostgreSQL, or SQLite</td>
<td style="border: 1px dotted rgb(0, 0, 0);"><p>MySQL, PostgreSQL, and SQLite are supported.</p><p>Other databases should be usable without major additional work since Web2Py supplies many connectors.</p></td>
</tr><tr><td style="border: 1px dotted rgb(0, 0, 0);"><strong>Operating System</strong></td>
<td style="border: 1px dotted rgb(0, 0, 0);">Linux (Debian recommended)</td>
<td style="border: 1px dotted rgb(0, 0, 0);">Windows and Mac OS X are possible, but only recommended for single-user environments.</td>
</tr></table>

==Requirement Analysis==

The requirements state that some of the data needs new models. Also, the school database states that there is no module for education. Even on the [http://www.humanitarianresponse.info/operations/central-african-republic/dataset/central-african-republic-education education website] of Central African Republic, it says that the data is incomplete. Addition of new module, say edu.py in s3db module, will solve this problem.

For the purpose of this project, we will need to follow these steps-

1. Installation and setup- Follow the installation guidelines provided by Sahana to build the system on individual machines. Then, do the setup for Git repository, i.e. forking Sahana eden repo and adding the original as remote branch.

2. Identify properties for "edu.py" and define the basic data model in the models/ folder.

3. Add corresponding controller which provides access to this resource. Create another new file, this time in the controllers/ folder.

4. Define Field Types- By default fields are created with type string, however we may wish to use other data types. All fields have both client-side widgets & server-side validation automatically added based on their data type.

5. Customize and Internationalize field labels- Field labels are automatically generated from the field names, however we are able to customize these by adding a 'label' attribute.

6. Add Links to other Resources.

7. Override default CRUD Strings.

8. Update the Menus- There are two levels of menu within the system: The top-level 'Modules Menu' is visible in all modules. Underneath that, each module has its own menu for for module-specific navigation.

9. Test the changes.

=== GIS Requirements ===
==== Understanding OpenLayers & GeoExt ====
OpenLayers is an open source, client side JavaScript library for making interactive web maps, viewable in nearly any web browser. Since it is a client side library, it requires no special server side so beware or settings—you can use it without even downloading anything.Originally developed by Metacarta, as a response, in part, to Google Maps, it has grown into a mature, popular framework with many passionate developers and a very helpful community.
*OpenLayers.Map
Here is an example that will create a page containing a full screen OpenLayers map. This is not the most basic of maps, but will work if you copy and paste the html content.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<style>
html,body {
height: 99%;
width: 99%;
}
#map {
width: 100%;
height: 100%;
border: 1px solid black;
}
</style>
<script src='http://openlayers.org/api/OpenLayers.js'></script>
</head>
<body>
<div id='map'></div>
<script type="text/javascript">
var map = new OpenLayers.Map('map',{maxResolution: 0.703125} );
var wmscURL = [
"http://wmsc1.terrapages.net/getmap?",
"http://wmsc2.terrapages.net/getmap?",
"http://wmsc3.terrapages.net/getmap?",
"http://wmsc4.terrapages.net/getmap?"
];
var terrapagesStreetLayer = new OpenLayers.Layer.WMS( 'TerraPages Street',wmscURL, {layers: 'UnprojectedStreet', format: 'image/jpeg' }, {buffer: 1, isBaseLayer: true} );
map.addLayer(terrapagesStreetLayer);
map.zoomToMaxExtent();
</script>
</body>
</html>

*OpenLayers.Layer.Markers

Below is an example of how to create a Markers Layer, and add a single marker on that layer at the specified lon and lat. This will also apply an offest to the icon image, so that it can be aligned horizontally centered, vertically bottom over the position.

var markersLayer = new OpenLayers.Layer.Markers("My Marker Layer");
var iconSize = new OpenLayers.Size(20,20);
var iconOffset = new OpenLayers.Pixel(-(iconSize.w/2), -iconSize.h);
var marker = new OpenLayers.Marker(
new OpenLayers.LonLat(<<lon>>,<<lat>>),
new OpenLayers.Icon(<<iconURL>>,iconSize,iconOffset)
);
markersLayer.setVisibility(true);
markersLayer.addMarker(marker);
map.addLayer(markersLayer);

==== Add layers to the map ====
Sahana Eden makes use of Openlayers and GeoExt for its GIS module. A map is basically a combination of several stitched tiles which are rendered on the web page upon request. The overall map functionalities include displaying various hospital types, locations, heliports and other map related data.We are focusing on adding a new overlay layer to the existing map layers and as well using a customised image icon for displaying marker symbol for our overlay layer.

==Design Principles==

For our project, the best design principle applicable is "Open Close Principle". Since we are introducing a new module, there will definitely be extensions to it, but very few modifications.

The common features/functions will be encapsulated to ensure that the code is "DRY".

==Proposed Test Cases==

For end-user performance gains, Sahana Eden minimizes and compresses the CSS and JavaScript. While this approach works well for optimized end-user performance, to debug the CSS and JavaScript we shall enable debug mode in models/000_config.py in our Sahana Eden server with the following setting:

settings.base.debug = True

Once any changes to the CSS and JavaScript are working, then we can minimizes and compresses the CSS and JavaScript using:

static/scripts/tools/build.sahana.py

Although this uses a web service, you get better results by downloading a local version of the Closure Compiler (a tool for making JavaScript download and run faster) to static/scripts/tools. It is also possible to quickly view a single page in debug mode by adding the ?debug=1 variable to the end of a URL.

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

[http://sahanafoundation.org/sahana-launches-eurosha-humanitarian-data-site/ Sahana Launches EUROSHA Humanitarian Data Site]

[http://sahanafoundation.org/eurosha-volunteer-diary/ A EUROSHA Volunteer Diary]

[http://en.flossmanuals.net/sahana-eden/user-stories/ User stories]

[http://www.un.org/apps/news/story.asp?NewsID=49300#.VGLHHo_wbK8 Central African Republic: UN urges support to meet basic needs in hard-hit province]

[https://en.wikipedia.org/wiki/Central_African_Republic Wiki Page]

[https://www.youtube.com/watch?v=VoQAxQgevEA War in the Central African Republic (Full Length Documentary)]

CSC/ECE 517 Fall 2014/final S1455

2014-11-12T01:03:11Z

Vpiddem: /* Installation & tutorials */

This wiki page contains design details for the project for Sahana Eden Humanitarian Platform, on [http://eden.sahanafoundation.org/wiki/Deployments/CAR Central African Republic].

{| border="1" class="wikitable" style="float:{{{align|right}}}"
|colspan="2" align="center" |[[File:SahanaLogo.png|center|Sahana]]
|-

== Background Information ==
===About Sahana Eden===
Sahana Eden is an Open Source Humanitarian Platform, which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. It is supported by the Sahana Software Foundation, Used in many Deployments, such as Ebola, Kashmir Floods, Hurricane Sandy, just to name a few.

===Installation & tutorials===

Anyone who wishes to contribute their development skill to Sahana, can do so with the help of an elaborate guide they have provided, that covers everything from [http://eden.sahanafoundation.org/wiki/InstallationGuidelines installation] to [http://eden.sahanafoundation.org/wiki/Book tutorials] on Python. Once the installations are complete, you can simply identify a task you are interested in, and start working on it. You may also want to sign their [https://docs.google.com/a/ncsu.edu/spreadsheet/viewform?formkey=dEp5czdPYThPY2htX2pNM1JGaTBrRGc6MQ#gid=0 Contributor's License Agreement] before making any pull request.

===Getting to know the domain===

Their [http://eden.sahanafoundation.org/wiki/Domain domain] page elaborately describes various major management projects and deployments that are done in the past or are ongoing. Spending some time to understand goals and purposes of Sahana before starting with actual development might help making the code better and more sensible from Sahana's perspective.

==Introduction to project==

===Scope===

===Overview===

===Reference Material===

==System Overview==

Sahana Eden is mainly implemented using Python, web2py, CSS and foundation. When you open the code in Eclipse, you can see that web2py is very much like Ruby on Rails. Analyze the screenshots below-

[[File: workspace.png]][[File: workspace2.png]]

==System Architecture==

==Requirement Analysis==

==Data and Component Design==

==Design Principles==

==Proposed Test Cases==

==References==

==Further Reading==
[https://groups.google.com/forum/#!forum/sahana-eden Public Google Forum to discuss any development issues]

CSC/ECE 517 Fall 2014/oss E1463 vpd

2014-11-03T15:15:54Z

Vpiddem: /* look at the rest of the methods */

= '''E1463: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ Our Expertiza Fork on AWS]<br>
[https://github.com/Druotic/expertiza Github Repo]<br>
[http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ Project Running on AWS]<br>
Admin Account login details : <br>
Username: user2 <br>
Password: password

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

'''Example Image Of Tree Display:
'''
[[File:Expertiza.PNG ]]

=Refactoring TreeDisplayController Tasks=

As part of the refactoring task, we had to address the following issues for enhancing code readability and maintainability. The tasks include-
#Changing List to Index using a [http://www.restapitutorial.com/lessons/whatisrest.html RESTful] approach.
#Use of routing helpers
#Use {} and [] instead of Hash.new and Array.new
#Ensuring that instantiation of instance variables is minimized.

==Changing List to Index==
All our code changes can be checked out at our [https://github.com/Druotic/expertiza/pull/1/files Git project repository]. It can be seen that we have replaced all the controller action redirections with a tree_display_index_path which enormously reduces the code content and as well as provides an organized approach to action redirections.

[[File:List_to_Index.png]]

combined all of the goto methods

==Use Routing Helpers==
We refactored the treedisplay controller class to use route helpers rather than calling ":action => 'list', :controller => 'tree_display'", or something similar. This involved many edits in the tree_display_controller.rb file and related controller and view files. Our [https://github.com/Druotic/expertiza Github repo] shows all the changes made.

Example -- Route helpers added to breadcrumbs view file:
[[File:routehelpers.PNG ]]

==Minimizing the count of Instance Variables==
=== Instance Variables in Ruby ===
An instance variable has a name beginning with @, and its scope is confined to whatever object self refers to. Two different objects, even if they belong to the same class, are allowed to have different values for their instance variables. From outside the object, instance variables cannot be altered or even observed (i.e., ruby's instance variables are never public) except by whatever methods are explicitly provided by the programmer. As with globals, instance variables have the nil value until they are initialized.

Instance variables do not need to be declared. This indicates a flexible object structure; in fact, each instance variable is dynamically appended to an object when it is first assigned.

We have observed that in Expertiza, there were several code files related to the Tree Display controller which were observed to be using multiple instance variables which could be reduced. Our team aimed to limit the instantiation of such variables to only necessary places in our code.

==Other Methods==

=Summary and Conclusions=
=Future Work=

CSC/ECE 517 Fall 2014/oss E1463 vpd

2014-11-03T13:04:32Z

Vpiddem: /* Project Links */

= '''E1463: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ Our Expertiza Fork on AWS]<br>
[https://github.com/Druotic/expertiza Github Repo]<br>
[http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ Project Running on AWS]<br>
Admin Account login details : <br>
Username: user2 <br>
Password: password

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

'''Example Image Of Tree Display:
'''
[[File:Expertiza.PNG ]]

=Refactoring TreeDisplayController Tasks=

As part of the refactoring task, we had to address the following issues for enhancing code readability and maintainability. The tasks include-
#Changing List to Index using a [http://www.restapitutorial.com/lessons/whatisrest.html RESTful] approach.
#Use of routing helpers
#Use {} and [] instead of Hash.new and Array.new
#Ensuring that instantiation of instance variables is minimized.

==Changing List to Index==
All our code changes can be checked out at our [https://github.com/Druotic/expertiza/pull/1/files Git project repository]. It can be seen that we have replaced all the controller action redirections with a tree_display_index_path which enormously reduces the code content and as well as provides an organized approach to action redirections.

[[File:List_to_Index.png]]

combined all of the goto methods

==Use Routing Helpers==
We refactored the treedisplay controller class to use route helpers rather than calling ":action => 'list', :controller => 'tree_display'", or something similar. This involved many edits in the tree_display_controller.rb file and related controller and view files. Our [https://github.com/Druotic/expertiza Github repo] shows all the changes made.

Example -- Route helpers added to breadcrumbs view file:
[[File:routehelpers.PNG ]]

==Minimizing the count of Instance Variables==
=== Instance Variables in Ruby ===
An instance variable has a name beginning with @, and its scope is confined to whatever object self refers to. Two different objects, even if they belong to the same class, are allowed to have different values for their instance variables. From outside the object, instance variables cannot be altered or even observed (i.e., ruby's instance variables are never public) except by whatever methods are explicitly provided by the programmer. As with globals, instance variables have the nil value until they are initialized.

Instance variables do not need to be declared. This indicates a flexible object structure; in fact, each instance variable is dynamically appended to an object when it is first assigned.

We have observed that in Expertiza, there were several code files related to the Tree Display controller which were observed to be using multiple instance variables which could be reduced. Our team aimed to limit the instantiation of such variables to only necessary places in our code.

==look at the rest of the methods==

=Summary and Conclusions=
=Future Work=

CSC/ECE 517 Fall 2014/oss E1463 vpd

2014-11-03T12:53:30Z

Vpiddem: /* only use 1 instance variable in list method */

= '''E1463: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ Our Expertiza Fork on AWS]<br>
[https://github.com/Druotic/expertiza Github Repo]<br>
[http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ Project Running on AWS]<br>
Admin Account: <br>
Username: user2 <br>
Password: password

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

'''Example Image Of Tree Display:
'''
[[File:Expertiza.PNG ]]

=Refactoring TreeDisplayController Tasks=

As part of the refactoring task, we had to address the following issues for enhancing code readability and maintainability. The tasks include-
#Changing List to Index using a [http://www.restapitutorial.com/lessons/whatisrest.html RESTful] approach.
#Use of routing helpers
#Use {} and [] instead of Hash.new and Array.new
#Ensuring that instantiation of instance variables is minimized.

==Changing List to Index==
All our code changes can be checked out at our [https://github.com/Druotic/expertiza/pull/1/files Git project repository]. It can be seen that we have replaced all the controller action redirections with a tree_display_index_path which enormously reduces the code content and as well as provides an organized approach to action redirections.

[[File:List_to_Index.png]]

combined all of the goto methods

==Use Routing Helpers==
We refactored the treedisplay controller class to use route helpers rather than calling ":action => 'list', :controller => 'tree_display'", or something similar. This involved many edits in the tree_display_controller.rb file and related controller and view files. Our [https://github.com/Druotic/expertiza Github repo] shows all the changes made.

Example -- Route helpers added to breadcrumbs view file:
[[File:routehelpers.PNG ]]

==Minimizing the count of Instance Variables==
=== Instance Variables in Ruby ===
An instance variable has a name beginning with @, and its scope is confined to whatever object self refers to. Two different objects, even if they belong to the same class, are allowed to have different values for their instance variables. From outside the object, instance variables cannot be altered or even observed (i.e., ruby's instance variables are never public) except by whatever methods are explicitly provided by the programmer. As with globals, instance variables have the nil value until they are initialized.

Instance variables do not need to be declared. This indicates a flexible object structure; in fact, each instance variable is dynamically appended to an object when it is first assigned.

We have observed that in Expertiza, there were several code files related to the Tree Display controller which were observed to be using multiple instance variables which could be reduced. Our team aimed to limit the instantiation of such variables to only necessary places in our code.

==look at the rest of the methods==

=Summary and Conclusions=
=Future Work=

CSC/ECE 517 Fall 2014/oss E1463 vpd

2014-11-03T12:22:20Z

Vpiddem: /* Changing List to Index */

CSC/ECE 517 Fall 2014/oss E1463 vpd

2014-11-03T12:17:59Z

Vpiddem: /* Changing List to Index */

File:List to Index.png

2014-11-03T12:13:08Z

Vpiddem: A brief screen of the Git repo diff page.

A brief screen of the Git repo diff page.

CSC/ECE 517 Fall 2014/oss E1463 vpd

2014-11-03T12:11:36Z

Vpiddem: /* Refactoring TreeDisplayController Tasks */

CSC/ECE 517 Fall 2014

2014-10-29T00:51:43Z

Vpiddem:

*[[CSC/ECE_517_Fall_2014/sample_page]]
*[[CSC/ECE_517_Fall_2014/ch1a 22 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 19 mx]]
*[[CSC/ECE 517 Fall 2014/ch1a 3 zq]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 lf]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 wl]]
*[[CSC/ECE 517 Fall 2014/ch1a a7 ch]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 rs]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 jf]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 os]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 15 gs]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 hu]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 kv]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 24 sa]]
*[[CSC/ECE 517 Fall 2014/ch1a 26 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 6 rl]]
*[[CSC/ECE 517 Fall 2014/ch1a 2 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 16 av]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 rm]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 sj]]
*[[CSC/ECE 517 Fall 2014/ch1a 23 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 rn]]
*[[CSC/ECE 517 Fall 2014/ch1a 22 sp]]
*[[CSC/ECE 517 Fall 2014/oss M1454 rss]]

*[[CSC/ECE 517 Fall 2014/ch1a 26 gn]]

*[[CSC/ECE 517 Fall 2014/ch1a 13 va]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 aa]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 kn]]
*[[CSC/ECE 517 Fall 2014/ch1a 11 ap]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 ks]]
*[[CSC/ECE 517 Fall 2014/ch1a 7 kz]]
*[[CSC/ECE_517_Fall_2014/ch1a_6_bn]]
*[[CSC/ECE_517_Fall_2014/ch1a 10 zz]]
*[[CSC/ECE_517_Fall_2014/ch1a 16 va]]
*[[CSC/ECE_517_Fall_2014/ch1a F1415 rv]]
*[[CSC/ECE_517_Fall_2014/ch1a_3_cp]]
*[[CSC/ECE 517 Fall 2014/ch1b 26 sa]]
*[[CSC/ECE_517_Fall_2014/ch1b_28_cg]]
*[[CSC/ECE_517_Fall_2014/ch1b 29 ry]]
*[[CSC/ECE_517_Fall_2014/ch1b 30 cs]]
*[[CSC/ECE_517_Fall_2014/ch1b_33_jy]]
*[[CSC/ECE_517_Fall_2014/ch1b_27_js]]
*[[CSC/ECE 517 Fall 2014/oss E1463 vpd]]
*[[CSC/ECE 517 Fall 2014/oss E1465 oak]]
*[[CSC/ECE 517 Fall 2014/oss_M1456_kdv]]
*[[CSC/ECE 517 Fall 2014/oss_M1453_sst]]
*[[CSC/ECE 517 Fall 2014/oss_E1456_akk]]
*[[CSC/ECE_517_Fall_2014/oss_M1455_asa]]
*[[CSC/ECE_517_Fall_2014/oss_E1458_sst]]
*[[CSC/ECE_517_Fall_2014/oss_E1457_ags]]
*[[CSC/ECE_517_Fall_2014/OSS_E1466_gjf]]
*[[CSC/ECE_517_Fall_2014/oss_M1452_jns]]
*[[CSC/ECE_517_Fall_2014/oss_E1462_nms]]
*[[CSC/ECE_517_Fall_2014/OSS_S1455_ajp]]

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-26T02:31:46Z

Vpiddem: /* Real Power-Git Branches */

<div style="float: right;">
[[File:git-logo.png|center]]
{| class="wikitable"
|-
! Author(s)
| Ravish Roshan, Vikas Piddempally
|-
! Initial release
| 7 April 2005
|-
! Written in
| C, Bourne Shell, Tcl, Perl
|-
! Operating Systems
| Linux, POSIX, Windows, OS X
|-
! Type
| Version Control
|-
! License
| GNU General Public License v2
|-
! Website
| [http://git-scm.com/ git-scm.com]
|-
|}
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] originally designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005 with emphasis on managing Linux source code without requiring a central server, and has since then become the most widely adopted version control system for software development. Git facilitates a system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially

In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as listed below:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.<ref>[http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git Getting started a short history of Git]</ref>

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

=== Centralized Version Control System ===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed. <br/>Most modern version control systems deal with “changesets”, which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. <br/>For example: a change to a C header file and the corresponding .c file should always be kept together. <br/>Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. <br/>Some of the most popular centralized version control systems are [http://www.nongnu.org/cvs/ CVS], [https://subversion.apache.org/ Subversion (or SVN)] and [http://www.perforce.com/ Perforce].

=== Distributed Version Control System ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control System (DRCS)] takes a [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] approach, as opposed to the [https://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.<ref>[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software]</ref>

== Why use Git? <ref>[http://thkoch2001.github.io/whygitisbetter/ Why Git is better than X]</ref> ==
=== Branching Model ===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.<ref>[https://www.atlassian.com/git/articles/simple-git-workflow-is-simple/ Git workflow is simple]</ref>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.<ref>[https://en.wikipedia.org/wiki/Git_(software)#Characteristics Git Characteristics]</ref>

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:Git-3.png|center]]<ref>[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Git Basics Chapter 1]</ref><ref>[http://git-scm.com/book/en/Getting-Started-Git-Basics Git Basics Chapter 2]</ref>

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>
<ref>[http://code.tutsplus.com/tutorials/easy-version-control-with-git--net-7449 Easy Version Control System with Git]</ref>

== Real Power-Git Branches==
Branches allow to diverge from the main line of development. This allows developers to work on bug fixes and new features without interfering with the main (live) branch (master). Later you can merge branches with each other or with the master branch. The basics are quite simple:

Open up a new branch:

<pre>git checkout -b <branchname> </pre>

To list all the branches,a user can use the following command.
<pre> git branch </pre>

To merge a branch into the main branch (commonly refered as master),one can use the below command.
<pre>
git merge <branch name>
</pre>
If the branch is not needed anymore, delete it using the following command.
<pre>
git branch -d testing
</pre>

This is the easiest example of branching, there are more advanced options possible like 3-way merging (merging various branches at once) and rebasing.
<ref>[http://git-scm.com/book/ch3-6.html Git Rebasing]</ref>

'''Merging & Branching in a Nut Shell'''

In a nutshell you can create a branch with git branch (branchname), switch into that context with git checkout (branchname), record commit snapshots while in that context, then can switch back and forth easily. When you switch branches, Git replaces your working directory with the snapshot of the latest commit on that branch so you don't have to have multiple directories for multiple branches. You merge branches together with git merge. You can easily merge multiple times from the same branch over time, or alternately you can choose to delete a branch immediately after merging it.

== Comparison of various Version Control Softwares ==

{| class="wikitable sortable" style="text-align: center; width: auto;"
|-
! Software
! Programming language
! Storage method
! Scope of change
! #Revision IDs|Revision IDs
! Protocol (computing)|Network protocols
! Source code size
|-
! [http://bazaar.canonical.com/en/ GNU Bazaar]
| Python, Pyrex , C
| Snapshot
| Tree
| Pseudorandom
| custom
| 4.1 MB
|-
! [http://www.bitkeeper.com/ BitKeeper]
| C (programming language)
| Changeset
| Tree
| Changeset keys, numbers
| custom, Hypertext Transfer Protocol, Remote Shell, secure shell, email
| Unknown
|-
! [http://www-03.ibm.com/software/products/en/clearcase ClearCase]
| C (programming language)|C, Java (programming language), Perl
| Changeset
| File and Tree
| Numbers
| custom (CCFS), custom (MultiVersion File System|MVFS filesystem driver), Hypertext Transfer Protocol
| Unknown
|-
! [http://www.relisoft.com/co_op/ Code Co-op]
| C++
| Changeset
| Unknown
| User ID-Ordinal
| e-mail (Messaging Application Programming Interface|MAPI, SMTP/POP3, Gmail), Local area network
| Unknown
|-
! [http://www.nongnu.org/cvs/ CVS]
| C (programming language)|C
| Changeset
| File
| Numbers
| pserver, Secure Shell|ssh
| 3.3 MB
|-
! [http://git-scm.com/ Git]
| C (programming language)|C, shell scripts, Perl
| Snapshot
| Tree
| SHA-1 hashes
| custom (''git''), custom over Secure Shell, Hypertext Transfer Protocol, rsync, email, bundles
| 10.2 MB
|-
! [https://www.gnu.org/software/gnu-arch/ GNU arch]
| C (programming language), shell scripts
| Changeset
| Tree
| Numbers
| Hypertext Transfer Protocol, WebDAV
| Unknown
|-
! [http://dev.libresource.org/ LibreSource Synchronizer]
| Java (programming language)
| Changeset
| Unknown
| Timestamps
| Hypertext Transfer Protocol, File-System
| Unknown
|-
! [http://mercurial.selenic.com/ Mercurial]
| Python (programming language)|Python, C (programming language)
| Changeset
| Tree
| Numbers
| custom over secure shell, Hypertext Transfer Protocol
| 1.2 MB
|-
! [http://www.perforce.com Perforce]
| C++, C (programming language)|C
| Changeset
| Tree
| Numbers
| custom
| Unknown
|-
! [https://subversion.apache.org/ Subversion]
| C (programming language)|C
| Changeset and Snapshot
| Tree
| Numbers
| custom over Secure Shell, Hypertext Transfer Protocol
| 5.2 MB
|-
! [http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx Team Foundation Server]
| C++ and C Sharp (programming language)|C#
| Changeset
| File and Tree
| Numbers
| SOAP over HTTP or HTTPS
| Unknown
|-
|}<ref>[https://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of revision control software]</ref>

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-26T02:30:19Z

Vpiddem: /* Real Power-Git Branches */

<div style="float: right;">
[[File:git-logo.png|center]]
{| class="wikitable"
|-
! Author(s)
| Ravish Roshan, Vikas Piddempally
|-
! Initial release
| 7 April 2005
|-
! Written in
| C, Bourne Shell, Tcl, Perl
|-
! Operating Systems
| Linux, POSIX, Windows, OS X
|-
! Type
| Version Control
|-
! License
| GNU General Public License v2
|-
! Website
| [http://git-scm.com/ git-scm.com]
|-
|}
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] originally designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005 with emphasis on managing Linux source code without requiring a central server, and has since then become the most widely adopted version control system for software development. Git facilitates a system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially

In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as listed below:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.<ref>[http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git Getting started a short history of Git]</ref>

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

=== Centralized Version Control System ===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed. <br/>Most modern version control systems deal with “changesets”, which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. <br/>For example: a change to a C header file and the corresponding .c file should always be kept together. <br/>Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. <br/>Some of the most popular centralized version control systems are [http://www.nongnu.org/cvs/ CVS], [https://subversion.apache.org/ Subversion (or SVN)] and [http://www.perforce.com/ Perforce].

=== Distributed Version Control System ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control System (DRCS)] takes a [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] approach, as opposed to the [https://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.<ref>[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software]</ref>

== Why use Git? <ref>[http://thkoch2001.github.io/whygitisbetter/ Why Git is better than X]</ref> ==
=== Branching Model ===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.<ref>[https://www.atlassian.com/git/articles/simple-git-workflow-is-simple/ Git workflow is simple]</ref>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.<ref>[https://en.wikipedia.org/wiki/Git_(software)#Characteristics Git Characteristics]</ref>

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:Git-3.png|center]]<ref>[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Git Basics Chapter 1]</ref><ref>[http://git-scm.com/book/en/Getting-Started-Git-Basics Git Basics Chapter 2]</ref>

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>
<ref>[http://code.tutsplus.com/tutorials/easy-version-control-with-git--net-7449 Easy Version Control System with Git]</ref>

== Real Power-Git Branches==
Branches allow to diverge from the main line of development. This allows developers to work on bug fixes and new features without interfering with the main (live) branch (master). Later you can merge branches with each other or with the master branch. The basics are quite simple:

Open up a new branch:

<pre>git checkout -b <branchname> </pre>

To list all the branches,a user can use the following command.
<pre> git branch </pre>

To merge a branch into the main branch (commonly refered as master),one can use the below command.
<pre>
git merge <branch name>
</pre>
If the branch is not needed anymore, delete it using the following command.
<pre>
git branch -d testing
</pre>

This is the easiest example of branching, there are more advanced options possible like 3-way merging (merging various branches at once) and rebasing.
<ref>[http://git-scm.com/book/ch3-6.html]</ref>

'''Merging & Branching in a Nut Shell'''

In a nutshell you can create a branch with git branch (branchname), switch into that context with git checkout (branchname), record commit snapshots while in that context, then can switch back and forth easily. When you switch branches, Git replaces your working directory with the snapshot of the latest commit on that branch so you don't have to have multiple directories for multiple branches. You merge branches together with git merge. You can easily merge multiple times from the same branch over time, or alternately you can choose to delete a branch immediately after merging it.

== Comparison of various Version Control Softwares ==

{| class="wikitable sortable" style="text-align: center; width: auto;"
|-
! Software
! Programming language
! Storage method
! Scope of change
! #Revision IDs|Revision IDs
! Protocol (computing)|Network protocols
! Source code size
|-
! [http://bazaar.canonical.com/en/ GNU Bazaar]
| Python, Pyrex , C
| Snapshot
| Tree
| Pseudorandom
| custom
| 4.1 MB
|-
! [http://www.bitkeeper.com/ BitKeeper]
| C (programming language)
| Changeset
| Tree
| Changeset keys, numbers
| custom, Hypertext Transfer Protocol, Remote Shell, secure shell, email
| Unknown
|-
! [http://www-03.ibm.com/software/products/en/clearcase ClearCase]
| C (programming language)|C, Java (programming language), Perl
| Changeset
| File and Tree
| Numbers
| custom (CCFS), custom (MultiVersion File System|MVFS filesystem driver), Hypertext Transfer Protocol
| Unknown
|-
! [http://www.relisoft.com/co_op/ Code Co-op]
| C++
| Changeset
| Unknown
| User ID-Ordinal
| e-mail (Messaging Application Programming Interface|MAPI, SMTP/POP3, Gmail), Local area network
| Unknown
|-
! [http://www.nongnu.org/cvs/ CVS]
| C (programming language)|C
| Changeset
| File
| Numbers
| pserver, Secure Shell|ssh
| 3.3 MB
|-
! [http://git-scm.com/ Git]
| C (programming language)|C, shell scripts, Perl
| Snapshot
| Tree
| SHA-1 hashes
| custom (''git''), custom over Secure Shell, Hypertext Transfer Protocol, rsync, email, bundles
| 10.2 MB
|-
! [https://www.gnu.org/software/gnu-arch/ GNU arch]
| C (programming language), shell scripts
| Changeset
| Tree
| Numbers
| Hypertext Transfer Protocol, WebDAV
| Unknown
|-
! [http://dev.libresource.org/ LibreSource Synchronizer]
| Java (programming language)
| Changeset
| Unknown
| Timestamps
| Hypertext Transfer Protocol, File-System
| Unknown
|-
! [http://mercurial.selenic.com/ Mercurial]
| Python (programming language)|Python, C (programming language)
| Changeset
| Tree
| Numbers
| custom over secure shell, Hypertext Transfer Protocol
| 1.2 MB
|-
! [http://www.perforce.com Perforce]
| C++, C (programming language)|C
| Changeset
| Tree
| Numbers
| custom
| Unknown
|-
! [https://subversion.apache.org/ Subversion]
| C (programming language)|C
| Changeset and Snapshot
| Tree
| Numbers
| custom over Secure Shell, Hypertext Transfer Protocol
| 5.2 MB
|-
! [http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx Team Foundation Server]
| C++ and C Sharp (programming language)|C#
| Changeset
| File and Tree
| Numbers
| SOAP over HTTP or HTTPS
| Unknown
|-
|}<ref>[https://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of revision control software]</ref>

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-26T02:27:34Z

Vpiddem: /* Background */

<div style="float: right;">
[[File:git-logo.png|center]]
{| class="wikitable"
|-
! Author(s)
| Ravish Roshan, Vikas Piddempally
|-
! Initial release
| 7 April 2005
|-
! Written in
| C, Bourne Shell, Tcl, Perl
|-
! Operating Systems
| Linux, POSIX, Windows, OS X
|-
! Type
| Version Control
|-
! License
| GNU General Public License v2
|-
! Website
| [http://git-scm.com/ git-scm.com]
|-
|}
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] originally designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005 with emphasis on managing Linux source code without requiring a central server, and has since then become the most widely adopted version control system for software development. Git facilitates a system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially

In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as listed below:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.<ref>[http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git Getting started a short history of Git]</ref>

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

=== Centralized Version Control System ===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed. <br/>Most modern version control systems deal with “changesets”, which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. <br/>For example: a change to a C header file and the corresponding .c file should always be kept together. <br/>Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. <br/>Some of the most popular centralized version control systems are [http://www.nongnu.org/cvs/ CVS], [https://subversion.apache.org/ Subversion (or SVN)] and [http://www.perforce.com/ Perforce].

=== Distributed Version Control System ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control System (DRCS)] takes a [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] approach, as opposed to the [https://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.<ref>[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software]</ref>

== Why use Git? <ref>[http://thkoch2001.github.io/whygitisbetter/ Why Git is better than X]</ref> ==
=== Branching Model ===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.<ref>[https://www.atlassian.com/git/articles/simple-git-workflow-is-simple/ Git workflow is simple]</ref>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.<ref>[https://en.wikipedia.org/wiki/Git_(software)#Characteristics Git Characteristics]</ref>

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:Git-3.png|center]]<ref>[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Git Basics Chapter 1]</ref><ref>[http://git-scm.com/book/en/Getting-Started-Git-Basics Git Basics Chapter 2]</ref>

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>
<ref>[http://code.tutsplus.com/tutorials/easy-version-control-with-git--net-7449 Easy Version Control System with Git]</ref>

== Real Power-Git Branches==
Branches allow to diverge from the main line of development. This allows developers to work on bug fixes and new features without interfering with the main (live) branch (master). Later you can merge branches with each other or with the master branch. The basics are quite simple:

Open up a new branch:

<pre>git checkout -b <branchname> </pre>

To list all the branches,a user can use the following command.
<pre> git branch </pre>

To merge a branch into the main branch (commonly refered as master),one can use the below command.
<pre>
git merge <branch name>
</pre>
If the branch is not needed anymore, delete it using the following command.
<pre>
git branch -d testing
</pre>

This is the easiest example of branching, there are more advanced options possible like 3-way merging (merging various branches at once) and rebasing.

'''Merging & Branching in a Nut Shell'''

In a nutshell you can create a branch with git branch (branchname), switch into that context with git checkout (branchname), record commit snapshots while in that context, then can switch back and forth easily. When you switch branches, Git replaces your working directory with the snapshot of the latest commit on that branch so you don't have to have multiple directories for multiple branches. You merge branches together with git merge. You can easily merge multiple times from the same branch over time, or alternately you can choose to delete a branch immediately after merging it.

== Comparison of various Version Control Softwares ==

{| class="wikitable sortable" style="text-align: center; width: auto;"
|-
! Software
! Programming language
! Storage method
! Scope of change
! #Revision IDs|Revision IDs
! Protocol (computing)|Network protocols
! Source code size
|-
! [http://bazaar.canonical.com/en/ GNU Bazaar]
| Python, Pyrex , C
| Snapshot
| Tree
| Pseudorandom
| custom
| 4.1 MB
|-
! [http://www.bitkeeper.com/ BitKeeper]
| C (programming language)
| Changeset
| Tree
| Changeset keys, numbers
| custom, Hypertext Transfer Protocol, Remote Shell, secure shell, email
| Unknown
|-
! [http://www-03.ibm.com/software/products/en/clearcase ClearCase]
| C (programming language)|C, Java (programming language), Perl
| Changeset
| File and Tree
| Numbers
| custom (CCFS), custom (MultiVersion File System|MVFS filesystem driver), Hypertext Transfer Protocol
| Unknown
|-
! [http://www.relisoft.com/co_op/ Code Co-op]
| C++
| Changeset
| Unknown
| User ID-Ordinal
| e-mail (Messaging Application Programming Interface|MAPI, SMTP/POP3, Gmail), Local area network
| Unknown
|-
! [http://www.nongnu.org/cvs/ CVS]
| C (programming language)|C
| Changeset
| File
| Numbers
| pserver, Secure Shell|ssh
| 3.3 MB
|-
! [http://git-scm.com/ Git]
| C (programming language)|C, shell scripts, Perl
| Snapshot
| Tree
| SHA-1 hashes
| custom (''git''), custom over Secure Shell, Hypertext Transfer Protocol, rsync, email, bundles
| 10.2 MB
|-
! [https://www.gnu.org/software/gnu-arch/ GNU arch]
| C (programming language), shell scripts
| Changeset
| Tree
| Numbers
| Hypertext Transfer Protocol, WebDAV
| Unknown
|-
! [http://dev.libresource.org/ LibreSource Synchronizer]
| Java (programming language)
| Changeset
| Unknown
| Timestamps
| Hypertext Transfer Protocol, File-System
| Unknown
|-
! [http://mercurial.selenic.com/ Mercurial]
| Python (programming language)|Python, C (programming language)
| Changeset
| Tree
| Numbers
| custom over secure shell, Hypertext Transfer Protocol
| 1.2 MB
|-
! [http://www.perforce.com Perforce]
| C++, C (programming language)|C
| Changeset
| Tree
| Numbers
| custom
| Unknown
|-
! [https://subversion.apache.org/ Subversion]
| C (programming language)|C
| Changeset and Snapshot
| Tree
| Numbers
| custom over Secure Shell, Hypertext Transfer Protocol
| 5.2 MB
|-
! [http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx Team Foundation Server]
| C++ and C Sharp (programming language)|C#
| Changeset
| File and Tree
| Numbers
| SOAP over HTTP or HTTPS
| Unknown
|-
|}<ref>[https://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of revision control software]</ref>

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-26T02:19:50Z

Vpiddem: /* How do I use Git? */

<div style="float: right;">
[[File:git-logo.png|center]]
{| class="wikitable"
|-
! Author(s)
| Ravish Roshan, Vikas Piddempally
|-
! Initial release
| 7 April 2005
|-
! Written in
| C, Bourne Shell, Tcl, Perl
|-
! Operating Systems
| Linux, POSIX, Windows, OS X
|-
! Type
| Version Control
|-
! License
| GNU General Public License v2
|-
! Website
| [http://git-scm.com/ git-scm.com]
|-
|}
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.<ref>[http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git Getting started a short history of Git]</ref>

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

=== Centralized Version Control System ===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed. <br/>Most modern version control systems deal with “changesets”, which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. <br/>For example: a change to a C header file and the corresponding .c file should always be kept together. <br/>Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. <br/>Some of the most popular centralized version control systems are [http://www.nongnu.org/cvs/ CVS], [https://subversion.apache.org/ Subversion (or SVN)] and [http://www.perforce.com/ Perforce].

=== Distributed Version Control System ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control System (DRCS)] takes a [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] approach, as opposed to the [https://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.<ref>[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software]</ref>

== Why use Git? <ref>[http://thkoch2001.github.io/whygitisbetter/ Why Git is better than X]</ref> ==
=== Branching Model ===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.<ref>[https://www.atlassian.com/git/articles/simple-git-workflow-is-simple/ Git workflow is simple]</ref>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.<ref>[https://en.wikipedia.org/wiki/Git_(software)#Characteristics Git Characteristics]</ref>

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:Git-3.png|center]]<ref>[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Git Basics Chapter 1]</ref><ref>[http://git-scm.com/book/en/Getting-Started-Git-Basics Git Basics Chapter 2]</ref>

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>
<ref>[http://code.tutsplus.com/tutorials/easy-version-control-with-git--net-7449 Easy Version Control System with Git]</ref>

== Real Power-Git Branches==
Branches allow to diverge from the main line of development. This allows developers to work on bug fixes and new features without interfering with the main (live) branch (master). Later you can merge branches with each other or with the master branch. The basics are quite simple:

Open up a new branch:

<pre>git checkout -b <branchname> </pre>

To list all the branches,a user can use the following command.
<pre> git branch </pre>

To merge a branch into the main branch (commonly refered as master),one can use the below command.
<pre>
git merge <branch name>
</pre>
If the branch is not needed anymore, delete it using the following command.
<pre>
git branch -d testing
</pre>

This is the easiest example of branching, there are more advanced options possible like 3-way merging (merging various branches at once) and rebasing.

'''Merging & Branching in a Nut Shell'''

In a nutshell you can create a branch with git branch (branchname), switch into that context with git checkout (branchname), record commit snapshots while in that context, then can switch back and forth easily. When you switch branches, Git replaces your working directory with the snapshot of the latest commit on that branch so you don't have to have multiple directories for multiple branches. You merge branches together with git merge. You can easily merge multiple times from the same branch over time, or alternately you can choose to delete a branch immediately after merging it.

== Comparison of various Version Control Softwares ==

{| class="wikitable sortable" style="text-align: center; width: auto;"
|-
! Software
! Programming language
! Storage method
! Scope of change
! #Revision IDs|Revision IDs
! Protocol (computing)|Network protocols
! Source code size
|-
! [http://bazaar.canonical.com/en/ GNU Bazaar]
| Python, Pyrex , C
| Snapshot
| Tree
| Pseudorandom
| custom
| 4.1 MB
|-
! [http://www.bitkeeper.com/ BitKeeper]
| C (programming language)
| Changeset
| Tree
| Changeset keys, numbers
| custom, Hypertext Transfer Protocol, Remote Shell, secure shell, email
| Unknown
|-
! [http://www-03.ibm.com/software/products/en/clearcase ClearCase]
| C (programming language)|C, Java (programming language), Perl
| Changeset
| File and Tree
| Numbers
| custom (CCFS), custom (MultiVersion File System|MVFS filesystem driver), Hypertext Transfer Protocol
| Unknown
|-
! [http://www.relisoft.com/co_op/ Code Co-op]
| C++
| Changeset
| Unknown
| User ID-Ordinal
| e-mail (Messaging Application Programming Interface|MAPI, SMTP/POP3, Gmail), Local area network
| Unknown
|-
! [http://www.nongnu.org/cvs/ CVS]
| C (programming language)|C
| Changeset
| File
| Numbers
| pserver, Secure Shell|ssh
| 3.3 MB
|-
! [http://git-scm.com/ Git]
| C (programming language)|C, shell scripts, Perl
| Snapshot
| Tree
| SHA-1 hashes
| custom (''git''), custom over Secure Shell, Hypertext Transfer Protocol, rsync, email, bundles
| 10.2 MB
|-
! [https://www.gnu.org/software/gnu-arch/ GNU arch]
| C (programming language), shell scripts
| Changeset
| Tree
| Numbers
| Hypertext Transfer Protocol, WebDAV
| Unknown
|-
! [http://dev.libresource.org/ LibreSource Synchronizer]
| Java (programming language)
| Changeset
| Unknown
| Timestamps
| Hypertext Transfer Protocol, File-System
| Unknown
|-
! [http://mercurial.selenic.com/ Mercurial]
| Python (programming language)|Python, C (programming language)
| Changeset
| Tree
| Numbers
| custom over secure shell, Hypertext Transfer Protocol
| 1.2 MB
|-
! [http://www.perforce.com Perforce]
| C++, C (programming language)|C
| Changeset
| Tree
| Numbers
| custom
| Unknown
|-
! [https://subversion.apache.org/ Subversion]
| C (programming language)|C
| Changeset and Snapshot
| Tree
| Numbers
| custom over Secure Shell, Hypertext Transfer Protocol
| 5.2 MB
|-
! [http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx Team Foundation Server]
| C++ and C Sharp (programming language)|C#
| Changeset
| File and Tree
| Numbers
| SOAP over HTTP or HTTPS
| Unknown
|-
|}<ref>[https://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of revision control software]</ref>

== References ==
<references/>

File:Git-3.png

2014-09-26T02:01:56Z

Vpiddem: Git Hub Data Flow

Git Hub Data Flow

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:53:04Z

Vpiddem: /* How do I use Git? */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.<ref>[http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git Getting started a short history of Git]</ref>

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

=== Centralized Version Control System ===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed. <br/>Most modern version control systems deal with “changesets”, which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. <br/>For example: a change to a C header file and the corresponding .c file should always be kept together. <br/>Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. <br/>Some of the most popular centralized version control systems are [http://www.nongnu.org/cvs/ CVS], [https://subversion.apache.org/ Subversion (or SVN)] and [http://www.perforce.com/ Perforce].

=== Distributed Version Control System ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control System (DRCS)] takes a [https://en.wikipedia.org/wiki/Peer-to-peer peer-to-peer] approach, as opposed to the [https://en.wikipedia.org/wiki/Client%E2%80%93server_model client-server] approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.<ref>[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software]</ref>

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Comparison of various Version Control Softwares ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:43:58Z

Vpiddem: /* How do I use Git? */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.<ref>[http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git]</ref>

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

===Centralized Version Control System===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

===Distributed Version Control System===

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== References ==
<references/>

File:GitThreeStates.png

2014-09-20T02:42:24Z

Vpiddem: uploaded a new version of "File:GitThreeStates.png"

This represents the 3 states of Git.

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:41:33Z

Vpiddem: /* Developments and Feature Enhancements */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.<ref>[http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git]</ref>

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

===Centralized Version Control System===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

===Distributed Version Control System===

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:23:09Z

Vpiddem: /* Background */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

*Speed
*Simple design
*Strong support for non-linear development (thousands of parallel branches)
*Fully distributed
*Able to handle large projects like the Linux kernel efficiently (speed and data size)
Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

===Centralized Version Control System===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

===Distributed Version Control System===

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based [https://github.com/ Github] GUI and has successfully incorporated the following robust features which makes the job of Collaborative code management a breeze. These include the following:

*;Integrated issue tracking: A flexible issue tracker lets you stay on top of bugs and focus on features.

*;Collaborative code review: Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch. <br/>Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
<pre>
Pull Request = Code + Issue + Code Comments
</pre>
:Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. Henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

*;Text entry with understated power; Rather than dozens of buttons, [https://github.com/ Github] relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect [https://en.wikipedia.org/wiki/Emoji Emoji].

*;Syntax highlighted code & rendered data: [https://github.com/ Github's] highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

*;On the desktop and in your pocket:
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

*;Integration and Add-Ons:
Great software begins with great design. These integrators specialize in helping you explore and visualize ideas, design UI and workflows, and track your progress.
*Amazon Web Services
*Google Cloud Platform
*Heroku
*Windows Azure

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:22:20Z

Vpiddem: /* Background */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:
Speed
Simple design
Strong support for non-linear development (thousands of parallel branches)
Fully distributed
Able to handle large projects like the Linux kernel efficiently (speed and data size)
Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.
Further, [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

===Centralized Version Control System===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

===Distributed Version Control System===

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based [https://github.com/ Github] GUI and has successfully incorporated the following robust features which makes the job of Collaborative code management a breeze. These include the following:

*;Integrated issue tracking: A flexible issue tracker lets you stay on top of bugs and focus on features.

*;Collaborative code review: Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch. <br/>Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
<pre>
Pull Request = Code + Issue + Code Comments
</pre>
:Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. Henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

*;Text entry with understated power; Rather than dozens of buttons, [https://github.com/ Github] relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect [https://en.wikipedia.org/wiki/Emoji Emoji].

*;Syntax highlighted code & rendered data: [https://github.com/ Github's] highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

*;On the desktop and in your pocket:
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

*;Integration and Add-Ons:
Great software begins with great design. These integrators specialize in helping you explore and visualize ideas, design UI and workflows, and track your progress.
*Amazon Web Services
*Google Cloud Platform
*Heroku
*Windows Azure

== References ==
<references/>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:10:58Z

Vpiddem: /* Centralized Vs Distributed Version Control System */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development. [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

===Centralized Version Control System===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

===Distributed Version Control System===

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based Git-hub GUI and has successfully incorporated the following robust features which make the job of Collaborative code management a breeze. These include :

'''Integrated issue tracking.'''
A flexible issue tracker lets you stay on top of bugs and focus on features.

'''Collaborative code review.'''
Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch.

Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

'''Text entry with understated power.'''
Rather than dozens of buttons, GitHub relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect Emoji. zap
Adding images is as simple as dragging and dropping from your desktop. For an even more distraction-free writing experience, you can use the fullscreen Zen Mode.

Syntax highlighted code & rendered data.
Git-hub's highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

'''On the desktop and in your pocket.'''
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

'''Integration and Add-Ons'''
Great software begins with great design. These integrators specialize in helping you explore and visualize ideas, design UI and workflows, and track your progress.
*Amazon Web Services
*Google Cloud Platform
*Heroku
*Windows Azure

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:10:42Z

Vpiddem: /* Centralized Vs Distributed Version Control System */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development. [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

===Centralized Version Control System===

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

===Distributed Version Control System===

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based Git-hub GUI and has successfully incorporated the following robust features which make the job of Collaborative code management a breeze. These include :

'''Integrated issue tracking.'''
A flexible issue tracker lets you stay on top of bugs and focus on features.

'''Collaborative code review.'''
Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch.

Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

'''Text entry with understated power.'''
Rather than dozens of buttons, GitHub relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect Emoji. zap
Adding images is as simple as dragging and dropping from your desktop. For an even more distraction-free writing experience, you can use the fullscreen Zen Mode.

Syntax highlighted code & rendered data.
Git-hub's highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

'''On the desktop and in your pocket.'''
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

'''Integration and Add-Ons'''
Great software begins with great design. These integrators specialize in helping you explore and visualize ideas, design UI and workflows, and track your progress.
*Amazon Web Services
*Google Cloud Platform
*Heroku
*Windows Azure

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T02:10:18Z

Vpiddem: /* Why use Git? */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development. [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

'''Centralized Version Control System'''

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

'''Distributed Version Control System'''

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
=== Branching Model===
Git's most compelling feature is that, it really makes it stand apart from nearly every other SCM out there is its [http://nvie.com/posts/a-successful-git-branching-model/ branching model]. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds. <br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

=== Everything is Local===
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk. This not only makes most operations much faster than anyone may be used to, but it also allows you to work on stuff offline. Being able to branch, merge, commit and browse history of one's project while on the plane or train is very productive.

===Git is Fast===
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/>Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

===Git is Small===
Git is really good at conserving disk space. A Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br />The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk-space Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

===The Staging Area===
Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br />The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

===Distributed===
One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that were tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

===Any Workflow===
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the [http://www.linux.org/ Linux] kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based Git-hub GUI and has successfully incorporated the following robust features which make the job of Collaborative code management a breeze. These include :

'''Integrated issue tracking.'''
A flexible issue tracker lets you stay on top of bugs and focus on features.

'''Collaborative code review.'''
Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch.

Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

'''Text entry with understated power.'''
Rather than dozens of buttons, GitHub relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect Emoji. zap
Adding images is as simple as dragging and dropping from your desktop. For an even more distraction-free writing experience, you can use the fullscreen Zen Mode.

Syntax highlighted code & rendered data.
Git-hub's highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

'''On the desktop and in your pocket.'''
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

'''Integration and Add-Ons'''
Great software begins with great design. These integrators specialize in helping you explore and visualize ideas, design UI and workflows, and track your progress.
*Amazon Web Services
*Google Cloud Platform
*Heroku
*Windows Azure

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T01:43:53Z

Vpiddem: /* Centralized Vs Distributed Version Control System */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Background ==

[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development. [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Centralized Vs Distributed Version Control System ==

'''Centralized Version Control System'''

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most popular centralized version control systems are CVS, Subversion (or SVN) and Perforce.

'''Distributed Version Control System'''

DRCS take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
;Branching Model: Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.<br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

;Everything is Local: There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.

;Git is Fast: Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/> Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

;Git is Small: Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br /> The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

;The Staging Area: Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br /> The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

;Distributed: One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] I tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

;Any Workflow: One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based Git-hub GUI and has successfully incorporated the following robust features which make the job of Collaborative code management a breeze. These include :

'''Integrated issue tracking.'''
A flexible issue tracker lets you stay on top of bugs and focus on features.

'''Collaborative code review.'''
Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch.

Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

'''Text entry with understated power.'''
Rather than dozens of buttons, GitHub relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect Emoji. zap
Adding images is as simple as dragging and dropping from your desktop. For an even more distraction-free writing experience, you can use the fullscreen Zen Mode.

Syntax highlighted code & rendered data.
Git-hub's highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

'''On the desktop and in your pocket.'''
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

'''Integration and Add-Ons'''
Great software begins with great design. These integrators specialize in helping you explore and visualize ideas, design UI and workflows, and track your progress.
*Amazon Web Services
*Google Cloud Platform
*Heroku
*Windows Azure

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T01:33:12Z

Vpiddem: /* Developments and Feature Enhancements */

<div style="float: right;">
[[File:git-logo.png]]
</div>
= Background =

== What is Git? ==
[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development. [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

== Why use Distributed Version Control System? ==

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

== Why use Git? ==
;Branching Model: Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.<br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

;Everything is Local: There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.

;Git is Fast: Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/> Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

;Git is Small: Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br /> The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

;The Staging Area: Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br /> The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

;Distributed: One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] I tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

;Any Workflow: One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based Git-hub GUI and has successfully incorporated the following robust features which make the job of Collaborative code management a breeze. These include :

'''Integrated issue tracking.'''
A flexible issue tracker lets you stay on top of bugs and focus on features.

'''Collaborative code review.'''
Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch.

Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

'''Text entry with understated power.'''
Rather than dozens of buttons, GitHub relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect Emoji. zap
Adding images is as simple as dragging and dropping from your desktop. For an even more distraction-free writing experience, you can use the fullscreen Zen Mode.

Syntax highlighted code & rendered data.
Git-hub's highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

'''On the desktop and in your pocket.'''
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

'''Integration and Add-Ons'''
Great software begins with great design. These integrators specialize in helping you explore and visualize ideas, design UI and workflows, and track your progress.
*Amazon Web Services
*Google Cloud Platform
*Heroku
*Windows Azure

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T01:31:23Z

Vpiddem: /* Developments and Feature Enhancements */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
[http://git-scm.com/ Git] (/ɡɪt/) is a locally enabled distributed revision control and [https://en.wikipedia.org/wiki/Revision_control source code management (SCM)] system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by [https://en.wikipedia.org/wiki/Linus_Torvalds Linus Torvalds] for [http://www.linux.org/ Linux] kernel development in 2005, and has since become the most widely adopted version control system for software development. [https://github.com/ Github], a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.

Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why use Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why use Git? ===
;Branching Model: Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.<br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

;Everything is Local: There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.

;Git is Fast: Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/> Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

;Git is Small: Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br /> The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

;The Staging Area: Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br /> The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

;Distributed: One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] I tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

;Any Workflow: One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based Git-hub GUI and has successfully incorporated the following robust features which make the job of Collaborative code management a breeze. These include :

'''Integrated issue tracking.'''
A flexible issue tracker lets you stay on top of bugs and focus on features.

'''Collaborative code review.'''
Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch.

Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

'''Text entry with understated power.'''
Rather than dozens of buttons, GitHub relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect Emoji. zap
Adding images is as simple as dragging and dropping from your desktop. For an even more distraction-free writing experience, you can use the fullscreen Zen Mode.

Syntax highlighted code & rendered data.
Git-hub's highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

'''On the desktop and in your pocket.'''
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T01:23:53Z

Vpiddem: /* Developments and Feature Enhancements */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
;Branching Model: Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.<br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

;Everything is Local: There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.

;Git is Fast: Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/> Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

;Git is Small: Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br /> The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

;The Staging Area: Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br /> The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

;Distributed: One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] I tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

;Any Workflow: One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
[[File:Git_data_flow_simplified.svg.png|frame]]
</div>

;Remote repository: A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

;Local repository: A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

;Index (cache) - Staging: When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

;Working directory: A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

Git Revision control System has come a long way with its Web based Git-hub GUI and has successfully incorporated the following robust features which make the job of Collaborative code management a breeze. These include :

'''Integrated issue tracking.'''
A flexible issue tracker lets you stay on top of bugs and focus on features.

'''Collaborative code review.'''
Code review is an essential part of the GitHub workflow. After creating a branch and making one or more commits, a Pull Request starts the conversation around the proposed changes. Additional commits are commonly added based on feedback before merging the branch.

Pull Requests are living conversations that streamline the process of discussing, reviewing, and managing changes to code.
Pull Request = Code + Issue + Code Comments
Each Pull Request takes into account not only what you would like pulled, but also where you intend those changes to be applied. henceforth, a team can discuss the changes as a whole, individual parts, or even specific lines. Later commits addressing concerns or ideas appear as part of the conversation.

'''Text entry with understated power.'''
Rather than dozens of buttons, GitHub relies on the simplicity of GitHub Flavored Markdown for formatting text. The autocompleter makes quick work of mentioning people and teams, creating links to other issues, and adding the perfect Emoji. zap
Adding images is as simple as dragging and dropping from your desktop. For an even more distraction-free writing experience, you can use the fullscreen Zen Mode.

Syntax highlighted code & rendered data.
Git-hub's highlighting currently supports over 200 programming languages. Data is as important to us as code, so we're always looking for new ways to render formats like STL 3D models, CSV files, and GeoJSON maps in the browser.

'''On the desktop and in your pocket.'''
Native GitHub applications for Windows and Mac make sharing code simple. You can use them to clone repositories, create branches, browse history, and commit changes with a friendly interface. Our Android app and mobile web views let you keep track of your projects on the go.

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T01:14:26Z

Vpiddem: /* How do I use Git? */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
;Branching Model: Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.<br/>This means that you can do things like:
:* Create experimental branches.
:* Clear cut Branch delineation into Production, Development, Testing, Fixes, Patches, etc.
:* Seamless Navigation across feature branches and Code Versions.
:* Create and Work on your own patches, features and tests without effecting the Production/Master branch.
:* Independent Merging and Management of one's content changes.

;Everything is Local: There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.

;Git is Fast: Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on [https://subversion.apache.org/ SVN] and [http://www.perforce.com/ Perforce], both of which require network access for certain operations. However, even compared to the other [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] that also perform operations locally, Git is pretty fast. <br/> Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, [http://git-scm.com/ Git] is written in [https://en.wikipedia.org/wiki/C_(programming_language) C], reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

;Git is Small: Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an [https://subversion.apache.org/ SVN] checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs). <br /> The following numbers were taken from clones of the [https://www.djangoproject.com/ Django] project in each of its semi-official Git mirrors at the same point in its history.
:{| class="wikitable" style="text-align: center;"
|+ Disk Usage
!
! [http://git-scm.com/ Git ]
! [http://mercurial.selenic.com/ Mercurial]
! [http://mercurial.selenic.com/ Bazaar]
! [https://subversion.apache.org/ SVN]
|-
! Repo Alone
| 24M
| 34M
| 45M
| -
|-
! Entire Directory
| 43M
| 53M
| 64M
| 61M
|}

;The Staging Area: Unlike the other systems, Git has what it calls the '''"staging area"''' or '''"index"'''. This is an intermediate area that you can setup what you want your commit to look like before you commit it. <br /> The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory.

;Distributed: One of the coolest features of any of the [https://en.wikipedia.org/wiki/Distributed_revision_control Distributed SCMs], Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. <br/> This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point. <br />This does not slow things down much, either. On average, an [https://subversion.apache.org/ SVN] checkout is only marginally faster than any of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs]. Of the [https://en.wikipedia.org/wiki/Distributed_revision_control DSCMs] I tested, Git was the fastest.

:{| class="wikitable" style="text-align: center; width: 200px;"
|+ Cloning Benchmarks
|-
! [http://git-scm.com/ Git ]
| 1m 59s
|-
! [http://mercurial.selenic.com/ Mercurial]
| 2m 24s
|-
! [http://mercurial.selenic.com/ Bazaar]
| 5m 11s
|-
! [https://subversion.apache.org/ SVN]
| 1m 4s
|}

;Any Workflow: One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.

:*;Subversion-Style Workflow: A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

:*;Integration Manager Workflow: Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or [https://github.com/ GitHub] repositories.

:*;Dictator and Lieutenants Workflow: For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div>
<h2>Commands</h2>
<p>For a list of command line commands, please go to [Git-Reference]</p>

<table>

<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>

<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.

A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>

</table>

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

== Developments and Feature Enhancements ==

File:Git data flow simplified.svg.png

2014-09-20T01:11:30Z

Vpiddem: uploaded a new version of "File:Git data flow simplified.svg.png"

Git Revision Control-Data Flow

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:55:58Z

Vpiddem: /* Git Work Flow Terminology */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
'''Branching Model'''
Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
This means that you can do things like:
• Create experimental branches.
• Clear cut Branch delineation into production,Development,Testing,Fixes,Patches,etc.
• Seamless Navigation across feature branches and Code Versions.
• Create and Work on your own patches, features and tests without effecting the Production/Master branch.
• Independent Merging and Management of one's content changes.

'''Everything is Local'''
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
local repo to remote repo flowchart.
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
'''
Git is Fast'''
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

'''Git is Small'''
Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
The following numbers were taken from clones of the [[Django]] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/ch1a_8_os#cite_note-0]project in each of its semi-official Git mirrors at the same point in its history.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M

'''The Staging Area'''
Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
commit only workflow diagram

'''Distributed'''
One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s

'''Any Workflow'''
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
subversion-style workflow

'''Integration Manager Workflow'''

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
integration manager workflow
'''
Dictator and Lieutenants Workflow'''

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div>
<h2>Commands</h2>
<p>For a list of command line commands, please go to [Git-Reference]</p>

<table>

<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>

<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.

A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>

</table>

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:55:29Z

Vpiddem: /* Git Work Flow Terminology */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
'''Branching Model'''
Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
This means that you can do things like:
• Create experimental branches.
• Clear cut Branch delineation into production,Development,Testing,Fixes,Patches,etc.
• Seamless Navigation across feature branches and Code Versions.
• Create and Work on your own patches, features and tests without effecting the Production/Master branch.
• Independent Merging and Management of one's content changes.

'''Everything is Local'''
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
local repo to remote repo flowchart.
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
'''
Git is Fast'''
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

'''Git is Small'''
Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
The following numbers were taken from clones of the [[Django]] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/ch1a_8_os#cite_note-0]project in each of its semi-official Git mirrors at the same point in its history.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M

'''The Staging Area'''
Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
commit only workflow diagram

'''Distributed'''
One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s

'''Any Workflow'''
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
subversion-style workflow

'''Integration Manager Workflow'''

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
integration manager workflow
'''
Dictator and Lieutenants Workflow'''

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div>
<h2>Commands</h2>
<p>For a list of command line commands, please go to [Git-Reference]</p>

{| border="1" class="wikitable"

<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>

<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.

A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>

|}

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:53:50Z

Vpiddem: /* Git Work Flow Terminology */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
'''Branching Model'''
Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
This means that you can do things like:
• Create experimental branches.
• Clear cut Branch delineation into production,Development,Testing,Fixes,Patches,etc.
• Seamless Navigation across feature branches and Code Versions.
• Create and Work on your own patches, features and tests without effecting the Production/Master branch.
• Independent Merging and Management of one's content changes.

'''Everything is Local'''
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
local repo to remote repo flowchart.
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
'''
Git is Fast'''
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

'''Git is Small'''
Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
The following numbers were taken from clones of the [[Django]] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/ch1a_8_os#cite_note-0]project in each of its semi-official Git mirrors at the same point in its history.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M

'''The Staging Area'''
Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
commit only workflow diagram

'''Distributed'''
One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s

'''Any Workflow'''
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
subversion-style workflow

'''Integration Manager Workflow'''

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
integration manager workflow
'''
Dictator and Lieutenants Workflow'''

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div>
<h2>Commands</h2>
<p>For a list of command line commands, please go to [Git-Reference]</p>

<table>
<tbody>
<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>

<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.

A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>
</tbody>
</table>

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:52:38Z

Vpiddem: /* Git Work Flow Terminology */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
'''Branching Model'''
Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
This means that you can do things like:
• Create experimental branches.
• Clear cut Branch delineation into production,Development,Testing,Fixes,Patches,etc.
• Seamless Navigation across feature branches and Code Versions.
• Create and Work on your own patches, features and tests without effecting the Production/Master branch.
• Independent Merging and Management of one's content changes.

'''Everything is Local'''
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
local repo to remote repo flowchart.
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
'''
Git is Fast'''
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

'''Git is Small'''
Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
The following numbers were taken from clones of the [[Django]] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/ch1a_8_os#cite_note-0]project in each of its semi-official Git mirrors at the same point in its history.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M

'''The Staging Area'''
Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
commit only workflow diagram

'''Distributed'''
One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s

'''Any Workflow'''
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
subversion-style workflow

'''Integration Manager Workflow'''

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
integration manager workflow
'''
Dictator and Lieutenants Workflow'''

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div>
<h2>Commands</h2>
<p>For a list of command line commands, please go to [Git-Reference]</p>

<table class="table table-striped">

<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>

<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.

</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.

A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>
</tbody>
</table>

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:46:04Z

Vpiddem: /* Git Work Flow Terminology */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
'''Branching Model'''
Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
This means that you can do things like:
• Create experimental branches.
• Clear cut Branch delineation into production,Development,Testing,Fixes,Patches,etc.
• Seamless Navigation across feature branches and Code Versions.
• Create and Work on your own patches, features and tests without effecting the Production/Master branch.
• Independent Merging and Management of one's content changes.

'''Everything is Local'''
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
local repo to remote repo flowchart.
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
'''
Git is Fast'''
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

'''Git is Small'''
Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
The following numbers were taken from clones of the [[Django]] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/ch1a_8_os#cite_note-0]project in each of its semi-official Git mirrors at the same point in its history.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M

'''The Staging Area'''
Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
commit only workflow diagram

'''Distributed'''
One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s

'''Any Workflow'''
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
subversion-style workflow

'''Integration Manager Workflow'''

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
integration manager workflow
'''
Dictator and Lieutenants Workflow'''

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div>
<h2>Commands</h2>
<p>For a list of command line commands, please go to [Git-Reference]</p>

<table class="table table-striped">

<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>

<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.

A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>
</tbody>
</table>

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:42:52Z

Vpiddem: /* Git Work Flow Terminology */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
'''Branching Model'''
Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
This means that you can do things like:
• Create experimental branches.
• Clear cut Branch delineation into production,Development,Testing,Fixes,Patches,etc.
• Seamless Navigation across feature branches and Code Versions.
• Create and Work on your own patches, features and tests without effecting the Production/Master branch.
• Independent Merging and Management of one's content changes.

'''Everything is Local'''
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
local repo to remote repo flowchart.
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
'''
Git is Fast'''
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

'''Git is Small'''
Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
The following numbers were taken from clones of the [[Django]] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/ch1a_8_os#cite_note-0]project in each of its semi-official Git mirrors at the same point in its history.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M

'''The Staging Area'''
Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
commit only workflow diagram

'''Distributed'''
One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s

'''Any Workflow'''
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
subversion-style workflow

'''Integration Manager Workflow'''

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
integration manager workflow
'''
Dictator and Lieutenants Workflow'''

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div>
<h2>Commands</h2>
<p>For a list of command line commands, please go to [Git-Reference]</p>

<table class="table table-striped">
<tbody>
<thead>
<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>
</thead>
<tbody>
<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.
<br /><em>This was taken from <a href="http://www.vogella.com/articles/Git/article.html">vogella.com</a></em>

<br /><br />
A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>
</tbody>
</table>

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:40:58Z

Vpiddem: /* Git Work Flow */

<div style="float: right;">
[[File:git-logo.png]]
</div>
== Introduction ==

=== What is Git? ===
Git (/ɡɪt/) is a locally enabled distributed revision control and source code management (SCM) system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development. Github, a git repository web-based hosting service is in fact the largest code host on the planet with over 15.7 million repositories. Large or small, every repository comes with the same powerful tools. These tools are open to the community for public projects and secure for private projects.
As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

=== Why Distributed Version Control System? ===

[https://en.wikipedia.org/wiki/Distributed_revision_control Distributed Revision Control Systems (DRCS)] take a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository.Distributed revision control conducts synchronization by exchanging patches(change-sets) from peer to peer. This results in some important differences from a centralized system:

*No canonical, reference copy of the codebase exists by default; only working copies.
*Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server.
*Rather, communication is only necessary when pushing or pulling changes to or from other peers.
*Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing inherent protection against data loss.

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems:
*Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
*Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
*Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
*Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

=== Why Git? ===
'''Branching Model'''
Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model.Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
This means that you can do things like:
• Create experimental branches.
• Clear cut Branch delineation into production,Development,Testing,Fixes,Patches,etc.
• Seamless Navigation across feature branches and Code Versions.
• Create and Work on your own patches, features and tests without effecting the Production/Master branch.
• Independent Merging and Management of one's content changes.

'''Everything is Local'''
There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
local repo to remote repo flowchart.
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
'''
Git is Fast'''
Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.

'''Git is Small'''
Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
The following numbers were taken from clones of the [[Django]] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/ch1a_8_os#cite_note-0]project in each of its semi-official Git mirrors at the same point in its history.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M

'''The Staging Area'''
Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
commit only workflow diagram

'''Distributed'''
One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s

'''Any Workflow'''
One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Subversion-Style Workflow
A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
subversion-style workflow

'''Integration Manager Workflow'''

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
integration manager workflow
'''
Dictator and Lieutenants Workflow'''

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.

== Git Work Flow Terminology ==
<div style="float: right;">
<p align="right">
[[File:Git_data_flow_simplified.svg.png]]
</p>
</div>
'''Git Data Flow'''

Understanding the Git and a typical Distributed VCS terminology :

A project is the files/source code a developer is currently writing. A git-project is a project that is using git to track/manage changes to the project.
'''Remote repository'''
A centralize Git server to host all your git-projects. A central repository (repo) is not required but it is the best way to distribute (share) your git-projects to different user/developers. Most would call the remote repository (repo) the Origin and keeping it up-to-date is highly recommended. In our case, GitHub would be our remote repo. They all work together and it all one thing.

'''Local repository'''
A local repo is a git-project on your computer. If you were to have a Remote repository (GitHub), then the local repo would be a clone (exact copy) of the remote git-project. When you make changes to your local repo like adding code, you will need to update (push) the git-project to remote repo.

'''Index (cache) - Staging'''
When you make changes to your files, you can not commit (snapshot in time) until you "stage" the files. Once you stage the file, you can then commit the changes.The purpose of this Index (staging area) is that it allows you to control what you want to commit. Typically,any code changes that are not complete can be left out of the commit.

'''Working directory'''
A working directory is the current git-project, which is your source code with git files. A working directory is a local repo which you can make changes (commit, branches) to it.

<div class="tab-pane" id="lC">
<h2>Commands</h2>
<p>For a list of command line commands, please go to <a href="http://gitref.org/">gitref.org</a></p>

<h2>Definitions</h2>
<p>This is not a complete list, it ones that I think are important.</p>

<table class="table table-striped">
<tbody>
<thead>
<tr>
<th width="120px">Term</th>
<th>Explanation</th>
</tr>
</thead>
<tbody>
<tr>
<td>branches</td>
<td>It allows you to create a separate working copy of your code and develop it in a
new way wihtout affect the original code. So its like creating a new project (branch) based on the original, the original
is usually called the Master. The branch is completely independent of the Master and you can develop both the Master and
branch at the same time. You can also have multiple branches and you can <code>merge</code> any of these together.

<br /><br />Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>clone</td>
<td>
Clone is a copy of a repository. Clone is used when you copy from the remote repository to your local repository.
<br /><br />Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>collaborator</td>
<td>Collaborators are other GitHub users that you’ve given write access to one or more of your repositories.
Collaborators may fork any private repository you’ve added them to without their own paid plan. Their forks do not count against your private repository quota.
<br />
<em>This was taken from github.com</em>
</td>
</tr>
<tr>
<td>commit</td>
<td>A commit is like a bookmark/milestone that is recorded in the repository. It creates a revision that you can view and
revert back to at anytime. When using Git, you are encourge to do many small commits since all of these commits are done
on your computer. When you update (push) to the remote repository to backup or share with other developers all the commits will
be viewable.
<br /><br />
In projects with multiple developers, doing many small commits and updating the remote repository many times a day will allow your coworkers
to merge your changes into their code and thus resolving discrepancies early which is much easier to resolve than waiting
and doing a massive merge.
<br /><br />
A commit will always contain the author and committer. Author is usually the creator/owner
of the project and a committer can be a collaborator or the author.</td>
</tr>
<tr>
<td>fetch</td>
<td>
Fetch is a command in Git or command, you use fetch to synchronize your local repository with the remote repository. Its important to know that
fetch does not merge any new changes to your source code (local repository). New changes from the fetch will be considered a "remote branches",
you can combine new changes to your code by using the <code>merge</code> command.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the changes with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>fetch</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository
and if new code is downloaded, then you can check out what is new. You will also need to do a <code>merge</code>.
</li>
</ul>

Note: fetch is not a clone, clone is a new copy down from the repository, fetch is to update your local repository.
</td>
</tr>
<tr>
<td>fork</td>
<td>
Fork is NOT a Git term, its a term born from the community. Forking is similar to branching in that you copy the origin
(Master) to your account. The difference is that you are copying the source code from the author (owner) to your
account. Branching is copying within the same account.
<br /><br />
So when does this happen? Forking usually happens for 2 reasons:
<ol>
<li>You fork it to take the project in a new direction. Obviously you can only do this with open source projects</li>
<li>You fork the project to add to the project and request a merge back to the origin/master. You as a independent
developer want to contribute to the code.</li>
</ol>
Branching, cloning and forking is sometimes confused.
<br />Good discussion on <a href="http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-and-clone-in-git">stackoverflow.com</a>
</td>
</tr>
<tr>
<td>merge</td>
<td>
A merge is combining branches with your Master (origin). When to you do <code>pull</code> a fetch and merge will be done to update your local repository.
When merging two code sets together, if a conflict were to occur, it will be up to you to resolve it.
</td>
</tr>
<tr>
<td>pull</td>
<td>
A pull is basically 2 command execute together. Pull will do a <code>fetch</code> and <code>merge</code> on your local repository.
When using the GitHub Windows Client, you will usually do a pull.

<br /><br />When will this happen?
<ul>
<li>When a collaborator/coworker ask you to test the change with your code</li>
<li>Before you do a push (upload to remote repository), you would want to do a <code>pull</code>, which will synchronize your
local repository to the remote repository. So you are making sure your local repository is up-to-date with the remote repository and you can
test you code with any new code committed to the remote repository.
</li>
</ul>
</td>
</tr>
<tr>
<td>push</td>
<td>
Push is the command to upload your local repository to the remote repository. Any changes that you want to push to the remote repository, you
will need to <code>commit</code> on those changes on your local repository.
</td>
</tr>
<tr>
<td>repository</td>
<td>Contains all the history... like commits, branches, tags and your source code. Repository can be remote which is a central
storage for repository. Local repository would be what the user/deverloper works with (make changes to).
Remote repository is a centralize repository for sharing projects.</td>
</tr>
<tr>
<td>revision</td>
<td>
Revisions represents a version of the source code. Git identifies revisions with SHA1 ids. SHA1 ids are 160 bits long and are represented
in hexadecimal. The latest version can be addressed via "HEAD", the version before that via "HEAD~1" and so on.
<br /><em>This was taken from <a href="http://www.vogella.com/articles/Git/article.html">vogella.com</a></em>

<br /><br />
A revision is created when you do a commit. So a commit is a command and a revision is like the bookmark... so when you hear someone
say "revert back to the last commit"... technically they should say, "revert back to the last revision".
</td>
</tr>
<tr>
<td>tags</td>
<td>A tag is like a commit, it allows you to permanantly mark a point in your project. A common use of tags is to mark the
application version number. This version number is the same displayed in the help/about.</td>
</tr>
<tr>
<td>URL</td>
<td>Used to tell Git where the remote repository is.
<br />There is more than one type of URL
<ul>
<li>HTTP: Should be a https (secure) https://github.com/<user>/<git_project></li>
<li>GIT: Uses git communication git://github.com/<user>/<git_project></li>
<li>SSH: Uses SSH git@github.com:<user>/<git_project></li>
</ul>
</td>
</tr>
</tbody>
</table>

</div>

== Characteristics of Git ==

;Strong support for non-linear development: Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.

;Distributed development: Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.

;Efficient handling of large projects: Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.

;Cryptographic authentication of history: The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.

;Toolkit-based design: Following the [http://www.unix.org/ Unix] tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both convenient human usage and easy scripting to perform new clever operations.

== How do I use Git? ==

Every commit that a user makes will have his/her name and email address to identify the ‘owner’ of the commit, so the user should give these values in a form of configuration.

<pre>
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
</pre>

To get started with Git, a user needs to run the git init command in an empty directory; this initializes a [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository Git repository] in that folder, adding a ''.git'' folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

<pre>
git init
</pre>

A project managed by Git can be considered as a tree; a user can create different features on different branches, and everything will stay separate and safe. After the user has created new files in the repository. It is time to commit these files to mark the completion of feature development and ready to push changes to remote repository. However, before that, the user needs to add the files and move it to staging area.

<pre>
git add .
</pre>

A user can also more specifically add files.

<pre>
git add *.js
git add index.php
</pre>

This will add all the files to staging area. To stage is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit.
[[File:GitThreeStates.png|frame|center]]

After a user has staged the required files, they need to commit the files by giving a commit description.

<pre>
git commit -m "Commit description"
</pre>

Each commit should have an accompanying message, so everyone in the project knows why that code was committed. A user can also skip the command to add the files in the staging area by directly asking Git to stage and commit with a message.

<pre>
git commit -am "Commit description"
</pre>

Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it's using the code to create the hash, no two hashes in the user's project will be the same unless the code in the commits is identical. A user can check the status of the git repository by the following command.

<pre>
git status
</pre>

To push the changes to a remote git repository, a user can do a git push as following.

<pre>
git push origin master
</pre>

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:34:42Z

Vpiddem: /* Why Git? */

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:34:28Z

Vpiddem: /* Git Work Flow */

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:34:19Z

Vpiddem: /* Git Work Flow */

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:32:58Z

Vpiddem: /* Git Work Flow */

CSC/ECE 517 Fall 2014/ch1a F1415 rv

2014-09-20T00:32:21Z

Vpiddem: /* Git Work Flow */