Man, I feel sorry for workplaces that require developers jump through the git hoops such as constant squash, fixup, drop, edit, cherry picking, branching, and merging, etc.

There are safer, saner ways to work with way less git-wrangling.

Congrats on knowing so much Git, I guess.

I keep forgetting how to change the remote for a git repo.

1) View existing remotes

git remote -v

2) Change the ‘origin’ remote’s URL

git remote set-url origin https://github.com/user/repo2.github

3) Verify new remote URL

git remote -v

I will always prefer one of these ways of working over the other.

I have an extremely hard time to understand how the other is reasoned about or chosen.

1

2

If you like to work in long lived branches:

Why do you think that your work needs to be able to work in isolation from everyone else’s work?

At the end of the day, it’s one product. Your code needs to work with everyones code.

While you are probably not concerned if you find yourself in a bad merge conflict, you are just as likely to inflict a bad merge conflict on others.

Why are you okay with setting your teammates up like this?

There are ways you can work that doesn’t do this to your teammates.

Would you be willing to learn another way?

You can avoid having complicated git setups, rules, when to merge, when to rebase, etc, if you work to get your small commits that don’t break the build into main sooner. Instead of rebasing/merging 25 commits, get your code into main after 1-3 commits. The pain goes away.

Think you can’t work in such small steps?

I think you can. I believe in you if you try.