DEV Community

Discussion on: How to use git efficiently

Collapse
 
adityasridhar profile image
Aditya Sridhar • Edited

Till now haven't faced any issues with gitflow workflow. But in case issues do come will look into implementing something like trunk based development :)

Collapse
 
melezhik profile image
Alexey Melezhik • Edited

yeah. just a few questions:

  • how often you make prod releases? ( daily, weekly, few times a month or less frequent )
  • what is a frequency of commits? ( say per day )
  • average size of developers team? ( per one project )
  • if you have a hotfixes ( urgent bugs ) how do you deal with them in terms of SCM flow ... ?
Thread Thread
 
adityasridhar profile image
Aditya Sridhar • Edited
  • A monthly release

  • Maybe 10 to 20 commits a day max by all devs combined :D.

  • Varies. 4 to 8 depending on the requirement.

  • Current approach is to create a hotfix branch directly from master and make the change for high priority bugs. Low priority ones are generally pushed to the next release

There are situations where the codebase is shared between multiple projects and teams. That's one of the reason this approach worked well till now.

Thread Thread
 
melezhik profile image
Alexey Melezhik • Edited

Current approach is to create a hotfix branch directly from master and make the change for high priority bugs. Low priority ones are generally pushed to the next release

Ok. You did not say here. Do you propagate hotfix commits back to dev and release branches ?

Do you make production release immediately once new release branch is created? Do you continue to merge from dev to release after a new release branch is created?

There are situations where the codebase is shared between multiple projects and teams. That's one of the reason this approach worked well till now.

not sure, what you mean. please specify ...

Thread Thread
 
rbukovansky profile image
Richard Bukovansky • Edited

Git-flow:

1) The hotfix branches are cut from master branch and merged back to master and then to develop branch.

2) You do production release when the hotfix branch from 1) is merged back to master.

3) You don't merge develop branch once you cut release branch from it. This release branch is then just for fixes devs create against it directly or with PRs. Release branch in git-flow is used to QA testing and resolving bugs they find to stabilize that release. When it's signed off then it's merged to master and followed by merge to develop.

Thread Thread
 
melezhik profile image
Alexey Melezhik • Edited

Hi Richard. I am replying here to both of your comments. All it boils down to the fact that gitflow is hard to maintain. You have many branches that you have to merge back and forth in right order. It's not immediately seen on simple projects but it becomes painful as soon as frequency of releases and quantity of projects piles up. There is more about this here - endoflineblog.com/gitflow-consider...

In trunk based development there is one main branch ( I am not talking here about short leaving features branches and release / hotfix branches that also exist, anyway ... ) which radically simplifies and increasers the speed of development cycle. And trunk branch is always stable, you can read more about this on the mentioned site or other resources.

Yeah TBD has some tradeoffs but they are incomparable with disadvantages introduced by gitflow.

Thread Thread
 
rbukovansky profile image
Richard Bukovansky

Sorry, but what is hard on following commands to create a release branch and then close it?

gitflow release start "2.10.1"
gitflow release end "2.10.1"

Similar for hotfix branch:

gitflow hotfix start "2.10.1.1"
gitflow hotfix end "2.10.1.1"

Similar for creating short-lived feature or bugfix branch:

gitflow feature start "feat/new-login-page"
gitflow feature end "feat/new-login-page"

Sure, it's one of my scripts that does all the hard work, but I don't need to think about merging...

Sorry again, but people who do write off git-flow because they think it's complicated, they simply don't understand its beauty, sophistication, and advantages. And when you combine it with GitHub Flow (Fork&Pull Request), it can't simply be beaten.

And believe me, with TBD you get your trunk/master messy and unstable if anybody can merge there, I tried implementing that many times.
And I ask you again: How do you manage what goes to release when everybody is merging to one branch whatever and whenever they decide?

Thread Thread
 
melezhik profile image
Alexey Melezhik • Edited

Well, the shortcuts you have here is just smallest and easiest part of the workflow, the hardest part is merge branches not creating them. In classical git flow https://jeffkreeftmeijer.com/git-flow/git-flow.png you have 5 types of branches you have to merge and create in specific order and in specific times. If you don't follow the rules strictly you end up with the mess.

While it's probably easy to follow gitflow with small projects and low frequency of releases, it is way too harder to keep this approach with frequent releases and large code base. This is why companies with large code base and frequent releases like Google practice kinda TDB methodologies ( with variations ) instead of gitflow.

And believe me, with TBD you get your trunk/master messy and unstable if anybody can merge there, I tried implementing that many times.

It's not true. Pull requests / Code Reviews are still here to fence main code from junior developers direct commits ( though you might not need this with mature teams, anyway )
Also if a build is broken - it's ok, but you have to stop all the current development and make a fix OR rollback - it's what all the pretty textbook stuff devops methodologies teach us. There is no problem with broken build, there is a problem with recklessness about it. Add here automatic tests triggered by CI/CD, pre commits / push hooks tests and you will get even more layer of confidence ...

And last thing:

Sure, it's one of my scripts that does all the hard work, but I don't need to think about merging...

Actually you do, but not about technical aspects of merging, but about WHAT you merge, even the fact you have no conflicts or resolved ones does not mean the resulted code is right. Don't get me wrong I am not against merging, but merging is still hard ( not technically but logically ), TBD tries to avoid a lot of merging while gitflow upholds.

And I ask you again: How do you manage what goes to release when everybody is merging to one branch whatever and whenever they decide?

The same as with gitflow. At some point you cut off from main branch and create release one.