~williamvds/website

4303d862c3729524d1a3dfad8de0f99f6441c748 — williamvds a month ago 2f0b275
blog: git: fix mangled sentence and syntax
1 files changed, 8 insertions(+), 9 deletions(-)

M content/blog/git/index.md
M content/blog/git/index.md => content/blog/git/index.md +8 -9
@@ 360,7 360,7 @@ nothing to commit, working tree clean

Let's run `$ git show` to see the last commit that we just created:

```git
```gitlog
$ git show
commit 173bb18cd1059b1efb048dc32442eb34b36c78a4 (HEAD -> master)
Author: William <william@example.com>


@@ 2601,14 2601,13 @@ use [`$ git revert`](https://git-scm.com/docs/git-revert) to create a new commit
that undoes the changes in another.

Thankfully, remotes will prevent you from rewriting branch history by default.
However, this isn't an absolute rule, and you can force remotes accept the
rewritten cases in cases where it makes sense.

For example, if you're working on temporary feature
branches, it may be acceptable to first rebase them before merging them into a
main branch. Your team should set rules on when shared branch history may be
rewritten, and shared repositories can be configured to block forced rewrites to
enforce those rules.
However, this isn't an absolute rule, and you can force remotes to accept the
rewritten history in cases where it makes sense.

For example, if you're working on temporary feature branches, it may be
acceptable to first rebase them before merging them into a main branch. Your
team should set rules on when shared branch history may be rewritten, and shared
repositories can be configured to block forced rewrites to enforce those rules.

If you find yourself having accidentally rewritten shared history, try
cancelling your current merge or rebase, or use the [reflog](#reflog) to (mixed)