Category Archives: Git

Add Existing SSH Key To OSX

26 May 2016

Here are the steps to setup your Mac to work with your Git repo with the same key that you’ve been using on your other development machines.

Copy your id_rsa file into your “.ssh” folder which is a child of your home folder. This folder is hidden but can be easily revealed via this terminal command:

$ open ~/.ssh

Now that your .ssh folder is open in the finder you can easily drag/drop/copy your pre-existing id_rsa file into it.

Next, check to see if the SSH agent is running:

$ ps -e | grep ssh-agent
20207 ?? 0:00.53 /usr/bin/ssh-agent -l // its running

If it is not running:

$ ssh-agent /bin/bash

Check to see what identities have been loaded:

$ ssh-add -l

Now load your identity with this command:

$ ssh-add ~/.ssh/id_rsa

Finally, check again for the list of identities – there should be one more than before (or just one if there weren’t any previously).

$ ssh-add -l
2048 SHA256:41ZyLeEcsdfwefsdfLegsdftQdm0Ew /Users/my_mac/.ssh/id_rsa (RSA)

Brackets & Git Integration

14 Mar 2016

If you haven’t already discovered Brackets then IMO you owe it to yourself to download it and check it out. Its an Adobe-backed open source text editor geared towards web development with many exciting features. 2016 will see Brackets being brought into Adobe Dreamweaver as the default code editor (incidentally, Intel’s XDK already uses brackets) along with Edge Reflow’s responsive design features.

Anyway, one of the cool things about Brackets is that various devs have created plugins to integrate Git into Brackets, such as UnGit or Git Branch. The most feature rich of them is a plugin called Brackets Git. In fact, according to the publicly viewable Trello card-wall it is likely to be integrated into Brackets as part of the application.

So then, lets take a look at Brackets Git. I’ve just started working on a project – I ran npm init and git init to help get things started.

Selecting and Creating Branches

How many times have you started working on a project without realizing that you were in the wrong branch? Brackets Git provides a branch drop-down in the file pane showing you your current branch and also facilitates branch switching and creation.


Notice the current branch – I’m currently in the Master branch and I can verify by using the git branch command in Git Bash. As the current branch is always visible It’s easy for me to see the current branch without leaving Brackets.

The branch drop-down also lets me create new branches. By clicking on the Git icon within the file pane, you’ll see a list of available branches (if any) and the option to create a new branch:



Once you enter your new branch name and click “OK” the branch is created and it becomes the current branch (akin to doing git checkout -b branch-name). As before you can check via Git Bash to see if this is what truly happened.

Hereafter, you can select your working branches via the branch drop-down in the file pane.

On a side note, I created a test branch via this method and verified it in Git Bash. Next I deleted the branch using Git Bash and then switched to Brackets to see how the plugin would handle this. It handled it fine with no issues and correctly displayed the changes made via bash.

One thing I observed was that once in a while if I create and change to a new branch via the console $git checkout -b branch-name-here that the branch drop-down didn’t update to indicate both the existence of the new branch and that the new branch had been checked out. To resolve this I selected a different branch within Brackets which caused the branch drop-down to refresh and thus reveal that branch in the list.

NOTE: When creating a new branch you should realize that the new branch will always be based on your current branch!!!! If you want to create a new branch off of master then always select the master branch ***before*** creating your new branch!

Common Git Tasks -Tracking, Adding and Committing Files

Ok, we’ve seen how we can use the branch drop-down to quickly create and move between branches, how about tracking, adding and committing files? Here’s a screen shot of the same project but this time with the Brackets Git UI opened – you access it by clicking the Brackets Git icon in the plugin toolbar.


The Brackets Git interface needs some explanation – the first thing you might notice is that my project has untracked files. Being that this is a brand new project and nothing has been committed I need to do my initial commit. I don’t need to use the console for this as Brackets Git can help complete that task without leaving the editor.

Tracking files (git add)

The equivalent of git add is accomplished simply by checking the check boxes to the left of the “Untracked” text. Before I use Brackets Git to do this lets confirm what I’m seeing in Git bash – that I have two untracked files:


Git Bash shows me something a little different, that I have an untracked package.json and an untracked src/ folder. Within that folder lies the untracked index.html – its a small discrepancy but one that Brackets Git feels isn’t worthy of telling you. Lets use Brackets Git to do the equivalent of issuing a git add command.


As indicated above you can see that the two files are now being tracked. Lets see what Git bash shows us now that we’ve done this within Brackets.


As you can see both the package.json and the src/ directory are now being tracked.

Committing Files (git commit)

As our two files are now being tracked its time to commit them. Clicking the “Commit” button reveals a “Git commit…” panel within Brackets:


Whats cool here is that Brackets Git shows you what was edited when you do a commit, akin to doing a git add -p. The “EXTENDED” button lets you type a longer message. I imagine that if you don’t click the “EXTENDED” button that you are in reality doing a git commit -m “message here” and if you do click “EXTENDED” you are doing a git commit which at the console or Git Bash triggers VI or some other text editor to appear. For now I won’t try the “EXTENDED” option but will do so shortly.

So then, my commit message was “My initial commit”. After entering the message and hitting “”OK” Brackets UI updates and tells me that the working directory is clean:


Lets verify with Git bash:


And lets view the commit:


Ammend the last commit

You may have noticed the option to “Ammend the last commit” in the “Git commit…” dialog. Lets give that a try – I’ve edited the index.html so that its no longer an empty file. Via Brackets Git I’ve added it and have clicked on the “Commit” button. In the screen shot below you can see that I’ve also checked the “Amend last commit” checkbox – and that by doing this the message text field is populated with the previous commit’s message.


To make it obvious that I’m amending the commit I’ll change the commit message to “My initial commit (2)” – and will click the “OK” button.

As before Brackets Git updates and tells me that the working directory is clean. Lets take a look at Git Bash to see what happened.


As expected, the previous commit was amended with the new commit message.

Commit files with the Extended option

Lets try adding an “extended” message. If you don’t already know, the first 50 characters of a commit’s message is used by Git as the commit’s subject line. That’s why you see the character counter next to the message field. By clicking the “EXTENDED” option you’ll see the single-line text field change into a multi-line text area. The first line must still be less than 50 characters but now you have more room to enter relevant text to describe your commit. The section following this one will explain why this matters.

So then, here’s what the commit message field looks like when the “EXTENDED” button is clicked:


Now whats cool about the above screen capture is that you are seeing what was changed in the committed file – it pays to review the edits you are about to commit before you commit them. If there were more than one file you would just scroll through them all via this dialog. Unfortunately, you can’t cherry pick edits…. some things you just have to do in Git bash….

Ok then, lets add a more verbose commit message, taking care to leave the first line below the 50 character limit:


As you can see the first line (our commit subject line) is less than 50 characters – but the counter keeps going as I type. As soon as I exceed 50 characters in total it turned red. I suppose the plugin author may want edit the plugin to only count the first line of text – maybe stop counting at the first line break / carriage return.

Anyway, leaving a blank line in between the first (subject) line and the body of the message is how you distinguish between the two. Ok, time to commit by clicking the “OK” button.

Like the previous commits, the Brackets Git interface updates to let me know that there is nothing to commit and that the directory is clean. Lets look at what happened via Git Bash.


The above screen capture verifies the commit and you can see the second commit and its longer message.

Show history / Show File History

You may have noticed that I was using git log in the previous sections to verify that Brackets Git is doing as advertised. Well, you can do the same thing within Brackets Git via the History and File History buttons:


Recall in the previous section that the first line of a commit message is that commit’s subject, and that it must be less than 50 characters? this is where you see the impact of a short commit subject line – click one of the two history buttons – notice what is displayed as the subject of our commits and that the extended text of the most recent commit is not displayed:


Above, circled in red, is our 50 character or less subject line for the commit where we added a separate description using the “EXTENDED” commit option. You can see how neatly it fits in the window. Imagine trying to read something much longer – it wouldn’t fit and would be truncated at the 50 character limit. That’s why commit messages should be short and concise and the extended option should be used if a longer / more detailed description is warranted.

Inspecting Commits

You can read the entire commit message along with viewing the details of the commit by clicking on the commit itself. The commit details will appear within the main editor’s window:


In the above example you can see that I’ve clicked on the most recent commit and that I can see the extended text of that commit. You can also inspect the individual file changes by toggling the arrow next to each file name or by clicking on the “Expand all” button in the upper right corner.

The screen capture below illustrates viewing a commit’s history and file changes:


Pushing to a repo

Alright, its time to see if we can push using Brackets Git. Everything I’ve done up to this point has happened locally. I’ve just logged into my account and created a test repo called… (drum roll)… “test-repo’. I need to now let Brackets Git know about it. Lets start by clicking the “Pick preferred remote” button where the option to “Create new remote…” will appear.


Selecting the “Create new remote…” option will result in a wizard walking you through the steps of adding a new remote.

First enter the name of the remote repository:


Click”OK”, next enter the address of the repository:


Click “OK” again and you will notice that the Push/Pull buttons have become enabled.


Now its time to push our changes – usually you would need to do this via Git bash:

$ git remote add origin
$ git push -u origin master

Brackets Git handles the above via a dialog with some options – click the “Push” button to see that dialog:


For my purposes the default settings are fine. All I need to do is to provide my credentials, so I enter my username and password and click on “OK”. A console of sorts appears briefly followed by this dialog:


To verify the above I visit the repo itself at GitHub. I see exactly what I expect to see – the single Master branch, my 3 commits and the associated commit messages.


Launching Git Bash

Lastly there are some things that can only be done via a console. Brackets Git provides an easy way to launch the console via the “Bash/Terminal Console” button.


GIT Help

26 Feb 2016

If you’re like every other developer (including myself) your go-to for help is Google – just type a question and a whole sea of answers are there to choose from. Git is pretty deep in terms of its functionality and many features are rarely used thus Google is often our friend in that regard. Depending on your familiarity with Git using the help features that are built into it might speed up your workflow when you wonder what the proper way to use a Git command is.

Inline Help

I use Git Bash – the command line interface for Git and I wondered the other day if there were any man pages for it. A search online reveals that there are some installable packages or other alternatives to get “man” functionality… but before I started that search I stumbled upon a man page without installiing man….

$ git add –?
error: unknown switch `?’
usage: git add [options] [–]
-n, –dry-run dry run
-v, –verbose be verbose
-i, –interactive interactive picking
-p, –patch select hunks interactively
-e, –edit edit current diff and apply
# etc…… the above list is truncated, issue the command in Git Bash to see the entire output

Notice that I used a switch that Git didnt understand and the result was a man page for the Git command. I did search for how to not “trick” Git into giving me a man page but only found pointers towards installing man files. The above works for me for now even if Git considers it to be a mistake.

Jump to Online Documentation From The Console

git help offers a quick shortcut to the online documentation for any command. See this example:

$ git help command-here

This command returns a a list of all Git commands:

$ git help -a

Common Git Guides

Git will reveal a list of useful guides via git help -g as seen below:

$ git help -g
The common Git guides are:
attributes Defining attributes per path
glossary A Git glossary
ignore Specifies intentionally untracked files to ignore
modules Defining submodule properties
revisions Specifying revisions and ranges for Git
tutorial A tutorial introduction to Git (for version 1.5.1 or newer)
workflows An overview of recommended workflows with Git

To Launch any of these guides simple issue a git help followed by the name of the guide and the guide will launch in your browser.

$ git help guide-name-here

For example:

$ git help tutorial
$ git help workflows

View a List of the Most Commonly Used Git Commands

Its also possible to use git help to pull up a list of the most commonly used Git commands with a short description of each:

$ git help -m
usage: git [–version] [–help] [-C ] [-c name=value]
[–exec-path[=]] [–html-path] [–man-path] [–info-path]
[-p|–paginate|–no-pager] [–no-replace-objects] [–bare]
[–git-dir=] [–work-tree=] [–namespace=]
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
diff Show changes between commits, commit and working tree, etc
fetch Download objects and refs from another repository
grep Print lines matching a pattern
init Create an empty Git repository or reinitialize an existing one
log Show commit logs
merge Join two or more development histories together
mv Move or rename a file, a directory, or a symlink
pull Fetch from and integrate with another repository or a local branch
push Update remote refs along with associated objects
rebase Forward-port local commits to the updated upstream head
reset Reset current HEAD to the specified state
rm Remove files from the working tree and from the index
show Show various types of objects
status Show the working tree status
tag Create, list, delete or verify a tag object signed with GPG

And as before, you can jump directly to the online documentation for the command simple by issuing a git help followed by the name of the command:

$ git help command-name-here

Git: Working With Branches

04 Feb 2016

Quite often when using version control (Git, GitLab) you will need to create a new branch where you can develop in isolation from other developers / the master branch. Below are the basic branch-related commands to help you get started.

When to Create a Branch

You should create a branch that encapsulates a single train of thought that depends on your workflow. If, for example, you are creating a product which has a list of features you can create a new branch per feature. This would allow your various team members to work on the same project on different features without overwriting each others work should the various features happen to utilize some common files.

Given the above, you may still have some code collisions when you merge in which case GIT will alert you to that fact so that you can manage resolve the conflicts as needed.

Another scenario would be if you want to experiment with something without directly impacting the master branch. You could then create a new local branch and feel safe knowing that if what you’re doing doesn’t work you can easily return to the master branch to create yet another branch based on the master sot that you can pursue the issue in a different way.

For information on a workflow that utilizes branching view this article: A successful Git Branching Model.

Create and Checkout a New Branch

You can create and checkout a branch using a one-liner:

$ git checkout -b new-branch-name

Or use two separate commands:

$ git branch new-branch-name
$ git checkout new-branch-name

Branch names should follow a naming convention, such as:

  • Adding new features:
    • feature/user-login
    • feature/display-user-profile
  • Resolving bugs:
    • bugfix/resolve-form validation-issues
    • bugfix/fix-layout-issue-on-ios
  • Or better yet, if you are Scrumming then you should follow your stories and tasks:
    • story/login/create-login-service
    • story/login/integrate-login-service-w-frontend
    • story/login/layout-login-page
    • story/list-products/create-product-service
    • story/list-products/import-database
    • story/list-products/integrate-product-service-w-frontend
    • story/list-products/layout
    • etc…

The naming conventions allow us to more easily manage our branches.

View All Branches

To view all the branches in the repo that you have worked on issue the following command. The resulting list will place an asterisk in front of the currently checked out branch.

$ git branch

To View All Branches in the Repository

By default you will only see those branches that you have created. Other members of the team may have pushed branches that you don’t yet see in your copy of the repo.

Viewing Remote Branches

To view remote branches issue the following command:

$ git branch -a

The result of the above might look like:

$ git branch -a
* master

The "remotes" are the branches that are part of the remote repo that you do not yet have a local tracking branch for.

To Create a Local Tracking Branch from a Remote Branch

Using the above example, if you want to work on the “kangaroo” branch you need to create a local tracking branch:

$ git checkout -b kangaroo origin/kangaroo

A message will appear letting you know that you were successful.

You are now in your local “kangaroo” branch. Issue $git branch to see that you are indeed in the “kangaroo” branch:

$ git branch
* kangaroo

Checkout a Branch

$ git checkout name-of-branch

After checking out a branch it is a good practice to do…

$ git pull

…to ensure that you have the latest version of the files especially if other members of your team are committing to the same branch.

When to Merge Your Branch Back Into the Master Branch

While working in your new branch you can commit as often as you like. You may even push your branch back up to Git should you need a copy there as well – which would allow other team members to download your latest committed/pushed work so that they can contribute.

Its ok though to work locally without pushing your branch to the repository. When you are done with your edits, have tested everything and feel that the changes are ready to be merged back into the master branch you can do the merge yourself or you will have to create a merge request. For the latter you will definitely need to push your branch to the repo.

To merge a branch into master assuming your working branch is called “my-working-branch”:

$ git checkout master
$ git pull
$ git merge my-working-branch
$ git push

As you can see above the first thing to do before merging your branch is to “pull” the latest copy of the master branch.

What if the Master Branch is Updated and I Need Those Updates in My Working Branch?

If you find that while you work other team members have updated the master branch and that the those changes would be beneficial to have within your own branch you can do the following from within your branch:

$ git rebase master

This will “rewind” the edits you made to your branch back to the point where the branch is at parity with master, then the master updates are applied and then Git “plays” your changes back on top of the updated master.

Generate an SSH Key Pair within Git Bash

28 Jan 2016

If you want to be able to interact with your Git account without using passwords then you need to create an SSH key pair. You will then share the public key with GitHub to indicate to your repo that your computer is trusted. The first thing to do is to create the keys.

There are a couple of ways to do this on Windows, the easiest IMO is to use Git Bash.

Launch Git Bash and then enter the following command:

$ ssh-keygen –t rsa –b 4096 –C ‘’

You will be prompted for the file name and location but the default will be shown to you, illustrated via the following example.

$ ssh-keygen -t rsa -b 4096 -C ‘’
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/Rick/.ssh/id_rsa):

Hit “Enter” to accept the default.

Next you will be asked for a password. You probably don’t want a password so that you can push to your Git repo without being asked to provide one. In that case, just hit “enter” and move on.

Below is an example showing the password step:

$ ssh-keygen -t rsa -b 4096 -C ‘’
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/Rick/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

Next you will be asked to confirm the password – once you’ve confirmed it you will see a message indicating that both the private and public key were created:

Your identification has been saved in /c/Users/Rick/.ssh/id_rsa.
Your public key has been saved in /c/Users/Rick/.ssh/
The key fingerprint is:

Two key files have been created. Next you probably need to copy the public key to your clipboard. Enter the following command to view your Public Key:

$ cat ~/.ssh/

Your key will appear within the Git Bash console – copy the key text starting with “ssh-rsa” and ending with your entire email address.

In Windows you won’t be able to simply highlight the text itself at first. Hit the “CTRL + a” key combination to select everything. This enables the ability to do a normal “click drag” text selection. Select your Public Key and hit “CTRL + c” to copy it.

From here…. you likely want to use it with your GitHub account.

Or, if you are using GitLab then follow these steps:

  1. Log into GitLab and navigate to the project.
  2. In the upper right-hand corner select the options icons (cog)
  3. Click the “SSH Keys” button in the left column
  4. Click the green “Add SSH Key” button
  5. Enter a Title
  6. Paste the public key into the key textarea
  7. Click “Add key”

If you need to see all of your public keys you can do the following:

$ ls ~/.ssh/*.pub


All content © 2012-2017.