Author: Mikoy Date: 2018-02-04

1. The concepts of git:

• Git: Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.

• Git Space:

  • <font color="blue">Working Directory:</font> The working directory is the place where files are checked out.
  • <font color=blue>Staging Area:</font> The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well.
  • <font color=blue>Git Directory:</font> The Git directory is where Git stores the metadata(元数据) and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
    
    WorkFlow.png

• Files Status:

  • Committed means that the data is safely stored in your local database.
  • Modified means that you have changed the file but have not committed it to your database yet.

  • Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

    
    
    FilesStatus.png

• Common Commands:

  • <font color=blue>Comiit:</font> Commit holds the current state of the repository. A commit is also named by SHA1 hash. You can consider a commit object as a node of the linked list. Every commit object has a pointer to the parent commit object. From a given commit, you can traverse back by looking at the parent pointer to view the history of the commit. If a commit has multiple parent commits, then that particular commit has been created by merging two branches.
  • <font color=blue>Branch:</font> Branches are used to create another line of development. By default, Git has a master branch, which is same as trunk in Subversion. Usually, a branch is created to work on a new feature. Once the feature is completed, it is merged back with the master branch and we delete the branch. Every branch is referenced by HEAD, which points to the latest commit in the branch. Whenever you make a commit, HEAD is updated with the latest commit.
  • <font color=blue>Tag:</font> Tag assigns a meaningful name with a specific version in the repository. Tags are very similar to branches, but the difference is that tags are immutable. It means, tag is a branch, which nobody intends to modify. Once a tag is created for a particular commit, even if you create a new commit, it will not be updated. Usually, developers create tags for product releases.
  • <font color=blue>Clone:</font> Clone operation creates the instance of the repository. Clone operation not only checks out the working copy, but it also mirrors the complete repository. Users can perform many operations with this local repository. The only time networking gets involved is when the repository instances are being synchronized.
  • <font color=blue>Pull:</font> Pull operation copies the changes from a remote repository instance to a local one. The pull operation is used for synchronization between two repository instances. This is same as the update operation in Subversion.
  • <font color=blue>Push:</font> Push operation copies changes from a local repository instance to a remote one. This is used to store the changes permanently into the Git repository. This is same as the commit operation in Subversion.
  • <font color=blue>Head:</font> HEAD is a pointer, which always points to the latest commit in the branch. Whenever you make a commit, HEAD is updated with the latest commit. The heads of the branches are stored in .git/refs/heads/directory.

2.The Workflow of Github:

<font color="red">Step 1:</font> Getting a Git Repository

1. You can take a local directory that is currently not under version control, and turn it into Git repository.
   
   Initializing a Repository in an Existing Directory:
   
   Input Command: cd path, the path is project directory that is currently not under version control and you want to start controlling it with Git.
   
   Input Command: git init, it creates a new subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton.

2. You can clone an existing Git repository from elsewhere.
   
   Cloning an Existing Repository:
   
   If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone <url>. Such is like this:

   git clone https://github.com/MikoyChinese/HelloWorld
   

<font color="red">Step 2:</font> Recording Changes to the Repository

1. Checking the Status of Your Files:
   
   The main tool you use to determine which files are in which state is the git status. It looks like this:

   $ git status
   On branch master
   Your branch is ahead of 'origin/master' by 6 commits.
     (use "git push" to publish your local commits)
   nothing to commit, working directory
   

   If you creat a new file(eg: README.md), and you run git status, you will see your untracked file like so:

   $ git status
   On branch master
   Your branch is up-to-date with 'origin/master'.
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
   
       README.md
   
   nothing added to commit but untracked files present (use "git add" to track)
   

2. Tracking New Files:
   
   In order to begin tracking a new file, you use the command git add. To begin tracking the README file, you can run this:

   git add <files>
   

   If you wanna tracking a new folder, you can use the <path> instead of the <files>. Then, that will track all the files in your folder path.

