Day-7:Basic Git & GitHub for DevOps Engineer's

By far, the most widely used modern version control system in the world today is Git. Git is a mature, actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. A staggering number of software projects rely on Git for version control, including commercial projects as well as open source. Developers who have worked with Git are well represented in the pool of available software development talent and it works well on a wide range of operating systems and IDEs (Integrated Development Environments).

Having a distributed architecture, Git is an example of a DVCS (hence Distributed Version Control System). Rather than have only one single place for the full version history of the software as is common in once-popular version control systems like CVS or Subversion (also known as SVN), in Git, every developer's working copy of the code is also a repository that can contain the full history of all changes.

In addition to being distributed, Git has been designed with performance, security and flexibility in mind.

Version control with Git

Git is the best choice for most software teams today. While every team is different and should do their own analysis, here are the main reasons why version control with Git is preferred over alternatives:

Git is good

Git has the functionality, performance, security and flexibility that most teams and individual developers need. These attributes of Git are detailed above. In side-by-side comparisons with most other alternatives, many teams find that Git is very favorable.

Git is a de facto standard

Git is the most broadly adopted tool of its kind. This makes Git attractive for the following reasons. At Atlassian, nearly all of our project source code is managed in Git.

Vast numbers of developers already have Git experience and a significant proportion of college graduates may have experience with only Git. While some organizations may need to climb the learning curve when migrating to Git from another version control system, many of their existing and future developers do not need to be trained on Git.

In addition to the benefits of a large talent pool, the predominance of Git also means that many third party software tools and services are already integrated with Git including IDEs, and our own tools like DVCS desktop client Sourcetree, issue and project tracking software, Jira, and code hosting service, Bitbucket.

If you are an inexperienced developer wanting to build up valuable skills in software development tools, when it comes to version control, Git should be on your list.

What is GitHub?

GitHub is a web-based interface that uses Git, the open source version control software that lets multiple people make separate changes to web pages at the same time. As Carpenter notes, because it allows for real-time collaboration, GitHub encourages teams to work together to build and edit their site content.

How can GitHub help my team and me?

GitHub allows multiple developers to work on a single project at the same time, reduces the risk of duplicative or conflicting work, and can help decrease production time. With GitHub, developers can build code, track changes, and innovate solutions to problems that might arise during the site development process simultaneously. Non-developers can also use it to create, edit, and update website content, which Carpenter demonstrates in her tutorial.

How do I speak GitHub?

There are some common terms teams will need to understand when using GitHub. They are:

• Git — a tool that allows developers and others to use version control

• GitHub — one of many web interfaces for using Git

• Organization (org) — a grouping mechanism allowing teams to collaborate across many projects at once

• Repository (repo) — a folder in which all files and their version histories are stored

• Branch — a version of the repo that allows work without affecting other branches. Repos may have many branches for different possible changes being tested or considered, along with a default branch that serves as the source of truth.

• Fork — a new repository that inherits from a parent “upstream” repo. It is used to suggest changes to an “upstream” public repo by someone who doesn’t have access to edit in the repo’s home org.

• Markdown (.md) — a way to write content that converts plain text to formatted text.

• Commit Changes — a saved record of a change made to a file within the repo.

• Pull Request (PR) — a request for changes made to a branch to be pulled into another branch. Allows multiple users to see, discuss and review work being suggested.

• Merge — after a pull request is approved, the commit will be pulled in (or merged) from one branch to another and then, deployed on the live site

• Issues — allow users to report issues or bugs and track progress of assigning the fix for the issues.

• Federalist — a platform that securely deploys a website from a GitHub repository in minutes and lets users preview proposed and published changes.

• Projects — allows you to use GitHub for project management and tracking a set of issues, either for a specific repo or an entire org

• Wiki — a section of a repo made for hosting documentation. Documentation may be in the repo’s README files instead.

Becoming fluent in GitHub terminology might seem intimidating at first, but the more team members engage with the platform, the easier it is to understand the ins and outs of GitHub.

How do I use GitHub?

Note

This second tutorial and live demonstration covers a variety of Git-related concepts so that you can have confidence using GitHub in the future. You can also download the slides that are found in this presentation (.pptx, 28.4 MB, 41 slides).

In the demonstrations on this page, both presenters show how files are changed and merged in GitHub. This can be done by any member on the team, developers and non-developers, that has access to a GitHub repository. The following is a step-by-step method in which GitHub users can develop their websites:

• Step 1 — Team members will open an issue via a project board.

• Step 2 — Team members will create a new branch from the most recent version of the main branch in the repository where the entire team works to avoid conflicts.

• Step 3 — Team members will add commits (edits or changes) to their respective branches.

• Step 4 — Team members will open a pull request in which users can assign other team members to review content changes and internally discuss the details of the commits.

• Step 5 — After waiting for the Federalist build to complete, team members can preview the change on a test version of the website and request reviewers to approve or comment on the change. Once the reviewers approve the pull request, the commits merge into the main branch and are published on the live site.

What else do I need to know about GitHub?

When starting a project using issues and project boards, write your content on external word processors or via Google Docs, and then, save these files to their respective project boards. These steps allow developers and content creators to have a master copy of the file(s), thus helping them track changes over the course of a project.

In addition, developers should consider downloading GitHub Desktop. GitHub Desktop allows users to do everything that could be done on GitHub’s web interface, but locally on a user’s machine.

GitHub is built to be a collaborative interface. By allowing multiple users to work on the same project simultaneously and requiring cross-team approval for pull requests, GitHub not only allows for, but encourages collaboration within design teams. This type of collaboration can help produce a higher level of quality control.