Motivation

Our project team is using the Git version control tool for most new development. I have become comfortable with the tool, but it took me a little time to reach that state. Unlike many other useful software development tools, the problem with Git is not lack of documentation; on the contrary, an incredible amount of documentation exists and is accessible via web searches.

Let me start by providing the links that I ended up finding the most useful to this Git novice:

After reviewing these and other references and tutorials on the Git version control tool, I thought yet another demonstration of the basic features might provide value. This demonstration shows a simple cross-workstation sharing workflow using a central shared repository. This demonstration uses a USB memory stick in sneakernet mode as the central repository; however, a network shared folder or a GitHub.com repository would be equivalent.

Getting Git

The easiest way to get started with Git in a Windows environment is to obtain Portable Git for Windows from here:

http://code.google.com/p/msysgit/downloads/detail?name=PortableGit-1.7.10-preview20120409.7z

In order to unpack the file, you may need the 7-Zip File Manager program from here:

http://www.7-zip.org/

Expand PortableGit-1.7.10-preview20120409.7z into any local folder, such as C:\PortableGit

After expanding the PortableGit folder contents, you will have a local copy of HTML documentation for Git in the C:\PortableGit\doc\git\html sub-folder. This includes a copy of the Git User’s Manual as user-manual.html

Launch a Git command-prompt console window by double-clicking either git-bash.bat or git-cmd.bat from within C:\PortableGit (or whatever local folder you chose).
Both command-prompt environments support the same Git commands; the difference is which operating system commands they also support.
Git-cmd supports standard MS-DOS style Windows Command-Prompt commands;
Git-bash supports Unix/Linux commands.

This demonstration uses Java software development and tests application execution on
Windows and Linux environments, so the examples use the Git-bash version.  Equivalent Git-cmd operations may be noted from time to time.

A Note on the Demonstration Approach

This demonstration uses the Hurricane Poker Java application described in my January 21, 2012, article: Playing Poker with Prolog and Java.

We are going to perform a historical reenactment of some recent edits made to the program to improve its use of Unicode special characters to be compatible across multiple operating systems. The previously established GitHub repository provides me with the historical copies of the software files at various points in time. However, all activity within the confines of our demonstration uses brand new repositories created during the reenactment.

Imagine a television cooking show where the actual baking steps are omitted by using previously prepared versions of the final dishes.

Creating a Git Repository within an Existing Source Tree

I developed my Hurricane Poker application in Java using Eclipse as my Integrated Development Environment (IDE). My Eclipse workspace folder resides beneath my Windows user’s home library folder. My HurricanePoker project folder exists there.

Using the Git-bash command window, I navigate there using this command sequence:

  cd ~/eclipse-ws
  ls -al
  cd HurricanePoker

The equivalent commands for Git-cmd are:

  cd /d %HOME%\eclipse-ws
  dir
  cd HurricanePoker

Now we turn the HurricanePoker folder, and its tree of sub-folders, into a local Git repository with this command:

  git init

We can confirm that Git knows we are in a repository and that there is untracked content waiting to be added:

  git status

The following output appears

$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#       .classpath
#       .project
#       bin/
#       lib/
#       out/
#       src/
nothing added to commit but untracked files present (use "git add" to track)

Before we add our files to the new repository, we need to create a text file named .gitignore to omit compiler output files and various Eclipse support files. This file is explained by this link: http://help.github.com/ignore-files/

Using any text editor, we save the following contents to the file .gitignore in our HurricanePoker root folder:

# Reference: http://help.github.com/ignore-files/
# Save as .gitignore at root of repository (or any sub-folder).

# Compiled source #
###################
bin
*.com
*.class
*.dll
*.exe
*.o
*.so

# Packages #
############
# it's better to unpack these files and commit the raw source
# git has its own built in compression methods
*.7z
*.dmg
*.gz
*.iso
# NOTE: For our project, we want to include the executable JAR file in our shared repository.
#*.jar
*.rar
*.tar
*.zip

# Logs and databases #
######################
*.log
*.sql
*.sqlite

# OS generated files #
######################
.DS_Store*
ehthumbs.db
Icon?
Thumbs.db

Note that we commented-out the ignore rule for JAR files, since we want our executable JAR file to be readily available from our shared repository without having to compile it. We also added an ignore file for our bin folder, which holds the compiled *.class files. Our Eclipse project has its build-path configured to export the JAR file into the out folder. We also include an HTML help file and an HTML applet-launch page in that out folder.

