Discovering Git

I studied a general Computer Science degree which focused mainly on Software. During my studies I had to do a number of individual as well as group assignments. I remember a particular one on web software development —which happens to be my current area of work. We had to develop this project in a team of 5 peers. As it had to be mainly developed over the Christmas break, we divided our work and each of us developed one part. Then we did a manual merge of our work. At the time presentation we set up an IIS server and loaded our project to be defended. This was the winter period of 2008-2009.

After having worked for barely a month as a professional web engineer I can only now realise how rudimentary our process was. Our code changes weren’t controlled or logged in any way, our individual work could not be tracked and our deployment process consisted on copying over ftp our code files. We could have destroyed our mates’ work by overriding their files! (Something that in fact did happen).

I believe it is almost a crime, to have studied software engineering in University and not having been taught the essentials of version control —especially important when you work with a team— and a decent approach to deployment. Deployment by copying code through ftp would have probably been enough for the educational purpose of the project but only with decent collaboration strategy such as using git for version control.

What is git?

Git is a version control system for code. It is responsible for the management of changes to files. Changes are usually identified by a code string, referred to as "revision". Each revision is associated with a timestamp and the person making the change. Revisions can be compared and merged. It allows for more than one versions of the software to be developed concurrently allowing this through the creation of branches.

Structure

Revisions are generally thought of as a line of development (in git, called master by default) with branches off of this, which may vary depending on the development and deployment strategy. For example, a project may have a development branch, used by the developers to create new features, those features, once developed, are merged into a “test” branch and deployed to a testing environment where the new feature is tested. Lastly once the tests are done, this testing branch is merged into the main branch, called “master” and lastly released as a new version of the software.

Local and remote repositories

A repository encompasses the entire collection of files and folders associated with a project, along with each file’s revision history. The file history appears as snapshots in time called commits.

Git is a distributed system. As such, it gives each developer a local copy of the full development history, and changes are copied from a local repository to a remote central one. The other developers can pull those changes from the remote to their local repositories and merge them with their own work. Already existing repositories can be cloned and shared to be used by others as a new centralized repo.

Git can be installed in a private server and be used by others to create centralized repositories or a “GIT as a service” platform can be used as GitHub, Bitbucket or GitLab.

Basic Git commands

To use Git, developers use specific commands to copy, create, change, and combine code. These commands can be executed directly from the command line or by using a git GUI such as GitHub Desktop, Sourcetree or TortoiseGit. Here are some common commands for using Git:

git init initializes a brand new Git repository and begins tracking an existing directory. It adds a hidden subfolder within the existing directory that houses the internal data structure required for version control.
git clone creates a local copy of a project that already exists remotely. The clone includes all the files, history, and branches.
git add stages a change. This command performs staging, the first part of the two-step process of updating a repository. Any changes that are staged will become a part of the next commit and a part of the project’s history.
git commit saves the snapshot to the project history and completes the change-tracking process. A commit is like taking a photo. Anything that’s been staged with git add will become a part of the snapshot with git commit.
git status shows the status of changes as untracked, modified, or staged.
git branch shows the branches being worked on locally.
git merge merges lines of development together. This command is typically used to combine changes made on two differe t branches.
git pull updates the local line of development with updates from its remote counterpart. Developers use this command if a team mate has made commits to a branch on a remote, and they would like to reflect those changes in their local environment.
git push updates the remote repository with any commits made locally to a branch. 
To learn more, find here a full reference guide to Git commands.

Example : Set-up a privately-hosted bare Git repository

Assumption: You have ssh access to a remote server with Git installed on it.

1. Setup the server repository. In the server, navigate to your desired location and create your git folder:

git init --bare my-project.git

2. Use your newly created remote repository. Back on your local computer, and your local project folder, initialise the project and change the remote url:

git init
git remote set-url origin git@yourserver:/path/to/my-project.git

3. Now you can create the first files of the project, for example, create a new index.html and style.css files. After creating files, let's check the status of the repository:

git status

As we expected, we get:

On branch master
Initial commit

Changes to be committed:
(use "git rm --cached ..." to unstage)

  new file: index.html
  new file: style.css

4. Let's stage them with

git add index.html style.css

5. Take a snapshot of the staging area:

git commit -m “add index and style files"

6. Push changes to remote:

git push

So with this, we’ve created our first git repository and pushed our first commit. I recommend finding some time to work with a small team and test pulling new changes and merging files.