Menu
I host with AWS which means I cant use environment variables to control my production and staging deployments. I am therefore forced to use separate branches for deployment, and am wondering if there is a best practice approach towards their maintenance?
If I merge changes into my production branch, the commit that contains my production settings will get lost in the branches history, making it more difficult to tweak those settings.
However I have read that you shouldn't use rebase in this situation as it will make it more difficult to roll back changes.
621
All the commits on a feature branch are combined into a single commit on the master branch. All commits are rebased, and the same number of commits are added to the master branch. Merge is best used when the target branch is supposed to be shared. Rebase is best used when the target branch is private.
Merging is a safe option that preserves the entire history of your repository, while rebasing creates a linear history by moving your feature branch onto the tip of main .
Git rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch. Unlike merging, rebasing flattens history. It transfers the completed work from one branch to another. In the process, unwanted history is eliminated.
Once you've completed work on your branch, it is time to merge it into the main branch. Merging takes your branch changes and implements them into the main branch.
I also faced many challenges to implement git in my latest project. After too much googling I found this blog and it is really a nice way of maintaining git branch model.
A successful Git branching model
The central repo holds two main branches with an infinite lifetime:
The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
Supporting branches
The different types of branches we may use are:
Feature branches : Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release.
May branch off from: develop
Must merge back into: develop
Branch naming convention: anything except master, develop, release-, or hotfix-
Release branches : Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s.
May branch off from: develop
Must merge back into: develop and master
Branch naming convention: release-*
Hotfix branches : Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version.
May branch off from: master
Must merge back into: develop and master
Branch naming convention: hotfix-*
You can find more details about this Git branching model from the blog. The commands used for the branching model also listed in the blog. Check the blog for more details. I successfully implemented the branching model in my project with some changes from the model mentioned in the blog. Git is a powerful and flexible tool,and this is just one way of using Git.
98
There are a few links below that share some opinions on methodologies and the reasoning behind why you should choose rebase or merge.
See:
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
