[killerstorm]

If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features.

A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.

[Cthulhu_]

As soon as you have the situation of multiple people working on the same branch, forbid force pushes at all times. But it's better to avoid that in the first place, all work should be on its own branch at all times.

For larger features we often have a feature branch with merge requests for various task branches. Limits the review sizes as well.

Of course, you can also then consider to use feature toggles, so there's no feature branch but just your main branch.

[alexjplant]

> A lot of people are religious about rebasing

Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in the same physical office was out on vacation.

When I interview for new roles I always make a habit of asking how work gets done to avoid shops that engage in these types of shenanigans.

[raylu]

wait what?

bitbucket will merge a PR from your feature branch onto the base branch even if it's not fast-forward from the base branch. as long as you use the "squash" or "rebase" option on the PR interface (instead of the "merge" option), the resulting history will be linear

[km144]

A lot of the time, multiple devs working on a single branch can be avoided via different decisions made upstream about work that needs done. If my job included more git wrangling as one of my daily tasks I would probably hate my job.