A repository ("repo") is where snapshots of your code are stored, and can be retrieved and compared against. Its right there, next to the code, on your local drive in a folder named .git. Commits will by default go to this local repository and commands will operate against this repository. There is no central "mothership", no master repo that many people contribute to and have to sync with, no master-slave relationsip, no "ground truth". At least not enforced.
You can however create remote repositories and syncronize with them, if you want "Upstream" in this context is a repo you trust and pull in changes from (they flow down to you). You can also push your changes to a "downstream" repo. By default your remote will be called "origin".
So in git you have:
- a "working copy" these are files you edit, which may or may not be known to the repo already
- a "staging area" (also "index"), of code tracked but not commited yet
- your local repo
- zero or more remote repos
A commit is a snapshot of a repository at a given point in time. Each commit has an unique id to refer to it (also called "sha1" after the algorithm used to calculate it) . The latest commit can be accessed with the symbolic name HEAD. Commits have a pointers to the commits they are based on.
A branch really is just a name for a pointer to a commit. In git, you are always on a branch, your current or checked-out branch. The default branch is named "master" by default. When you make a commit while on a branch, the branch pointer is moved to point at it. As it is associated with a name, you can use that name in commands. A tag is similarly a symbolic name for a pointer but it is not automatically moved as you commit, it is intended to stick durably to a given, specific commit.
(A commot is what would be called a revision in CVS, but it is not limited to a single file. If you want to work on only a single file in a given commit, you have to specify the commit and the full path to the file name, sepated by a :. If you want to compare your local copy of a file with the version in a remote repo, it gets even more complicated. You need to define that remote, fetch a local copy, and compare against that.)
A branch really is just a name for a pointer to a commit. In git, you are always on a branch, your current or checked-out branch. The default branch is named "master" by default. When you make a commit while on a branch, the branch pointer is moved to point at it. As it is associated with a name, you can use that name in commands. A tag is similarly a symbolic name for a pointer but it is not automatically moved as you commit, it is intended to stick durably to a given, specific commit.
(A commot is what would be called a revision in CVS, but it is not limited to a single file. If you want to work on only a single file in a given commit, you have to specify the commit and the full path to the file name, sepated by a :. If you want to compare your local copy of a file with the version in a remote repo, it gets even more complicated. You need to define that remote, fetch a local copy, and compare against that.)
A revision is the general term for versioned objects, be they files ("blobs"), directories ("trees") or commits.
- The unique id, also called "sha1", after the algorithm to calculate it, or the first few chars of the id
- A symbolic reference (called "ref") name for a commit, eg.
- HEAD (of the currently active branch in the local repo)
- A branch name (meaning the HEAD commit of that branch in the local repo)
- A remote repo name (meaning the HEAD of its default branch)
- A remote repo/branch name (meaning the HEAD of that)
- A tag (an explicitly defined label)
As commits know their "parent", the commit (or, in case of a merge, commits) they are based on, ancestors and ranges can be applied ("~" also works in place of "^"):
^, ^^, ^^^ (etc): parent, grandparent, great-grandparent etc before a commmit, eg HEAD^
^1, ^2, ^3 (etc): first, second, third parent (in case of a merge).
..: all commits starting with one stated, eg HEAD~3.., or all betwen two stated eg HEAD~4..HEAD^
Default behaviour
The branch you are on is by default "master". An remote repo is by default called "origin", with "origin/master" as its main branch.
When working with branches and remotes to give just the branchname
Is there a common order if there are multiple revisions listed for a command?
git rebase rev1 rev2 ... will rebases rev2 onto rev1
git rebase rev ... will rebase your current branch onto rev: the missing value is defaulting to current
git pull rev1 rev2
git push n1 n2 ... n1 is the remote repo, n2 is your local branch.
git push n1 ... n1 is the remote repo, missing argument defaults to current branch
No comments:
Post a Comment