Starting tool to introduce yourself to Devops culture – Git

DevOps is a new term emerging from the collision of two major related trends. It is  the outcome of  collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world

“DevOps” doesn’t really differentiate between different sysadmin sub-disciplines – “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other sub disciplines and job titles. “Dev” is used as shorthand for developers in particular, but really in practice it is even wider and means “all the people involved in developing the product,” which can include Product, QA, and other kinds of disciplines.

Version control systems are like the file servers of the software development world. And they are key to create a successful and efficient devops culture. GIT is one of the popular tool which is widely used for version controlling purpose.

In Simple terms “GIT is distributed version control tool”, but if you are absolutely new to distributed version control, there is a set of terms you have to know  to understand in the context of a simple developer workflow.

Each developer has a local copy of a repository. This is, at its core, a standalone copy of the history of changes made in the project. In order to share changes, developers will typically publish a copy of the repository to a centralized code hosting system, such as GitHub. Although, as you will see later in this chapter, there are other ways to share code.

From the central copy of the repository, developers will create a copy of the repository that they can make changes to. In Git parlance, this process is referred to as creating a clone, although this process can also be referred to as forking.

When cloning a repository, software developers may choose to make their copy of the project private or public. A private repository makes a quiet decision to not encourage people to look directly at this copy of the repository, and instead only look to the main project for officially accepted changes.

A public copy of a developer’s repository, on the other hand, is available for individuals to contribute to directly. This is a more open approach to software development, but may cause confusion about which copy of a repository ought to be the starting point.

It’s only through project governance that one repository for a project is decided to be the most important version. This is because every repository can accept changes, and share its changes with others. The relationships between projects are not fixed in stone. You can create a web of relationships between different copies of the repositories, or a more linear chain.

Generally, though, the official version of a software product is referred to as being upstream of the current repository. Within a single repository, I can store different versions of the project. These in-repository changes are tracked via branches. To switch from my current branch to another one, I will check out the branch I want to switch to. (In my head I say, “This is really cool! Check! It! Out!”) Before switching, Git will force me to deal with the uncommitted changes by either committing them, stashing them, or discarding them. The commit process will permanently store my changes to the repository, whereas stash will temporarily shelve the changes, allowing me to pull them off the shelf and reapply them later.

The process of incorporating and publishing changes uses some common set of commands. I pull my changes from the remote repository to automatically incorporate them into the repository. This procedure fetches the new changes and then merges them into the tracked copy of the local branch. At any given time, I work on a local branch within my repository. If I want to share my changes with other developers, I commit my work to the repository, and then push my branch to the remote repository.