Git and Github

Git is a distributed version control system and it differs from a centralized version control system like SVN in quite a few respects.

SVN involves a central repository. Each client then checks out a copy of this repository to make a local copy called the ‘Working directory’. Each client makes changes to his own working directory. The changes are committed to the Central repository when the client checks in i.e.commits the code.The central repository maintains the older versions of the code as well. Hence the client can rollback his working directory to a previous version of code from the central repository.

Git (–distributed is the new centralized) also includes a central repository. But in addition to the central repository, each client has his own repository on his local machine. Essentially, the working directory in this case acts as a repository in itself. Commits, rollbacks etc are to be done first at the working directory level and then pushed to the remote branch in the central repository. The client here can rollback to a previous version of code from his local repository or from the central repository.

For more details on the differences between Git and SVN, here is a good link

http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/

When you are moving away from SVN and towards Git, things can be confusing. I published a couple of projects on Github and that is how I got my first taste of Git.

This blog simply aims at giving you the basic Git commands that you need to know in order to work with Git and publish your projects to Github. The commands and responses below are all from MAC OS X 10.8.5 Terminal app.

To demo this, I am going to create a Test iOS project and publish it to Github.

1. Create an account at github.com.

2. Create your project on your MAC that you wish to publish to github. In my case, I am creating a Test iOS application project. Xcode provides you a capability to create a git repository as you create the project, but I will create it using a terminal command.

3. Check if you have git on your MAC. The latest versions of MAC OS X come with built in Git. You can check for this from the Terminal using the command

$ git –version

If you do not have git installed on your desktop, download and install it from http://git-scm.com/downloads

Once git is installed, navigate to your project folder path in the Terminal and use the below command to create your local git repository:

$ git init

4. You can see that the above command adds a .git hidden folder in your project folder. To see the .git folder, navigate to your project folder in Finder, click on the ‘Go’ option on the top menu and select ‘Go to Folder’. Type in ‘.git’ and click Go. This will show you the hidden .git folder and the contents under it.

.git folder

5. On github, login with your account and go to Repositories tab. Click on ‘New’ to create a new repository. Provide the repository name. In this case, I am going to name it as ‘Test’. Provide a description (although it is optional, its good to provide one). Select the option ‘Private’ or ‘Public’ to indicate who can see the repository. ‘Private’ option will need you to have a paid account with github.

At this point you can add the README file and license by selecting the checkbox ‘Initialize this repository with a README’ and selecting appropriate options in the dropdowns below. You can add these files later as well.

Creating new repository on github

Click on Create Repository. At this point, this is an empty repository on github.

Github Test repository

You will now need to add your project to this repository.

6. In order to add your project to the github repository, you will first need to add the files and folders of the project and commit them locally. In order to do this, type the following commands in the terminal:

In order to selectively add the files to commit, type the following command:

git add <files or folder name>

Alternately, in order to add all the files in the current folder and its subfolders, type the command as

git add .

7. Once the files to commit have been added, you need to do a local commit first using the command

git commit -m “message”

“message” should be any commit message that you wish to provide.

add and commit files

8. Configure your git username, email address and password as below

git config –global user.name “your name to be visible when you commit”

git config –global user.email “your email associated with github”

git config –global user.password “your github password”

9. You will then need to add your github ‘Test’ repository as your remote origin using the command:

git remote add origin <git repository url>

10. Your remote repository is called has the origin branch by default. To push your local repository a.k.a. master to the remote github repository, use the command:

git push origin master

push to origin

If you now check your repository on github, you will see your project files added in it.

Github Test repository

11. To update your local copy with the changes from the remote repository, use the command

git pull <git repo url> <branch name>

If you do not wish to work with the command line tools, there are GUI clients available for git. Take a look at

http://git-scm.com/downloads/gui

These are the basic steps to using git and publishing to github. There is a lot more to git than this. This should hopefully help you get started. Do leave your comments if you found this useful.

Advertisements

Same-Origin policy and working around it

Scripting languages like Javascript are restricted on their ability to call a service hosted on a domain different than their own domain by a policy implemented in the browsers called the same-origin policy.

The domain is determined by 3 parameters of the url:

– protocol

– host

– port number

If any of this differs between the caller domain and the callee domain, the javascript call to the callee domain will return an error saying cross domain requests are not allowed.

More information: http://en.wikipedia.org/wiki/Same_origin_policy

To overcome this constraint, at least 3 solutions exist today:

JSONP – JSON with Padding

This is an older technique supported by all the browsers. This works if you are calling a service which returns a JSON response. You make the service call as the ‘src’ attribute value of a <script> tag and pass the name of the callback function in the url. The service will then respond back with a javascript call to the callback function and the JSON response will be passed as the parameter to that function. You implement the callback function in your javascript code and this is where you will receive your response.

