80 Lines: From Git to GitFlow.
by Leonardo Ferreira
Introduction
This article aims to document the internal workflow used by 80Lines, familiarizing developers with the concepts involved in the process. For this, the concepts of Git with its main commands and ways of use will be presented, as well as the concept of GitFlow: a workflow created to facilitate the development process with Git.
Git
Git is a free and open source distributed version control system designed to streamline processes. It allows fully independent local branches to be created, merged or deleted in seconds, creating different possibilities for use.
One of the uses would be frictionless code replacement. With it, you can create a new branch to experiment an idea, increment the code, make the necessary commits (a set of temporary changes saved in the local repository), and finally, if you want, merge it with the branch of origin.
Another possibility is to have role-based branches. This can be accomplished by creating new branches specific to each purpose (production, testing, new features being created on a day-to-day basis, etc.), and deleting them when merged into your mainline. If you create a new branch for testing and find it won't work, simply delete it, abandoning all the work you created without anyone seeing it (even if you've uploaded other branches in the meantime).
Git is an easy-to-learn tool with extremely fast performance. It outperforms SCM tools (full system flow management from build to customer delivery) like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
Main git commands
1. git config
This command is used to define your configuration values at a global or local level, inserting information such as name and email that will be used in each commit. Example:
$ git config –global user.name <your_name>
$ git config –global user.email <your _email>
2. git clone
This command is used to create a copy of an existing repository. Example:
git clone <project_url>
3. git add
This command tells Git that you want to include changes from a specific file or add new local content to the next commit. Files will not be committed. Example:
$ git add <your_file> (this command will add the specific file to the repository)
$ git add . (this command will add all new and/or modified files to the repository)
4. git commit
This command commits the files that have been added or modified and creates a new revision with a log of commits. Before using the git add command it is necessary to add the new or local changes with git add. It is possible to combine the two actions in a single command:
$ git commit -a.
It is also possible to add a message to the execution of a commit. Example:
$ git commit -m “<your_comment>”
5. git branch
It is common, most of the time, to have multiple branches in your Git repository. The git branch command allows you to create, list, rename and delete these branches. Roughly speaking, a branch is an independent development path, an alternative. Examples:
$ git branch (list all branches)
$ git branch <branch_name> (creates a branch with the specified name)
$ git branch -d <branch_name> (deletes a branch with the specified name)
6. git checkout
This Git command is used to switch from one branch to another or even create a new branch. Example:
$ git checkout <branch_name>
It is also possible to combine operations, creating and checking out a new branch with a single command:
$ git checkout -b <new_branch_name>
7. git remote
This command is used to connect your local repository to a remote one. Example:
$ git remote add <short_name> <url>
8. git push
This command is used to send your modifications prepared by a git commit to a remote repository previously connected with git remote. Example:
$ git push
At the first time, you need to specify the origin and upstream (original project, author or maintainer of a software that is distributed as source code) before using git push. Example:
$ git push –set-upstream <short_name> <branch_name>
9. git pull
This command is used to receive all the modifications that were changed in the remote repository to your local repository, updating its contents to the last version uploaded. Example:
$ git pull
10. git stash
This Git command temporarily stores your modified files in an area, called a stash, without interacting with the other files until called back with all the modifications made. Example:
$ git stash
To list all your “stashes”, we use:
$ git stash list
When it's time to apply the stash content to a branch, we use the “apply” parameter:
$ git stash apply
11. git merge
This command merges changes from two different branches into a single branch. It is used from the current branch, which will be merged with all changes made on the other branch, with the name passed as a parameter. Example:
$ git merge <branch_name>
12. git cherry-pick
This command is used to select a specific commit from a branch and apply it to another branch, without having to use the git merge command. The commit is listed in the history. Example:
$ git cherry-pick <commit_id>
80 Lines GitFlow
In 2010, software engineer Vincent Driessen wrote on his personal blog the way he thought was the simplest way to work with Git in large projects. Then, GitFlow was born: a workflow to facilitate the large-scale development process.
GitFlow works with specific long-lived branches and larger commits. This model creates a branch for each new change, whether updates or bug fixes, which delay merging with the main branch until they are complete. These new branches, since they have new long-lived features, require more collaboration when merged into the main branch, with a greater risk of conflicts between them.
Despite being an enabler, GitFlow can become quite inefficient and unpleasant if used improperly. Therefore, we must always have some reservations about the way it is applied to our work.
Based on these concepts, the 80Lines workflow was developed, which consists of creating 4 environments, where each one reflects a specific function in the project. They are:
Main:
Production branch, final and stable version of the system.
Staging:
Branch available to the customer for validation and confirmation of the new update. Once validated, the pull-request (request to merge changes/updates made in staging) is made to the main branch.
Release:
Branch for internal QA testing with the newly developed update. In this environment, Smoke Tests and Regression Tests are performed. After validating the tests and fixing the bugs, a pull-request is made to the staging branch.
Development:
New feature development branch. Used during development, for developers to merge functionality that is developed in isolation, after having been completed and tested by the developer himself. At the end of a Sprint cycle, a pull-request is made for the release branch.
From these environments, all necessary changes (new implementations and bug fixes) are made based on the following branches:
Feature:
Branch created from development for small tasks of developing new features. After the development is done, a pull-request is made to the development branch, the pattern used is:
Feature: <task_number>
- <development_description>
Example:
Bugfix:
Branch created from the release branch with pull-request for the release and development environment, the default used is:
Bugfix: <task_number>
- <fix_description>
Example:
Hotfix:
Branch created from the branch that had a bug, which could be main or staging, and made two pull-requests, first for the release branch, where this hotfix will be tested, and second for the branch where this hotfix appeared, which will be merged after being tested, the default used is:
Hotfix: <task_number>
- <fix_description>
Example:
Example of the environments with all the improvement processes and/or bug fixes:
