Is git a history of what happend or a list intentional changes?

Had this discussion with my boss. He said i shouldn't rebase my feature branch because it is too much hassle (I did some squashing and fixups). I should just commit on top and merge master into my branch.

What is your git philosophy?
Do you "own" a feature branch until you create the PR?

Git history is a series of commits. Commits are patches of specific changes to specific files. By that definition it's intentional, because you made the changes.

You should always rebase; most of your dust doesn't matter to people in the future, it only matters during your work process. All merges should be fast forward. Your future self will thank you the first you have to bisect a changeset.

If your boss is okay with quite literally shitting on history and micromanaging your process in that fashion, you have bigger problems. My guess is he doesn't really understand rebase in the first place.

The real question to ask is:

"Is git a record of what happened or what was intended?"

If I'm a pointy haired boss, uninvolved in the work, I want to know what happened.

If I'm an engineer, needing to deliver software and operate on intent, it's definitely a record of intent.

Tl;dr: Introduce your boss to pull request history and tags as a means to keep track of what was done. Merge commits are heinous.

Tl;dr 2: git is a unidirectional data store, in which all roads lead to master. If your timelines resemble clover leaves and anything other than straight lines to master, you're doing it wrong

Tl;dr 3: when two people are working on a single feature branch, this can create history conflicts. Only rebase when agreed and before issuing PRs

Tl;dr 4: git affords forking. Avoid pushing work branches to the original repo until you're ready for it to be reviewed. The lack of easy forking, is why shitbucket sucks, and is a favourite of pointy haired bosses everywhere.

Tl;dr 5: git is a complicated, opinionated subject with a lot of options. Branches exist for when you have delays between when work is done and when it goes to production. The more time between those two points, the more branch indirection and pipeline ceremony you will inevitably have.

Tldr 5 tldr: keep tasks small. Rebase early. PR often.

Tldr 6: this is probably a quine in shakespeare lang

I always rebase and test again after just to make sure that there is no functional conflict.

Its just easier to resolve that way.

Especially if any problems surface later.

There have been occasions where I have merged directly but that mainly if i the only existing commits are small and not touching any code or functionality that I am touching.

@SortOfTested probably the first time the tl;dr section is longer than the actual post

Your boss might wanna read this: https://blog.carbonfive.com/always-...

You will have the same issues upon merging the target branch in your feature branch than with rebasing from the target branch. The conflicts will not go away if there are any.

I don't see your boss's point.

By gitflow procedure, if that is what you are describing, there is no specific user ownership on a feature branch. There should still be some kind of process to validate nothing is broken before merging or while commiting.

@SortOfTested THANK YOU. The number of times I ask "sure, but then what happens when you need to bisect?" and get... "Err... bisexual what now?"

Bisecting is one of the killer git features, and I've no idea how so few people know of it's existence. Near enough my entire git workflow is set up so I can run automatic bisection at a moment's notice and pinpoint issues exactly.