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.

results matching ""

    No results matching ""