Working with git

OpenHatch has a long history of helping contributors build existing and learn new skills. This document section has information that OpenHatch contributors have found useful when working with git. We encourage you to share helpful git resources by adding your favorites to this file and creating a pull request.
Git Commands What it does
git clone <repo> Used to clone the repo git clone <repo> | <name>
git commit Commit an applied change on the given branch
git remote Track a remote branch
git revert <commit-SHA-1> Revert changes in a commit
git fetch <remote> <branch> The git fetch command imports commits or tags from a remote repository into your local repo.
git pull
Updates your repo. Shorthand for git fetch followed by git merge FETCH_HEAD
Recommended to use it with –rebase.
git log
Lists commits made in the current branch of the repo. Check this.
Hacks: git log --pretty=format:"<%h> [%an] %d%Creset %s"
git rebase :
  • git rebase <base>
  • git rebase -i <base>
  • git rebase -i HEAD~NUM
  • git rebase -i bbc643cd^
  • git rebase --abort
  • git reflog
  • Rebasing is the process of moving a branch to a new base commit
  • Interactive rebase
  • Modifying to a head
  • Modify to specified commit bbc643cd
  • Abort a rebase
  • Tracks the changesets to the tip of branch

Issues with Pull Requests

Helpful tips for new contributors

  1. Get into OpenHatch workflow .

  2. Understand your problem first.

  3. Learn to go to a certain commit.

    • Tip: Each commit has a hash value(SHA-1) which is fixed. Switch to a commit.
  4. If you need to modify a single commit as requested by the maintainer in the pull request revert the old commit with a new commit and push it mentioning the changes you have made:
    • Tip: Please understand reset and revert . The ideal solution is to revert previous commit , edit it and push it for changes that are not published or force push it for changes that are published. You can also undo a commit and force push the changes made.
    • Note: Commits do not technically change when we force push the commit, reset or modify them. But the hash gets updated, and the new hashed commit gets tagged to that branch. You can easily find you previous commit(s) on github too just by adding /commit/<branch> to the repo address. It will show you the remote git log. See the hash get changed after rewriting the commit.
  5. Sometimes you have two or more commits on your pull request, which is usually not desired by maintainers. The solution is to do an interactive rebase and squash the previous N commits:
    • Tip: Please understand interactive rebase. Checkout the branch the pull request represents, count the number[N] of commits you need to squash from the pull requests or git log on that branch, then git rebase -i HEAD~N. N (number of commits before) is usually 2 if you want to squash 2 commits. Change pick to squash for all but one line. Save the configuration. Then force push the new commit git push -f origin <branch>.
  6. If you have unwanted commits attached to the pull request or history is broken then you need to do an interactive rebase :
    • Tip: It is better to tell others that you are having such problem as it needs rewriting history. Please understand rebasing and please see your logs. The solution is an interactive rebase Command: git rebase -i HEAD~N (N gives the number of the revisions up in that branch). Try to pick N carefully count the commits as maintainers will ask you to give the finalized result in a single commit.
    • The interactive rebase on that branch will show the commands that runs on that branch and finally shows on the pull request. Delete the commits you don’t need and keep the ones you need. Squash the needed commits to a single commit.
    • Note: Branches are technically a tagging system to commits that have a hash value, they are relative, even the master branch. It can operate with commands like squash, pick and many others. The commands are played from top to bottom on each commit and finally shown in the pull request. See the options.

Resolving Merge Conflicts

Conflicts are essentially two or more commits from different branches which overlap because they have different content on the same revision. Understanding Merge conflict, you can manually resolve it with git.
Tools like kdiff3 helps you pick that content of the commit which you want to get merged in the final commit. A tutorial on using kdiff3. Kdiff3 can be configured for all types of version control ranging from git, svn or mercurial.

Note: The merge conflicts can also be resolved with an interactive rebase.

Tips on Installing kdiff3

Ubuntu:

$ sudo apt-get install kdiff3

Mac:

$ brew install kdiff3

Configure kdiff3:

Recent Git versions have built-in support for kdiff3.

$ git config --global merge.tool kdiff3

This makes git mergetool launch kdiff3.

Note: We recommend that you refer to the kdiff3 documentation for the latest installation instructions.

Become a git Expert

If you like git a lot and use it often, use tools like git-extras and aliases to increase your productivity.

Alias

Saves you Keystrokes. These scripts are added to your .bashrc, .zshrc or any file you want to source. Open .bashrc on your favorite text editor. Follow the instructions.

Examples

alias gc="git commit -m "$1""

alias shortform="the longer version of the command"

git-extras

Get 40 extra commands that you may find helpful but are missing in git, i.e git-undo, git-summary, git-changelog, git-effort.

Installation

Ubuntu:

$ sudo apt-get install git-extras

Mac:

$ brew install git-extras

Usage

  • git-summary # gives the status of the hours and duration you are actually working on a git project.

  • git-effort # shows your file stats on the project.

  • git-undo # undo a git commit.

  • git-extras # shows the list of commands.