Developing Web Applications using ASP.NET 5 (beta 7) on Ubuntu Linux 14.04.2 LTS Part 2 – Configuring Git for ASP.NET on Linux
By: Nestor Guadarrama
In this article, I’ll show how to set your Ubuntu environment for work using Git as version control system client for your ASP.NET 5 development projects. I’ll assume that you already have your environment up and running and you also read the first part for this series: Developing Web Applications using ASP.NET 5 (beta 7) on Ubuntu Linux 14.04.2 LTS. Part 1 – Installing & Configuring.
GitHub is a Web-based Git repository hosting service. It offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features. Unlike Git, which is strictly a command-line tool, GitHub provides a Web-based graphical interface and desktop as well as mobile integration. It also provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project.
From Git documentation system, the major difference between Git and any other Version Control Systems (VCS) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time:
Figure 1. Other systems tend to store data as changes to a base of each file.
Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored:
Figure 2. Git stores data as snapshots of the projects over time.
Based on this definition, Git was designing as a Distributed Version Control Systems (DVCS). In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data:
Figure 3. Distributed version control.
Microsoft has been embracing uses Git as a client and GitHub as a services for all its Open Source project and this is something so remarkable because, as a matter of fact, there are tons of huge OSS projects developed by Microsoft and/or Microsoft communities that are being developed, maintain and running on GitHub: ASP.NET, Entity Framework 7, .NET, etc.
Coming back to our project, in order to get a well-configured environment, ASP.NET project on Github suggests clone several ASP.NET projects into your environment (in our case Ubuntu 14.04). So, let’s start!
INSTALLING GIT ON UBUNTU 14.04
I’m assuming that you are signed in as non-root user. By far the easiest way of getting Git installed and ready to use is by using Ubuntu's default repositories. This is the fastest method, but the version may be older than the newest version. If you need the latest release, consider following the steps to compile Git from source, however, in this article, we will not describe this method.
You can use the apt package management tools to update your local package index. Afterwards, you can download and install the program:
| sudo apt-get update sudo apt-get install git |
CONFIGURING GIT ON UBUNTU 14.04
Once the installation has successfully completed, the next thing to do is to set up the configuration details of the GitHub user. To do this use the following two commands by replacing "user_name" with your GitHub username and replacing "email_id" with your email-id you used to create your GitHub account. (Yes, you will need to create a user account on GitHub J):
| sudo git config --global user.name “user_name” sudo git config --global user.email “email_id” |
We can see all of the configuration items that have been set by typing:
| sudo git config –list |
Figure 4. Configuring Git global settings.
As you can see, this has a slightly different format. The information is stored in the configuration file, which you can optionally edit by hand with your text editor like this (I’ll use Gedit for edit this file):
| sudo gedit ~/.gitconfig |
There are many other options that you can set, but these are the two essential ones needed. If you skip this step, you'll likely see warnings when you commit to Git that are similar to this:
| [master 0b2a60b] initial project version Committer: root Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate. You can suppress this message by setting them explicitly: git config --global user.name "Your Name" git config --global user.email you@example.com After doing this, you may fix the identity used for this commit with: git commit --amend --reset-author |
SOME BASICS ABOUT GIT
Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot:
Figure 5. Working directory, staging area, and Git directory.
The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. The staging area is a file, generally contained in your Git directory that stores information about what will go into your next commit. It’s sometimes referred to as the “index”, but it’s also common to refer to it as the staging area.
CLONING ASP.NET vNEXT SAMPLES FROM GITHUB
Just like you want to have a good, clean work environment, the same idea applies to where you do your coding, especially if you're going to contribute to a number of projects at the same time. A good suggestion might be to have a folder called Git in your home directory which has subfolders for each of your individual projects. I created a folder on my Home location called git and cloned all samples from ASP.NET GitHub repository:
| mkdir –p ~/git/aspnetsamples ; cd ~/git/aspnetsamples git clone https://github.com/aspnet/home.git |
Figure 6. ASP.NET project samples cloned into my environment.
ASP.NET vNext (beta 8) has developed three (3) main samples: a) ConsoleApp, b) HelloMvc and c) HelloWeb. I’ll test HelloMvc and HelloWeb. First, I’ll navigate into HelloWeb folder. Using .NET Development Utility (DNU) you can restore all required packages for this project:
| cd ~home/samples/-beta8/HelloWeb/ dnu restore |
Figure 7. Packages restores using DNU command.
Now, using .NET Execution Environment (DNX), we can execute kestrel for running our web application:
| dnx kestrel |
We should see our web application up and running:
Figure 8. “HelloWeb” sample running on kestrel.
We will apply same procedure for HelloMvc sample. Here is the output:
Figure 9. “HelloMvc” sample running on kestrel.
CONVERTING AN EXISTING PROJECT INTO A WORKSPACE ENVIRONMENT
What happened with my first ASP.NET project created (test)? Can I use it into Git?. Short answer “Yes, you can use your previous projects and upload them into Git”. Let’s do it.
Because I love trying to be organized (this statement doesn’t necessarily mean that I’ve success all the times J) with my development projects, I’ll move my first project testproject into my Git folder:
| sudo mv /home/nguada/aspnet5/testproject /home/nguada/git -v |
Now, I want to start tracking my project on Git, so I need to use next command:
| git init |
This creates a new subdirectory named .git that contains all of your necessary repository files – a Git repository skeleton. At this point, nothing in your project is tracked yet. I want to start version-controlling existing files, so I’ll begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a git commit:
| git add *.* git commit –m ‘initial project version 0.0’ |
Following same procedure, I added a README.txt file just for testing purpose. After added this file and committed it to Git. You can see log operations using:
| git log |
Figure 10. Git log command.
PUBLISHING YOUR CODE INTO GITHUB
Up until this point, we have done everything on our local server. That's certainly an option to use Git locally, if you want to have any easy way to have version control of your files. If you want to work with a team of developers, however, you're going to need to push changes to a remote server. This section will explain how to do that.
I’m assuming that you already created a repository on GitHub. The first step to being able to push code to a remote server is providing the URL where the repository lives and giving it a name. You can choose publish your files using SSH or HTTPS. I’ll select using HTTPS for configure a remote repository to use and to see a list of all remotes, type the following:
| git remote add origin https://github.com/<YOURUSERNAME>/aspnet5projects.git git remote -v |
Now, you are able to push code to a remote server by typing the following:
| git push origin master |
Figure 11. Pushing code into my remote GitHub server.
That’s it!. Now, we should see files on our remote repository (GitHub):
Figure 12. Code already uploaded into GitHub.
‘till next time!