|
|
Git Repository
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.
|
|
|
|
|
Git Branching Model
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:
- 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 and develop.
- release-* — release branches support the preparation of a new production release. They allow many minor bugs to be fixed and preparation of meta-data for a release. May branch off from develop and must merge into master and develop.
Advantages
- It is ideally suited for projects that have a scheduled release cycle
- Ensures a clean state of branches at any given moment in the life cycle of the project
- The branches naming follows a systematic pattern making it easier to comprehend
- It has extensions and support on most used git tools
Disadvantages
- The Git history becomes unreadable
- The master/develop split is considered redundant and makes the Continuous Delivery and the Continuos Integration harder
- It isn’t recommended when it need to maintain single version in production
|
|
GitLab Branching Model
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:
- master - this is everyone's local development environment line.
- staging - this is where master is merged into for last minute tests before making it into production
- production - this is the tagged production code that staging is merged into. If you are not using staging, then you would merge here from master.
The GitLab Flow is based on 11 rules:
- Use feature branches, no direct commits on master
- Test all commits, not only ones on master
- Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).
- Perform code reviews before merges into master, not afterwards.
- Deployments are automatic, based on branches or tags.
- Tags are set by the user, not by CI.
- Releases are based on tags.
- Pushed commits are never rebased.
- Everyone starts from master, and targets master.
- Fix bugs in master first and release branches second.
- Commit messages reflect intent.
Advantages
- It defines how to make the Continuous Integration and Continuous Delivery
- The git history will be cleaner, less messy and more readable.
- It is ideal when it needs to single version in production
Disadvantages
- It is more complex that the GitHub Flow
- It can become complex as Git Flow when it needs to maintain multiple version in production
|
|
GitHub Branching Model
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:
- Anything in the master branch is deployable
- To work on something new, create a branch off frommaster and given a descriptively name(ie: new-oauth2-scopes)
- Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
- Once it is merged and pushed to master, you can and should deploy immediately
Advantages
- A simpler alternative to Git Flow
- It is friendly for the Continuous Delivery and Continuous Integration
- It is ideal when it needs to maintain single version in production
Disadvantages
- 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
|
|