Version control system – Git and Github Flow

A version control system tracks the history of changes to files. It is especially useful in projects built by software development teams. As the project evolves teams can run tests, fix bugs, and contribute new code with confidence that any version can be recovered at any time. Reconstructing the edit history of various files can be useful for a variety of reasons, such as when you need to investigate when some change was introduced and why. You are already familiar with Git and GitHub but it is also important that you understand how they relate to the concept of a version control system.

Why is version control system important?

You can use Git and GitHub to keep track of all the changes to your code as well as to collaborate with your peers. Understanding what Git and GitHub are will make it much easier for you to join a company and get used to their workflow faster because almost every single company that you can join uses a version control system.

What’s the difference between Git and GitHub?

Git is an example of a distributed version control system. GitHub is a Git hosting repository that provides developers with tools to ship better code.

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 an application like GitHub Desktop.

Common Git Commands

• 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 project’s files, history, and branches.
• git add stages a change. Git tracks changes to a developer’s codebase, but it’s necessary to stage and take a snapshot of the changes to include them in the project’s history. This command performs staging, the first part of that two-step process. Any changes that are staged will become a part of the next snapshot and a part of the project’s history. Staging and committing separately give developers complete control over the history of their projects without changing how they code and work.
• git commit saves the snapshot to the project history and completes the change-tracking process. In short, a commit functions 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 distinct branches. For example, a developer would merge when they want to combine changes from a feature branch into the main branch for deployment.
• git pull updates the local line of development with updates from its remote counterpart. Developers use this command if a teammate 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.

GitHub flow :

GitHub flow is a detailed process for using branches with your team. If everybody in your team uses the same flow, you collaborate more effectively because everyone knows how to track the history of changes in your shared code easily.

GitHub flow is slightly different than Gitflow, even though their names look alike. If you look for additional information, please make sure that you are using the correct name – GitHub flow. 

How to use GitHub flow:

Main branch

You can think about the main branch as a snapshot of your application that at any moment can be used for:

• deployment to production (which often occurs automatically) – you do not want to deploy broken code by accident.
• developing new features with multiple collaborators – your teammates need a stable version of your project to start implementing changes.

Therefore the main branch should always be stable code that actually works and can be safely used. Any changes required in the application should be introduced in feature branches and approved before merging them to the main branch.

NOTE: The main branch is a rather new name. Previously it was called the master branch. GitHub has changed it for good reasons, but you can still see some references to the master in many articles. Do not let that confuse you.

Feature branches

Before you start working on a new feature, you should create a new feature branch that is based on the main branch. You will use this branch for all your work. In order to get a deeper understanding of feature branches, watch this video about creating new branches

Remember that your branch name should be descriptive (e.g.: refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.

Opening pull requests :

Once you start working on any project, initialize its main branch. Then, add changes in a feature branch(es). You will need to create a pull request to compare your feature branch with the main branch and you may ask for code review within your team or from anyone who is not involved in the development of that code.