3. Staging Modified Files:
   
   If you change a file(eg: README.md) that was already tracked and then you run git status command, you get something that looks like this:

   $ git status
   On branch master
   Your branch is up-to-date with 'origin/master'.
   Changes to be committed:
     (use "git reset HEAD <file>..." to unstage)
   
       new file:   README
   
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git checkout -- <file>..." to discard changes in working directory)
   
       modified:   README.md
   

   To stage it, you run the git add <file> command. git add is a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. And then you run git status command, you will see like this:

   $ git status
   On branch master
   Your branch is up-to-date with 'origin/master'.
   Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
   
      new file:   README.md
      modified:   README.md
   

4. Ignoring Files:
   
   Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file:

   # ignore all .a files
   *.a
   
   # but do track lib.a, even though you're ignoring .a files above
   !lib.a
   
   # only ignore the TODO file in the current directory, not subdir/TODO
   /TODO
   
   # ignore all files in the build/ directory
   build/
   
   # ignore doc/notes.txt, but not doc/server/arch.txt
   doc/*.txt
   
   # ignore all .pdf files in the doc/ directory and any of its subdirectories
   doc/**/*.pdf    
   

5. Committing Your Changes:
   
   Now that your staging area is set up the way you want it, you can commit your changes.

   $ git commit
   

   Git creates your commit with that commit message (with the comments and diff stripped out). The editor displays the following text (this example is a Vim screen):

   # Please enter the commit message for your changes. Lines starting
   # with '#' will be ignored, and an empty message aborts the commit.
   # On branch master
   # Your branch is up-to-date with 'origin/master'.
   #
   # Changes to be committed:
   #   new file:   README
   #   modified:   CONTRIBUTING.md
   #
   ~
   ~
   ~
   ".git/COMMIT_EDITMSG" 9L, 283C
   

   Alternatively, you can type your commit message inline with the commit command by specifying it after a -m flag, like this:

   git commit -m <Your commit message.>
   

6. Removing the Files:
   
   If you want to remove a file which is from your tracked files from git or in other words, remove it from your staging area. The git rm <file> does do that, and it means that it will remove the file from your working directory, and you can't see it anymore as an untracked file next time around. Then, if you run git rm, it stages the file’s removal(such as README.md):

   $ git rm README.md
   rm 'README..md'
   $ git status
   On branch master
   Your branch is up-to-date with 'origin/master'.
   Changes to be committed:
     (use "git reset HEAD <file>..." to unstage)
   
   deleted:    README.md
   
   

   If you want to keep the file in your working directory but remove it from your staging area. In other words, you wanna keep the file on your hard drive but not have git track it anymore. You can use the git rm <file> with --cached flag.

   git rm --cached <file>
   
   

7. Moving Files:
   
   Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later.
   If you want to rename a file in git, you can run the command something like this:

   git mv <file_frome/old_filename> <file_to/new_filename>
   

   However, this is equivalent to running something like this:

   $ mv <file_from> <file_to>
   $ git rm <file_from>
   $ git add <file_to>
   

<font color="red">Step 3:</font> Working with Remotes on Github

1. Configure your git remote:
   
   If you are the first time to use the git's remote function, you should configure your git such like this:

       git config --global user.name <Your Name>
       git config --global user.email <Your Email>
   

2. Showing Your Remotes:
   
   If you wanna show what remote your git repositories have, you can run git remote -v which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote.
3. Adding Remote Repositories:
   
   There are so many demonstrations which show you add remote called origin. But in fact, you would need add remote with yourself shortname you like.So you also can add remotes like this:

   git add remote <Shortname> <Repository_url>
   

4. Pushing to Your Remotes:
   
   When you finished your project and you wanna share it to github, you have to push it upstream. The command for this is very simple: git push <remote> <branch>, meaning that it will push your <remote> project upstream to <branch>. If you want to push your master branch to origin server, you can run like this:

   git push origin master
   

5. Checkout You branch:
   Sometime we want to work with other and noninterference, so that you can creat another branch to save new project coping from origin project, and another worker can checkout their branch to hisself work. The eg is like this:

   git checkout <new_branch>