undefined | Better HN

0 pointsjrochkind110y ago0 comments

I tend to agree. One exception I think is rebase on a feature branch. If you rebase a feature branch onto master before merging it into master, I think you can get a cleaner history while achieving the linear history the OP wants -- and in this isolated case, I think you aren't losing any useful context by making it seem the feature commits were all done right before merge into master.

Maybe. I'm not actually sure, to be honest what's a good idea with git history, this included. Feedback welcome.

0 comments

Mithaldu10y ago

People who love rebasing and linear history tend to see feature branches, even if pushed to a public repository, as private to their creator and maintainer and fair game for any sort of rebase. In fact, we do consider rebasing of feature branches mandatory.

jrochkind1OP10y ago

The counter argument though is when your feature branch doesn't only have _one_ creator/maintainer. Mine often don't, especially on open source projects, two or three people can be working collaboratively, or others that aren't the lead on the feature can come in to make a helpful commit here or there.

And when one person rebases the feature branch it wreaks havoc for collaborators on the feature branch.

Which is why I limit my "rebasing is okay" on a feature branch to only _right before_ it's merged into master and then deleted. It still doesn't get rid of all the problems, but it gets rid of most of them.

Mithaldu10y ago

If you have a handful of people, you simply communicate with them, check that there's a good reason to rebase and that you're not creating unnecessary burden and do it when everyone is happy.

When you have more than a handful of people, then your feature branch is not a feature branch, but a project, which should have feature branches of its own.

Scale, dynamic adaption to it and situational awareness are a requirement in team work. :)

2 more replies

sytse10y ago

If it is pushed other people can cherry-pick, CI generates results and other people might push commits on the same branch (when using the same repo). We think pushing indicates you want to work in public. We even made a Work In Progress (WIP) function for it in GitLab http://doc.gitlab.com/ce/workflow/wip_merge_requests.html

Mithaldu10y ago

It's a social question. To be honest, for the vast majority of people i work with (and i've worked with a few: https://github.com/wchristian?tab=repositories ) it would be considered very strange to see feature branches as public and stone-written history. There's a common understanding that feature branches are feature branches because the creator wishes to avoid writing things in stone.

That said, if a team decides on that kind of convention, marking things as WIP is a neat feature. I've seen other people do that simply by creating feature branches as "<username>/feature_branch".

j / k navigate · click thread line to collapse

0 comments

Mithaldu10y ago

jrochkind1OP10y ago

And when one person rebases the feature branch it wreaks havoc for collaborators on the feature branch.

Mithaldu10y ago

If you have a handful of people, you simply communicate with them, check that there's a good reason to rebase and that you're not creating unnecessary burden and do it when everyone is happy.

When you have more than a handful of people, then your feature branch is not a feature branch, but a project, which should have feature branches of its own.

Scale, dynamic adaption to it and situational awareness are a requirement in team work. :)

2 more replies

sytse10y ago

Mithaldu10y ago

That said, if a team decides on that kind of convention, marking things as WIP is a neat feature. I've seen other people do that simply by creating feature branches as "<username>/feature_branch".

j / k navigate · click thread line to collapse