Git Keeps track of changes (especially text changes). Thus it is considered as a Version Control System (VCS) and used as Source Code Management (SCM).

• short single-line summary (less than 50 characters)
• optionally followed by a blank line and a more complete description
• keep each line line less than 72 characters
• write commit messages in present tense, not past tense
• bullet points are usually asterisks or hyphens
• can add "ticket tracking numbers" from bugs or support requests
• can develop shorthand for your organization

The first solution with saving commit history - https://help.github.com/articles/syncing-a-fork/

Another one: Source: http://stackoverflow.com/questions/7244321/how-do-i-update-a-github-forked-repository

# Add the remote, call it "upstream":

git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

# origin is a forked repo
# update 
git push -f origin master

"A lot of answers end up moving your fork one commit ahead of the parent repository. This answer summarizes the steps found here which will move your fork to the same commit as the parent."

1. Change directory to your local repository.

• Switch to master branch if you are not git checkout master

2. Add the parent as a remote repository, git remote add upstream <repo-location>
3. Issue git fetch upstream
4. Issue git rebase upstream/master

• At this stage you check that commits what will be merged by typing git status

5. Issue git push origin master

List your settings:

git config --list

git config --system
/etc/gitconfig # Unix
Program Files\Git\etc\gitconfig # Windows

git config --global
~/.gitconfig # Unix
$HOME\.gitconfig

my_project/.git/config

git config --global user.name "Ilya Khadykin"
git config --global user.email "[email protected]"
git config --global core.editor "subl"
git config --global color.ui true
git config --list

git commit -m 'Short summary of your changes`

git log

One of the most common ways I use relative refs is to move branches around. You can directly reassign a branch to a commit with the -f option.

^
git checkout master^
git checkout HEAD^

~
git branch -f master HEAD~3

Branches are pointers to a specific commit

branch early, and branch often

Create a new branch:

git branch [branch_name]

Switched between branches:

git checkout [branch_name]

Create a new branch AND check it out at the same time, you can simply type:

git checkout -b [your_branch_name]

Merging in Git creates a special commit that has two unique parents. A commit with two parents essentially means "I want to include all the work from this parent over here and this one over here, and the set of all their parents."

git merge [branch_name]

Don't forget to switch to right branch first!

There are two primary ways to undo changes in Git:

• one is using git reset and
• the other is using git revert

git reset reverts changes by moving a branch reference backwards in time to an older commit. In this sense you can think of it as "rewriting history;" git reset will move a branch backwards as if the commit had never been made in the first place.

git reset HEAD~1

While reseting works great for local branches on your own machine, its method of "rewriting history" doesn't work for remote branches that others are using.

In order to reverse changes and share those reversed changes with others, we need to use git revert.

git revert HEAD

git cherry-pick is a very straightforward way of saying that you would like to copy a series of commits below your current location (HEAD).

Git cherry-pick is great when you know which commits you want (and you know their corresponding hashes) -- it's hard to beat the simplicity it provides.

git cherry-pick <Commit1> <Commit2> <...>

Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else.

git rebase [branch_name]

All interactive rebase means is using the rebase command with the -i option.

If you include this option, git will open up a UI to show you which commits are about to be copied below the target of the rebase. It also shows their commit hashes and messages, which is great for getting a bearing on what's what.

For "real" git, the UI window means opening up a file in a text editor like vim.

When the interactive rebase dialog opens, you have the ability to do 3 things:

1. You can reorder commits simply by changing their order in the UI
2. You can choose to completely omit some commits. This is designated by pick -- toggling pick off means you want to drop the commit.
3. Lastly, you can squash commits.

git rebase -i HEAD~4

1. Find out base for future rebase:

git merge-base  your local_branch remote_repo_name/master
> c0faaea49f90484d0bc99e02fcf9da204e2819ac

2. Use given commit hash in the following command:

git rebase -i HASH

3. Perform rebase:

git rebase remote_repo_name/master

4. Resolve conflicts and finish rebase by:

git rebase --continue

5. Push your changes:

git config --global push.default simple
git push -f

Source: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request

HEAD is the symbolic name for the currently checked out commit -- it's essentially what commit you're working on top of.

HEAD always points to the most recent commit which is reflected in the working tree. Most git commands which make changes to the working tree will start by changing HEAD.

Normally HEAD points to a branch name (like bugFix). When you commit, the status of bugFix is altered and this change is visible through HEAD.

Detaching HEAD just means attaching it to a commit instead of a branch. This is what it looks like beforehand:

HEAD -> master -> C1

git checkout [commit_hash]

We can use the following commands:

• git rebase -i
• git cherry-pick

Our steps:

• We will re-order the commits so the one we want to change is on top with git rebase -i
• We will commit --amend to make the slight modification
• Then we will re-order the commits back to how they were previously with git rebase -i
• Finally, we will move master to this updated part of the tree to finish the level

echo "# ru-latinina" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/m-a-ge/ru-latinina.git
git push -u origin master

git clone https://github.com/m-a-ge/groovy.git --config "http.proxy=http://proxy.example.com:3129"

Check what settings are used right now:

git config --global --get http.proxy

Use the following command to change http proxy server:

git config --global http.proxy http://proxyuser:[email protected]:8080

Reset settings:

git config --global --unset http.proxy

If you using Git on Windows, make sure you selected 'Checkout as-is' during setup. Then make sure that you run: git config --global core.autocrlf false, so Git will not perform any conversions when checking out or committing text files.

Not doing so may bring issues on Windows with extra '/r' caret return symbols added to shell scripts make them not valid for unix shell.

git config --global core.autocrlf false

Credit: http://stackoverflow.com/a/35872606/3345737

git config --global http.sslVerify false

• Learn Git Branching