Your workflow majorly depends on how many kinds of servers your company has.
Many companies follow the below configuration:
- Production server, the public, customer-facing server. Deployment to this server is done after testing rigorously on the staging server.
- Staging serverwhere testing is done by the team members before releasing it to the public.
- Feature testing servers (usually spun up for each feature), where new features are tested by individual developers before pushing it to the staging server.
The ideal setup is to have a dedicated branch for each of the server types
- master branch → For Production server
- dev/staging branch → For staging server
- feature branch → For feature testing server
The workflow we follow at our company & which I am going to show here is closely related to the popular Gitflow workflow.
When it comes to comparing git changes, I am not a huge fan of the terminal.
I would rather view the changes on my VS Code editor itself, where I can compare the before and after, effectively.
Check out the below screenshot of my VS Code editor showing changes.
My git workflow consists of various branches and certain rules attached to these branches.
This is the main branch and will be considered as the single source of truth.
The changes made to this branch are to the production server.
You are not supposed to make any changes to this branch directly. Creating any branches out of this to create features is also forbidden until it’s a production bug (in which case you will create hotfix branches, which I have explained in detail below).
Once you have setup
master branch, you should derive a
dev branch out of it.
This branch is used to test out all features before deploying to production. Changes to this branch are tested to staging server and.
Every feature will have a separate branch.
Feature branches are branched out of the
dev branch and merged back to
dev branch after the feature is completed.
Feature branches can be named according to the feature for better identification.
Let’s take a feature and build a branch for it.
Here, you branched out a
feature branch and created 2 commits on it,
Now suppose, your colleague Raj, who is also working on the same feature, has created 2 commits on his local feature branch.
Hmm, this is getting tricky. How do you integrate his changes into your branch before pushing it into the dev branch?
Here’s where we use the
git-rebase command mentioned above. In a way, you are rebasing your changes on to his branch so that the feature branch is in one, linear structure of commits (notice that both your and Raj’s branches are having the same name, and the remote contains only one branch with that name ).
On your end, you are going to enter the command
git rebase <Raj's branch>
Let’s see how our branches look now.
Your commits have been ‘appended’ to his commits. Now you have both your changes and Raj’s changes.
Mind that, rebasing this way is okay since you are not editing any of the major branches. As for Raj, he can take a pull from the
featurebranch once you push it to the remote and he can see your commits as well.
The reason we use
rebase command instead of git’s
merge command is to have a linear, simple git branch, which is not achievable using merge.
It’s time to merge the
feature back to
D3 commit with changes in the
Once enough features are tested to the staging server and tested, you can deploy them to the production server by first merging the changes of
To merge into
masteryou create a
release branch, out of the
dev branch. This branch will be merged into
After this, you can merge the
release branch into the
When something breaks in your production server, there is not enough time to branch out of
devmerge it back, create a release branch, etc.
The simplest way will be to do the following:
- Branch out a
- Make the required changes to it
- Merge the
hotfixbranch back to
- Merge the same to
Something like this
When you are working in a collaborative environment, you need to follow some etiquette while using Git.
- Every merge to public branches should be reviewed. Whenever you are trying to merge to
devbranch or master branch, create a pull request and let your teammates know that you want to merge some of your changes. This will help them take a pull and work with the latest code.
- Do not mess with the history of the branches. Git commits are immutable. But there are certain commands in git which can create commits using the previous commits, making it look like you have reverted to a previous commit. This can cause issues with the working code of other teammates. Do this only if it’s absolutely required. Also, follow tip #1 after you do this.