- Merging branches is much simpler in Git. You can think of branches as alternate timelines (or alternate universes).
- It’s much easier to keep stable work and work in progress, separate.
- Git separates the act of committing new code from the act of inflicting it on everybody else. I.e., you can commit your changes locally, but the rest of the team won’t see them until you Push your changes up to Origin.
- If you’re used to having one big gigantic repository for the whole company, where some people check out and work on just the subdirectories that they care about, this isn’t a very good way to work with Git—you’re better off having lots of smaller repositories for each project.
- There is no central repository, only an agreed-upon funnel-point (a remote repository named Origin).
- Git doesn’t use the concept of Revisions. Instead, it uses the concept of Changesets (also known as commits).
- A commit is a snapshot of the state of a branch. as it existed at a particular point in time.
- Like a commit, a branch is a version of a repository, but it contains an alternate lineage of commits that differ from that of master (it diverges from master).
- A commit is identified by a hash of its contents, and the resulting hash code (a forty digit hex value) becomes the symbolic reference – its “Reference ID”.
- So for example, when you edit a sentence in a text file within a particular branch, not only have you altered that one file, you’ve also altered the entire branch.
- When you Commit the change, a new hash code is generated (based on the new hash of the branch snapshot), and that hash code becomes the unique identifier for that set of changes (well, one change in this case). A changeset generally contains more than just one change to one file. In practice, you hold-off on “Committing” until you’re done making a series of related changes. E.g., updating all topic source files with the revised ordering of JSON nodes with the JSON dictionary returned in responses (in the Examples section of each topic).
- Commits also contain a back-pointer to the previous commit. Such recursive linking turns your set of commits into a linked list (a directed graph). Viewed as such, this link information represents the lineage of your branch. It allows you to see the entire history of your branchy all the way back to its beginning (where it diverged, and ultimately – when it was cloned).
- It also allows you to identify where in the lineage a particular change was introduced, and it allows you to revert back to any branch state.
- Git allows you to use a short form of the hash to specify a commit. The convention is to use the first six digits, but you can use less if you project is small. E.g., you can use 48b217 to refer to 48b2179994d494485b79504e8b5a6b23ce24a026.
- The “current version” of your repository is always the latest commit (the one that the HEAD reference points to), and the hash of it is always placed at the end (the tip) of the linked list.
- HEAD is a symbolic reference to (the Reference ID of) the commit at the end of the branch. It identifies what the current repository is pointing to. It marks the branch that is advanced with the next commit.
- The command ‘git branch’ displays a list of branches in your repository, and it marks the current branch with an asterisk next to its name.
- Creating new branches in Git is much simpler than in centralized version control systems. Branching is encouraged in Git – because it’s built on a very simple concept. To create a new branch in Git, you simply add a new branch label to the commit that HEAD point to.
- You can switch to any branch just by changing the commit that HEAD points to, to point to the commit with that branch label. In Git, you use the git checkout command to switch branches (which is confusing for CVCS users because checkout doesn’t mean what they’re used to).
- In Git, you’re encouraged to create branches way more often than in centralized VCSs. As a result, you can think of Git branches as throwaway changesets.
- The default branch is called master.
- You synchronize your repository with a remote repository using git push and git pull. You use push to update the remote repository with your latest bits, and you use pull to update your repository with the remote repository’s changes. Either way, when you’re done, both repositories contain the same thing (assuming you pulled first).
Note: For this reason, always pull before you push.
- If you clone an existing repository, then a remote named Origin is automatically set up for you. You keep up-to-date with what’s happening on the remote repository by executing git pull origin. “Origin” is the name of the default remote, but you can have many remotes per repository. E.g.,
git remote add github http://github.com/alblue/babel.git
git push github
- Git allows you to “Commit” files, much like any other version control system. Each commit can be a single file, or many files; and a message goes along with it.
- Unlike other VCS’s, Git has a separate concept of a staging area, or Index. When you want to track a file (i.e., add it to the repository), you stage it (i.e., add it to the index). In other words, when you stage a file (or files), you can then commit them to the respository. The index contains a set of files to be committed. You can think of it as an active changeset; as you’re working on multiple files, you want only some changes to be committed as a unit. First, you git add the files to the Index, then you git commit subsequently.
- git add – to add untracked files for change tracking, and to update already staged files.
- git commit – commits the staged files. Creates a commit object, and adds it to the graph.
- You have to git add a file in order for it to be tracked. After you add it to the staging area, you can keep working on it – you just have to continually save it to the file system. When you’re finished with the file, you can then commit it. Once committed, you can then push it up to the origin repository.
- When you run git fetch, you get the newest commits from Origin, but they are not merged into your current branch. Just the remote refs are updated. I.e., all of the remote branches are updated in your local repository.
- git fetch followed by git merge = git pull
- A fast-forward is the simplest kind of merge (i.e., with no conflicts). It just brings your branch up-to-date with the same branch on a remote repository (origin). All it does is download the changesets that exist on the remote, that don’t exist in your repository, and then it updates your “HEAD” to point to the new branch tip.
- Rebasing simplifies the repoisitory tree structre. It replays a series of commits upon a specified commit. ‘git rebase’ – Reapplies a series of changes from a branch to a different branch, and resets the head of that branch to the result. Rebasing replants your tree – but do it on local branches only!