Adding the Files to the New Repository

Now we add our files to the new empty repository with the following command sequence:

  git add .
  git status
  git commit --all --message="Add existing project files to new repo"
  git log

The git status command is optional, but it shows the files staged for commit by the git add command:

$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#       new file:   .classpath
#       new file:   .gitignore
#       new file:   .project
#       new file:   lib/2p.jar
#       new file:   out/2h.gif
#       new file:   out/HurricanePoker.html
#       new file:   out/HurricanePoker.jar
#       new file:   out/HurricanePokerApplet.html
#       new file:   out/as.gif
#       new file:   src/HurricanPoker.Help.txt
#       new file:   src/HurricanePoker.Symbols.txt
#       new file:   src/com/live/rrutt/hurricane/GeneticHurricaneEncodings.txt
#       new file:   src/com/live/rrutt/hurricane/HurricanePoker.java
#       new file:   src/com/live/rrutt/hurricane/HurricanePoker.pl
#       new file:   src/com/live/rrutt/hurricane/HurricanePokerApplet.java
#       new file:   src/com/live/rrutt/hurricane/cards/2c.gif
  . . .
#       new file:   src/com/live/rrutt/hurricane/cards/th.gif
#       new file:   src/com/live/rrutt/hurricane/cards/ts.gif
#       new file:   src/com/live/rrutt/tuprolog/lib/PrologPredicatesAndFunctors.
java
#       new file:   src/com/live/rrutt/tuprolog/util/MenuDialog.java
#       new file:   src/com/live/rrutt/tuprolog/util/OkDialog.java
#       new file:   src/com/live/rrutt/tuprolog/util/TextWindow.java
#       new file:   src/com/live/rrutt/tuprolog/util/Utilities.java
#       new file:   src/com/live/rrutt/tuprolog/util/YesNoDialog.java
#

The git log command is also optional, but it confirms our message was accepted:

$ git log
commit 5032d2aff0a0e1df85e6f9487c59feddff2eb6f0
Author: Rick Rutt 
Date:   Sun May 27 14:00:27 2012 -0400

    Add existing project files to new repo

Creating a Shared Central Repository

One of the likely places you would create a central shared Git repository would be at GitHub.com. This demonstration strives for simplicity, so we emulate a GitHub shared repository using a folder on a USB memory stick. A local network shared folder is equivalent.

Note that even a solitary developer without any (current) intention to share their work can benefit from this approach to maintain a backup of their current work and their revision history.

For this demonstration, we have a USB memory stick plugged into a port with the Windows drive letter K: assigned to it. From the Git-bash command-prompt window, we can confirm the visibility of the drive by entering the command ls /k (or use the dir k: command if using the Git-cmd command-prompt).

If the drive is not visible, you may need to launch the git-bash.bat or git-cmd.bat script after inserting the USB memory stick. If that doesn’t work, copy your C:\PortableGit folder tree to the USB stick and launch the git-bash.bat or git-cmd.bat script from the USB folder.

We create a new shared folder on the USB drive using the following sequence of commands:

  cd /k
  mkdir GitRepos
  cd GitRepos
  mkdir HurricanePoker
  cd HurricanePoker
  git init --bare

If using git-cmd instead of git-bash, substitute cd /d k: for cd /k

The –bare option sets up this new repository so it can be the recipient of “push” commands. This emulates the operation of a GitHub.com shared repository, and follows the recommendations of this article from gitready.com: push to only bare repositories.

Pushing Our Private Local Repository to the Shared Repository

We return to our private local repository with either of the following commands (the first is for Git-bash, the second is for Git-cmd):

  cd ~/eclipse-ws/HurricanePoker
  
  cd /d %HOME%/eclipse-ws/HurricanePoker

We define a remote name for our shared repository using either of the following commands:

  git remote add HurricanePokerUsb /k/GitRepos/HurricanePoker
  
  git remote add HurricanePokerUsb k:/GitRepos/HurricanePoker

We can then confirm all our current remote definitions for the current local repository with the git remote -v command.

We push our local repository contents to the central shared repository for the first time with the following command sequence:

  git push HurricanePokerUsb master
  git remote show HurricanePokerUsb

Cloning the Shared Repository to Another Workstation

Our demonstration moves to a separate netbook running Ubuntu Linux in order to test our Java program in a non-Windows environment. We really only need the Git command-line software, so we install it from within a Linux terminal with the following Advanced Packaging Tool command:

  apt-get install git-core

