Wilson Mar bio photo

Wilson Mar

Hello. Hire me!

Email me Calendar Skype call 310 320-7878

LinkedIn Twitter Gitter Google+ Youtube

Github Stackoverflow Pinterest

Here is a quick way to learn Git with GitHub for enterprise use


This presents a couple of videos followed by what was discussed in the video, so you can understand the sequence of commands using Git and GiHub.

The first video uses native Git commands to obtain data from a repository you have permissions to update and a repository you do not have permission to update. This also covers how to make a request to update a repository you do not have permission to update.

This provides you the basis for understanding the value described in the second video.

The second video shows how additional software called “Git Flow” can work with different types of branches.

About this presentation

This is for someone with a Git command-line client installed.

We encourage you to actually type out (rather than just read) the commands shown in the narrative below, which provides additional alternatives not shown in the video.

Saeed Noursalehi says at Microsoft * “hotfixes happen in topic branches off a release branch. All topic branches are merged using a pull request.”.

The Git-client approach

PROTIP: Print this picture of the video and pin it on a wall for reference.

Let’s get hands-on typing each of the commands in the sequence presented in the video.

PROTIP: Click “Whoops” links for instructions on un-doing the commands immediately before the link. There is a “Return” link to go back and continue.


  1. Here we have some stranger’s repository in GitHub which we have no rights to edit.


  2. (Thank you for clicking the Star.)

  3. But if you fork it into your own GitHub account, you would then have rights to change it.

    • For example, if your account is “hotwilson”, your copy of the repo would be:


    Git client

    To work with repositories on your local machine, install a Git client.

    • This tutorial is called “Git-client based workflow” because it makes use of a Git client on your local machine.

    Git config

  4. Its installation includes adding in your user home folder a dot git folder containing a config file. That file stores git global commands such as username and userid settings for attribution.

    • (The video has the wrong syntax) to define attribution:
    git config --global user.name "Wilson Mar"
    git config --global user.id "wilsonmar@gmail.com"
    git config --global user.user "wilsonmar"

    (The 3rd line is not often seen. It’s used to identify the user name in GitHub for use in custom code.)


    Terminal (vs GUI)

    Git commands are typed into a Terminal shell window on a Mac or a Run command window on Windows.

    Most IDEs incorporate commonly used Git client functionality into their software.

    • For example, in Eclipse, right-click on the project, then select Team for the Git menu:
      git eclipse menu 518x648

    • Eclipse “Switch To” = git checkout

    • Return to this picture after going through this course to see if you recognize what each GUI item does.

    Clone in account folder

    PROTIP: I recommend that you create an account folder to hold all your various repositories.

    cd ~
    mkdir gits
    cd gits
    mkdir gitclass
    cd cigclass
  5. Be in that folder when you clone a repository from GitHub.

    • Substitute your own account as your type:
    cd ~
    git clone https://github.com/hotwilson/git-utilities

    Git then creates that repo’s folder and within it a folder named dot git to hold objects that track changes to the repository.

    During cloning, Git automatically extracts files from objects out to the repository’s folder, as if you typed a git checkout of the default branch.

    • Add parameter –recursive to pull in sub-modules (repositories stored within the repository).

    • Add parameter –depth=1 to only clone the latest version, to save disk space locally by not having previous version history on your machine.


  6. Now we cd into the repository folder.

    Branch list

  7. A git branch command shows us all the branches held in the repository.

    git branch -avv
    • The -avv parameter provides more detail. Dash a specifies remote tracking branches to appear as well.

    • PROTIP: Create an operating-system alias “gb” by adding in .bash_profile <pre>alias gb=’git branch -avv’</pre> then open up a new Terminal shell window to rerun the profile.

    PROTIP: Git defaults to the master branch. But many organizations protect that name for production use, and instead create a “development” or “dev” branch for developers to work with.

    This is a read-only operation.

    git checkout

  8. The git checkout command controls what Git extracts out from the repository database to the repository’s folder.

    • If you add a file after the git checkout command, Git will replace the file in the working folder with the version in the committed repository.


    New branch

    The dash b specifies creation of a new branch, such as “feature1”, to associate new changes.

    • PROTIP: Atlassian defines its branches* with a type (feature, bugfix, hotfix, etc.), a slash, an issue number, then a short description.

    git atlassian branch naming 650x222

    • The advantage of creating a branch is that parallel development can occur without risking the master branch.

    • Unlike Subversion, all files are available for change with a Git branch.



    Now we can edit the file named README.md. The md designates markdown format. Such a file GitHub creates with this specific name to describe each repository.

    We can use vim or another text editor (such as nano, atom, etc.) to change contents inside files. Batch files would echo text to the bottom of the file.

    • If you use vim, press the I key to begin insertion and press Esc to end insertion mode. When out of insertion mode, type : to enter command mode, then wq to write and quit the program or then q! to quit without changes.


    The git status command details the status of changes to the repo.

    • This command is used so often that many create an operating system level alias such as “gs”.

    Add to Staging

  9. You can change several files, but only the files you add to Git’s staging area will be pushed to GitHub.

    git add . -A

    The dot selects all files changed. The dash capital A parameter specifies that deleted files be processed. But many prefer to specifically add individual files to go into each particular commit, which works on all files added to staging.

    • Alternately, “git add -u” adds all the files modified (not new files created and untracked).

    • Some prefer using the single dash to avoid needing to press the Shift key to get the double quote.



  10. The commit supplies a message describing changes, which applies to all files added.

    git commit -m"Update for show"
    • A space is not needed between the m and the message.

    • If you don’t specify the dash m, Git will display a file containing comments as a prompt.

    Any line beginning with the # comment character will be ignored and not be part of the comment.

    • If a user name prefixed by an at sign (such as “@wilsonmar”) is specified in the message, GitHub automatically sends an email.



  11. The git log command provides a history of all commits. It has lots of options, so to avoid typing all the parameters desired, most people define an alias of the command in git’s config file.

    git log –graph

    • Add -3 to display only the last 3 commits.

    • If a colon appears at the bottom of the screen, press q to quit.

    • To skip the colon, add –no-pager.

    • List a count of changes in each file in the commit (for example, abcdef1) with

    git log --stat abcdef1


  12. lists actions that have occurred on the local machine.

    git reflog
    • Each entry is pruned after 90 days (by default).


    Before pushing to GitHub, some prefer to rebase to squash some commits so that only one commit message appears for several commits made.

    • Rebasing cleans up intermediate commits that is unwanted noise to the rest of the team. The extra commits complicates the history, and makes back-out of code more difficult.

    • Yes, this changes history, which is why we do it. But it’s only on your local version.

    • See http://wilsonmar.github.io/git-rebase for step-by-step instructions.


    The git push command sends to a remote what has been committed for a specific branch. If you didn’t paste your public key into GitHub, you would get an error now.

    git push


    Push tags

  13. When a commit is known good as the one to release, most organizations tag that specific commit with semantic versioning text.

    git tag v1.3.4
  14. Tags require an additional git push command to be pushed to GitHub.

    git push --tags


    Delete branch

  15. Because branches are just markers within Git, once a feature branch is in GitHub, that branch can be deleted from the local repo

    git branch -d feat1
  16. and from GitHub (by specifying that colon in front of the branch name).

    git push origin :feat1

    NOTE: The colon is the secret special sauce. There is no “delete” command with this.

    Pull Request

    Unless you have been designated a committer in the upstream repository, you can’t push changes to it. But you can request their committers to pull changes from your forked repo. When a committer of that repo merges (or in other words, accepts) your PR, you’ll get an email from GitHub.

    Upstream Remote

    Next, let’s look at what happens if, over time, changes occur in the upstream repo.

    The git remote –verification command tells us that the origin remote was created, as usual, with the repo.

  17. To enable dowload by Git, we add the upstream remote.

    git remote add upstream https://github.com/wilsonmar/git-utilities
    • The URL is the one owned by someone else.


    To obtain changes locally, many would rather NOT issue a git pull upstream command, which blindly fetches and automatically merges changes. Differences in the same line within the same file, Git is forced into automatic conflict resolution mode.

    • “Unintentional” merge commits are what some call “evil”.
    git pull --rebase
    • To set it up so every branch you ever create on any repository is set to pull with rebase, set this global configuration:
    git config --global pull.rebase true

    Prior to version 1.7, it was:

    git config --global branch.autosetuprebase always


    So many prefer to take it one step at a time –

  18. first a

    git fetch upstream
  19. then a

    git checkout master

    gitk for diff

    Now we can use a utility such as gitk to see what changes came in.

    • Click the commit listed at the top of the list, which is the most recent commit.

    • Alternately, there is also utilities vimdiff, meld, difftool, etc.

    • For Linux: https://wiki.gnome.org/Apps/Gitg/

    • To see the difference between what is in last commit vs. what’s in the working folder:

    git difftool
    • To see the difference between what is in last commit vs. what’s added in the index cache:
    git difftool --cached
    • You can make a default command such as this to explicitly specify some file to compare:
    git diff HEAD HEAD^ -- file1

    git merge

  20. If they don’t affect you, do a git merge.

    Notice the slash separator. Use a cat or less command to verify file contents.

    git push origin master

  21. git push to update origin master on our forked repository.

    There are variations to these commands, but this is the typical workflow.


  22. To make specific commits easier to find, add a tag to the latest commit so that it travels with that commit:

    git tag -a v1.2.3

    The example here is called a semantic tag described in the website http://semver.org

  23. Tags are pushed using its own separate command:

    git push --tags

    File a pull request from git command line

  24. Request the pull from the upstream repo. For example:

    git request-pull v1.0 https://github.com/upstream/project  master
    • The URL must be specified (rather than a remote designator such as “upstream”).

    • This feature is described at: http://git-scm.com/docs/git-request-pull which says “this will produce a request to the upstream, summarizing the changes between the v1.0 release and your master, to pull it from your public repository.”

Recap diagram

(Click here for full screen and printing)

Other videos and articles

Hub add-in

This describes installation and use of a simple wrapper around Git’s CLI so you can do it all from the command line rather than switching to GitHub’s web page:


git-flow software

Those who DO have permissions to update can use an approach described in a popular blog, which identified different types of updates at:

Each of these are a different type of branch:

  • Hotfix (from master and back to master)
  • Bugfix
  • Release - for next release development
  • Feature
  • Support

These branches are used more in corporate rather than open source software.


  1. [3:30] Install it on a Mac:

    brew install git-flow
    • http://github.com/nvie/gitflow/wiki/Mac-OS-X
    • http://github.com/nvie/gitflow/wiki/Windows
    • http://github.com/nvie/gitflow/wiki/Linux
  2. Create content in a folder (such as “davebock_www”) and [4:01] initialize Git:

    git init
  3. Customize .gitignore file:

    git init
  4. Add to Git and commit (Git commit commands are still necessary):

    git add .
    git commit -m"initial commit"
  5. Push to GitHub:

    git remote add origin git@github.com:CodeSherpas/da...
    git push origin master
  6. View the branches:

    git branch -avv

    Atlassian presents their take on the different branches in this video:

    github branches atlassian 650x260
    (click for full screen and to print)

  7. Set the upstream tracking branch:

    git branch --set-upstream develop origin/master
  8. Activate:

    git flow init -d
  9. Answer the series of questions:

    Which branch should be used for bringing forth production releases?
    - master
    Branch name for production releases: [master] 
    Branch name for "next release" development: [develop] 
    How to name your supporting branch prefixes?
    Feature branches? [feature/] 
    Release branches? [release/] 
    Hotfix branches? [hotfix/] 
    Support branches? [support/] 
    Version tag prefix? [] 
  10. View menu:

    git flow
    usage: git flow 
    Available subcommands are:
    init      Initialize a new git repo with support for the branching model.
    feature   Manage your feature branches.
    release   Manage your release branches.
    hotfix    Manage your hotfix branches.
    support   Manage your support branches.
    version   Shows version information.
    Try 'git flow <subcommand> help' for details.
  11. Instead of native git commands the “git flow” command is issued with a new branch name:

    • git flow hotfix start branchx
    • git flow bugfix start branchx
    • git flow release start branchx
    • git flow feature start branchx
    • git flow support start branchx

    A sample of the response:

    Switched to a new branch 'feature/controller'
    Summary of actions:
           - A new branch 'feature/branchx' was created, based on 'develop'
           - You are now on branch 'feature/branchx'
    Now, start committing on your feature. When done, use:
      git flow feature finish branchx
  12. Edit files (such as generate controller).

  13. List branches:

    git-flow feature
  14. Publish:

    git flow feature publish branchx

    The response:

    Summary of actions:
           - A new remote branch 'feature/branchx' was created
           - The local branch 'feature/branchx' was configured to track the remote branch
           - You are now on branch 'feature/branchx'   
  15. Instead of native git commands the “git flow” command is issued with a git flow branch name and whether you want to finish (git merge):

    • git flow hotfix finish branchx
    • git flow bugfix finish branchx
    • git flow release finish branchx
    • git flow feature finish branchx
    • git flow support finish branchx

    The response:

    Switched to branch 'develop'
    Already up-to-date.
    Deleted branch feature/branchx (was 31a9657).
    Summary of actions:
           - The feature branch 'feature/branchx' was merged into 'develop'
           - Feature branch 'feature/branchx' has been removed
           - You are now on branch 'develop'   

    To Master

  16. List Git Flow commands available [12:14]:

    git flow release start initial deploy
  17. You are automatically prompted for a tag message (because it’s master).

    This also occurs with Hotfix.

