Wilson Mar bio photo

Wilson Mar


Calendar YouTube Github


How to setup Git clients like a pro

US (English)   Norsk (Norwegian)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Estonian   اَلْعَرَبِيَّةُ (Egypt Arabic)   Napali   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean


Here is a hands-on instructions and software to get those new to Git productive for professional usage using a local Git client.

PROTIP: This integrates (implements) actions that block possible leak of data in my “GitHub Data Security” blog article.

This is designed to offer maximum depth at minimum time because I’ve spent a lot of time on sequencing learning and on time-saving automation.

Stages to install software and run

This explains both the shell script and manual steps in the stages outlined below:

A. Establish a Terminal CLI environment
B. Download sample repository containing setup files

C. Install base utilities, if needed
D. Install Editor app
E. Install Git client apps

F. Define a file listing each GitHub organization/account
G. Begin work on each GitHub organization/account

H. Create global .gitconfig file with editor setting
I. Make a folder for each GitHub account’s repositories

J. Replace global .gitconfig user settings
K. Populate a Git configuration file in each account folder
L. Specify IncludeIf for account in Git config

M. Be in SSH folder
N. Generate SSH keys for each GitHub account

O. Test interaction with each GitHub repository
P. Configure other Git features
Q. Repeat above steps for each additional account

Summary Diagram

This tutorial is part of a video that explains my bash script as part of my Git Basics tutorial sequenced by this animated diagram about installation and configuration:

Click on the flowchart above to pop-up a full-screen (static) image

A. Establish a Terminal CLI environment

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

To make use of it on your laptop, you need to open the Terminal program on a Mac or, if you’re on a Windows machine, the Git Bash program installed.

Terminal on macOS

  1. Switch to your local IDE or Terminal (on Mac, press command+spacebar for the Spotlight Search, then type “Term” and press Enter to select “Terminal.app”). Enter your password if prompted.

  2. Click anywhere on the Terminal window. Press command+N for the Basic session colors and other UI. Alternately, point your cursor beyond the top of the screen for the Terminal menu to appear and select Shell, New Window and select one of the themes.


    • Grass is green
    • Ocean is blue
    • Pro is black
    • Red Sands is earthy brown

Setup on Windows utilities

Since a Bash shell does not come built-in on Microsoft Windows machines, a bash terminal program called git bash needs to be install by the Windows Chocolatey installer installing the msysgit package. But you must have Administrator permissions to install them.

  1. So that you can update versions automatically later, automate client installs on Windows, by first installing Chocolatey using a PowerShell command:

    <@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"
  2. While you’re on a command window, have Chocolatey install a Git client:

    choco install msysgit -y

    -y takes the place of clicking “OK” to submit to legalistic licenses.

  3. To open git bash, press the Micosoft icon on the keyboard. Type git. When “git bash” appears, click on it.


B. Download sample repository containing setup files

Since Git utilities may not be available on your laptop at this point, download sample files using a command.

  1. Defines a variable to specify the path, then use the variable to create a folder, and cd into it.


mkdir -p “$HOME/${GIT_FOLDER}”

cd “$HOME/${GIT_FOLDER}” </strong></tt>

The Terminal prompt should now be at ~/git-utilities or whatever you changed the path to.

Files in the folder relevant to this:

curl -O https://raw.githubusercontent.com/wilsonmar/git-utilities/master/my_github_accts.csv
curl -O https://raw.githubusercontent.com/wilsonmar/git-utilities/master/git-certs-setup.sh
  • my_github_accts_vars.sh

### C. Install base utilities, if needed

  1. If requested by a parameter, the automated script installs these:

    1. XCode
    2. Homebrew
    3. Git program
    4. GitHub CLI

    Alternately, if you don’t run the script, you’ll need to manually install each one.

    D. Install Editor app

  2. Determine what text editor you want to load when Git needs one.

    PROTIP: I personally like the Sublime Text editor because it loads up the fastest.

    But subl needs to be installed and licensed (for $85 one time).

    The nano editor comes with MacBbook macOS operating system.

  3. Install the selected editor app (such as Sublime Text).

E. Install Git client apps

Due to the open-source availability to how Git works, there are many Git clients available.

But NOT clients include a git bash program so you can run commands like a Linux command line (shown by this tutorial).

Most IDEs and text editors today have incorporated commonly used Git client functionality into their software.

On IntelliJ, get its Git menu by right-clicking on the project in the left Solution pane to see this menu:

We will return to this after going through this course to see if you recognize what each GUI item does.


In Eclipse, right-click on the project in the left Solution pane, then select Team for the Git menu:

git eclipse menu 518x648

  • The “Switch To” in Eclipse is the equivalent of git checkout. This avoids confusion with the “checkout” function in Subversion, which does something completely different than git checkout. Git does not isolate what is checked out nor lock portions of code like what Subversion does, which results in people waiting for others to finish. For this reason, many have migrated from Subversion to Git. We will soon show how Git enables every portion of code to be worked on at the same time.

  • See VIDEO: Using Git within Eclipse May 21, 2013 by Dr. Brian Fraser

### F. Define a file listing each GitHub organization/account

PROTIP: Many developers switch among multiple GitHub organizations/accounts during a working day.

  1. Download a sample file using the curl utility:

    curl -O https://raw.githubusercontent.com/wilsonmar/git-utilities/master/my_github_accts.csv
  2. Open a text editor to manually edit sample file named my_github_accts.csv.

    It contains a line for each github organization/account, with associated fields:

    _folder,      _Name,    _acct,    _email,            _note
    gmail_acct,   John Doe, johndoe,  johndoe@gmail.com, Personal GitHub account created using personal Gmail or other email
    client1_acct, John Doe, john-doe, john_doe@mck.com,  Customer/client organization account
    job1_acct,    John Doe, john-doe, john_doe@mck.com,  Employer organization account
    vendor1_acct, John Doe, johndoe1, john-doe@soft.ai,  vendor organization account

    PROTIP: We recommend that, even if you only have your own personal account now, be prepared to use multiple GitHub accounts by doing the work of just the first account.

    If you’re manually performing the steps below, create the file above as a checklist as you repeat commands for each organization/account folder and files.

    G. Begin work on each GitHub organization/account

  3. Switch back to the Terminal.

  4. Download a sample script file:

    curl -O https://raw.githubusercontent.com/wilsonmar/git-utilities/master/???script.sh
    chmod +x ???script.sh

    That script automatically performs all the steps described in the remainder of the steps below, for each GitHub organization/account listed in the file above.

  5. If want to run the automated script, first run without any paramters to get a list of possible parameters to customize each run:


    -v specifies verbose output.

    H. Create global .gitconfig file with editor setting

    Since we are creating a git configuration file for each organization/account folder, we don’t need global user configurations.

  6. In a Terminal, set the text editor command to be used by Git:

    git config --global core.editor "subl"

    Instead of subl for Sublime, use code for Visual Studio Code, nano for Nano, etc.

    git config –global commands update the contents of the ~/.gitconfig file.

    ~ specifies the user’s home folder.

  7. Open the editor using a git command:

    git config --global --editor subl

    That command is equivalent to, alternately :

    subl ~/.gitconfig

    Due to the previous command, you should see in your editor:

    editor = 'subl'
  8. List git global settings:

    git config --list

    Sample response:

    filter.lfs.clean=git-lfs clean -- %f
    filter.lfs.smudge=git-lfs smudge -- %f
    filter.lfs.process=git-lfs filter-process

    PROTIP: If you see a : (colon) on the last line of the Terminal screen, press q to quit out of the listing.

  9. There are possibly other git global configuration settings if your Git configuration is not new, such as:

    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true

    Configuring these is not within the scope of this document.

    Later, from this file we will replace global configuration settings values for a single user such as:

     name = John Doe
     email = johndoe@gmail.com

    (with “IncludeIf” and “path” statements)

    That setting is the result of a command such as:

    git config --global user.name "John Doe"
    git config --global user.id "johndoe@gmail.com"


    I. Make a folder for each GitHub account’s repositories

  10. Switch back to the Terminal.

  11. Download a sample script file:

    curl -O https://raw.githubusercontent.com/wilsonmar/git-utilities/master/my_github_accts_vars.sh
    chmod +x my_github_accts_vars.sh

    That script automatically performs all the steps described in the remainder of the steps below, for each GitHub organization/account listed in the file above.

  12. To avoid manualtyping, run script:

    chmod +x my_github_accts_vars.sh

    The script creates variables based on values copied from the Github organizations/accounts defined above in flat file my_github_accts.csv:

    export LOCAL_SSH_KEYFILE="gmail_acct"
    export MY_EMAIL_ADDRESS="johndoe@gmail.com"
    export MY_GITHUB_ACCTNAME="johndoe"
    export MY_FULL_NAME="John Doe"

    REMEMBER: In Bash script export commands allow no spaces around the equal (=) sign.

    Use of variables helps ensure that several commands below will use values consistently.

  13. Make a folder for the current GitHub organization/account based on the variable defined above:

    mkdir ~/$LOCAL_SSH_KEYFILE

    J. Replace global .gitconfig user settings

  14. Use your default editor to edit Git’s global .gitconfig configuration file:

    git config --global --edit

    In 2019, at git version 1.23, “conditional include” (“IncludeIf”) was added to Git Core. That enables Git to automatically select the configuration file Git uses to be based on whatever folder is active.


    K. Populate a Git configuration file in each account folder

  15. Edit the ~/.gitconfig text file to confirm that the above commands created a git configuration file, using your favorite text editor:

    Either way, you should see something like this (but with your name and email instead):

     name = John Doe
     email = johndoe@gmail.com

    In a config file, we will replace the above values with IncludeIF statements.

    The above staements will be in a config file, with name and email appropriate for each GitHub organization/account.

    L. Specify IncludeIf for each account

  16. Construct new lines in the account folder’s .gitconfig file based on the $LOCAL_SSH_KEYFIL variable name:

    [includeIf "gitdir:~/gmail_acct/"]
     path = ~/gmail_acct/.gitconfig

    PROTIP: We are using the name of the account folder the same name as the SSH keypair file name.

    PROTIP: In the includeIf line, the trailing slash after the directory path makes it so that all subdirectories of the specified directory is matched.

    Alternately, instead of using a text editor, use these commands to concatenate the lines to the bottom of the file:

    echo "[includeIf "gitdir:~/$LOCAL_SSH_KEYFILE/"]" >>~/$LOCAL_SSH_KEYFILE/.gitconfig
     path = ~/$LOCAL_SSH_KEYFILE/.gitconfig  >>~/$LOCAL_SSH_KEYFILE/.gitconfig

    Either way, put the includes at the bottom of your files to make sure the included config isn’t overridden later on in the source file.


  17. Verify:

    git config list

    TODO: If you get error: key does not contain a section: list

    Next, let’s create that folder referenced above.

    Be in SSH folder

  18. Be at the folder where SSH stores its key pairs file:

    cd $HOME/.ssh

    If it does not already exist, make the folder yourself.

    Generate SSH keys for each GitHub account


  19. Within the ~/.ssh folder, generate a pair using defaults for the GitHub account:

    ssh-keygen -t rsa -f "${LOCAL_SSH_KEYFILE}" -C "${MY_EMAIL_ADDRESS}" -N ""

    -N specifies that no Passphrase will be requested when the key is used. Specifying one would require it to be manually entered with every command – not something most would want to do.

    -C provides an optional unique name within the Public key.

    TODO: A “fingerprint” of the key is generated to uniquely identify each one.

  20. The public key we copy into each server so we can SSH

  21. with the private side of the pair (instead of a password).

    Some use an encrypted USB Solid State Drive for sole physical posession. But if that’s lost or stolen, security can be compromised.

P. Configure other Git features

