In reply to @callahad:matrix.org
So there's a bit of... manual pruning / gardening that's just become a customary part of using Git. It shouldn't be necessary (cf. my allusion to former Git competitors like Darcs and Mercurial), but Git + GitHub won, and so here we are 😆

In reply to @shayshay:matrix.org
Ah so when i pulled the upstream repository and merged it i should have used git pull --ff-only rather than pulling and then merging it?

In reply to @callahad:matrix.org
https://learngitbranching.js.org/ looks like it might be OK

In reply to @callahad:matrix.org
Shay: Would you want to hop on a call real quick? I think I found a decent way walk to show what's up .

TL;DR:

• Generally speaking, avoid committing to your local copy of the master branch.
• Use git pull --ff-only to avoid automatically creating merge commits when a branch you're working on diverges from upstream.
• It's a best practice to use separate branches for each feature you work on: e.g., git switch master then git switch -c my-feature to create a new branch based off of master. If you're waiting for that to be reviewed and want to work on something else in parallel, just git switch master then run git switch -c another-feature to create another "feature branch."

TL;DR:

• Generally speaking, avoid committing to your local copy of the master branch.
• Use git pull --ff-only to avoid automatically creating merge commits when a branch you're working on diverges from upstream.
• It's a best practice to use separate branches for each feature you work on: e.g., git switch master then git switch -c my-feature to create a new branch based off of master. If you're waiting for that to be reviewed and want to work on something else in parallel, just git switch master then run git switch -c another-feature to create another "feature branch."

Also:

• If you do accidentally create a merge commit, you can undo it with git reset --hard commit where commit is the thing you want to reset to (e.g., the hash of your last commit before the merge). Be careful, as this discards your local changes and resets the local copy of your current branch to the commit specified. For example, if you want to nuke all of your master and make it equivalent to upstream, then run git switch master followed by git reset --hard origin/master
• If you want to move commits somewhere else in the tree (like to put them on top of a diverging branch to make history linear) you can use git rebase target where target is something like origin/master or origin/feature-branch-name. Be careful with this one, too, as it only changes your local copy of the branch, which can make things confusing if you've shared your changed with other people, e.g. in a GitHub pull request, since suddenly there will be disagreement between clones of the repo about what changes should fall under which branch name.

Also:

• If you do accidentally create a merge commit, you can undo it with git reset --hard commit where commit is the thing you want to reset to (e.g., the hash of your last commit before the merge). Be careful, as this discards your local changes and resets the local copy of your current branch to the commit specified. For example, if you want to nuke all of your master and make it equivalent to upstream, then run git switch master followed by git reset --hard origin/master
• If you want to move commits somewhere else in the tree (like to put them on top of a diverging branch to make history linear) you can use git rebase target where target is something like origin/master or origin/feature-branch-name. Be careful with this one, too, as it only changes your local copy of the branch, which can make things confusing if you've shared your changed with other people, e.g. in a GitHub pull request, since suddenly there will be disagreement between clones of the repo about what changes should fall under which branch name.

In reply to @callahad:matrix.org
Yep. I'm pretty happy with git fetch origin then git rebase origin/master as a workflow... but once you've submitted your pull request then updating it requires git push --force to overwrite the previous history in the pull request

In reply to @reivilibre:librepush.net
I learned something new now (about using git fetch origin which I guess I could have figured out :))