if it will only be used by a single user across all machines.
+
It is important not to use a cloud syncing service to sync any portion of a Git
repository, since this can cause corruption, such as missing objects, changed
or added files, broken refs, and a wide variety of other problems.  These
services tend to sync file by file on a continuous basis and don't understand
the structure of a Git repository.  This is especially bad if they sync the
repository in the middle of it being updated, since that is very likely to
cause incomplete or partial updates and therefore data loss.
+
An example of the kind of corruption that can occur is conflicts over the state
of refs, such that both sides end up with different commits on a branch that
the other doesn't have.  This can result in important objects becoming
unreferenced and possibly pruned by `git gc`, causing data loss.
+
Therefore, it's better to push your work to either the other system or a central
server using the normal push and pull mechanism.  However, this doesn't always
preserve important data, like stashes, so some people prefer to share a working
tree across systems.
+
If you do this, the recommended approach is to use `rsync -a --delete-after`
(ideally with an encrypted connection such as with `ssh`) on the root of
repository.  You should ensure several things when you do this:
+
* If you have additional worktrees or a separate Git directory, they must be
  synced at the same time as the main working tree and repository.
* You are comfortable with the destination directory being an exact copy of the
  source directory, _deleting any data that is already there_.
* The repository (including all worktrees and the Git directory) is in a
  quiescent state for the duration of the transfer (that is, no operations of
  any sort are taking place on it, including background operations like `git
  gc` and operations invoked by your editor).
+
Be aware that even with these recommendations, syncing in this way has some risk
since it bypasses Git's normal integrity checking for repositories, so having
backups is advised.  You may also wish to do a `git fsck` to verify the
integrity of your data on the destination system after syncing.

Common Issues
-------------

[[last-commit-amend]]
I've made a mistake in the last commit.  How do I change it?::
	You can make the appropriate change to your working tree, run `git add
	<file>` or `git rm <file>`, as appropriate, to stage it, and then `git
	commit --amend`.  Your change will be included in the commit, and you'll
	be prompted to edit the commit message again; if you wish to use the
	original message verbatim, you can use the `--no-edit` option to `git
	commit` in addition, or just save and quit when your editor opens.

[[undo-previous-change]]
I've made a change with a bug and it's been included in the main branch.  How should I undo it?::
	The usual way to deal with this is to use `git revert`.  This preserves
	the history that the original change was made and was a valuable
	contribution, but also introduces a new commit that undoes those changes
	because the original had a problem.  The commit message of the revert
	indicates the commit which was reverted and is usually edited to include
	an explanation as to why the revert was made.

[[ignore-tracked-files]]
How do I ignore changes to a tracked file?::
	Git doesn't provide a way to do this.  The reason is that if Git needs
	to overwrite this file, such as during a checkout, it doesn't know
	whether the changes to the file are precious and should be kept, or
	whether they are irrelevant and can safely be destroyed.  Therefore, it
	has to take the safe route and always preserve them.
+
It's tempting to try to use certain features of `git update-index`, namely the
assume-unchanged and skip-worktree bits, but these don't work properly for this
purpose and shouldn't be used this way.
+
If your goal is to modify a configuration file, it can often be helpful to have
a file checked into