Sunday, February 25, 2018

Git hosted by Creating a Pull Request

For some reason Git had create new names for things that already existed in computer science. The term code review was coined by Charles Babbage in 1810 so two centuries later Git decided that they would change Babbage's term "code review"  to "create a pull request." So this post describes how to create a pull request using a Git repository hosted on

Once a branch is pushed (see Git: Pushing code to a remote repository) a pull request can be generated that allows other team members to review the code. There is no mechanism to create pull requests from the command-line. Creating a pull request is done suing the web front end of the Git provider (GitHub, BitBucket, , etc.).

To generate a pull request for a Git repository hosted on , open the Git project in the web interface and navigate to Code | Branches:

To create the pull request first hover the mouse to the right of the delete icon (the trash can) until three dots (...) are displayed with the tool tip "More Actions...".

Clicking on the three dots (....) displays a context menu that include menu item, New pull reuqest:

Selecting New pull request displays the following:

Notice in the screen above the individual reviewers can be added to the pull request. Also notice that a work item (e.g. Task-335) can and should be associated with the pull request. A correct pull request is associated with only a single work item.

Once the fields have been filled in as desired, click on the Create button to create the pull request.

Saturday, February 24, 2018

Git: Pushing code to a remote repository


This is the second recipe in the series designed to inspire my team of user-interface-git-users to embrace the command-line. This post presents the commands used to determine which files have been changed in a repository and how to push to a remote repository.

Detecting changes to Git repository

After modifying files, deleting files or adding files to a Git repository, the git status command can be used to determine which files have been changed;

git status

Below the changes to a repository can be seen by invoking git status:

Using git status the files modified can be determined. Additional the files/directories added and deleted can be determined. The output is color code for those who can see color. Being color blind, I cannot read the non-white text above so I wrote a separate post to address the issue Git (for the color blind): Detecting changes to a repository.

Pushing code to a remote Git repository

The steps to pushing code to a remote repository are:

  • git add -- adds files in the directory or sub-directory to a staging area. Individual files or folders can also be specified.
  • git commit -- records the change to the repository (commits them locally) and includes a message to describe the purpose of the commit.
  • git push -- pushes changes from a local branch to a remote branch meaning your local changes get pushed up to the server hosting Git.

An example of the commands to run is as follows:

git add .
git commit -m "Task-335 completed"
git push origin Task-335

Invoking the command sequence above generated the following:

The "git add ." added all modified, created and delete files and directories including those in sub-directories. It is also possible add files or folders individual using "git add <filename>" and "get add <directoryname>".

 The message with commit should describe the action. Since Task-335 is completed there is not much to describe,. To see Task-335 the bug tracker can be used.

The command "git push origin Task-335" pushes the local changes from branch, Task-335, back to origin. The term "origin" refers to the cloned repository.

Wednesday, February 21, 2018

Git (for the color blind): Detecting changes to a repository

I am color blind. Git's command-line clearly written by developers who are not color blind. This post will present how to get around Git's use of unreadable, dark-gray-text on a black background. Here is an example of Git's use of dark-gray to indicate files have been modified (if you see the color red, why are you reading this article?):

In order to change from the dark-gray-text on a black background run git Gtatus and pipe it through more:
git status | more

An example of this is as follows:

Notice above that piping through more removes all dark-gray and makes the text legible.

Another way to fix the text issue is to swap the foreground and background colors of the console window. This works for modified but new files are markee in light green so these become hard to see.  It is even possible to set the colors Git uses. An excellent article discussing this is How to: Colours in Git.

In case Mr. Nnathan Hoad's blog link (reference above) goes away, here is the contents of his blog:

Tuesday, February 20, 2018

Git: pulling and creating a new branch from the command-line

I am working with a team that relies on Windows applications for managing source code with a Git repository. To inspire them to use the command-line (which supports Windows, OS/X, and Linux in a standard fashion), I am creating standard recipes for them to follow.

  1. Pick the branch name. A branch should be associated with a single bug or task so branch name such as Task-123 or Bug-456 are acceptable because they map to the specific work item being addressed.
  2. From a console window, navigate to the directory into which a git repository will be cloned:

  3. Running the following from the console windows (assuming the branch to be created is Task-335 (which maps to Task-335: Fix PiplelineStageStatus names (changed Free to New):
  4. git clone

    CD Server

    git checkout -b Task-335

    The URL used in cloning will depend on the Git provider used (GitHub, BitBucket, The link above is formatted for which is provided by Microsoft (for free) but is git all the same.
  5. To see the current branch simply type the following:
    git status

    Invoking "git status on a branch with no code modification simply displays the current branch name:

  • Remember "git clone" is cloning a repository not simply getting a branch as you would in TFS or SVN. The name clone is precisely what is happening.
  • The "git checkout -b" is the action that creates the new branch.