There are other lines in the .gitconfig file.

  1. On a Windows machine, to mute annoying warnings about conversion of line endings in files saved on Mac machines:

    git config --global core.safecrlf false

    The command issues no response.

    The command does not turn off conversion.

  2. Configure Git Signing describes steps to enable the gpg program to establish GPG keys used to sign git commits, which would add lines such as these:

     editor = subl
    signingkey = 62C414BA89BFBE52
     program = gpg
     forceSignAnnotated = true
  3. GitHub Enterprise users whitelist hostnames using:

    git config --global --add hub.host my.example.org
  4. Change default commit message editor program to Sublime Text (instead of vi):

    git config core.editor "~/Sublime\ Text\ 3/sublime_text -w"
  5. Allow all Git commands to use colored output, if possible:

    git config color.ui auto
  6. Get the size of what was transmitted on the current repo folder:

    git count-objects -v
    count: 1749
    size: 12308
    in-pack: 344
    packs: 1
    size-pack: 109
    prune-packable: 0
    garbage: 0
    size-garbage: 0
    git remote show origin

    But I have a script that installs them and other apps on a Mac according to a specification file. It’s at https://github.com/wilsonmar/mac-setup/master/blog/mac-install-all.sh

Q. Repeat above steps for each additional account


Ways to get a shell script

a. bash curl command to a script (see immediately below)

Ways to get a Git repository

PROTIP: There are several ways to obtain this file from GitHub, GitLab, BitBucket, or other host:

a. Download ZIP file
b. Open in Desktop client (using Git for GitHub)
c. git clone https or SSH url
d. hub command
e. bash curl command to a script (see immediately below)

A script types commands for you

An bash script was created to automatically type for you the various commands in this course. It’s to see whether what you are asked to type manually actually works. This is so we can see whether it was working before, so you don’t blame yourself for not typing commands correctly and waste time debugging.

  1. Let’s look at the script by providing an internet browser (such as Brave) with this full URL:


    Follow along with me on your own machine.

    This file in GitHub.com is associated with an account named “wilsonmar”.

    The file is in a repository (or “repo”) named “git-utilities”.

    The “.sh” means it’s a shell script file.

    The first line inside each shell script specifies the program which processes it. In this case it’s


    which is the default shell program that comes with MacOS machines to process commands of the operating system.

    A “blob” is the set of characters in the last revision identified by a “hash” calculated from the text changed plus some metadata such as the data of the change, the person making the change, etc. The 7 characters shown is the first 7 characters of the full hash string.

    Bash curl command pasted in Terminal

    To run the shell script without first downloading it:

  2. Open a Terminal or Git Bash dialog.
  3. Run a Bash script is by pasting in a Terminal a bash curl copied from a web page. This places you at your account’s home directory such as, in my case:


    On your dialog, a different name would appear instead of “wilsonmar”.

  4. PROTIP: You can return to this folder by several commands: cd (change directory) command by itself or cd ~ (the tilde character), which resolves to cd $HOME.

  5. $HOME is a built-in variable for your account’s home directory.

    Shell scripts make use of built-in variables such as $HOME.

  6. There is also a built-in command pwd (present working directory), which is equivalent to the “dir” command on Windows machines.


  7. PROTIP: When a Terminal or Git Bash session is started, the operating system automatically (in the background) runs command:

    source ~/.bash_profile

    This places into memory definitions for the PATH of directories the operating system looks for the location of programs requested to run, for export of environment variables.

  8. The dot character in the file name means that the file is normally hidden, so additional parameters need to be specicifed to see them, such as:

    ls -al

    PROTIP: Don’t type the “[ll]” shown in the flowchart because that defines a keyboard alias which the bash_profile also defines them.

    git-basics.sh add aliases

  9. PROTIP: A set of aliases is defined at:


    You can copy and paste the raw text into your ./bash_profile open in a text editor.

    Or you can run a script to do that for you, described below.

    What follows are the steps to get the aliases to be available in your laptop, among other tasks.

    Remote bash command run

    To get you started quickly:

  10. Highlight this entire line (which may wrap around)

    bash -c "$(curl -fsSL https://raw.githubusercontent.com/wilsonmar/git-utilities/master/git-basics.sh)"

    (Position your mouse at the beginning of the string, drage the mouse as you drag across the line, then relase at the end of the line. Press command+C to copy to your Clipboard.)

  11. Press command+C to copy into your operating system’s Clipboard.
  12. Open a (Git-capable) Terminal or Git Bash session.
  13. Click on the blank part and right-click to select Paste.
  14. Press Enter to run it.

    In the output displayed on the Terminal:

    Lines prefixed by >>> output by function echo_f() precede each section and step of the script:

    Lines prefixed by $ output by function echo_c() precede each command:

index to git-basics.sh output

Numbering of sections in the script:

0.x Script start-up

1.x Mac client Install and Configuration

2.x Git Setup and Configuration

3.x Cloud repository setup, forking, cloning

4.x Branch and edit locally

5.x Local config, add, commit

6.x Local edit, add, commit, push

7.x Pull and Merge

8.x Update origin with upstream changes

9.x Get changes in origin to local

In outputs on Terminals, “$” precede commands issued by the script, so you can type the exact commands.

0.x Bash script start-up

1.x Client Install and Configuration

