Git without a doubt is one of the essential tools for every developer. As helpful as Git is, it becomes absolutely useless without adopting best practices. This is why Git and its cool features have various basic workflows to make the most of it.
Apart from knowing git add, git commit, and git push, there are a bunch of other important techniques in Git. Knowing these will help a lot in the long run.
Git workflow
Whenever multiple developers are involved in a project it is necessary to use the right workflow for Git. Here I will be covering a git workflow that I personally use and seems best for most of the projects
How it works
Instead of having one single master branch, we have another extra branch named develop. Both branches should be locked so that no one can directly push on to that.
The master branch should always have a copy of the existing code in Production. Only after testing new features, code from feature branch should be merged into master branch.
develop branch is the most active branch in the workflow. Each developer should create a new feature branch off develop and merge back into it. Since there are features pushed into develop it is always ahead of master.
git checkout -b myfeature develop Switched to a new branch "myfeature"$
Note:
- When starting any git workflow, make sure master and develop are in sync.
- Always create feature branch from develop.
- Make sure to pull the latest update from develop into your local feature branch every day.
- When completed with the work, pull the changes from develop into your local feature branch and push the local branch on Github.
After the feature branch is pushed online the feature branch owner should create a Pull Request to merge to changes from feature branch into develop. Then after reviewing the code, the Tech Lead/Repository owner will approve the pull request.
So this was all about keeping the develop branch updated with the latest features. Now after testing the features it needs to be released on to production.
How to release features into production
Production eventually is master, so now we have to merge the changes from develop to master. For that, we use a supporting branch named release branch.
git checkout -b release-1.2 develop Switched to a new branch "release-1.2"$
release branch is created from develop. At this stage, small bugs can be fixed in the release branch (rather than on the develop branch). They must be merged into develop. Adding large new features here is strictly prohibited.
Now comes the final release part, where we merge release branch into master, and add a tag for future reference.
git checkout master Switched to branch 'master' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) $ git tag -a 1.2$
To keep the changes made in the release branch, we need to merge those back into develop, though.
git checkout develop Switched to branch 'develop' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes)$
This step may lead to a merge conflict. If so, fix it and commit.
Seriously Don’t do git push –force
Ask for help from the developer who wrote the code and resolve it, test it, and then commit it.
Now we are really done and the release branch may be removed since we don’t need it anymore.
Let’s see this in action
Let me show you all the things that I mentioned above in an example.
So you are working in a team of 5, you are the tech-lead and you have the ownership of the repository. let’s say you need to develop 4 features from scratch, now you have divided the task into your team members.
Steps:
Create a new branch off develop by feature name.
$ git checkout -b feat/feature-name develop Switched to a new branch "feat/feature-name"
Code your feature on the checked-out branch. After completing the work take a pull from develop and push the branch to the remote.
$ git pull origin develop -- ---- --- user@computer$ git push origin feat/feature-name
Create a pull request from online repository to merge code from feat/feature-name to develop.
Now we have to release the features into the master branch i.e Production. To do so follow the steps described here.
Voila 😄
Wasn’t it simple yet powerful? Initially, it may sound a little complex but trust me this is the best way you can collaborate and work asynchronously. The Workflow may defer from project to project. So If you are already using this kind of workflow its Awesome :D, if not go, and create your project flow that suits your requirement and work pattern.
If you need to ask something or have some suggestions.
