Git Manual

This post includes the general description of Git and its operations.

Git Intro

Version Control

Version control is a system that records and manages changes for a file or a set of file, so that you could later revert those changes if needed

Why Version Control

Many default version-control method of choice is to simply copy files into another directory, and renaming them somehow to keep track of the changes
however, this could be inconvenient and error prone

Solutions

One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today. RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.

Problem

The next major issue that people encounter is that they need to collaborate with developers on other systems.

Centralized Version Control Systems (CVCSs) were developed as a solution to the problem above. These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.

Advantages

everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what, and it’s far easier to administer a CVCS than it is to deal with local databases on every client.

Problems

If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything — the entire history of the project except whatever single snapshots people happen to have on their local machines.

Here Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

Advantages

you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.

Basic Conmmands

Getting Help

To get more information about a command in Git, use any of the three below:

$ git help <verb>
$ git <verb> --help

Getting a Git Repository

This can be done in two ways:

1. take a local directory that is currently not under version control and turn it into a Git repository
2. clone an existing Git repository from elsewhere

Then you will end up with a Git repo on your local machine.

• To achieve the first option:
  First, It is fatal to cd into the working directory

  $ cd [Your path]
  

  Then type:

  $ git init
  

  This creates a new hidden subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton. At this point, nothing in your project is tracked yet.

  To start version-controlling, you need to git add your file that you need to control, and then git commit

  $ git add yourFile1
  $ git add yourFile2
  $ git commit -m 'Initial project version'
  
  

• To achieve the second option, for example, a project you’d like to contribute to — the command you need is git clone, so that Git receives a full copy of nearly all data that the server has

  git clone <url>

Checking File Status

The main tool you use to determine which files are in which state is the git status command.

For example,

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

A clean working directory means none of your tracked files are modified.

Difference between git add and git commit

Q: why add and commit as two functions? They seem to be two repeated checkpoint procedures.

• The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn’t really affect the repository in any significant way—changes are not actually recorded until you run git commit.

The command git commit takes all changes in the Staging Area, wraps them together and puts them in your Local Repository. A commit is simply a checkpoint telling git to track all changes that have occurred up to this point using our last commit as a comparison. **After committing, your Staging Area will be empty.

Display the Modifications

By just executing git diff will compare what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.

For example:

$ git diff
warning: LF will be replaced by CRLF in firstFile.txt.
The file will have its original line endings in your working directory
diff --git a/firstFile.txt b/firstFile.txt
index 640bb73..caada99 100644
--- a/firstFile.txt
+++ b/firstFile.txt
@@ -1,3 +1,5 @@
 hello
 hello
 hello
+
+aa

The + and +aa lines in the end means those are the lines added to the file, but not being staged yet.

Committing Changes

Now if you want to commit to those changes, you can execute git commit. However, this will only commit changes that are staged, so modified yet unstaged changes will not be recorded.

After executing git commit, it will bring up your editor of choice, which can be chosen when you setup your Git.

For example:

$ git commit
[master 2031fb7] first commit made
 4 files changed, 11 insertions(+)
 create mode 100644 LICENSE.txt
 create mode 100644 README.md
 create mode 100644 justTracked.txt

Removing Tracked File/ Untracking File

If you want to remove a tracked file, meaning you want to delete the file, you need to execute git rm yourFile. This will:

• remove the file from the current working directory
• remove the file from the staging area

Now, the next time you commit, it will be no longer tracked by Git since it will be completely removed.

Now, same as before, you will still need to execute git commit to complete the removal from the Git

Changing/Undoing your Commit

If you want to revert the file to its previous committed state (you cannot revert to those added state), you have several options to do. You could:

• Run git restore <file>. In fact, this is also adviced by the command git status if the file is in the unstaged area. It is usually used for restoring files in the working tree from either the index or another commit. This command does not update your branch.

• Run git reset <commit-id> is about updating your branch, moving the tip in order to add or remove commits from the branch

• Run git revert which creates a new commit that undoes the changes from a previous commit. This command adds new history to the project (it doesn’t modify existing history).

Run git checkout <commit-id>. This is the most conservative and prefered by myself. It first move the HEAD to that commit, so that you can view changes at that point. However, this will make the HEAD DETACHED, because it does not follow any branch (in fact, Git will create a temporary branch for you, which will disappear once you switch to other branches), which means that if you do some changes here, they will not be visible once checkout to other branches. Therefore, now you will need to run git branch -b <yourBranchName> to create a branch and attach this DETACHED HEAD to that branch. Now, everything will be saved if you move around and switch bewteen branches.