On the Mac, the git-basics.sh script installs a Git client if needed.

  1. The first thing the script does is figure out what operating system it is running on. That uses a command common to all operating systems:

    uname -a

    “Darwin” is the internal name of the operating system running on a Mac.

  2. If the script is running on a Mac, the script installs Homebrew if needed.

  3. A Git client is installed if the git command is not found.

    brew install git

    Its version is output so you know what you have.

  4. For the script to automatically create a repository in GitHub and fork a repository from another account, it first installs the “hub” add-in to Git:

    brew install hub

    BTW: There is no “cask” in the brew command because it only works within the command line, not GUI.

    PROTIP: Technically “Hub” is called a “wrapper” around Git’s CLI so you can do it all from the command line rather than switching to GitHub’s web page.

  5. Also install jq to enable Git to process JSON:

    brew install jq

    environment variables & values

  6. File git-basics.env is downloaded to your $HOME account folder (by a curl command):

    curl -O "https://raw.githubusercontent.com/wilsonmar/git-utilities/master/git-basics.env"

    The file provides values to environment variables controlling the script. It is loaded into memory using this command:

    source git-basics.env

    The variables and the values are displayed.

    PROTIP: The git-basics.env file is placed in your $HOME folder, separate from any folder that can be pushed back to Git hosting because you may want to type your password in the file for more automatic functionality in the script, such as deleting repos, functions which even hub does not perform.

    git-scripts folder in $HOME

  7. The script looks for a persistent folder named git-scripts and creates it if it doesn’t exist there.

    Files from GitHub load the folder with files containing default values. If the file is there already, don’t overlay the file.

  8. git-basics.sh, the shell script, is copied into that “git-utilities” folder so you have the option of editing the files and re-running locally on your laptop.

  9. To halt processing for customizations, press control+C on the Mac or Press any key to continue default processing.

    This is so you can edit the files downloaded so you can run rerun locally (as described below).

    If you do edit the file locally, comment out the read command line and its fancy_echo command by adding a # in front of them.

    Edit and rerun locally

    The script git-basics.sh is designed to both run without modification and to allow you to customize it. There are several reasons you want to customize files in the “~/git-utilities” folder the script added for you:

    • Edit the git-basics.env to place exit anywhere you want the script to stop.

    • Edit the git-basics.env file to replace “secret here” with your GitHub password so that the script can automatically delete repos locally, so that you don’t have to manually do it every time you run. PROTIP: The git-basics.env file is copied to a separate folder than the script so that you never upload it back to a Git hosting GitHub/GitLab.

    • Adopt the git-basics.sh to automate other activities using Git. PROTIP: Select a text editor. See my notes at https://wilsonmar.github.io/text-editors


    PROTIP: To avoid error messages that says the file is not there, change premissions to enable the script file to be executed

    chmod +x git-basics.sh

    To run the file, type a “./” in front of the script file name:


    Continuing processing

  10. aliases.txt containing keyboard shortcut definitions are copied in. Again, if the file is there already, it is not overlaid.

  11. If a ~/.bash_profile is not found, the script creates it in your $HOME folder.

  12. Whenever a Bash terminal session is opened, it automatically runs the ~/.bash_profile script file at the user home folder. The “~/” specifies that the file is in the user’s $HOME folder.

The file contains a definition of the PATH the operating system searches for executables.

The file can also contain custom keyboard commands defined by alias specifications. The alias.txt file.

The aliases.txt file is concatenated to the bottom of the ~/.bash_ profile

  1. The script creates a volatile/non-persistent workspace folder which, when configured, the script deletes at the beginning of each run, and populates again with downloads.

    The name of the volatile folder is based on the variable $WORKSPACE_FOLDER defined in file git-basics.env. Thus, if you may the value of the variable, a different workspace would be created on the next run.

    This is what enables the script to be run over and over again.

  2. Before invoking a Git command, load the default SSH public key file to make sure it is available for use with “hands-free” GitHub API calls:

export RSA_PUBLIC_KEY=$(cat ~/.ssh/id_rsa.pub)

### Local Git projects container folder

  1. PROTIP: Optionally, create a folder with a name such as gits or “project” to hold anonymouse Git repositories from various GitHub/GitLab accounts. This would be immediately under your $HOME folder:

    cd $HOME && mkdir gits && cd gits
  2. PROTIP: Optionally, create an account container folder to hold repositories under each account on GitHub/GitLab or to group repositories relared to the same subject:

    mkdir myacct && cd myacct

    PROTIP CAUTION: Some repos have a 20 character limit on the prefix before the repo name. The character count includes slashes:


    Init repo

  3. PROTIP: If you are creating a local repository, first create an account or project container folder to hold the various repositories.

    mkdir local-init && cd local-init
  4. The git init command creates a blank Git repository:

    git init

    The sample response:

    Initialized empty Git repository in /Users/kevingrastorf/git-basics-workspace/gits/myacct/local-init/.git/

    This creates in the current folder a folder always named .git into which Git stores and retrieves all change history.

  5. Add contents:

    git add --all
    git commit -m "First commit"
  6. Delete the “local-init” repo created by a previous run on GitHub. This requires use of the GitHub API because “hub delete” does no work.

    BONUS: See the GitHub API description

  7. Although GitHub docs say that you need to first create repos in the GUI. However, the Hub add-in enables it:

    hub create -d "My new thing"

This is instead of

  • git remote add origin remote repository URL
  • git push -u origin master

  1. git remote -v
  2. Manually check on GitHub to make sure it’s really there.

3.x Cloud repository setup

Now let’s talk about working with repositories in cloud hosts such as Microsoft’s GitHub, GitLab, Atlassian’s BitBucket, etc.

Identify a public GitHub repository and something that you can contribute to, such as suggesting a typo fix. But you have no right to edit that repo. For example:


An “open source” repository available to the “public” can be accessed using an URL using https protocol even if you are not a designated collaborator with a right to alter it.

Such a repository we call an upstream remote or some other name.

You can click the “Star”, but you would need to be signed in under your own account.

We assume here that you have already opened a personal email account and used it to create an account on GitHub.com.

PROTIP: I use email accounts on both Gmail.com and Outlook.com so I can test sending emails.

PROTIP: It helps if you pick a unique handle that is available throughout various social media (Twitter, Medium, Instagram, etc.)

Setup SSH manually

Before you can “Fork” another account’s repository, you need to enable your Git commands to have right to modify.

The right to alter a cloud repo is claimed by pasting the contents of your machine’s .pub (public key file) obtained by using pbcopy to put it in your Mac’s Clipboard, then pasted in the cloud GitHub/GitLab GUI.

The “rsa” in the default file name “id_rsa.pub” refers to the clever mathematicians who figured out how to encrypt and decrypt files without exchanging secret passwords. It works by generating two files – the public and private key file “id_rsa” – into your account’s ~/.ssh folder.

SSH (for secure shell) is the same mechanism the Linux team uses to secure its bash terminals. In fact, Git was designed by Linus Torvold and his team who developed the Linux kernel and its secure shell (SSH).

The ssh-keygen program that generates the rsa files comes with all Linux and Mac operating systems. First cd to the .ssh folder, then run the program. If you are using it for the first time, press Enter for all the defaults.

