Tag, Index, Track, Staging
Cloning copies an existing Git repository. Like SVN checkout except the working copy is a full-fledged Git repository (has its own history, manages its own files and is a completely isolated environment). Cloning automatically creates a remote connection called origin pointing back to the original repository.
Developing a project revolves around the basic edit/stage/commit pattern.
Git doesn’t force you to interact with the central repository until you’re ready. Just as the staging area is a buffer between the working directory and the project history, each developer’s local repository is a buffer between their contributions and the central repository.
First, you edit your files in the working directory. When you’re ready to save a copy of the current state of the project, you stage changes with
git add. After you’re happy with the staged snapshot, you commit it to the project history with git commit.
The
git add command should not be confused with svn add, which adds a file to the repository. Instead, git add works on the more abstract level of changes. This means that git add needs to be called every time you alter a file, whereas svn add only needs to be called once for each file. It may sound redundant, but this workflow makes it much easier to keep a project organized.
Commit commits the staged snapshot to the project history. While they share the same name, this command is nothing like
svn commit. Snapshots are committed to the local repository, and this requires absolutely no interaction with other Git repositories.
Staging = Adding changes to 'pending changes' (done automatically). Then you commit your staged changes.
Merging is non-destructive = existing branches not changed. Rebasing re-writes.
Fetch = update working copy (but not merge yet)
Pull (get latest) = Fetch + Merge
Push = Publish to Shared
emote-tracking branches are references to the state of remote branches. They’re local references that you can’t move; they’re moved automatically for you whenever you do any network communication. Remote-tracking branches act as bookmarks to remind you where the branches in your remote repositories were the last time you connected to them.
They take the form (remote)/(branch).
As an alternative to merging, you can rebase the feature branch onto master branch. This moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
Fetch = update working copy (but not merge yet)
Pull (get latest) = Fetch + Merge
Push = Publish to Shared
emote-tracking branches are references to the state of remote branches. They’re local references that you can’t move; they’re moved automatically for you whenever you do any network communication. Remote-tracking branches act as bookmarks to remind you where the branches in your remote repositories were the last time you connected to them.
They take the form (remote)/(branch).
As an alternative to merging, you can rebase the feature branch onto master branch. This moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
No comments:
Post a Comment