More Videos

Video illustrations from GitHub Education

https://github.com/zacksiri @zacksiri

  1. Git Flow Introduction
  2. Git Flow Feature Branch and Pushing to GitHub [11:16] 6 Dec 2015
  3. Git Flow and Github Pull Request [6:53] 1 Jan 2016

git-flow software is described by this video and blog from 2013 by @KBasarab and at:

Hubflow fork software

Datasift people created an upgrade to GitFlow to work with GitHub, which they call HubFlow

git clone https://github.com/datasift/gitflow
cd gitflow
sudo ./install.sh
sudo git hf upgrade

The flow of hf git commands are explained at:





Introduction to GitLab Workflow [49:14] Mar 11, 2016


This is one of a series on Git and GitHub:

  1. Git and GitHub videos

  2. Why Git? (file-based backups vs Git clone)
  3. Git-client based workflows
  4. Git whoops (correct mistakes)
  5. Git rebase
  6. Git commits with a Tag and Signature
  7. Git HEAD (Commitish references)
  8. Git commands and statuses

  9. Git custom commands
  10. Git utilities
  11. Git hooks

  12. GitHub data security

  13. TFS vs GitHub
  14. GitHub REST API
  15. GitHub GraphQL API
  16. GitHub PowerShell API Programming
  17. GitHub GraphQL PowerShell Module