I feel like this is "solving" a problem that doesn't exist in good workflows. How often are you pulling from a shared branch that you are making local commits to? Each of the people in the video should be branching off main and doing pull requests to get back into main.
> How often are you pulling from a shared branch that you are making local commits to
When more than one dev is working on a feature branch? You could take feature/a, branch off feature/a.1 for your local work but at some point you gotta incorporate work from feature/a. Not so different from origin/main -> main.
git pull --ff-only should really be the default (changeable) behavior.
I think that at the point in the workflow where you are ready to get some new changes from upstream and integrate with your local ones, you're probably going to have all your outstanding work in a commit.
A rebase that is part of a pull, together with auto-stash, doesn't make a whole lot of sense.
I've never run into the problem of not being able to rebase due to uncommitted changes, except in two situations:
- suddenly wanting to rewrite something in the branch, unrelated to the in-progress work.
- working in a badly structured project whose builds alter tracked files
I did that for several months in 2010. It's too error prone; you will forget to have that configured somewhere and get a merge by mistake.
So then I trained myself on "pull --rebase". I soon realized, I don't want to be combining fetch and rebase. The best way was to just scrub the pull command from the vocabulary.
It's fine nowadays but there was a time when "git pull --rebase" worked slightly differently to "git fetch" and "git rebase". I'd get conflicts with the former that I didn't get with the latter.
I don't rebase immediately after a git fetch. I look at what is new first. I might not rebase over all of it. E.g. the first three commits may have something I need to pick up, but then after that there may be something I don't want to integrate with yet.
21 comments
[ 4.5 ms ] story [ 52.5 ms ] threadWhen more than one dev is working on a feature branch? You could take feature/a, branch off feature/a.1 for your local work but at some point you gotta incorporate work from feature/a. Not so different from origin/main -> main.
git pull --ff-only should really be the default (changeable) behavior.
Every working/hobbying day for the past decade and a half.
alias gupa="git pull --rebase --autostash"
A rebase that is part of a pull, together with auto-stash, doesn't make a whole lot of sense.
I've never run into the problem of not being able to rebase due to uncommitted changes, except in two situations:
- suddenly wanting to rewrite something in the branch, unrelated to the in-progress work.
- working in a badly structured project whose builds alter tracked files
It provides a clean commit history, without actually rewriting the commit history.
I wish more developers in the company used this approach.
So then I trained myself on "pull --rebase". I soon realized, I don't want to be combining fetch and rebase. The best way was to just scrub the pull command from the vocabulary.