Jump to navigationJump to search



Stage and Add are the same.

git add <filename>  
 git status
 On branch mediatorLogging
 Your branch is up to date with 'origin/mediatorLogging'.

nothing to commit, working tree clean
gitk GUI version - for the current branch

gitk --all GUI version showing everything we know about (locally)

git diff --staged   <-- see what changes we have made locally (pre-commit)
git commit 
git diff HEAD <-- see what changes we have committed (but not pushed)
git push

Note: Tags are not explicitly pushed by default Local change history

git reflog

Repository change history

git log

A change to an existing commit (that has not been pushed)

git commit --amend

Local Changes vs Repo

git log origin/master..HEAD

You can also view the diff using the same syntax

git diff origin/master..HEAD

Diff between the current branch and develop (origin of this branch hopefully) aka diff source and then current branch

git diff develop..feature/[branch_name]

If working in master (no branches used)

git diff origin/master...HEAD

Wipe all local changes and get the latest from the repo

git reset --hard        or       git checkout -- <file name>
git rebase origin/master

Or to store changes and re-apply them after pulling

git stash
git pull
git stash pop

Note opposite of push is fetch, Pull does fetch + local merge

git push origin master
git merge origin/master


Existing Branch

$ git checkout --track origin/blah

New Branch

$ git checkout -b feature/myFeature origin/dev

Creates MyFeature branch off dev. Do your work and then

Create branch y from x

git branch y x

Remember to checkout the new branch

Remember to push the new branch back to origin

git push origin feature/y

Set the upstream repo

git push --set-upstream <remote> <branch>


Ensure the following are selected:

  • Delete source branch when merge request is accepted
  • Squash commits when merge request is accepted

$ git checkout -b myFeature dev

Creates MyFeature branch off dev. Do your work and then

$ git commit -am "Your message"

Now merge your changes to dev without a fast-forward

$ git checkout dev
$ git merge --no-ff myFeature

Now push changes to the server

$ git push origin dev
$ git push origin myFeature

Merge another branch upto a particular commit

git merge <id of commit>

Cherry pick a single commit and merge it

git cherry-pick <id of commit>

Merging Branches

Submitted a merge request - and it comes up with - this branch is x commits behind target_branch.

Gitlab helps you by showing how much the version of the branch you updated is behind the remote branch.

Being behind will not set any hindrance to the act of merging, but it is a common practice to rebase your commits on top of the branch your merging into. This will make your merge request updated by putting your commits chronologically after the ones that already are in that branch. That approach makes the work of the person responsible for the merge easier because the commiter himself has already resolved any conflicts that would have happened.

To do a rebase following the scenario you proposed would be like this:

  1. Add a remote named `upstream` pointing to the original repository

git remote add upstream

  1. Fetch the latest commmits from `upstream`

git fetch upstream

  1. Checkout our branch-A

git checkout branch-A

  1. Rebase our branch on top of the `upstream/develop` branch

git rebase upstream/develop

  1. If needed fix any conflicts that may have appeared and then `git rebase --continue`
  1. Push the changes to the branch of your merge request

git push --force origin branch-A

Rebase and Squash

git rebase --interactive origin/develop   <--- where to rebase to - where are we going to re-start this branch from

# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
# These lines can be re-ordered; they are executed from top to bottom.
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
# Note that empty commits are commented out

then need to push this to the remote

git push --force origin feature/branchname

Split a commit

git rebase --interactive origin/develop

Change the commit to e for edit

git reset HEAD^    some say git reset HEAD~     
git diff

commit the single change as many changes

 git add xyz
 git commit 
git rebase --continue

Deal with any Merge conflicts due to the order of things being changed potentially

git push --force origin feature/feature_name

Standard Workflow

  • Branch from develop
  • Work in Branch
  • Rebase branch against remote/develop
  • Merge Branch into Develop - Squash Commits, Delete Branch
  • Merge Develop into Production (Production will be x commits ahead as it has all the dev->prod merges that develop does not have)

Less Common

Revert a commit

This adds a new commit which undoes something from the past, history is not-rewritten!

git revert [commit_id]

Forking to pull workflow

Updating a forked repo

git remote add upstream

$ git fetch upstream
remote: Enumerating objects: 62, done.
remote: Counting objects: 100% (62/62), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 85 (delta 56), reused 60 (delta 54), pack-reused 23
Unpacking objects: 100% (85/85), done.
 * [new branch]      develop    -> upstream/develop
 * [new branch]      master     -> upstream/master

git checkout master     <---- go into master -- we will merge something into here.
git diff HEAD..upstream/master <--- see what we are missing
git merge upstream/master   <---- merge this into the branch we have checked out

Make the forked repo match the origin

Blow away everything local + what is in our 'remote' repo

git remote -v
git fetch upstream
git fetch upstream

find the commit we want to sync to

git reset --hard cb0034d6a
git push --force origin

Update a Forked Repo using the Web GUI only!

N.B this will cause there to be an additional pull in the local repo - thus will be one commit ahead of the original

  • Open Repo
  • Select compare
  • Change Base Fork to your repo (aka the copy)
  • Change the head Fork to the upstream repo (aka the original)
    • There should be a list of commits
  • Create a Pull Request (this goes to your repo for you to approve)
  • Merge and have a beer

Disaster has struck

Rollback the last change (merge, commit) locally

git reset --hard HEAD~1

If the branch has been rebased (by someone else) and pushed to origin - blow away our version of the world git reset --hard origin/branch

Find what commit made something break

git bisect

Install meld - then its used if there is a non-ff merge where humans are required.

git mergetool

Reset local repo to match upstream/origin git reset --hard origin/feature/branch