The Virgin rebase vs the Chad merge

The Virgin rebase
>cares a lot about a clean state of the git history
>spends a lot of time rebasing his commits
>rejects a quality pull request if it isn't properly rebased
>requires autistic attention to detail from his fellow colleagues for no beneficial reason
>makes his product owner unhappy by not delivering features fast enough

The Chad merge
>just merges the development trunk into his feature branch
>resolves merge conflicts effortlessly
>juggles multiple in-development feature and integration branches if his feature branch is dependent on it
>has mapped the dependencies in his memory, doesn't forget to pull updates from them into his own branch to continuously resolve merge conflicts
>doesn't care about his git history, fixes forward instead
>employs a deployment strategy with a working fallback version in case of catastrophe
>puts focus on code quality, not version control mechanics
>makes product owner happy by delivering features faster

Attached: git.png (348x145, 4K)

>git add .
>git commit -m "didn't even read op"
>git push -f

rekt. pwnd.

>not doing "git -am"

Get out of my board

>the Chad force push

>cares about his owner
>"chad'

The Chad is responsible for his team and does what's in their best interest. Fostering a good relationship with the product owner is beneficial for everybody, especially his own team, because it puts them in a superior situation for negotiating technical improvements. It also eases the pressure on his colleagues and keeps happiness on a maximum. If necessary, the Chad will tell the product owner that technical improvements must be prioritized over features for a few sprints, and his good relationship with the product owner as well as the team's impeccable record of delivering features makes it no big deal.

>git
>capable of dealing with any directed acyclic graph
>some retard junior dev read on Reddit that non-linear history is bad
>rebases to resolve a merge conflict
>screws up the merge conflicts
>2 weeks later QA finds a problem on the release branch
>do git bisect, the commit that introduces the problem is one big entire feature change-set that's been rebased multiple times and squashed into a single commit
>platform manager asks what did the code look like when it worked?
>idk, there's no history of it because some Dunning-Kruger effect dipshit erased all the history for 'muh fast-forward'
>this would have been trivial to deal with if we had a merge commit and could see the code before and after merge conflicts were 'fixed'

I just use Vim as my version control via backups and undo history. Basically for any file I've ever edited I have a backup and history. If I want to "push", I just sent a patch via email.

>cares a lot about a clean state of the git history

This is silly. Most version control software will display merge commits as appropriate, and you can just ignore merge commits from git itself if they tickle your autism.
Having the exact commit where changes were made to facilitate the merge is also useful, because that's an area where bugs can arise.

It's way safer, faster and communicative to properly merge from upstream than to try to fuck around for some false notion of 'purity'.

Why aren't people happier with the merge history?
Why would you not want to be able to see the exact history in all branches as it happened?
Rebase is historic revisionism bullshit.

git reset --hard HEAD

Attached: 96377734ad73f8411681bfbb120d56e064c4848ac8eed840fa65a48f053ac865.jpg (511x509, 36K)

bisect is much easier to understand with a rebased history.

It's not particularly difficult to understand either way. If you need a linear history to get your bisect to work, it's because you're blindly copy-pasting bisect commands from stack overflow.

Is there a git good?

Not using magit with incremental staging and commits, individually committing each and every line of code with a message so you can go back later and know what it's all for

webdev fag here, whats the benefit of git in web production, if any.

Chad isn't afraid to rewrite history. He's gonna git push --force and you're gonna have to deal with it.

What source control tool you are using then?

the chad sounds a lot like a wage- cuck all of the sudden. where did it all went so wrong? will cowboy coder come along and show the chad how realm men develop software and change the world while at it?

yes man gittutorial
basically you only need log, status, add, commit, checkout, reset, pull, push

Not losing all your work