Begin using Git

Installation and Configuration

• First thing first, you can easily install Git on all 3 mainstream OS, Windows, Linux, OSX.

  Get Windows Installer on https://git-for-windows.github.io/.

  Note in Windows, the official Git tool is called "Git for Windows" as well as msysgit. They ' re aimed at the same thing.

• git provide a command tool named git Config for environment configuration.

You should configure some basic information with least for better using experience.

Editor & Merge tool would be need other stand alone tools, e.g. Gvim, KDIFF3, etc.

Here we don't configure external editor but get the kdiff3 right here Http://sourceforge.net/projects/kdiff3/file S/latest/download?source=files.

• User Information

  $ git config--global user.name "John Doe"

  $ git config--global user.email [email protected]

• Editor

  $ git config--global core.editor gvim

• Merge Tool

  Say we ' re using KDIFF3 in Windows for Comparison and Merge branch.

  $ git config--global merge.tool kdiff

  $ git config--global mergetool.kdiff3.path "Your path to Kdiff3.exe"

• Ps:the configuration could be list using below commands:

  $ git config--list

  Or If you need to check the value of a configuration, use:

  $ git config user.name

• as sometimes you'll need to clone a remote repository, and your ' re trying to use the SSH in for remote operations. It ' s time for some SSH stuffs.
  • Check whether your SSH keys exists:

    $ ls ~/.ssh

    There should is text files similar to below, which contains the public key & end with your email.

    id_dsa.pub

    id_rsa.pub

  • Generate your new SSH keys:

    $ ssh-keygen-t rsa-b 4096-c "[email protected]"

  • Ensure Ssh-agent is enabled:

    # Start the ssh-agent in the background
    $ ssh-agent-s
    # Agent PID 59566

  • Add your SSH key to the ssh-agent:

    $ Ssh-add ~/.ssh/id_rsa

  • Add your SSH key to your account, copy the whole public key and paste to your remote Git repository server such as GitHub, GitLab, etc.

    $ clip < ~/.ssh/id_rsa.pub

  • Ps:this ssh-to-your private key to identify your user information, it is used when the repository URL happened to Be something similar to git://example.com/repo.git.

Dance at local

• Initialize a new Git repository or clone a remote repository
  • Initialize locally

    Change directory to your local project and then:

    $ git init

    $ git Add *.cpp

    $ git Add README

    $ git commit-m ' initial project version '

  • Clone Repository

    $ git clone git://github.com/example/project.git [directory name]

    This would create a directory using your [directory name] or the remote project name (If no directory name specified).

• Git Status

  There ' re 3 different status here includes changed, staged, committed.

  • untracked

    By default, if you create, modified some files in your local repository, these files would get a untracked Status, nothing is the record in the Stage area.

      

    $ gvim README

    $ git status

    # on branch master

    # untracked files:

    # (use "git add <file> ...." To include in what'll be committed)

    #

    # README

    nothing added to commits but untracked files present (use "Git add" to track)

      

  • Stage

    Now your re going to track & Stage These files and you can use git add to finish this.

    These files would be committed together if you commit your changes next time.

      

    $ git add README

    $ git status

    # on branch master

    # Changes to be committed:

    # (use "git reset HEAD <file> ..." to Unstage)

    #

    # new File:readme

      

    Note that you can use Git diff to compare your changes all the time.

    $ git diff

    This would compare your unstaged file with the your staged area.

      

  • Commit

    You ' re-ready-to-finish a period of development, now let's get a version of clean and ready.

      

    $ git diff--staged

    This would compare your staged changes with the last time you committed.

      

    $ git commit-m "Example message"

    If all the needed files were tracked already and then you can also use below command to commit your changes directly Witho UT Stage files:

    $ git commit-a-M "Example message"

      

• remove files
  • to Remove files from git, and you'll need command to Comple Te this task. This is because your file records were in the staged area, and this command would help you to remove it from the Stage area .

    After deleting files, the status would become "Changed but not updated".

      

  • then your can use:

    $ git rm filestoberemoved

      

  • to just untrack some files and not remove them, you can use:

    $ git rm--cached filestobeuntracked

    Aft Er, you can just add the missing rule to the. gitignore file.

      

  • Glob could also be used, note the \ symbol would help to achieve this feature recursively:

    $ git rm \*.log p>

      

• Rename files
  • Using git MV

    $ git mv filename1 filename2

  • Using git rm & git Add, this is important if you ' re renamed some files already but haven ' t yet remove the records in Git stage area.

    $ mv README.txt README

    $ git rm README.txt

    $ git Add README

