Cheatsheet — Git & GitHub

Using Git Bash

Note: The tips below are tested under MS Windows.

Cloning

• Using HTTPS

  With the HTTPS connection you will be prompted for your GutHub credentials when you clone, pull and push.

    git clone https://github.com/telerik/ajax-docs.git 
  

• Using SSH

  As for SSH, you should create an SSH key and add it to your GitHub account. More detail are available in this GitHub article—Generating SSH keys.

    git clone [email protected]:telerik/ajax-docs.git
  

Generating SSH Keys

Information about that is available in this GitHub article—Generating SSH keys.

If there are complication head to the GitHub troubleshooting article on the matter—Error: Permission denied (publickey).

However, you can follow this steps to generate an SSH key:

1. Generate a file with your ssh key (passphrase is optional, although, recommended):

    ssh-keygen -t rsa -C "[email protected]"
   

2. Add your new key to the ssh-agent:

   1. Start ssh agent:

       ssh-agent -s
      

      or

       eval "ssh-agent -s"
      

      or

       eval "$(ssh-agent)"
      

      Tip: On my end, the eval "ssh-agent -s" and eval "$(ssh-agent)" always do the job.

   2. Add the key to the ssh agent:

      The file generated is available in the root folder, where GitBash has been started. Therefore, you need to use this file.

      Note: The generated files are two - [FileName] and [FileName].pub.

      	ssh-add [FileName]
      

      or

      	eval "ssh-add [FileName]"
      

3. Add your ssh key to your GitHUb account:

   1. Remember the generated [FileName].pub file? Use the following command to copy the ssh key to your clipboard:

       clip < [FileName].pub
      

   2. Head to your GirHub account;

   3. Go to settings ;

   4. Go to SSH Keys section;

      

   5. Press the Add SSH key button—

   6. A form will appear below, type a title and paste the key in the textarea below:

      

   7. Add the key by using the green Add key button below.

4. Test the connection

    ssh -T [email protected]
   

Stage Files

Staging is used to prepare a commit or a stash.

• Staging all changes:

    git add -A	
  

  or

    git add --a
  

• Staging a file:

    git add filename.ext
  

  Tip: With Tab key GitBash will list all files and folders available for staging.

• Staging an entire folder (and all file within):

    git add controls/ajax/
  

Now, you can either commit or stash the staged files.

Committing

When adding a new commit—new pointer is added in the HEAD of the local repository.

git commit -m "description"

Stashing

Stashing is useful for preserving changes made locally. By using stash, changes are not added neither to a commit, nor to the remote, but they can be restored.

• Saving files into the stash:

    git stash
  

• Seeing the available stash item:

    git stash list
  

• Showing files in stash

    git stash show 
  

  or

    git stash show stash@{0}
  

• Getting the last saved stash:

    git stash pop
  

  or

    git stash apply
  

• Getting files from a certain stash item:

    git stash apply stash@{0}
  

Pull with Re-base

Pulling from a remote without a --rebase procedure may cause a branch to appear in the history. That happens because the default pull command triggers a merge procedure. See the figures below.

Important: If there are changes that have not been staged, committed or stashed, Git will not let you to pull. To resolve that you can either commit the changes or stash them.

---

Figure 1: Result of a merge procedure

git pull origin master

---

Figure 2: Result of a re-base procedure

git pull --rebase origin master

---

Pulling from a remote may lead to a conflict, when a file changed on your end has been committed by someone else before your push.

Due to that, you are forced to resolve the conflict. When that happens, the re-base is paused. This is indicated in Git Bash—.

Start a resolve conflict procedure to merge changes, and eventually, commit them. After that, you should continue the re-base procedure:

git rebase --continue

Resolving Conflicts

Resolving a conflict is preferred to be done by using an external diff tool, e.g., meld, tortoisemerge, kdiff3 etc. You can configure globally which tool to be used for resolving conflicts. This option is well explained here—External Merge and Diff Tools.

Here is showcased how to resolve conflict without global configurations:

1. First, see which tools are available (you can update the list by installing more diff tools):

    git mergetool --tool-help
   

   A list in Git Bash will appear:

   

2. For example, you want to use tortoisemerge, you should use the following command

   git mergetool --tool=tortoisemerge

3. The procedure will start automatically, and the tool will appear to finalize the file.

   Note: A new file may appear in the root of the repository—[Filename.ext].orig. This file is a backup copy, you can delete it to make sure it is not pushed into the remote.

4. Stage the changes again, and if needed add a new commit.

Pushing Commits

When you are ready with the changes, that are committed locally, you can push them to the remote.

Important: Always make sure a pull --rebase is done before a push.

git push origin master