Git: What is Git, Github, and Gitlab?

Every Front-End Developer should know about Git and Gitlab. Git is software for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different systems).

And Gitlab or Github is one of free Git remote repositories where we can save project collaboration files in a cloud so every member of project can be accessed together and support each other to complete project documents. There are many remote repositories beside Gitlab and Github but these 2 repositories which are recommended to be used for Git learning.

1. Git Flow
The Git Flow was created by Vincent Driessen in 2010 and it is based in two main branches with infinite lifetime:
  • master — this branch contains production code. All development code is merged into master in sometime.
  • develop — this branch contains pre-production code. When the features are finished then they are merged into develop.
During the development cycle, a variety of supporting branches are used: 
  • feature-* — feature branches are used to develop new features for the upcoming releases. May branch off from develop and must merge into develop. 
  • hotfix-* — hotfix branches are necessary to act immediately upon an undesired status of master. May branch off from master and must merge into master anddevelop. 
  • release-* — release branches support preparation of a new production release. They allow many minor bug to be fixed and preparation of meta-data for a release. May branch off from develop and must merge into master and develop.

Git Process
There are some process in Git as in the picture below.

Git Process

Local Environment consist of some areas which must be understood, such as:
  • Committed Area : The area where commits are collected. A commit is a collection of recorded changes.
  • Stage Area: The area where our files are monitored for changes by Git.
  • Working Space / Unstage Area: Where files are not supervised / have not entered the Stage Area. 
  • Stash Area: A place for stash to gather. Stashes are changes that are saved without committing.

Stage is a command to add files previously in the Unstage Area / Unsupervised by Git to the Stage Area. So that any changes that occur to files in the Stage Area will be detected by git and allow for commits. 
  • How to find out the status of changes in the Git Repository is with the command: git status
  • Meanwhile, to add files to the Stage Area, is with the command: git add

Unstage is a command to delete files from the Stage Area and move them to the Working Space / Unstage Area. By doing this, unstaged files will not be monitored by Git and commits will not be possible. Because commits can only be made to files in the Stage Area.
  • To unstage you can use command: git reset

Commit is a command to save a record of changes that occur to files in the Stage Area. Before committing, you must ensure that the conditions in the Working Space are clean from changes. To clean it can use the command commit or stash.
  • To commit, use command: git commit -m "description"

Stash is a command to save a record of changes that occur in the Working Space / Unstage Area. This is different from commits because stash commands are saved to the stash area. We do stash if we are building code with steady progress. The code created is far from finished and working, but it's too bad to delete or undo.
  • To do stash can use command: git stash

Unstash is a command to re-apply the code that we saved in the Stash Area with the previous stash command. The unstash process is known as the Apply Stash process.
  • To unstash you can use command: git stash pop or git stash apply

Git Branch
Gitflow works based on predefined branches.

Git Branch

Branch Master is the parent branch where various application changes occur. This branch records changes that occur even if they are not released. This is what distinguishes the branch release.

Branch Hotfix will be used if it turns out that there is a bug or error in the version of the application that is on the master branch, and this bug / error is quite important and needs to be resolved immediately.

Branch Release works if there are updates or additional features in the application and then released.

Branch Develop
In the develop branch, application developers carry out early stages of development and are very prone to errors. In this branch there are also various kinds of experiments.

Branch Feature
Every new feature should be in this branch. However, this feature branch does not branch from master , the feature branch uses develop as its parent branch. When a feature is complete, it will be rejoined into development. Features should not interact directly with master .

Git Commands

2. Github
The GitHub Flow is a lightweight workflow. It was created by GitHub in 2011 and respects the following 6 principles: 
  1. Anything in the master branch is deployable.
  2. To work on something new, create a branch off frommaster and given a descriptively name(ie: new-oauth2-scopes).
  3. Commit to that branch locally and regularly push your work to the same named branch on the server.
  4. When you need feedback or help, or you think the branch is ready for merging, open a pull request.
  5. After someone else has reviewed and signed off on the feature, you can merge it into master.
  6. Once it is merged and pushed to master, you can and should deploy immediately.

It is friendly for the Continuous Delivery and Continuous Integration. A simpler alternative to Git Flow. It is ideal when it needs to maintain single version in production.

The production code can become unstable most easily. Are not adequate when it needs the release plans. It doesn’t resolve anything about deploy, environments, releases, and issues. It isn’t recommended when multiple versions in production are needed.

3. Gitlab
The GitLab Flow is a workflow created by GitLab in 2014. It combine feature-driven development and feature branches with issue tracking. The most difference between GitLab Flow and GitHub Flow are the environment branches having in GitLab Flow (e.g. staging and production) because there will be a project that isn’t able to deploy to production every time you merge a feature branch (e.g. SaaS applications and Mobile Apps).

The GitLab Flow is based on 11 rules: 
  1. Use feature branches, no direct commits on master.
  2. Test all commits, not only ones on master.
  3. Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel). 
  4. Perform code reviews before merges into master, not afterwards. 
  5. Deployments are automatic, based on branches or tags. 
  6. Tags are set by the user, not by CI. 
  7. Releases are based on tags. 
  8. Pushed commits are never rebased. 
  9. Everyone starts from master, and targets master. 
  10. Fix bugs in master first and release branches second.
  11.  Commit messages reflect intent.

It defines how to make the Continuous Integration and Continuous Delivery. The git history will be cleaner, less messy and more readable (see why devs prefers squash and merge, instead of only merging, on this article). It is ideal when it needs to single version in production.

It is more complex that the GitHub Flow. It can become complex as Git Flow when it needs to maintain multiple version in production.

4. How to Install Git
To install Git in our PC or Laptop can be read from here:


Popular posts from this blog

How to Inspect Problems in Your ReactJS Codes

ReactJS Hooks: How to Use useState in ReactJS?