When there are multiple accounts, you can’t use default names and also must edit the config file to make sure the different accounts are specified correctly.

Windows users need to download the puttygen program.

When the Git client runs, it retrieves the private key in the id_rsa file to encrypt what it sends. The GitHub or GitLab cloud service decrypts using the public key.

  1. When this script runs, one can optionally use the built-in command “cat” to retrieve the contents of the public key for later use by the GitHubAPI:

    export RSA_PUBLIC_KEY=$(cat ~/.ssh/id_rsa.pub)
  2. Alternately, list the files in folder .ssh to confirm the file size:

    ls -a ~/.ssh

    Two-factor authentication and repo URLs

    Next, instead of git init creating a purely local repository and its need for being in a repository folder, we now look at use of git clone commands to bring in remote repositories from the Cloud to your local machine.

    When pulling in a repository belonging to some other account you don’t have right to change, use the “HTTPS” URL format, such as:


    PROTIP: If we have setup two-factor authentication (2FA), we should use the “SSH” or “git@” form to specify URLs we have right to change, such as:


    We should use two-factor because it is good security practice. The “two” means we use an alternate form of identification, in a number from an authentictor app (such as Google Authenticator) on that smart phone you’re always looking at.

    PROTIP: –depth=1

    BTW: When cloning another account’s repo, some add –depth=1 or –recursive

    • --depth=1 says only clone the latest version, to save disk space locally by not having previous version history (nor branches) on your machine.

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

    Fork from another repository

    Since our objective is to work on open source repositories we don’t own, we now bring in a repository from another account we don’t own.

    VIDEO: On the GitHub/GitLab website, we can manually click fork to bring it under our own account. We would then have a right to change the our own repository.

    Fork using Hub add-in to Git

    BLOG: Instead of doing that manually, we have a way to do that in a command-line script.

  3. The forked repository created from a previous run needs to be first deleted from GitHub/GitLab, manually because there is no “hub delete repo”.

    Click Settings tab. Scroll down to click “Delete this repository”. Type the repo name. Click the red “I understand…”.

    [ Whoops ]

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

    Un-comment the command to pause to read your response of pressing any key after doing the action stated.

  4. Use hub to clone before forking.

    cd && cd "$WORKSPACE_FOLDER"

    PROTIP: Instructions at https://hub.github.com assume you added an alias with a command such as “alias git=hub”. So I say don’t do that because I only use Hub just for forking. So use “hub” instead of “git” in commands.

    Hub expects the upstream remote to be named “origin”, so first clone the other repo:

    hub clone hotwilson/some-repo

    Hub creates the repo with remote of “origin”. That’s counter to how we’re using that remote name in this script. But hub requires it for its fork command:

    hub fork hotwilson/some-repo

    You may need to provide your cloud account credentials if they are not cached.

    Hub’s fork command returns:

    Updating wilsonmar
    From git://github.com/hotwilson/some-repo
            * [new branch]      master     -> wilsonmar/master
    new remote: wilsonmar

    To make the remote names the way I want:

    hub remote add myself
    git remote rename myself origin
    git pull --all

    The git pull –all command returns this:

    Fetching upstream
    Fetching origin
    Already up to date.

    BONUS: Set default branch

  5. Verify using a git remote -v to show it looks like this:

    origin   git@github.com:wilsonmar/some-repo.git (fetch)
    origin   git@github.com:wilsonmar/some-repo.git (push)
    upstream git://github.com/hotwilson/some-repo.git (fetch)
    upstream git://github.com/hotwilson/some-repo.git (push)
  6. If you want, manually see the new fork on your cloud account at:

    You may want to un-comment the command to pause to read your response of pressing any key after doing the action stated.


  7. When a repository is cloned, Git automatically 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 in its history, such as README.md out to the repository’s Working Directory, as if you typed git checkout master.

    [ Whoops ]

    So remember to cd into the repository folder:

    cd some-repo

    PROTIP: Forgetting to cd into a newly cloned folder is a common mistake.

  8. For a listing of repository files and folders in the Git working directory for the current git checkout, which is “master” when first initialized:

    ls -al
  9. List the remotes:

    git remote -v

    This information is also presented by the git branch command.

    Branch list

  10. A git branch command shows us the branches defined in the repository (in a read-only operation):

    git branch -avv

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

    Alternately, shortcut:


    An example of the response:

            * master                6110cb1 [origin/master] Update ...
      remotes/origin/master 6110cb1 Update ...
    • The asterisk (*) marks the current branch – master, the default branch name.

    • 6110cb1 in this example is the SHA hash prefix of the last commit made.

    • The default remote is origin with default branch master.

    Alternatively, identify just the current remote and branch using this command:

    git symbolic-ref --short HEAD

    BTW: A Git alternative to the Bash “pwd” (present working directory) command is:

    git rev-parse --show-toplevel

    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.

4.x Branch and edit locally

Here’s where you add value to that Open-Source repository.

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

  • 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.

[ Whoops ]

### New branch with commit