We can now use the same Git-bash commands we have been using in the Windows environment. We assume we already have Eclipse installed on this netbook with an existing workspace. We will create a local cloned repository for our HurricanePoker project. Since we are using a USB memory stick for our shared repository server we need to insert it and reference the mount point assigned to it. Assuming our USB memory stick has a disk label of USBSTICK, our Linux command sequence follows:

  cd ~/eclipse-ws
  git clone /media/USBSTICK/GitRepos/HurricanePoker
  cd HurricanePoker
  git remote show origin

Note that the git clone command creates a sub-folder with the name of the repository being cloned, so we started in our Eclipse workspace folder. After the clone operation, we navigate into the new sub-folder. Also note that the clone operation automatically defined the remote name origin for the shared repository that we cloned from.

We test the executable JAR file by launching it from our terminal window:

  java -jar out/HurricanePoker.jar

We immediately notice two portability issues we need to resolve:

  • Our GUI windows are partially covered on the left by the Ubuntu Unity Launcher bar.
  • Our Unicode text characters are not appearing with the proper font glyphs.

Shared Application Development

Since we have our Eclipse programming environment on both workstations, we can make our program edits in either Linux or Windows. We can then share the edits with our other workstation, or with other developers.

With our simple USB memory stick demonstration, we have to use sneakernet manual transfer methods to move the USB device between workstations. However remember that a local network shared folder works the same and can remain connected to several workstations simultaneously.

We choose to use our Windows environment to make the edits because our Linux netbook has a smaller screen and a slightly shrunken keyboard. Since this was the original environment where we created our repository, we decide to add the origin remote name so it acts more like we cloned from the central shared repository:

  git remote add origin /k/GitRepos/HurricanePoker
  git fetch origin
  git remote show origin

Next we want to be able to experiment with program changes without affecting our master code branch until we are sure the changes work as desired in all target environments. We create a temporary branch for this. Branch names are essentially moveable labels attached at any one time to a commit point in the Git repository. We use an arbitrary naming convention for our temporary branches consisting of our user name (or initials), the current date, and a letter.

  git branch ruttr.20120527a
  git checkout ruttr.20120527a

As we start working with branches, the git status and git branch commands help us keep track of where we are:

$ git status
# On branch ruttr.20120527a
nothing to commit (working directory clean)

$ git branch
  master
* ruttr.20120527a

Our First Revision

We tackle the GUI window positions first. While we are editing, we add some Java annotations to suppress some nagging warnings that we decide do not affect our application. Once we have tested the changes from within Eclipse, we build (export) a new copy of the the runnable JAR file. Then we check our changes using the git status and git diff commands:

$ git status
# On branch ruttr.20120527a
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       modified:   out/HurricanePoker.jar
#       modified:   src/com/live/rrutt/hurricane/HurricanePoker.java
#       modified:   src/com/live/rrutt/tuprolog/lib/PrologPredicatesAndFunctors.
java
#       modified:   src/com/live/rrutt/tuprolog/util/MenuDialog.java
#       modified:   src/com/live/rrutt/tuprolog/util/TextWindow.java
#
no changes added to commit (use "git add" and/or "git commit -a")



$ git diff
diff --git a/out/HurricanePoker.jar b/out/HurricanePoker.jar
index 15e22ad..6502f49 100644
Binary files a/out/HurricanePoker.jar and b/out/HurricanePoker.jar differ
diff --git a/src/com/live/rrutt/hurricane/HurricanePoker.java b/src/com/live/rru
index 461743c..6acb1b9 100644
--- a/src/com/live/rrutt/hurricane/HurricanePoker.java
+++ b/src/com/live/rrutt/hurricane/HurricanePoker.java
@@ -16,6 +16,8 @@ public class HurricanePoker

        private static final long serialVersionUID = 2785996048582414206L;

+       public static final int windowHeight = 240;
+
        private static String TheoryResourceName = "com/live/rrutt/hurricane/Hur

        private String theoryFilePath = null;
@@ -49,7 +51,11 @@ public class HurricanePoker

                initComponents();
                pack();