Working with Remotes

To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. Managing these remote repositories involves pushing and pulling data to and from them when you need to share work.

To show the remote server for repo in the current directory, you can execute git remote, or git remote -v to see the URLs stored as well.
To add a remote server, you can execute git remote add <shortname> <url>, which will configure the shortname/nickname for that repo. Then you can use that shortname to access that repo.

Pushing/Sharing to Your Remote

When you have your project at a point that you want to share, you have to push it upstream. The command for this is simple: git push <remote> <branch>. If you want to push your master branch to your origin server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you’ve done back up to the server:

$ git push origin master

Git Branching

Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots. Thus, When making version control, git can creat branches to work on multiple jobs simutaneously.

When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.

Creating a new branch means creating a new pointer for you to move around. Let’s say you want to create a new branch called testing. You do this with the git branch command:

$ git branch <newBranchName>

To switch to an existing branch, you run the git checkout command:

$ git checkout testing.

This will move the head to the new branch you are at. This means that now, if you make modifications and commit, you will create a new commit object that the head/your current branch points to, but the other branch still points to the original commit object.

However, if you have made some changes in this new branch and switched back to the old branch, your current working directory will be reverted back to the snapshot that old branch points to. Now, if you make some changes on the old branch, the two branch will diverge:

• the new branch does not know that change made in the old branch
• the old branch cannot go forward directly to the new branch because a commit object that both shared has been changed now
• basically, you will have two different commit objects, one for the old branch, and another for the new branch, both links to the same parent.

Merging Different Branches

1. You have two diverged branches, but they used different files, or, to put it more suggestively, the file they shared are the same. In this case, it is simple for Git to figure out how to merge (basically just putting all the files together), and you run:

Merging Case

$ git checkout master
$ git merge testing

Branch Management

There are a handful of commands with git branch that is useful for branch management:

• git branch This will show you a list of branches that yuo have, with an asterisk * in front of the current branch you are on.
• git branch -v Shows you a list of branches with their last commit message
• git branch --merged shows you branches that have been merged
• git branch --unmerged shows you branches that have not been merged

Typical WorkFlow Using Git Branches

Usually, people tend to put code that is entirely stable in their master branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into master.

In general, for some larger projects, you will want your branches are at various levels of stability, ordered from most stable top branch (master) to the least stable bottom branch(topic, for example); when they reach a more stable level, they’re merged into the branch above them.

Pushing Your Branch to the Server

Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on.
To realize this, you can run:

$ git push <remoteShortName> <yourBranchName>

For example, you want to push up a branch serverfix to the server with shortname origin, you run:

$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
 * [new branch]      serverfix -> serverfix

Difference between git fetch and git pull

git fetch only gets you information on what their progess is, but does not have a physical copy of their work. git pull gets you both the information about their progess and a physical copy on your local machine of their work on server.

git pull is essentially a git fetch immediately followed by a git merge in most cases. If you have a tracking branch set up as demonstrated in the last section, either by explicitly setting it or by having it created for you by the clone or checkout commands, git pull will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch for you.

Viewing the Current Tracking Branch

$ git fetch --all
$ git branch -vv
  iss53     7e424c3 [origin/iss53: ahead 2] Add forgotten brackets
  master    1ae2a45 [origin/master] Deploy index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it
  testing   5ea463a Try something new

So here we can see that:

• iss53 branch is tracking origin/iss53 and is “ahead” by two, meaning that we have two commits locally that are not pushed to the server.
• master branch is tracking origin/master and is up to date.
• serverfix branch is tracking the server-fix-good branch on our teamone server and is ahead by three and behind by one, meaning that there is + one commit on the server we haven’t merged in yet and three commits locally that we haven’t pushed.
• testing branch is not tracking any remote branch.

Deleting a Remote Branch

Suppose you’re done with a remote branch — say you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable codeline is in). You can delete a remote branch using the:

$ git push <remoteShortName> --delete <remoteBranchName>

• This operation does not remove the branch in the server immediately. All this does is remove the pointer from the server. The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it’s often easy to recover.

Recording Changes

Typically, you’ll want to start making changes and committing snapshots of those changes (i.e. recording/saving those changes) into your repository each time the project reaches a state you want to record.

As you edit files, Git sees them as modified, because you’ve changed them since your last commit. As you work, you selectively stage these modified files and then commit/save all those staged changes, and the cycle repeats.

• Note
  • Not all files under the directory will be tracked, and only tracked files will Git know about
  • once you git add to start your file to start tracking. Then it will be snapedshotted if you then call git commit