Git like a BOSS !

mohuk

mohukh

Literally, like a BOSS !

  • Had the skill and a plan
     
  • Knew the possibilities
     
  • Trusted himself

Aim ...

  • Learn the skills and possibilities
     
  • Murder the GUI
     
  • Walkout like a BOSS !

Recap with CLI

  • clone
  • add
  • commit
  • push/pull/fetch
  • checkout
  • branch

Merge & Rebase

Brothers in arms

Merge

Joins the work done in 2 branches

No Fast Forward (no-ff)

Fast Forward

No FF

FF

FF

If no commits are made to the parent branch after the feature was branched off

 

HEAD is moved ahead by the number of commits in the feature branch

No FF

If commits are made to the parent branch after the feature was branched off

 

A merge commit is created combining changes of parent commits and feature commits and is merged into the parent branch

Points ...

  • Github PRs use no-ff by force
  • CLI will try FF else it will do No FF
  • You can force ff or no-ff by providing flags

Rebase

Joins the work done in 2 branches

Rebase

Rebase creates new commits, so technically it rewrites history

Merge

Pros:

  • Easier to understand
  • Doesn`t destroy history

 

Cons:

  • Makes the history messier and harder to read

Rebase

Pros:

  • Keeps history linear

 

 

Cons:

  • Destroys history by creating new commits

When to use what?

branch.pushed() ? merge() : rebase();

Conflicts

Divided loyalties

In reality ...

What is a conflict?

Merrrggeee ...

$ git merge alice/master
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
<<<<<<< HEAD
Hello, Cat !
=======
Hello, Dog !
>>>>>>> alice/master
  • Head region is your/our branch i.e. master
     
  • Other region is their branch i.e. alice/master

Resolving ...

# Accepting our changes i.e. master
$ git checkout README.md --ours

# Accepting their changes i.e. alice/master
$ git checkout README.md --theirs

# Some complicated stuff, it can use any tool other than vimdiff
$ git mergetool -t vimdiff

Tip

Always keep you feature branches updated before pushing changes

# Working directly on develop

$ git pull --rebase origin develop
# Working on a branch from develop

$ git checkout develop 
$ git pull origin develop
$ git checkout feat/mock
$ git rebase develop

# Working directly on develop

$ git pull origin develop
# Working on a branch from develop

$ git checkout develop 
$ git pull origin develop
$ git checkout feat/mock
$ git merge develop

Merge

Rebase

Reset & Revert

Regroup to organize

simply ...

Creates a new undo commit

Moves the HEAD back to erase commit

Reverts

# Reset HEAD by one commit
$ git revert HEAD~0

# Reset a specific commit
$ git reset edfb4b55651af6de35753e4eef171107c37d5396

Resets

# Revert the last commit made
$ git revert HEAD~0

# Revert a specific commit
$ git revert edfb4b55651af6de35753e4eef171107c37d5396

Resets

Reset

  • Alters history
  • Unsafe to undo
  • Cleaner history
  • For repositories which are neither shared not public

Revert

  • Does not alter history
  • Safe to undo
  • Untidy history with additional commits
  • For shared/public repositories

Interactive Staging and Rebase

Nitpickings

--patch

$ git commit readme.md --patch
diff --git a/readme.md b/readme.md
index c212d60..f9f7184 100644
--- a/readme.md
+++ b/readme.md
@@ -1,4 +1,4 @@
-MOVE IT !
+MOVE it !
 
 
-Moveit!
+Move IT!
Stage this hunk [y,n,q,a,d,/,s,e,?]? s
Split into 2 hunks.
@@ -1,3 +1,3 @@
-MOVE IT !
+MOVE it !
 
 
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? y
@@ -2,3 +2,3 @@
 
 
-Moveit!
+Move IT!
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? n

[master d186e5c] crraazzzyyy
 1 file changed, 1 insertion(+), 1 deletion(-)

Interactive rebase

$ git rebase -i HEAD~3
   pick 54c4c28 freefall¬                                                                             
   pick d186e5c crraazzzyyy¬
   ¬
   # Rebase ebbf626..d186e5c onto ebbf626¬
   #¬
   # 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¬

Release Management

Pursue and engage

Semantic Versioning

MAJOR.MINOR.PATCH

  1. MAJOR version when you make incompatible API changes
  2. MINOR version when you add functionality in a backwards-compatible manner
  3. PATCH version when you make backwards-compatible bug fixes

Tagging

$ git tag -l "v1.8.5*"
$ git tag -a v1.4 -m "my version 1.4"

Light weight tags

Annotated tags

$ git push origin master --tags

Releases

  • Each tag can represent a release
  • Include this in your build process
  • Point to the release and deploy

No more code backups, zips, tars, blah

Github

Github - Releases

ghooks

Preemptive strike

https://github.com/gtramontina/ghooks

hook what you want

  • static analysis
  • testing
  • commit validation

Style Guide

Stairway to heaven

Style Guide

Bossed !

Questions, comments, discussions...

Git like BOSS !

By Mohammad Umair Khan

Made with Slides.com

Git like BOSS !

Some advanced Git concepts

  • 1,284

More from Mohammad Umair Khan