-               setBounds(0, 350, 450, 250);
+               setBounds(
+                       TextWindow.windowX,
+                       TextWindow.windowY + TextWindow.windowHeight,
+                       TextWindow.windowWidth,
+                       windowHeight);
                engine = new Prolog();
                try {
                        engine.loadLibrary("com.live.rrutt.tuprolog.lib.PrologPr
@@ -83,6 +89,7 @@ public class HurricanePoker
                                t = new Theory(theoryInputStream);
                        }
                        engine.setTheory(t);
+                       @SuppressWarnings("unused")
                        SolveInfo info = engine.solve("x.");
 //                     System.out.print(info);
                } catch (Exception e) {
diff --git a/src/com/live/rrutt/tuprolog/lib/PrologPredicatesAndFunctors.java b/
index 6c14c42..ec18539 100644
--- a/src/com/live/rrutt/tuprolog/lib/PrologPredicatesAndFunctors.java
+++ b/src/com/live/rrutt/tuprolog/lib/PrologPredicatesAndFunctors.java
@@ -26,7 +26,7 @@ public class PrologPredicatesAndFunctors extends Library {
                        textWindow = new TextWindow();
                }

-               textWindow.setBounds(0, 0, 450, 350);
+               textWindow.setDefaultBounds();
                textWindow.setVisible(true);
        }

