Isolating features into different branches is a crucial practice for any serious developer. By separating each feature, bugfix or working experimen...
For further actions, you may consider blocking this person and/or reporting abuse
If you like keeping a cleaner history you can rebase the branch onto master prior to doing the merge. It depends on how vital the independent branch history is.
If you don't do a rebase it often makes sense to merge master into the branch first. This allows you to resolve and test conflicts, get a stable state, then have a flawless merge to master. Logically it sounds about the same, but in some pipelines it works better.
I always prefer rebasing the feature branch first, then merging. It allows for a simpler linear repo history (this is if I'm the only one working on it).
I also like to clean it up with some commit squashing with:
git rebase -i HEAD~n.Couldn't agree with you more!
In the future, there will be another article regarding rebasing that will cover its positive and negative points compared to merging.
Actually, I do not agree. There might be cases were this strategy is useful. My team tried both, committing to master/dev as well as using feature branches for every feature.
We agreed to stop using feature branches because it added complexity and large efforts due to merging without giving us benefits. We never needed to skip features that are not complete. We never needed to reject features. However we had serious troubles merging code after refactorings e.g.
Moreover, we had a contionous job that builds, deploys and runs a system test against code changes for immediate feedback.
So, in some scenarios feature branching might be useful but definitely not in all.
Hey, Jan, I understand your point, merging can cause some frustration, especially when conflicts happen.
Kolosek team prefers to create a new branch for each feature unless it is a hotfix or emergency bug fix. In this case, we commit directly to master or development.
To ensure the code is "clean" we always have someone to check the Pull Request before merging the feature branches. This is another reason why we mostly go with feature branches.
This is exactly opposite the latest findings of highly effective teams, there is a correlation of highly effective teams and trunk based development or branches with a lifespan of less than a day. See "Accelerate: Building and Scaling High Performing Technology Organizations", it bases its data off of statistics that I imagine any one of us will be hard pressed to argue against effectively.
The point is to get changes in as soon as possible, not features, but changes. I try to only work in branches when I need a merge-request reviewed (e.g. if I couldn't pair on the change). BTW low-overhead change-management process is another correlation of effectiveness. And if talk of correlations bore you I'll just say it's a lot more fun to develop without all those processes :)
(and thanks for sharing your article and viewpoint, it's by discussion we grow)
Hey, Jon! Well, currently, our team prefers to separate each specific feature into a separate branch, since multiple people work on different features at the same time.
That being said, when it comes to hotfixes or any crucial bugs that need immediate and quick attention we push those changes directly without creating a new branch for each problem.
Sure, my pleasure, that's why this is a great community. We share opinions and grow. :)
I can relate to that from my(limited) experience. Together with CI, pushing to master as soon as possible has worked quite well.
Thank you for the explanation on the 3-way merge. It cleared up a lot of issues I was having.
Sure, glad you found it helpful!
In the 'After Merge' part of the 'Three-Way Merge' pic in your article, shouldn't C2 and C4 be swapped?
C4 would be the new commit that master points to after merging/combining the C2 and C3 branch. Yet it shows C2 as the latest commit after the merge.
I'm curious, is there any draw backs with merging the master branch into the hot fix branch. Then running regression tests on the hot fix branch and then merging the hot fix branch into the master branch.
This is really really useful. I only use Git from the command line interface, that's why I want to understand the core concept of Git so everything can be smooth and productive.
Thanks for posting.
Nice post! always good to git fetch git pull then git merge origin/dev :)
Glad you liked it, Tony! :)
Thanks for the explanation on the 3-way!