A repository, or Git project, encompasses the entire collection of files and folders associated with a project, along with each file’s revision history. The file history appears as snapshots in time called commits, and the commits exist as a linked-list relationship, and can be organized into multiple lines of development called branches. Because Git is a DVCS, repositories are self-contained units and anyone who owns a copy of the repository can access the entire codebase and its history. Using the command line or other ease-of-use interfaces, a git repository also allows for: interaction with the history, cloning, creating branches, committing, merging, comparing changes across versions of code, and more.
Working in repositories keeps development projects organized and protected. Developers are encouraged to fix bugs, or create fresh features, without fear of derailing mainline development efforts. Git facilitates this through the use of topic branches: lightweight pointers to commits in history that can be easily created and deprecated when no longer needed.
The Git branching model (GitFlow) is the most known workflow which was created by Vincent Driessen in 2010 and it is based in two main branches with infinite lifetime:
During the development cycle, a variety of supporting branches are used:
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)
Unlike with the other flows where master was the line representing the code that is on the production server, this flow has a dedicated production branch that serves that purpose. Also, you will probably want a "pre-production", "staging", or "release" branch to represent your staging environment that you push to for last minute testing. This means that you should have at least 3 main lines:
The GitLab Flow is based on 11 rules:
The GitHub Flow is a lightweight workflow which was created by GitHub in 2011. It is ideal for organizations that need simplicity, and roll out frequently. If you are already using Git, you are probably using a version of the Github flow. Every unit of work, whether it be a bugfix or feature, is done through a branch that is created from master. After the work has been completed in the branch, it is reviewed and tested before being merged into master and pushed out to production.
The GitHub Flow respects the following 6 principles:
© 2021 Digcode.com