Sep 9, 2021
Git Tips👾
Distributed source control is grace for probably any software project. Learning fundamentals is just enough for any team member to keep up with the git rules of any project. This article includes my favorite bad practices of Git.
Say Yes to a Git Workflow 💎
There are few popular git workflows. It is usually a good practice to adopt one. Having a custom workflow is also an option. Make sure your project has a workflow suiting your needs and capabilities. Otherwise, release management or your cicd flows will become torture.
Beware Hardcoded Environment Configurations 🌎
Applications must be runnable for every possible environment without changing branches. Always use environment variables and config files. Do not bury configurations into branches.
Hybrid Feature Branches 🌵
Creating a feature branch from a non-stable branch & eventually having it merged into a stable branch. Many development teams claim that they have a solid git workflow. They usually don’t. It requires a little bit of discipline. Everyone must follow the rules.
Have a look at the following shortened scenario. This is the most common git workflow logic of the projects I’ve seen.
There are two branches, Develop & Master. Assume that Develop is the main test environment branch where all features are merged into. Master is the stable branch. In the end, feature branches merged into Master.
Development of Feature-1 started with creating a branch from branch “Develop“. Feature-1 is completed and merged back into Develop.
Development of Feature-2 again started by creating a branch from Develop. Feature-2 is merged into Develop.
Both features passed tests successfully. It is time for deployment.
For some reason, the release of Feature-1 is postponed or canceled. This is a very possible real-life scenario. Decisions, needs can change anytime.
At this moment, the flexibility of working with feature branches is demolished. Because feature branches are created from non-stable develop branch. Every feature branch includes all previously merged features before itself. How do you overcome it?
The developer will separate features or cherry-pick commits, re-open merge requests just for the stable branch to save the day. Someone will quickly review and approve. Meanwhile, all your completed tests are garbage now. Plus, your development branch & your stable master branch are getting away from each other because of freshly broken git history. Say goodbye to your plans for the rest of the day/night.
This is not maintainable. Plus, this poor workflow design costs money because of all the harm it just caused. Feature branches must have been created from the most stable branch possible.
Best practices to keep your git workflow efficient;
- Release frequently. As for differences between test environments and production environments increase, the deployment will get harder.
- Do not commit anything unrelated stuff to your feature branch. Keep your features separate and clean as much as possible.
- Keep track of hotfixes merged into your stable branches. Make sure every main branch gets the fix.
- Document your git workflow.
Resolving Merge Conflicts By Your Own Does Not Make You a Hero🦸♀🦸♂️️
As the size of the development team grows, so does the number of merge conflicts. This is natural. Many conflicts can be resolved by just reading but some developments are more complicated. Instead of flipping coins, talk to each other, make sure everyone related to the conflict is there. Solve it together. It is way easier.
Bonus 💸
Checkout Other People’s Feature Branches/Merge Requests 🔍
Inspecting other people’s merge requests is a great opportunity to learn new approaches, coding skills or prohibit future risks.
- Do not spend a lot of time on it if you are not the desired reviewer.
