Duck check: git-scm.com/book/en/v2/Git-Tools-Rewriting-History has a note

> One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world.

Does this hold for pushes I do to my GH repo? Or should I think about this as things having gone into the RD repo?

depends on the workflow

for our usual workflow it does not apply to pushes to your fork

it does not even apply to stuff you have an open PR about

because before the PR is merged, it's still all in your fork

Once it's gone into the RD repo though...

yeap

:+1: Making sure.

your fork is basically a way to make your local repo visible to others in our workflow

The idea of a repo is getting much clearer now.

Probably a bad example but it's kind of like a property accessor, just for local files?

~confused

Yep bad example.

It provides public access to what I want to be seen.

not necessarily ....

actually ... not at all

:click: So that's what 'Head' means when you us it in the CLI...

@Vogel612 You have a moment to duck out loud with me? I want to make sure I understand.

sure

git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell at figure 14.

When you create a new branch and work on it nothing changes until the 'staged' changes are actually 'commit'ted?

That's why I've seen some messages why HEAD is ahead/behind by so many commits?

@IvenBach yes.

@IvenBach not quite sure which exactly you mean

@Vogel612 I can't recall the specifics but when I was first getting into RD I would routinely have conflicts with whatever branch I was working on being ahead/behind of Head.

There'd be warnings about loss of information/commits/etc...

it's impossible to be behind or ahead of HEAD

#Words

you might be talking about a "detached HEAD state"

I've seen that part but haven't read through it yet.

basically HEAD points straight to a commit instead of to a branch

So HEAD is whatever is the checked out branch/commit?

yes

One last check.

figure 17.

With work that diverges and creates their own separate changes those can be merged without any conflicts if they same files aren't worked on.

correct