There are two ways to create a new branch.

  1. The easiest way is to specify a new branch name after a dash b (-g) with as part of a git checkout such as “feat1” (feature1), to associate new changes:

    git checkout -b feat1

    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.

    BTW: Unlike the Subversion client, which locks branches to all others, when a Git branch is created, all files are still available for change.

    [ Whoops ]

  2. List branches to compare with another git branch command:

    git branch -avv

    Notice the asterisk is now at the new branch “feat1”.

    Concatenate to .gitignore

  3. The script makes changes by using echo commands, such as:

    echo "peace" >newfile.md

    The single “>” clears out all contents and replaces it with that one word.

    echo -e "\n.DS_Store" >>.gitignore

    >> concatenates to the bottom of the file

    -e enables specification of escape characters

    \n` is an escape character for new line

    Alternately, you can of course edit files manually, we can use vim or another text editor (such as nano, atom, etc.) to change contents inside files.

    vim README.md

    The md in the file name designates markdown format. The README.md file Git hosts can create with this specific name to describe each repository.

    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.

    PROTIP: Remember to save the file before switching.

  4. Display the last 3 lines in the file to confirm:

    tail -3 .ignore

    This is better than using the cat program which displays all lines.

    git status -s -b [gsl]

  5. To detail the status of changes to the repo:

    git status -s -b

    Alternately, this command is used so often that Mac users create a shortcut in ~/.bash_profile:


    The response is:

    ## feat1
     M .gitignore

    ## marks a branch

    M marks a file Modified from Git

    ?? marks a file untracked by Git, one that has never been added to Git.

    Hide file from git status

    EXTRA: PROTIP: To have git status not display a particular file:

    git update-index .DS_Store

    PROTIP: Changes to files that should not be pushed up, such as the secrets.sh file, should be marked:

    git update-index --no-skip-worktree secrets.sh

    NOTE: Pulls of changes upstream in GitHub updates the local file.

    If both the local and upstream file are changed, Git outputs a conflict message.

    Skipped files are flagged with a “S” in this list command:

    git ls-files -v|grep '^S'

5.x Local config, add, commit

  1. Before adding to git’s Staging for the current repository, you may want to configure the local attribution just for the current repository:

    cat .git/config

    The first part of the file are repository-specific configurations:

    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true

    The second part:

    [remote "upstream"]
    url = git://github.com/hotwilson/some-repo.git
    fetch = +refs/heads/*:refs/remotes/upstream/*
    [branch "master"]
    remote = upstream
    merge = refs/heads/master
    [remote "origin"]
    url = git@github.com:wilsonmar/some-repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*

    Optionally, override the global attribution with this:

    git config          user.name "Wilson Mar"
    git config          user.id "wilsonmar+GitHub@gmail.com"

    This is done by issuing a git config command without the “–global” parameter.

  2. Before adding anything to the Git index file:

    git diff --cached

    --cached is a synonym for --staged.

    There should be no response when nothing has been put in Git staging.

  3. 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, recursively inside sub-folders as well.

    The dash capital A parameter specifies that deleted files be processed.

    PROTIP: Many prefer to specifically add individual files to go into each particular commit, which works on all files added to staging. Instead of the dot, several files can be specified on the same command.

    Alternately, to add all the files modified (not new files created and untracked):

    git add -u

    Git has a “two-phase commit” approach. Files are added to Git’s index file. Then all files staged in the index are committed together by the git commit command.

    [ Whoops ]

  4. Do another diff to see how git add changed:

    git diff --cached
  5. Do a git status again:

    git status -s -b

    Notice the green “M” and “A” showing it’s being tracked:

    M  .gitignore
    A  newfile.md

    git commit

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

    git commit -m"Add .DS_Store to .gitignore @hotwilson"
    • A space is not needed between the m and the left quote of the message.

    • If you don’t specify the dash m, Git will display a file containing comments as a prompt. In that file, any line beginning with the # comment character will be ignored and not be part of the message. Save and exit the text editor.

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

    A sample response:

    [feat1 e2265f6] Update for show
     2 files changed, 3 insertions(+)
     create mode 100644 newfile.md

    [ Whoops ]

    Local Reflog

  7. List history of actions that have occurred on the local machine.

    git reflog -5

    -5 specifies only the most recent 5 lines.

    Example output:

    9349be6 HEAD@{1}: commit: double quote removed for confusion
    9eb57bc HEAD@{2}: commit: mention gs shortcut 

    Each commit is put at the head of the chain of all commits made throughout history. That 7-characters is the prefix to a much longer “hash code” that Git generates from each commit. Content within Git is very difficult to alter because any change would result in a different hash. And insertions would break the chain of commits.

    • Locally, entries are pruned (removed) automatically after 90 days (by default).

    Local Log

  8. List commits that have occurred on the local machine:

    git log --pretty=format:"%h %s %ad" --graph --since=1.days --date=relative;git log --show-signature -n 1 | tail -n 10 

    | tail -n 10 limits the output to 10 lines

    Rebase to squash locally

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

    • 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 versions.

    git rebase -i

    -i for interactive

    See my blog on this.

    Study http://wilsonmar.github.io/git-rebase for step-by-step instructions. Then return here.

6.x Push and Push with tags

  1. The git push command sends to a remote repo what has been committed for a specific branch. For the default origin remote and master branch:

    git push

    [ Whoops ]

    Alternately, Bash users who have setup an alias can use this which includes a git add and commit:

    gas “JIRA #1234”

    This alias adds all changes and commits them all with a static “update” in message:


    The two aliases above include a git push for maximum convenience.

    GitHub Enterprise uses can push to multiple remotes with one command:

    git push production,staging

    If you see an error message like this, it means you don’t have permissions:

    ERROR: Permission to hotwilson/some-repo.git denied to wilsonmar.
    fatal: Could not read from remote repository.
    Please make sure you have the correct access rights
    and the repository exists.

    Two-factor authentication

    If you setup 2FA (two-factor authentication), Git will prompt you for a username and password. Because of 2FA, GitHub expects a personal access token. If you type in your account password, GitHub responds with “fatal: Authentication failed for https://github.com/…”.

    So when using 2FA, in a Terminal session, cd into .git, then edit file config to change, for example:

    url = https://github.com/wilsonmar/futures


    url = git@github.com:wilsonmar/futures

    Notice the git user name instead of “https://”. Behind the scenes, SSH protocol is used, but that doesn’t need to be specified here.

    Also notice the colon character instead of the slash.

    cd back up out of .git to the repo’s root folder before doing a git commit and push, or you’ll see error message “fatal: this operation must be run in a work tree”.

    Push tags

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

    git tag -a v1.2.3 -m\"New version\"

    -a adds the tag permanently. Without this parameter, the tag remains local.

    The v1.2.3 format is called “semantic versioning” described at http://semver.org

    PROTIP: This stores the tag within folder .git/refs/tags/.

  3. Tags require an additional git push command to be pushed to GitHub.

    git push origin --tags

    [ Whoops ]

    CAUTION: An additional push commands is needed for tags because it uses Git notes features. Since notes were not designed for many notes/tags, using them is known to slow commits.

    Delete branch

  4. 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
  5. 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.

7.x Pull and Merge

Unless you have been designated a committer in the upstream repository, you can’t directly push changes to it like you can with your own repo.

But you can send a request to committers of that upstream repo to pull and merge changes from your forked repo.

Each Git hosting service has their own GUI to make such requests.

GitHub calls them Pull Requests.
GitLab calls them Merge Requests.

That is why my script has “Press when ready” steps - for all three manual actions below:

### 1. Create a pull/merge request

  1. To make a pull/merge request, log into your Git hosting GUI and navigate to your origin repo.

  2. Click Compare. If there are differences, you’ll see a green “Create pull request”.

  3. Type in a Title for the request, such as “For the class”.

  4. Click the green “Create pull request”.

    You can make more changes.

    Alternately, there is a command to request the pull from the upstream repo. For example:

    git request-pull v1.2.3 https://github.com/hotwilson/master  master</em>
    • 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.”

    See https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/

    2. Squash and merge

  5. Next, on a different browser, login as the committer of that upstream repo.

    If you don’t own the account, talk to the owner (class instructor).

  6. Navigate to the repo that was forked, such as hotwilson.

  7. Click the “Pull requests” tab.

  8. Check the request that you added in the step above.

  9. If there are no conflicts, click Squash and merge (or in other words, accept) the request.


  10. Click “Confirm Squash and merge”.

    A purple “Merged” appears at the top of the screen.

### 3. Add file to upstream

While still in the upstream repo (hotwilson), establish conditions for the next set of steps, in the upstream remote, make a change such as adding a file. 
  1. Click “Create new file” button.

  2. Type in a new file name. I like a date and time such as


  3. Click under “Edit new file”.

  4. Type in some text, such as “hello”.

  5. Press Shift+down arrow to scroll to the bottom of the page.

  6. Click the green “Commit new file”.

8.x Update origin with upstream changes

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

See https://help.github.com/articles/syncing-a-fork/

  1. Open a different browser (Firefox or Brave) to login and make a change. In the script there is a message:

    Press any key after adding a file

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

    git remote add upstream "https://github.com/$OTHER_ACCT/$OTHER_REPO"

    which by default translates to:

    git remote add upstream https://github.com/hotwilson/some-repo

    It’s OK to see

    fatal: remote upstream already exists.

    Otherwise, expect no output returned from this command if ok.

    [ Whoops ]

  3. To verify whether the origin remote was created, as usual, with the repo.

    git remote –v

    -v is for verification.

    Expect to see both your origin and upstream remotes listed.

    origin   git@github.com:wilsonmar/some-repo.git (fetch)
    origin   git@github.com:wilsonmar/some-repo.git (push)
    upstream git://github.com/hotwilson/some-repo.git (fetch)
    upstream git://github.com/hotwilson/some-repo.git (push)
  4. 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.

    git fetch upstream master

    Example output:

    remote: Counting objects: 2, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 2 (delta 1), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (2/2), done.
    From git://github.com/hotwilson/some-repo
            * branch            master     -> FETCH_HEAD
    8843446..b33e370  master     -> upstream/master
  5. git checkout master

    Already on 'master'
    Your branch is behind 'upstream/master' by 1 commit, and can be fast-forwarded.
      (use "git pull" to update your local branch)
  6. List delta file names only

    git diff HEAD @{u} --name-only

    Sample output:


    git merge upstream

  7. git merge upstream/master”

    git merge upstream/master

    Sample output:

    Updating 8843446..b33e370
     newfile | 1 -
     1 file changed, 1 deletion(-)
     delete mode 100644 newfile

    Notice the slash separator between the upstream remote and the upstream branch (master).

    CAUTION: Once you start a merge, nothing else can be done until you reconcile ALL conflicts. One cannot save a partially-resolved merge. There is no way yet of testing a partially merged tree. You can’t go back if you make a mistake.

    [ Whoops Ref ]

  8. git push origin master”

    git push origin master

    Sample output:

    Counting objects: 2, done.
    Delta compression using up to 8 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (2/2), 608 bytes | 608.00 KiB/s, done.
    Total 2 (delta 1), reused 0 (delta 0)
    remote: Resolving deltas: 100% (1/1), completed with 1 local object.
    To github.com:wilsonmar/some-repo.git
    8843446..b33e370  master -> master
  9. 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

    PROTIP: 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

9.x Update your origin repository

In this section we change something on GitHub/GitLab and then fetch it locally, see what changed, and merge it.

  1. “Change something on the origin in GitHub wilsonmar/some-repo …”

    Press any key after adding a file ...
  2. Fetch (instead of pull)

    git fetch origin master

    Sample response:

    remote: Counting objects: 2, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 2 (delta 1), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (2/2), done.
    From github.com:wilsonmar/some-repo
            * branch            master     -> FETCH_HEAD
    9c9468b..bbac92d  master     -> origin/master
  3. See what changed:

    git diff master..origin/master

    Sample response:

    renamed: me 2018-09-04b to 2018-09-04-a
    added: smoky
    @@ -0,0 +1 @@
    added: xome
    @@ -0,0 +1 @@
  4. Merge tracking branch:

    git merge origin master -m"OK" --no-edit

    Sample response:


GitHub API

  • See https://gist.github.com/caspyin/2288960 about GitHub API
  • From https://gist.github.com/robwierzbowski/5430952 on Windows
  • From https://gist.github.com/jerrykrinock/6618003 on Mac

Set default branch

git symbolic-ref HEAD refs/heads/$DEFAULT_BRANCH
cat .git/HEAD
git branch -avv

Viewing files

  1. To see files changed vs. the tracking branch:

    git diff HEAD @{u} --name-only
  2. To see files changed, including uncommited local modifications vs. the tracking branch:

    git diff @{u} --name-only
  3. To see lines changed vs. the tracking branch:

    git diff master origin/master

    Compare tracking branch

  4. Before you fetch/pull, display incoming changes from remote origin master branch :

    git log ^master origin/master

    Nothing is returned if no changes were found.

  5. To see the difference introduced by fetch:

    gitk origin/master..master

    Alternately, some others prefer using 3rd-party merge utilities.

  6. To display outgoing changes before you push:

    git log master ^origin/master
  7. then a

    git checkout master

    [ gfu is the shortcut ]

    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 push origin master

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

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

    [ Whoops ]

    Changes in my repo

  9. In GitHub, on a repo you can change, create a new branch named “sample1”, create a new file, click the pencil to edit the file. Save it. For example, create a new file and change something.

    Even if you are not working with a repo that others update, you yourself may update files on GitHub.

fetch –dry-run

  1. Locally, when a team creates branches of the master, everything that the team is working on can be seen with one command:

    git fetch --dry-run

    A sample response is this from Scott Chacon:

    remote: Counting objects: 3032, done.
    remote: Compressing objects: 100% (947/947), done.
    remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
    Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
    Resolving deltas: 100% (1993/1993), completed with 213 local objects.
    From github.com:github/github
            * [new branch]      charlock-linguist -> origin/charlock-linguist
            * [new branch]      enterprise-non-config -> origin/enterprise-non-config
            * [new branch]      fi-signup  -> origin/fi-signup
    2647a42..4d6d2c2  git-http-server -> origin/git-http-server
            * [new branch]      knyle-style-commits -> origin/knyle-style-commits
    157d2b0..d33e00d  master     -> origin/master
            * [new branch]      menu-behavior-act-i -> origin/menu-behavior-act-i
    ea1c5e2..dfd315a  no-inline-js-config -> origin/no-inline-js-config
            * [new branch]      svg-tests  -> origin/svg-tests
    87bb870..9da23f3  view-modes -> origin/view-modes
            * [new branch]      wild-renaming -> origin/wild-renaming

    PROTIP: Branches such as “origin/wild-renaming” in the sample above is a remote tracking branch. File in your working folders are not updated by git fetch, which is the reason why we use it rather than git pull. Local branches don’t have the remote prefix and slash.

    [ Whoops ]

Pull rebase with git up alias

Use the Git utlity which resolves conflicts: It tries to find out which commits are really your local ones, and which had come from upstream in an earlier fetch.

git pull --rebase --autostash

As noted here, this finds the starting point for rebase by looking at the reflog of the remote tracking branch (the tips of successive git fetch operations on origin).

  • https://coderwall.com/p/7aymfa/please-oh-please-use-git-pull-rebase

--autostash (introduced in git 2.9 of June 2016) automatically performs stash commands before the pull so that pull works even on “dirty” trees. The automatic commands are git stash save before the pull, and then when done git stash pop. This added logic which solved a trap in automation via aliases such as:

git stash && git pull --rebase && git stash pop

If there’s nothing to stash, the first command will do nothing, but then stash pop will unstash some random stuff from before.

CAUTION: There still may be changes introduced which cause a conflict when the stash pops after a successful rebase. An example:

Created autostash: 094ad5c
HEAD is now at d39c25c repo1 - readme
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 6b6e1d4262fd5bc8d2b974f81222003a6c67fea6.
Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run "git stash pop" or "git stash drop" at any time.
  1. If you like the above approach enough to use it a lot, create a Mac or Git alias.

    On a Mac, you can type only 3 letters (gup) by defining in your ~/.bash_profile:

    alias gup='git -c rebase.autoStash=true pull --rebase'

    Alternately, on any system, define this command:

    git config --global alias.up '!git pull --rebase --autostash'


    git config --global alias.up '!git fetch && git rebase --autostash FETCH_HEAD'

    This would enable you to type only this (reminescant of Subversion):

    git up

    The above alias definitions obsoletes git-up and the Python port on Windows as well as previous suggestion to define a global default (saved in the global .gitconfig file) which automatically inserts --rebase parameter onto git pull commands:

    git config branch.autosetuprebase always

    [ Whoops ]

Trunk-based Development in MS Release Flow

Thoughtworks advocates for their Trunk-Based Development instead of using different branches, so every commit keeps the repository production ready.

VIDEO: Git patterns and anti-patterns for successful developers [20:25] at Microsoft Build conference May 7-9, 2018 by Edward Thomson (@ethomson) about Visual Studio Team Services says Microsoft now recommends Trunk-based Development, where coding is based on the trunk, which is a synoym for the master branch. Make Small, simple changes and integrate into the master branch. easier to code review small chunks fewer merge conflicts encourages pull requests simpler to ship, faster velocity

Keeping code isolated from other developers is Technical Debt. So code in feature toggle codes which allows features to be turned on or off in production.

[8:51] GitHub Flow adds an additional step

  1. Master is locked temporarily
  2. Merge master into the branch to deploy
  3. Build and run test suite on the branch to deploy
  4. Deploy the branch to canary servers; monitor for problems
  5. Deploy the branch to production servers; monitor for problems
  6. Merge the pull request into master; unlock the master branch

[15:20] Microsoft does “Release Flow” releases to production at the end of 3-week sprints.

Like GitHub, Microsoft fixes bugs in master first so that they can’t be forgotten and create the same error in the future. The changes are cherry-picked into the release branch.

See https://aka.ms/releaseflow dated April 19, 2018

Other videos and articles

More Videos

YOUTUBE: from GitHub Education Professional Guides: Workflow Strategies has video illustrations

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-basics software is described by this video and blog from 2013 by @KBasarab and at:

  • http://datasift.github.com/gitflow

  • https://blog.axosoft.com/gitflow/
  • https://leanpub.com/git-basics/read
  • https://www.git-tower.com/learn/git/ebook/en/desktop-gui/advanced-topics/git-basics



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 Markdown text

  4. Git basics (script)
  5. Git whoops (correct mistakes)
  6. Git messages (in commits)

  7. Git command shortcuts
  8. Git custom commands

  9. Git-client based workflows

  10. Git HEAD (Commitish references)

  11. Git interactive merge (imerge)
  12. Git patch
  13. Git rebase

  14. Git utilities
  15. Git-signing

  16. Git hooks
  17. GitHub data security
  18. TFS vs GitHub

  19. GitHub actions for automation JavaScript
  20. GitHub REST API
  21. GitHub GraphQL API
  22. GitHub PowerShell API Programming
  23. GitHub GraphQL PowerShell Module