Git Conventions

Getting Started - A Conventions of Git

Git does not impose many restrictions on how it should used, however some conventions are adopted in order to organize histories, especially those which require the cooperation of many contributors.

The master branch is created by default with git init and is often used as the branch that other changes are merged into . Correspondingly the default name of the upstream remote is origin and so the name of the default remote branch is origin/master. As of June 2020, GitHub is working on changing the default name of the branch on their services to "main".

Pushed commits should not be overwritten, but should rather be reverted (a commit is made on top which reverses the changes to an earlier commit), unless they contained sensitive information which should not remain in the history. This prevents shared new commits based off shared commits from being invalid because the commit off which they are based does not exist in the remote.

The git-flow workflow and naming conventions are often adopted to distinguish feature specific unstable histories (feature/*), unstable shared histories(develop), production ready histories(master), and emergency patches to released products (hotfix).

Pull requests are not a feature of git, but are commonly provided by git cloud services. A pull request is a request by one user to merge a branch of their repository fork into another repository sharing the same history (called the upstream remote).

The underlying function of a pull request is no different than that of an administrator of a repository pulling changes from another remote (the repository that is the source of the pull request); however the pull request itself is a ticket managed by the hosting server which initiates a scripts to perform these actions, it is not a feature of git SCM.

A Short History of Git

As with many great things in life, Git began with a bit of creative destruction and fiery controversy.

The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991-2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.

In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool's free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

1. Speed
2. Simple design
3. Strong support for non-linear development (thousands of parallel branches)
4. Fully distributed
5. Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development

The DevOps seminar will help you to learn DevOps from scracth to deep knowledge of various DevOps tools such as fallowing List.