Git Acrobatics

For Beginners

  1. GitFlow

  2. Git Basics

  3. Your Work

 In Three Acts

Quickly: why Git?

Git gives you options in how you you run your own daily workflow and coordinate with team members.

KEY DIFFERENTIATORS 

  • Git makes branching easy and inexpensive.
  • Git encourages merging early and often.
  • Git is decentralized source control using hash trees (Merkle trees, same struct as blockchain)

Git: a set of Commands to manage source control

  • git clone

  • git status 

  • git pull

  • git checkout

  • git branch

  • git merge

  • git push

 

Gits' got tools

  • GitHub Website
       great for open source

  • Command Line Interface
       OK not really a tool, just the raw commands

  • Desktop UI Tools
       source-tree; unGit; gitKraken, ...

  • Integrated into IDE's
       VS, VSCode, Atom ...

 

 GitMacros

GitFlow is a set of macros  that make it easy to use Git. High level commands mean fewer decisions less error prone repo management while developing a feature, fixing a bug or releasing a product.

 WorkFlow

GitFlow is opinionated. It dictates the use of branches in specific ways.

GitFlow is the automatic-transmission of repository management (don't worry about the inner mechanism and all those gear shifting details).

 GitFlow

Each branch has a purpose

GitFlow has three core branches named:

  • master (production, deployed code)
  • release/* (testing and quality assurance)
  • dev (code creation comes together here)

and helper branches:

  • feature/* (* you name it, all the code for your feature creation. your development sandbox)
  • hotfix/* (emergency patches here)

 GitFlow

Three operation:

  1. Feature development

  2. Release some software

  3. Hotfix

 GitFlow

Feature start and finish

  1. git flow feature start <name>
    makes a new branch from the dev branch and you are set up to do your work
  2. git flow feature finish <name>
    merges your work back into the dev branch

 GitFlow

source: https://danielkummer.github.io/git-flow-cheatsheet/

Release

Time for a release into the various test environments.

  1. git flow release start <version>
    merges dev into release for testing and approval.
     
  2. git flow release finish <version>
    merges the release into master as well as back into the dev branch.

 GitFlow

source: https://danielkummer.github.io/git-flow-cheatsheet/

Hotfix

An 'issue' is found in production and it needs to be fixed ASAP.

  1. git flow hotfix start <version>
    merges dev into release for testing and approval.
     
  2. git flow hotfix finish <version>
    merges the release into master as well as back into the dev branch.

 GitFlow

source: https://danielkummer.github.io/git-flow-cheatsheet/

 GitFlow

source: https://www.atlassian.com/software/sourcetree

 GitFlow

source: https://www.atlassian.com/software/sourcetree

 GitFlow

source: https://www.atlassian.com/software/sourcetree

Git is Complicated

Why can't we go back to the good old days?

Fear of Chaos

Nobody Wants That!

 Git basics

Maybe with super-human project planning, we would never need to edit the same file at the same time.

Working in a team is difficult

good old waterfall

Continuous Integration - Agile 

=>

You can make a new repo with init or even better, you can clone an existing repo

git init is one way to get things started. 

For example let's make a repository for "contracts."

OR

clone an existing repo making a local copy.

> mkdir contracts

> cd contracts

> git init

 

OR

> git clone https:url.of/repo

 Git basics

git status tells you the state of your local repo

git status has no affect on your repo. so never worry about asking git for status. 

 

I ask all the time and so do the UI tools...

> git status

On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)

 Git basics

make a new branch then use checkout to switch over to it

We are on the master branch. Let's see all branches and make a new branch (our own work space off to the side).

 

now checkout the new branch

> git branch --list

* master

> git branch dev

> git branch --list
  dev
* master

> git checkout dev

Switched to branch 'dev'

 Git basics

time to code

Teams members should adopt a work pattern:

============ time to code ==============

checkout the correct branch for your task*

pull from origin (remote => local) pulling in others work. 

  1. edit some code (all local)
  2. stage modified files using git add
  3. commit your staged files with a message**
  4. repeat 1-3 until you're proud

pull again (a pull includes a merge)***

push your commits back up to the origin (local => remote)

====== take a rest, or get back to work =====

 Git basics

Git makes a record of every commit.

commit is the best thing to do if you want to make a record of your modified files

stash is the thing to do if you are fearful that the modification may not be the best way forward, but you are not ready to discard them completely

 

 Git basics

What if you forgot to checkout the correct branch before you dug into work, oops

If you wish you had been working on a different branch, here is one way to fix that.

don't commit your code, instead

git stash --save , then

git checkout <the-correct-branch> and then

git stash --restore

 

stash is like "shelf" in TFS??

 

 Git basics

Checkout a different Branch

Branches make it easy to change the state of your code. checkout is the Git command that switches to another branch. the switch happens in-place on your local file system.

 

$> git checkout master

Also, making a new branch is also easy. To make a branch off of your current branch.

$> git branch <name-of-new-branch>

 

 

 Branch is skill one

Switch to a different Branch

Branches make it easy to change the state of your code. checkout is the Git command that switches to another branch. the switch happens in-place on your local file system.

Also, making a new branch is also easy. To make a branch off of your current branch.

$> git branch -b <name-of-new-branch>

 

 

 Branch is skill one

Merge two branches

Merge some branch into the current branch.

First checkout the target branch. Then merge the source in with this command.

$> git checkout <target>

$> git merge  <source>

The outcome of the merge,

One of three possibilities:

  1. Failed due to uncommitted files :(
  2. Automatic merge was successful :)
  3. Success with conflicts :/

 Merge is skill two

Failed

The merge fails due to the condition of the repo.

Usually this is uncommitted files.

To fix: either commit or stash the modified files. 

 

Then try the merge again.

  • If you are happy with the state of your code then commit then.
     
  • If you are not sure that your modified files are great then stash them to the side for later.

 Merge is skill two

Success (automatic)

Best news all day!

This means that the merge was able to be competed automatically and no conflicts were found.

This is either great planning and teamwork, where Developers didn't need to work on the same files at the same time,

OR

maybe you are the only one working on this project, lonely yes, but easy to merge. :)

 Merge is skill two

Success, but with Conflicts

You have more work to do.

This means that the merge could not resolve all conflicts automatically. Yes you humans still have a purpose.

This means that Git found places in the code where both branches edited the same area of code and it cannot know how to resolve the two edits into one.

One or more files will need your attention.

 Merge is skill two

Resolve those Conflicts

example conflict text...

<<<<<<< Updated upstream

Groucho -- Well see right here, this it what is call a real bona fide contract.

=======

Groutcho -- Well see right here, this it what you call a real bonafide contract.

Here, you read it.

>>>>>>> Stashed changes

 

 Merge is skill two

Important!

To Do Exercises.

Use your branch and merge skills to execute these:

  • feature

  • release

  • hotfix

the most important point  

(if nothing else is sticks)

Teams members should adopt a work pattern:

============ time to code ==============

checkout the correct branch for your task*

pull from origin (remote => local) pulling in others work. 

  1. edit some code (all local)
  2. stage modified files using git add
  3. commit your staged files with a message**
  4. repeat 1-3 until you're proud

pull again (a pull includes a merge)***

push your commits back up to the origin (local => remote)

====== take a rest, or get back to work =====

Nate Morse

  • n8morse@gmail.com
  • @natemorse
  • github/nmorse

References

 

https://danielkummer.github.io/git-flow-cheatsheet/

https://www.atlassian.com/software/sourcetree

https://git-scm.com/downloads/guis

 

git-scm.com           github.com

 

 

 

 

 

 

Git Acrobatics for beginners

By Nate Morse

Made with Slides.com

Git Acrobatics for beginners

Git is for teams of creators. Working with teams is difficult, but if we all adhere to the same etiquette, we will all get along famously. This is when Git really shines as a great collaboration tool. GitFlow is one option for providing manors and structure to Git. Each branch is given a purpose and processes on those branches are standardized. GitFlow is great to use, but we will look at defining your own rules of etiquette and the git commands that make it all work. Sometimes it feels like you are on the high-wire of software source control, but with some structure, basic Git skills and exercises, you will gain the confidence to handle Git with balance and composure.

  • 1,580

More from Nate Morse