4 ms·
my flow is (on my-branch with no one else's commits) * push some commits up to my remote branch * git fetch * git rebase master/main to get the latest stuff
by skrtskrt 4y ago
my flow is (on my-branch with no one else's commits)
* push some commits up to my remote branch
* git fetch
* git rebase master/main to get the latest stuff
* add changes on my-branch that use new stuff from master/main
* git push --force-with-lease to my remote branch - this fails if you don't use some version of force since my most recent commit is based on a commit (from master) not on the remote branch
- G3rn0ti 4y agoI don’t get why everybody wants to rebase their topic branches. Just use merge, come on. If you want a „clean“ commit history on main/master do a squashed merge into main at the end. This way we never had to force anything on the remote.
- ok_dad 4y agoI rebase on my topic branches because then my edits are neatly stacked on top of the other branch, so I can re-arrange things more easily. Why would I want a weird commit with a bunch of work I didn't do on the topic just smooshed into the middle of my well-crafted series of commits?
- mixmastamyk 4y agoWork you didn't do won't be in your branch. There is no rearranging, it is one commit.
- Dylan16807 4y ago> Work you didn't do won't be in your branch. The merge commit will be in the branch. > There is no rearranging, it is one commit. You misread that. They want to be able to rearrange things easily. Having multiple merge commits in the middle gets in the way of that.
- mixmastamyk 4y agoThe work doesn't show up on a diff, what I was getting at. Merges are from master in this example and already reconciled. Commits don't matter either, because they are being squashed. Was responding to the grandparent perhaps more than the parent.
- aulin 4y agoWhy would you have to force anything with rebase? you rebase your feature branch against main to rewind it on top of it and clean up history so you can do a clean fast forward merge. Squashing is bad for anything non trivial, you want small independent commits: easy to review, easy to revert, easy to blame if something goes wrong.
- G3rn0ti 4y agoAs soon as you pushed your branch to remote (which I tend to do for backup reasons especially after working hard on a solution) rebase only means trouble.
- aulin 4y agoif you're the only one working on that branch I don't see where is the problem in rewriting history and force pushing
- mixmastamyk 4y agoUntil you make a mistake.
- eru 4y agoWhy? That's what 'git reflog' is for. Or you mean that a mistake where you accidentally push to someone else's branch? The default model that public github uses is good for that: everyone works on their own fork of the repo, and makes pull requests to the shared repo. Nobody pushes directly to the shared repo.
- mixmastamyk 4y agoSecond. Github not an option for a lot/most work.
- __blockcipher__ 4y agoNot if it's the remote for your own dev branch. It only matters if the remote branch is being (actively) used by other people. Unfortunately I've met far too many who have your "remote" superstition. I remember arguing this exact point in my last gig, when someone was mad at me for force pushing my own remote branch that nobody else was using nor should have been.
- npc12345 4y ago