Git is a very flexible toolchain, which allows sheer amount of workflow variations.
But regardless of personal style, at the end of day, working with git ends up with modification of repository history.
Single commit, branch and tag – are basic elements upon which git commit history is built.
So I tried to collect my own notes about the subject and post them below.
Currently it may seem as an incomplete, draft version, but nevertheless I decided to push it instead of to keep it collecting the computer dust
- Commit is a point in git history, the most basic, atomic element.
- Commits are created as a result of git commit command.
- Each commit has its id in form of SHA1 hash.
- Usually a commit has a parent. That enables the commit history itself.
- Commits may participate in multiple branches.
- Can be checked out by its SHA1 code.
- When checked out by a SHA1, local working copy enters a “branchless” state.
- There is a special kind of commits – merge commits.
- Branch is s named linked list of commits.
- There is always a branch (master branch is automatically created upon git init).
- Branch can be checked out by its name.
- When checked out, the HEAD points to the most recent commit of the branch.
- Two or more branches could be synchronized with one another.
- Specific synchronization git subcommands are: merge, rebase, fetch, pull, push, cherry-pick
- Branch may be renamed or deleted.
- Tags are human readable commit labels/aliases.
- Tags are similar to branches because they have names.
- Tags are similar to commits because they may have “annotations”, just like commit messages.
- Tags can be used to perform checkout command instead of SHA1 hashes.
- Just as with individual commits, checkout by tag is a “brancheless” checkout.
- Unlike commits and branched, tags should be pushed separately.