Earlier quoted context omitted.
[flagged]
huttis? you mean like jabba?
I'll bet good Republic credits that the Hutts advocate for Gitflow.
Trunk-Based Development
81–90 of 108 posts
Re: Trunk-Based Development
#82No thanks. I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced. The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation…
> deal with them losing work The fact that is ever possible is a damning indictment on Git > Git is actually simple The clearest evidence that something isn’t simple is when there are thousands of people yelling in frustration that it’s simple. Things that are actually simple don’t require a never ending stream of guides and tutorials. The world can do much, much better than Git.
It's likely `git reflog` would have their work, but not everyone knows about it
Re: Trunk-Based Development
#83Earlier quoted context omitted.
> deal with them losing work The fact that is ever possible is a damning indictment on Git > Git is actually simple The clearest evidence that something isn’t simple is when there are thousands of people yelling in frustration that it’s simple. Things that are actually simple don’t require a never ending stream of guides and tutorials. The world can do much, much better than Git.
It's likely `git reflog` would have their work, but not everyone knows about it
Yeah data is often recoverable by experts. But it’s too hard.
My VCS rule is that commit ids are sacrosanct. If you make a commit that commit is safe. You can do whatever the hell you want. Merge, rebase, whatever. But you can always go back to that commit.
This is kinda sorta true for Git. But that isn’t a first principle. And Git’s management of branch labels is super finicky.
Mercurials anonymous branching is a better default imho.
Re: Trunk-Based Development
#84Earlier quoted context omitted.
I think you're mixing up a lot of things. Trunk-based development also doesn't mean that you are not allowed to create branches. And you can still check out an older version.
They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up. I would have rather just used SVN and called it a day.
Nothing is lost in git without great effort. Deleting a branch is simply removing the label from the history. Just take note of the hash of the latest commit on the "deleted" branch. It'll still be there and can be checked out in detached-head mode.
Re: Trunk-Based Development
#85[flagged]
I see this as typical of organizations that value creating a more inclusive environment for their developers. Also, for what it's worth, Jenkins changed their terminology to use "agent" instead of slave in 2020 [0]. These efforts might seem futile in isolation, but they add up over time. [0] https://www.jenkins.io/blog/2020/06/18/terminology-update/
An organization that cared more about inclusivity than compliance would have done more.
Re: Trunk-Based Development
#86Re: Trunk-Based Development
#87TFA advocates strongly against long-lived branches, which I understand and agree with, but with one exception: major/LTS versions should have their own branch, so that hotfixes can be cherry-picked from main (or, rarely, applied directly to the major version branch.
That's right. It's important to be able to reproduce released builds with minor patches, and branches are the right tool for that job. But resist the temptation to fix that CVE on the release branch and then upstream it, because then you're once again doing branch development, treating trunk like a garbage can.
Re: Trunk-Based Development
#88Earlier quoted context omitted.
Your local repo is the equivalent of the development branch. Yes, that means you don't collaborate with others on development branches, or go for weeks committing only to a branch. If you save up a bunch of work, dump it on the main branch, then start a new development branch that lets you escape from the integration pain of your big merge, then trunk becomes a dumping ground that nobody wants to (or can) work on.
Seems strange. Sometimes we’ll have feature branches that are made up of different parts, with different devs collaborating to build those parts out. For this I don’t see a way around having some staging branch with two devs sending PRs to before you work out all kinks and merge the staging branch back into main
"before you work out all kinks and merge the staging branch back into main"
Working out all kinks on an isolated branch is very hard to do. You need to integrate to hear the screams of the team you never expected your change would affect. So your choice is to integrate commit by commit on trunk, or to wad it all up into a single waterfall release from your branch to trunk, and then spend hours/days bisecting to find which commit caused the screams.
As jozzas said, feature flags enable your code to safely lurk on trunk before it's functional.
Re: Trunk-Based Development
#89This site has developed a lot of content without seeming to directly address the major concerns anyone coming from git flow will have. For example, their code review page does not really address how github and gitlab are both set up to support branch based review, and trunk based review is a lot harder when using those tools. Similarly, I poked around and figured out what they recommend for hotfixes, which is just fix it on trunk and cherry-pick the commit. That works sometimes, but anywhere with infrequent releases (like regulated environments or shipped software) may find that pretty painful. I suspect I could raise more issues if I put more energy into it, but it's hard to want to, given how the content is presented.
Overall, this site reads like someone who's so convinced they're right that they don't bother to take other viewpoints seriously enough to actually refute them.
Re: Trunk-Based Development
#90I think that good tooling is a necessity to do trunk based development well - not just CI/CD and testing on PRs, but also being able to have stacks of commits in multiple PRs before landing as a whole (from ghstack, Sapling, or Graphite). Having worked at Facebook before where managing stacks of diffs was far better than GitHub, I wish that more of the improvements to the developer workflow could be open sourced beyo…
I agree with what you said but I'd further refine it by saying not just having testing and CI but actually having "high" test coverage and tests that actually test the code.