Some Concept
Rebase vs. Merge
- Using
merge
means your repository’s commit history is a record of what actually happened.
- Using
rebase
is more like the commit history is the story of how your project was made.
- In general
- rebase local changes you’ve made but haven’t shared yet before you push them in order to clean up your story
- never rebase anything you’ve pushed somewhere.
"Tree-ish" and "Commit-ish"
Background
- Git keeps track of source code using four fundamental objects:
- Annotated tags, which point to commits.
- Commits, which point to the root directory tree of your project.
- Trees, which are directories and subdirectories.
- Blobs, which are files.
- Each of these objects has its own sha1 hash ID
Explanation
- "Commit-ish" are identifiers that ultimately lead to a commit object. For example,
tag -> commit
- "Tree-ish" are identifiers that ultimately lead to tree (i.e. directory) objects.
tag -> commit -> project-root-directory
- Because commit objects always point to a directory tree object (the root directory of your project), any identifier that is "commit-ish" is, by definition, also "tree-ish"
- But since directory tree objects never point to commits in Git's versioning system, not every identifier that points to a (sub)directory tree can also be used to point to a commit.
So what?
<tree>
: Indicates a tree object name.
<commit>
: Indicates a commit object name.
<tree-ish>
: Indicates a tree, commit or tag object name.
<commit-ish>
: Indicates a commit or tag object name.
- tree-ish identifiers that cannot be used as commit-ish are:
<rev>:<path>
, which leads directly to directory trees, not commit objects.
- Sha1 identifiers of directory tree objects.