Git Setup

By timadmin in Administrative, Git 5 Comments

Yesterday I ‘installed’ git on another MacBook – the process is pretty easy.  Simply open a terminal session & type the command “git“.  Follow the prompts as OS X installs the Command Line Tools.  Be sure to update them by visiting the App Store once the install is complete.

The harder thing is to initialize the git installation.  Here is what I am doing, based upon the suggestions found in Pro Git (link below).  I’m sanitizing some of the fields – they should obviously be set to appropriate values for other environments.

  1. Set username & email address
    1. git config –global user.name “Tim Armstrong”
    2. git config –global user.email tima@tims-zone.info
  2. Set the default text editor
    1. The default default text editor is typically Vim.  I like this and don’t change it, but it can be changed.
    2. git config –global core.editor <text editor>
  3. Verify the settings
    1. git config –list

Now that git is initialized, I should initialize a repository so that I can begin using git.  Within a terminal session, either create a new directory or change to an existing one that contains (or will contain) files to manage.  Once there type the command “git init“.  The next step is to begin tracking any files that are in the directory, using the following commands:

  1. git add *
  2. git commit -m ‘initial project version’

That gets things started.  I think that I’ll setup separate posts for each major action to be taken while managing the files/projects.

Lastly, here is a link to find the current version of the open source book on git, which can be downloaded for free and details everything that I’m doing.

https://progit.org

Related Articles.

5 Comments

  1. Today I learned how to restore an old version of a file, and how to revert to the latest state.
    Begin with git log to discover the commit values
    Execute git checkout (commit value) (filename)
    Do whatever needs to be done with the old file.
    Execute git checkout (commit value) (filename)
    Smile and wave!

  2. This week I replaced a file with a newer version and a different name. Git recognized this as having manually removed the file from the repository, and showed it this way:
    If you simply remove the file from your working directory, it shows up under the “Changed but not updated” (that is, unstaged) area of your git status output. Below is an excerpt from ProGit showing how to handle the reportedly deleted file.

    $ rm PROJECTS.md
    $ git status
    On branch master
    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: PROJECTS.md

    no changes added to commit (use “git add” and/or “git commit -a”)
    Then, if you run git rm, it stages the file’s removal:

    $ git rm PROJECTS.md
    rm ‘PROJECTS.md’
    $ git status
    On branch master
    Your branch is up-to-date with ‘origin/master’.
    Changes to be committed:
    (use “git reset HEAD …” to unstage)

    deleted: PROJECTS.md
    The next time you commit, the file will be gone and no longer tracked.

  3. Today I inadvertently deleted a file from the repository through the unwise use of wildcards. In order to restore the file I had to use the following command:
    git checkout HEAD
    This fixed things so that I could proceed with a commit.

  4. Thanks to a friend, I have discovered how to apply tags to specific points in a repository’s history to help me find important milestones within the project. A couple of notes beyond what I found in the book:
    1. If you inadvertently type “git tag show” the lightweight tag ‘show’ is created, which probably isn’t what you intended. In order to recover you need to delete the tag. Deleting a tag is done by simply typing “git tag -d show” where ‘show’ is the name of the tag to delete.
    2. To view the list of tags within a repository simply type “git tag”. If you want to see the message associated with each tag the command gets a little longer: “git tag -n”.

  5. I’ve been using git to track a set of diagrams as I create them using Omnigraffle. Today I opened a nice diagram and used it as a template for creating a new diagram. When I saved my work I was astounded to discover that the program did not ask me for a filename – I had just saved the new diagram over the source diagram!

    Git to the rescue. By using the “git checkout — ” command I was able to save my original work (after duplicating the new diagram and saving it in the proper file).

    Git is good!

Leave a Comment.