* * *

Introduction to Open Source

The term "open source" refers to something people can modify and share because its design is publicly accessible.

"Source code" is the part of software that most computer users don't ever see; it's the code computer programmers can manipulate to change how a piece of software—a "program" or "application"—works. Programmers who have access to a computer program's source code can improve that program by adding features to it or fixing parts that don't always work correctly.

Some software has source code that only the person, team, or organization who created it—and maintains exclusive control over it—can modify. People call this kind of software "proprietary" or "closed source" software.

Only the original authors of proprietary software can legally copy, inspect, and alter that software. And in order to use proprietary software, computer users must agree (usually by signing a license displayed the first time they run this software) that they will not do anything with the software that the software's authors have not expressly permitted. Microsoft Office and Adobe Photoshop are examples of proprietary software.

Open source software is different. Its authors make its source code available to others who would like to view that code, copy it, learn from it, alter it, or share it. LibreOffice and the GNU Image Manipulation Program (GIMP) are examples of open source software.

As they do with proprietary software, users must accept the terms of a license when they use open source software—but the legal terms of open source licenses differ dramatically from those of proprietary licenses.

Open source licenses affect the way people can use, study, modify, and distribute software. In general, open source licenses grant computer users permission to use open source software for any purpose they wish. Some open source licenses—what some people call "copyleft" licenses—stipulate that anyone who releases a modified open source program must also release the source code for that program alongside it. Moreover, some open source licenses stipulate that anyone who alters and shares a program with others must also share that program's source code without charging a licensing fee for it.

Version Control Systems

Version control systems are a category of software tools that help a software team manage changes to source code over time. Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing disruption to all team members.

Software developers working in teams are continually writing new source code and changing existing source code. The code for a project, app or software component is typically organized in a folder structure or "file tree". One developer on the team may be working on a new feature while another developer fixes an unrelated bug by changing code, each developer may make their changes in several parts of the file tree.

Version control helps teams solve these kinds of problems, tracking every individual change by each contributor and helping prevent concurrent work from conflicting. Changes made in one part of the software can be incompatible with those made by another developer working at the same time. This problem should be discovered and solved in an orderly manner without blocking the work of the rest of the team. Further, in all software development, any change can introduce new bugs on its own and new software can't be trusted until it's tested. So testing and development proceed together until a new version is ready.

What is GIT ??

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

Advantages Of GIT :-

  • You can revert your code anytime.

  • You can work on many branches at the same time (like software for different schools).

  • As the your code (say software ) evolves, you can release new versions from git , maintaining all the information of the previous versions and bugs and issues.

Alternatives to Git

Git is by far the most popular version control system (VCS) at the moment. As a developer, you are most likely already familiar with it, and it is used at your current or future workplace. But Git is not the only choice when it comes to version control. Let’s see what are some considerable alternatives to it.


Subversion (SVN) is probably the first alternative that comes to your mind. It is similar to Git in many ways, but there are major differences too. For example, SVN is a centralized version control system (VCS) while Git is distributed, which means that every developer has a copy of the repository on their local computers. This is not the case in Subversion, which relies on a single server to handle collaboration.


Perforce is a little different from Git or SVN. It can be used in many ways, including the way how Git works and even using actual Git commands. Instead of repositories, Perforce uses depots, which work in a similar fashion.

Perforce can be used with its own command-line client P4 or various graphical utilities, development environment integrations and plugins. Unlike Git or SVN, Perforce is a commercial product and is thus often found in enterprises. It is marketed for its speed and ability to work with large projects as well as enterprise-level security. Perforce comes with a free trial version and is free for up to five collaborators.

Team Foundation Version Control

Team Foundation Version Control (TFVC) is a version control system from Microsoft. It is capable of handling large binary files and uses an advanced permission system where it is possible to restrict access to code on a file-by-file basis. Team Foundation Version Control is also a centralized VCS.

It should be noted that Team Foundation Version Control is different from Team Foundation Server (TFS), although the names are often used interchangeably. TFS is a piece of software that can be used with TFVC to create a centralized version control system. Another choice is to use TFVC locally without any collaboration features.


Mercurial is a free, open-source distributed VCS. Due to its distributed nature a, Mercurial is fast and does not depend on an active Internet connection. Using Mercurial from the command line is very similar to Git: you edit files, add them to the staging area, commit and push. This is one of the reasons why Mercurial is considered easy to learn and use, especially if you have a previous Git background.


GIT Basics

1. Git init:

It is used to initialize a folder as a git repository.

2. Add :

It is used to add the new files that you create.

Syntax :

your_repository_folder>> git add filename

For adding all files :

 your_repository_folder>> git add .

3. Commit:

It is just like indexing . This command will index your changes and will not make any change in the main repository. It only changes locally. When you push (which will come further) the changes will be published to the main repository.


 your_repository_folder>> git commit -m "comment "


It is for making permanent changes to the source code.You can still revert to previous code


git push --all

I will suggest this –all


Fetch from and merge with another repository or a local branch


git pull

** before using anything like git pull –rebase please please take a look what harms it can do.

6. Clone

It is used to clone the git repository at any folder for making changes. It makes a new fork and only admin can allow to make the modification in the main Branch.


 git clone repository_location your_folder_location

These are Basic Operations that you must know if you are in software industry.

Now an example to show how to make a local repository

First you need to create a bare repository on H:. With git you usually name your bare repository with .git, so projectname.git in this case:

 >> cd Projects mkdir projectname.git cd projectname.git git init --bare

When this is done you change to c to create your repository:

 >> cd UsersxxxAptanaProjectsprojectname git init git add . git commit -m "First commit"

After this you need to setup the bare repo on h: as the remote repository so you can push up the code you just commited to the repo on c.

 >> git remote add origin H:Projectsprojectname.git git push origin master


Gitflow Workflow is a Git workflow design that was first published and made popular by Vincent Driessen at nvie. The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.

Git Workflow basics

Feature Branches

Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.


Feature Branches


Hotfix Branches

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.

Hotfix Branches


Some key takeaways to know about Gitflow are:

  • The workflow is great for a release-based software workflow.

  • Gitflow offers a dedicated channel for hotfixes to production.

The overall flow of Gitflow is:

  1. A develop branch is created from master

  2. A release branch is created from develop

  3. Feature branches are created from develop

  4. When a feature is complete it is merged into the develop branch

  5. When the release branch is done it is merged into develop and master.

  6. If an issue in master is detected a hotfix branch is created from master.

  7. Once the hotfix is complete it is merged to both develop and master.