The deal with JSONP is that it is not secure since any javascript can be injected in this way by the server. Also, this approach works only for HTTP GET requests.

CORS – Cross Origin Resource Sharing

This was introduced to provide a more secure solution than JSONP and now CORS is supported by all latest browsers. CORS involves addition of some new HTTP headers in the response from the server. The browser on receiving these headers will determine if the javascript call is allowed or not. Primary amongst these headers is

Access-Control-Allow-Origin: *

A value like ‘*’ will allow requests from any domain to call this service. A more restricted value can be applied to limit successful requests from specific domains only.

Apart from this, there are a number of other headers that may/may not be needed for CORS to work depending on your call. Some of them are as below:

Access-Control-Allow-Methods: <comma separated list of methods that the server allows>

Access-Control-Allow-Headers: <comma separated list of headers allowed by the server in the client request>

Apart from this, the server should also support a call to HTTP OPTIONS method which the client calls during a preflight request. The preflight request is made prior to making the actual HTTP request to the desired method and is used to determine the allowed HTTP methods that the server supports and also the allowed origins. When the OPTIONS request returns a successful response, the browser automatically will make the actual HTTP call for the desired method.

Here is a good reference on CORS:

http://www.w3.org/TR/cors/

Reverse Proxy

This is when you create a proxy between your javascript and the service such that the proxy is hosted in the same domain as the javascript. The javascript call to the service is then modified to be a call to the proxy and since the proxy is in the same domain as the javascript, it does not throw a cross domain error. The proxy will be responsible for calling the actual service on another domain, getting the response and then passing back the response to the javascript. The proxy can be a simple servlet or even a server like Apache or IIS can be configured to act as a pass through proxy.

Here is how you can configure the Apache server on a MAC (we are going to use the Apache server which comes installed by default on the latest MAC OS X versions) to act as a passthrough proxy:

Go to Terminal and type in

$ sudo nano /etc/apache2/httpd.conf

In the httpd.conf file, add the 3 lines highlighted below:

Listen 80

ProxyRequests off

ProxyPassMatch /<keyword>/(.*) <destination service domain>/$1

SSLProxyEngine On

Hit Ctrl+O to write out your changes to the conf file. Hit Enter. Hit Ctrl+X to exit.

Restart your apache server from the Terminal:

 $ sudo apachectl -k restart

The important line here is

ProxyPassMatch /<keyword>/(.*) <destination service url>/$1

This essentially means that when you make a call to this local Apache server in your javascript code with a url like

http://localhost:80/<…>/<keyword>/<rest_of_the_path&gt;

the server will act as a proxy and make a call to

<destination service url>/<rest_of_the_path>

and return back the response from the service call to the javascript.

Using this ProxyPassMatch, we are limiting the Apache server to only act as a proxy for the url calls that have the pattern ‘/<keyword>/’ and to append anything after ‘/<keyword>/’ to the destination url.

For more details on creating a reverse proxy, please refer:

http://overwatering.org/blog/2012/04/reverse-proxy-javascript-app/

In addition, I still haven’t found a reasonable explanation as to why the same-origin policy won’t affect a native app running javascript in a javascript engine or a hybrid app running it in a web view:

http://stackoverflow.com/questions/21143963/why-doesnt-same-domain-policy-affect-native-mobile-apps

If you have a good explanation, please do post it in the comments.

HTML5 – Clocks

My another Github project that I published during my learning phase of HTML5 (I am still learning) was a simple clock demo. It displays an analog and a digital clock. Works great on mobile web browsers as well. It uses the HTML5 canvas element and javascript apis to render.

Here is the link to the Github project: https://github.com/hetalv985/Clocks

The project is available for free under the MIT license.

Feel free to leave your feedback and suggestions.

iOS – Color Selector

I recently published a simple color selector tool for iOS. The project is available for free under the MIT license and can be integrated easily in your iOS apps. It is currently designed to work for iPhone 4, iPhone 4s, iPhone 5 and iPhone 5s form factors. The project has been created with Xcode 5.0 with Base SDK iOS 7. The deployment target is iOS 6.0 which means it works on iOS 6.0, 6.1, 7.0 and above. The code has been tested on iOS simulators for iOS 6.0, 6.1 and 7.0 with 3.5 inch and 4 inch displays.

Here is the link to the Github project: https://github.com/hetalv985/HVColorSelector

And here is a link to the wiki page where you can see the screenshots:

https://github.com/hetalv985/HVColorSelector/wiki

If you have any suggestions or feedback, please feel free to leave a comment.

Note: In case you face a crash when trying to run the project, select the Target in Xcode. Click on General. Go to Deployment Info section and set the ‘Main Interface’ to be either ‘Main_iPhone4’ or ‘Main_iPhone5’ storyboard and then run the app.