diff --git a/src/com/live/rrutt/tuprolog/util/MenuDialog.java b/src/com/live/rru
index d83251b..6e09862 100644
--- a/src/com/live/rrutt/tuprolog/util/MenuDialog.java
+++ b/src/com/live/rrutt/tuprolog/util/MenuDialog.java
@@ -68,6 +68,7 @@ public class MenuDialog extends javax.swing.JDialog {

                javax.swing.JButton btn = null;
                int i = 0;
+               @SuppressWarnings("rawtypes")
                java.util.Iterator iter = choices.listIterator();
                while (iter.hasNext()) {
                        i++;
diff --git a/src/com/live/rrutt/tuprolog/util/TextWindow.java b/src/com/live/rru
index 3cba4d0..95ed791 100644
--- a/src/com/live/rrutt/tuprolog/util/TextWindow.java
+++ b/src/com/live/rrutt/tuprolog/util/TextWindow.java
@@ -10,6 +10,11 @@ public class TextWindow extends javax.swing.JFrame {

        private static final long serialVersionUID = -1212370239230155880L;

+       public static final int windowX = 100;
+       public static final int windowY = 25;
+       public static final int windowWidth = 450;
+       public static final int windowHeight = 330;
+
        private int cursorRow = 0;

        private int cursorCol = 0;
@@ -17,8 +22,16 @@ public class TextWindow extends javax.swing.JFrame {
        public TextWindow() {
                initComponents();
                pack();
-               setSize(500, 340);
+               setSize(windowWidth, windowHeight);
        }
+
+       public void setDefaultBounds() {
+        setBounds(
+          windowX,
+          windowY,
+          windowWidth,
+          windowHeight);
+    }

        /**
         * This method is called from within the constructor to initialize the f

Note: Press the keyboard Q key (“quit”) to exit the git diff output display.

Next we commit our changes to our current branch:

  git add .
  git commit --all --message="Adjust window positions for Ubuntu launcher bar"

We confirm we didn’t miss anything with the git status command:

$ git status
# On branch ruttr.20120527a
nothing to commit (working directory clean)

Transferring Our First Temporary Branch

Still on our Windows workstation, we use the following command:

  git push origin ruttr.20120527a

Moving to our Linux netbook (along with our USB stick), we use the following commands to pull the revisions to a local copy of the temporary branch:

  git remote show origin
  git fetch origin
  git checkout ruttr.20120527a
  git remote show origin
  git branch

We confirm that git branch shows we are on the ruttr.20120527a branch. Then we test our changes with Java:

  java -jar out/HurricanePoker.jar

We are able to confirm the GUI windows are no longer obscured by the Ubuntu Unity launcher bar.

Our Second Revision

We return (with our USB stick) to our Windows workstation. After a few experimental edits and re-edits, we end up performing the following source revisions to resolve our Unicode character encoding issue:

  • Delete the obsolete src/HurricanPoker.Help.txt and src/HurricanePoker.Symbols.txt files.
  • Use our NotePad++ text editor to convert the encoding for out/HurricanePoker.html and out/HurricanePokerApplet.html from ANSI to UTF-8, and to edit the special characters in the examples.
  • Use NotePad++ to convert the encoding the encoding for src/com/live/rrutt/hurricane/HurricanePoker.pl from ANSI to UTF-8 without Byte-Order-Mark, and to edit the special characters.
  • Edit src/com/live/rrutt/hurricane/HurricanePoker.java within Eclipse to replace the bulk load of the Prolog theory text from the HurricanePoker.pl file with an explicit InputStreamReader constructor with an option “UTF-8” encoding parameter, followed by a readline loop into a StringBuffer.
  • Use Eclipse to build (export) the revised HurricanePoker.jar file.

Here is the result of a single-file git diff command showing the revision to HurricanePoker.java:

$ git diff src/com/live/rrutt/hurricane/HurricanePoker.java
diff --git a/src/com/live/rrutt/hurricane/HurricanePoker.java b/src/com/live/rrutt/hurricane/HurricanePoker.java
index 6acb1b9..cdfc46b 100644
--- a/src/com/live/rrutt/hurricane/HurricanePoker.java
+++ b/src/com/live/rrutt/hurricane/HurricanePoker.java
@@ -86,7 +86,21 @@ public class HurricanePoker
       + TheoryResourceName);
       }

-      t = new Theory(theoryInputStream);
+       InputStreamReader isr = new InputStreamReader(theoryInputStream, "UTF-8");
+       BufferedReader br = new BufferedReader(isr);
+       StringBuffer theoryBuffer = new StringBuffer();
+
+       String s = br.readLine();
+       while (s != null) {
+         // System.out.println(s);
+         theoryBuffer.append(s);
+         theoryBuffer.append('\n');
+
+         s = br.readLine();
+         }
+
+       String theoryString = theoryBuffer.toString();
+       t = new Theory(theoryString);
    }
    engine.setTheory(t);
    @SuppressWarnings("unused")

Here is our current git status result:

$ git status
# On branch ruttr.20120527b
# Changes not staged for commit:
#   (use "git add/rm ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       modified:   out/HurricanePoker.html
#       modified:   out/HurricanePokerApplet.html
#       modified:   out/HurricanePoker.jar
#       deleted:    src/HurricanPoker.Help.txt
#       deleted:    src/HurricanePoker.Symbols.txt
#       modified:   src/com/live/rrutt/hurricane/HurricanePoker.java
#       modified:   src/com/live/rrutt/hurricane/HurricanePoker.pl
#
no changes added to commit (use "git add" and/or "git commit -a")

Next we use git add . to stage our modified file changes, and check our status again with git status:

$ git add .

$ git status
# On branch ruttr.20120527b
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       modified:   out/HurricanePoker.html
#       modified:   out/HurricanePokerApplet.html
#       modified:   out/HurricanePoker.jar
#       modified:   src/com/live/rrutt/hurricane/HurricanePoker.java
#       modified:   src/com/live/rrutt/hurricane/HurricanePoker.pl
#
# Changes not staged for commit:
#   (use "git add/rm ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#       deleted:    src/HurricanPoker.Help.txt
#       deleted:    src/HurricanePoker.Symbols.txt
#

Notice that the file deletions are not staged by git add . which is why we use the –all option on our git commit command:

$ git commit --all --message="Use UTF-8 encoding for portable special characters."
[ruttr.20120527b b196e96] Use UTF-8 encoding for portable special characters.
 7 files changed, 47 insertions(+), 283 deletions(-)
 delete mode 100644 src/HurricanPoker.Help.txt
 delete mode 100644 src/HurricanePoker.Symbols.txt

 
$ git status
# On branch ruttr.20120527b
nothing to commit (working directory clean)

Transferring Our Second Temporary Branch

Still on our Windows workstation, we use the following command:

  git push origin ruttr.20120527b

Moving to our Linux netbook (along with our USB stick), we use the following commands to pull the revisions to a local copy of the temporary branch:

  git remote show origin
  git fetch origin
  git checkout ruttr.20120527b
  git remote show origin
  git branch

We confirm that git branch shows we are on the ruttr.20120527b branch. Then we retest our changes with Java:

  java -jar out/HurricanePoker.jar

We are able to confirm the special characters appear with proper font glyphs.

Publishing Our Revisions for Formal Approval

Satisfied with our revision iterations, we decide to formalize our current source code as a feature branch and submit it for review by another developer on our team.

We create a new branch off our last date-named temporary branch without actually applying any further edits. We then push the descriptively named feature branch to our shared central repository for review and approval.

These steps can be performed on either of our workstations:

git checkout ruttr.20120527b
git branch linux-portability
git checkout linux-portability
git push origin linux-portability

We then submit a Pull Request to another developer on our team. If we were using GitHub.com, there is a mechanism on the web page to create a Pull Request from a new branch. For an environment using a simple shared folder, use a text message or e-mail to notify your other developer of your Pull Request for a new feature branch.

Review of Our Feature Branch Pull Request

We return to our Linux netbook to simulate another developer on their own workstation. We pull the feature branch to our own workstation for formal review:

git remote show origin
git fetch origin
git checkout linux-portability
git log
git diff master

Approval of Our Feature Branch Pull Request

We decide the revisions meet our quality standards and want to approve the changes and merge them into our master branch.

This involves switching to our master branch, making sure it matches the central repository’s commit level, and then merging the already fetched feature branch. Finally we push the merged master branch back to the central repository.

git remote show origin
git checkout master
git pull origin master
git merge linux-portability
git push origin master

The “branching” involved in this demonstration involved only linear successive edits without any truly alternate branching code paths. No three-way merge steps were actually required, so most of these review and approval steps only involve fast forward moving of branch “labels” to later commit points.

Getting Latest Code

We return to our Windows workstation for a new round of coding and realize we need to ensure we are working with the latest code base. We check the state of our local repository with the git status and git remote show origin commands:

$ git status
# On branch linux-portability
nothing to commit (working directory clean)


$ git remote show origin
* remote origin
  Fetch URL: k:/GitRepos/HurricanePoker
  Push  URL: k:/GitRepos/HurricanePoker
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    linux-portability
    master
    ruttr.20120527b
  Remote branches:
    linux-portability tracked
    master            tracked
    ruttr.20120527a   tracked
    ruttr.20120527b   tracked
  Local refs configured for 'git push':
    linux-portability pushes to linux-portability (up to date)
    master            pushes to master            (local out of date)
    ruttr.20120527a   pushes to ruttr.20120527a   (up to date)
    ruttr.20120527b   pushes to ruttr.20120527b   (up to date)

We see that our master branch is out of date, so we refresh it and then start a new temporary branch for our next round of experimental coding:

git fetch origin
git checkout master
git pull origin master
git branch ruttr.20120527c
git checkout ruttr.20120527c

We can proceed now to edit code without harming our reviewed and approved master branch.

Cleanup of Temporary Branches from Shared Repository

Our date-named temporary branch names create clutter in our central shared repository. We can see them with the git remote show origin command:

$ git remote show origin
* remote origin
  Fetch URL: k:/GitRepos/HurricanePoker
  Push  URL: k:/GitRepos/HurricanePoker
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    linux-portability
    master
    ruttr.20120527b
  Remote branches:
    linux-portability tracked
    master            tracked
    ruttr.20120527a   tracked
    ruttr.20120527b   tracked
  Local refs configured for 'git push':
    linux-portability pushes to linux-portability (up to date)
    master            pushes to master            (up to date)
    ruttr.20120527a   pushes to ruttr.20120527a   (up to date)
    ruttr.20120527b   pushes to ruttr.20120527b   (up to date)

We can delete them with a strange non-intuitive syntax; we “push” the branch but precede the branch name with a colon (:) as follows:

$ git push origin :ruttr.20120527a
To k:/GitRepos/HurricanePoker
 - [deleted]         ruttr.20120527a


$ git push origin :ruttr.20120527b
To k:/GitRepos/HurricanePoker
 - [deleted]         ruttr.20120527b


$ git remote show origin
* remote origin
  Fetch URL: k:/GitRepos/HurricanePoker
  Push  URL: k:/GitRepos/HurricanePoker
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    linux-portability
    master
  Remote branches:
    linux-portability tracked
    master            tracked
  Local refs configured for 'git push':
    linux-portability pushes to linux-portability (up to date)
    master            pushes to master            (up to date)

Cleanup of Temporary Branches from Local Repository

We can similarly delete local branches using the git branch -d branch-name command:

$ git branch
  linux-portability
  master
  ruttr.20120527a
  ruttr.20120527b
* ruttr.20120527c


$ git branch -d ruttr.20120527a
Deleted branch ruttr.20120527a (was 7073cd3).


$ git branch -d ruttr.20120527b
Deleted branch ruttr.20120527b (was 3d704fd).


$ git branch
  linux-portability
  master
* ruttr.20120527c

The git remote show origin command shows any stale branches that were removed from the central repository from another workstation. If this occurs, the following command removes our local tracking elements for those branches:

git remote prune origin

Spreading Your Wings

I have found this demonstration workflow to meet almost all of the needs of our actual team development activity. However Git has many more features and allows lots of variation in its use.

To see the most important commands that are available, type git help

To learn all the options for any particular command, type git command –help where command is the actual command verb.

Also review the URL links provided at the top of this article.

Now it is time to Go Git ‘Em!

Advertisements