• Amend the last Commit
  • Using--amend param, the last commit is together with the new operations.

    $ git commit-m ' initial commit '

    $ git Add forgotten_file

    $ git commit--amend

  • Unstage File & Discard changes:

    $ git reset HEAD benchmarks.rb

    # Changes to be committed:

    # (use "git reset HEAD <file> ..." to Unstage)

    #

    # Modified:README.txt

    #

    # Changed but not updated:

    # (use "git add <file> ..." To update what would be committed)

    # (use "Git checkout-<file> ..." to discard changes in working directory)

    #

    # MODIFIED:BENCHMARKS.RB

    #

    Firstly the file benchmarks.rb is to is committed just like the README.txt above, but now it become a unstaged file which needed other steps.

  • You can add it back to staged status or checkout to discard the changes.

    $ git checkout--benchmarks.rb

    However, this is a dangerous command because it would really discard your changes, unlike some more friendly commands, i.e. stashing.

Remote Repository

• Show me the verbose

  $ git remote-v

  #origin Git://example.com/project.git

  #peter Git://hello.com/project.git

  #lan//dell-pc/d/path/project.git

• ADD Remote Repository
  • Using git remote Add to configure a new repository.

    $ git remote add alias Git://github.com/paulboone/ticgit.git

    Once you has your remote repositories, you can specify you'll choose which repository to fetch data:

    $ git fetch Peter

    Unpacking objects:100% (44/44), done.

    From Git://github.com/paulboone/ticgit

    * [New branch] master, Peter/master

    * [New branch] Ticgit-Pter/ticgit

• Push local commits to remote repository
  • This was a straight forward command, if the branch doesn ' t exist in remote, the new branch would be created automatically:

    $ git push [remote-name] [Branch-name]

Branch Model

The widely used part in Git. Efficient, Clear, and works great.

• Create a new branch

  $ git Branch Testing

  • In your local, there's always a HEAD pointer point to a specified version of your working branch. That is:

  • As the image says, Master & testing were the branches exist. HEAD now point to master. Because git branch won't change the working branch anyway.

  • Now your ' re going to check out the new branch for working:

    $ git checkout Testing

    The HEAD pointer has been redirected. And now the checkout command is used to switch branches, instead of discard changes.

  • After switch and commit different things in both branches, they might look like:

    This model explains why we should use Branch to control our development, and how easily it's to use.

• Basic workflow of development based on Git

1. Firstly you ' ve decided to work on a new feature or a bug fix, say #iss53.

   $ git Branch iss53

   $ git checkout iss53

• Now you have the below model look like:

1. Some work has been done and the progress moved on:

   $ git commit-m "Add something"

2. But there ' re some urgent fix should is done now, you'll switch back to complete the hotfix:

• $ git Checkout Master

• $ git Branch Hotfix

  $ git Checkout Hotfix

  #Switched to a new branch "hotfix"

  When the hotfix have been committed, it looks like:

1. now we merge the hotfix to master and push it to remote server:

2. Thin GS were moving smoothly and the hotfix can be deleted safely, and the iss53 could be keep developing again.

   $ git branch-d hotfix

   #Deleted Branch Hotfix (3A0874C).

   $ git checkout iss53

   $ git commit-m "other features"

3. when the iss53 have been finished, just merge the iss53 into master:

   $ git checkout master

   $ git merge iss53

     

     

   Even though the process of merge is different from the hotfix one , the git decided how to merge these-branches itself. Finding the Common ancestor, merge the commits, and create a new commit (which is a special commit named "Merge Commit"). /p>

     

• What if there ' re conflict occurred when merging? At the moment, all the conflict files would be listed as "unmerged files".

    

  $ git mergetool

  merge tool candidates:kdiff3 Tkdiff Xxdiff meld Gvimdiff Opendiff emerge Vimdiff

  merging the files:index.html

  normal merge conflict for ' index.html ':

  {local}: Modified

  {remote}: Modified

  hit return to start Merge Resolution tool (OPENDIFF):

    

  After that, the status would become modified again and could is committed now.

    

1. Actually, you can also merge the Master branch to your #iss53 anytime, if other ' s important changes is needed. And then push the local branch to the remote repository, create a merge request. Waiting for someone who have a write access right to merge your branch into master. This is a acceptable workflow as well.

   $ git checkout iss53

   $ GIT fetch origin

   $ git merge origin/master iss53

   $ GIT push origin iss53

   This kind of process could is completed easier via rebase:

   $ git checkout iss53

   $ git rebase Master

   $ GIT push origin iss53

   The rebase command would generate a clearer development history:

• Tracking Branch
  • A local branch checkout from remote server is called a tracking branch.

    $ git checkout-b localfix origin/serverfix

    Branch Localfix set up to track remote Branch refs/remotes/origin/serverfix.

    Switched to a new branch "Localfix"

    The branch name can be a same as branch on server side.

    $ GIT push origin serverfix:localfix or

    $ Git push Origin serverfix (if the name were the same)

Begin using Git