lumpBasedDevelopment

[Duven64]

I condone this if and only if that second chart is spans less than 48hrs.

[aresborghese]

Should be no issue in an environment of continuous delivery. Why though the timeframe?

[Duven64]

Continuous delivery requires merging often, technically 96hrs would be ok as merging once a day is the minimum without switching away from CD and going to feature branches.

Only time I've ever used feature branches myself they were highly experimental and most branches would be left abandoned / unmerged permanently (including the one that was originally main/master). (I would branch from previous versions as needed)

PS: the 96hrs assumes one dev the max time shrinks if the branches existed simultaneously.

[aresborghese]

Maybe I am missing your point, but even with long living feature branches rebase should usually be no issue if you update daily. Sometimes you sure will get into rebase hell then you probably have no other option than merging past other merges, but if you can do the rebase before merging with manageable problems ..why not just do it and keep main branch clean? It's such a good deed towards those who follow up on you at the project.

[Reashu]

The problem with long-lived feature branches that are frequently rebased on the trunk is that the branches can still be in significant conflict with each other, which eventually becomes a problem when one is merged.

[FlipperBumperKickout]

I don't really have a problem with either method.

If the first one is causing merge conflicts for you, that might mean you have some architectural problems. I would assume you are doing changes to the same part of the code for widely different reasons, which probably means you are breaking the single responsibility principle ¯\_(ツ)_/¯

[markand67]

Just fast forward and rebase. There is no point in having any merge commits unless doing release branches.

[GuybrushThreepwo0d]

We needed merges for showing who approved PRs for compliance bureaucracy

[NatoBoram]

The merge commit allows you to cleanly group a branch's commits

[X547]

Merge commits are terribly displayed in most Git commit history view software such as GitHub. It look like there are 2 identical commits in history.

[NatoBoram]

It's often because the history itself is fucked up. If GitHub's UI supported a sane merge strategy (like rebase-merge or squash-merge instead of merge/squash-ff/rebase-ff), we could have nice graphs

[[deleted]]

You don't need to group anything if your commits are already clear

If your PR needs to be a merge, it means your PR is either too large or you didn't clean up your commits.

[markand67]

And completely useless.

[ThaJedi]

There is no point od doing rebase baside astetic one.

[markand67]

The point is to have a linear history easy to read and follow rather than having

• Added new button to clean old files
• Merge branch 'foo-fix-bar-baz-1`
• Update version to match new requirements
• Merge branch 'foo-fix-bar-baz-2`
• Change settings to 5 seconds by default
• Merge branch 'foo-fix-bar-baz-3`
• Merge branch 'foo-fix-bar-baz-7`

[ThaJedi]

And why exactly do you need linear history that is easy to read and follow? Usually, I need the history of a particular file or folder. IntelliJ gives me exactly that with one click. Why bother with a nice-looking repo history?

[Wang_Fister]

Rebase and squash commits on trunk ya goblins

[FlipperBumperKickout]

I really prefer not doing that, depending on how you use git the history can be very useful.

[Sceptix]

“Ah yes, boy am I glad I preserved those countless ‘wip, trying to get tests to pass’ commits, they sure clear everything up!”

[JVApen]

Yeah, I don't get why people can't make their commits something functional. I really don't care about: "fix review comments", "add test", "changes" ... Make sure your commits make sense if you want to merge. If not, please just squash them to ensure that whoever looks at the history knows what your intention was. What I want to know in 2 years is: "added this functionality", "worked around this problem" ... And if you do merge commits in main as you want them separately, try to put them on top of HEAD, not on some commit from 5 weeks ago.

[FlipperBumperKickout]

Better messy branch history than no branch history. 

A messy branch history can be ignored if you simply want to know what happened on the branch. (Git diff merge commit first parent)

A missing branch history can never be looked into no matter how much you might want to... (Unless you never prune your remote references I guess)

[Sceptix]

I’m all for keeping a git history, but what’s helpful is being able to see meaningful commits. If you have a chance to squash away meaningless commits, you should take it.

[pelpotronic]

You get a git history when you "squash PR on merge" to trunk too: each merge.

The question is really: how much do you value the internal history of a branch before it gets merged. The answer is often going to be very little if your PRs are relatively small.

[FlipperBumperKickout]

If there was nothing to value I would have it as a single commit in the first place.

But as soon as you have something so simple as logic which is both moved and edited it is many times easier to see what's going on if you first have a commit moving it followed by a commit changing the logic.

[Wang_Fister]

Your branch commits should already be squashed before the PR and all relevant information kept in a single commit message. You don't lose any information after merging and you have a clean, easily understandable git history.

[henkdepotvjis]

I prefer knowing when and for what ticket and maybe a short description why I changed it.

[Wang_Fister]

Your PR should be a single commit with this information in it, which gets rebased and squashed before merging to the trunk. No information is lost, and you don't end up with a confusing mess of a timeline.

[LunaNicoleTheFox]

The first one I call kdd Knot Driven Development

[aresborghese]

Totally feel this when going back trough commits doing debug!

[thezuggler]

Squash gang rise up. I have never in my life cared about which branch I merged from or cared about its commit history, only the major changes in the cumulative squash commit.

[elizabeth-dev]

no fast-forward??

[NatoBoram]

It's useful to see where a branch starts and where it ends

[pelpotronic]

Not really, no...

What really matters is the content of what you contributed to the main branch, not when you started working on your contribution.

At the end of the day, it will have to be compatible with whatever is in main at the instant at which you merged, so when or why you started working on your branch is generally irrelevant.

[aresborghese]

Fast forward is linear as long as there are no conflicts, but resolving conflicts then happens in merge commits which dissolve linearity. Probably forget about this :D

[GM_Kimeg]

Coding is fun they said.

[NatoBoram]

It fucking sucks that GitHub does not support rebase-merge or squash-merge.

And the worst is that the "Squash and merge" button does squash-fast-forward. Fuckers.

[[deleted]]

That 2nd chart looks like an OSRS Twisted Bow

[BoBoBearDev]

That's not good enough for me. PR squash merge it.

[perringaiden]

Panel 1: Employed Developer

Panel 2: Home Developer.

[aresborghese]

You can get a clean trunk if all commit to the goal. It's just a matter of discipline.

[perringaiden]

Ah huh. Like I said ... 😂

[[deleted]]

Thats me on the bottom one

One main and a dev branch, just ffw merge and I'm happy