Development Using Git CLI

From Metro Studios Knowledgebase

Jump to: navigation, search


[edit] Setting Up

[edit] Windows

If you will be using the Git CLI from a Windows PC, follow the instructions to install Git GUI. This will also install Git Bash which we will use to run the Git commands.

[edit] Ubuntu Linux

Use apt-get to install Git on an Ubuntu box:

sudo apt-get install git-core

[edit] Identifying Yourself

Once Git is installed, you will need to configure the name and email settings so Git can track each user's changes to a project. These configuration values can be set using the config command. Set your name:

git config --global "James Smith"

And your e-mail address:

git config --global "[email protected]"

[edit] Accessing Remote Repositories

[edit] Constructing SSH Strings

This is the formatting for the SSH string that Git GUI uses for cloning remote projects via SFTP over SSH:


So an example of this for a standard development domain would be:


[edit] Cloning Remote Projects

Cloning a remote repository uses the clone command:

git clone ssh://USERNAME@SERVER.TLD:11200/var/www/vhosts/DOMAIN.TLD/httpdocs.git

You can find the specific git clone string you need by going to the domain lookup tool and selecting the domain you wish to clone.

[edit] Local Development/Committing

[edit] Rescan/Staging

Once you have made some changes to a file it is ready to start scanning for changes and staging your edits.

The first step is to check for changes using the status command. From the base directory of your working repository:

git status

If there are changes that have been made a message will appear showing you what files have been added, deleted, and/or modified. You can then use the add command to stage the changes:

git add .

It is also possible to stage only certain changes, so you can add specific commit messages for each change. To stage an individual file:

git add path/to/file.php

[edit] Committing

Once files have been staged using the add command, you're ready to make a commit. A commit is more or less just a checkpoint in development. Once you are finished with a specific edit, deletion, or addition to your code it is best practice to document that. Writing a good commit message is a must.

To commit your changes, use the commit command:

git commit -m "Your commit message"

Follow the rules in the Git GUI documentation for commits and commit messages.

[edit] Pushing/Fetching Changes

[edit] Pushing

Once you have committed some changes to your working repository, you can push them out to the remote master repository using the push command:

git push

Since your working copy was cloned from a remote master, Git automatically knows where to push your commits. You do not need to specify the location of the remote repository.

Assuming that you are pushing back onto a remote SSH repository, you will be prompted to enter your SSH password.

If the push was successful a notification message similar to the following will appear:

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 310 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: From /var/www/git/misc/httpdocs
remote:    d32872a..58d3ad9  master     -> origin/master
remote: Updating d32872a..58d3ad9
remote: Fast-forward
remote:  index.php |    4 +++-
remote:  1 files changed, 3 insertions(+), 1 deletions(-)
To ssh://
   d32872a..58d3ad9  master -> master

If there was a conflict (two branches of code must be merged together) then you will see a notification window similar to this:

To ssh://
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'ssh://[email protected]:11200/var/www/git/misc/httpdocs.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

If this happens this means that someone has pushed their branch onto the bare repository and you must "fetch" their changes and merge them into your branch before pushing your branch.

[edit] Fetching

To fetch code changes from the remote bare repository we will be fetching from the origin repository that we originally cloned our branch off of. To do this, use the fetch command:

git fetch

This will pull down the current branch from the remote bare repository as "origin/master", which is the master branch of the repository will be represented locally at all times.

If this was successful a notification message similar to the following will appear:

remote: Counting objects: 7, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From ssh://
   58d3ad9..fceb511  master     -> origin/master

This depicts the "master" remote repository getting fetched (->) to the "origin/master" repository locally. Once you have fetched the origin/master branch you will have to merge it with your local repository.

[edit] Local Merging and Handling Conflicts

[edit] Local Merging

After you have fetched changes from the remote repository, you will need to merge those changes with your local working copy. This can be done with the merge command:

git merge origin/master

In nearly all cases you will be merging the "origin/master" tracking branch with your local working copy as shown above. This will pull the changes from the remote repository into your working copy.

If Git is able to merge the changes automatically, you will receive a success message like the following:

Merge made by recursive.
 location/index.php |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

[edit] Merge Conflicts

If a file has been modified in a way that prevents Git from being able to automatically merge the changes, you will receive a conflict notice when you try to do a local merge:

Auto-merging index.php
CONFLICT (content): Merge conflict in index.php
Automatic merge failed; fix conflicts and then commit the result.

This generally happens when another user has modified the same lines of the file as you have. In this case you will have to manually edit the file to resolve the conflict. When Git notices a conflict, it will add markup to the file indicating where that conflict occurs. In this example, the index.php file was modified with these lines:

<<<<<<< HEAD
                <div id="other-header" class="clearfix">
<!-- TEST -->
                <div id="my-header" class="clearfix">
>>>>>>> origin/master

In the example above the conflicting lines are displayed between the "<<<<<<< HEAD" and ">>>>>>> origin/master" markup that Git has added to the file. The lines between "<<<<<<< HEAD" and "=======" are the contents of your local working copy, and the lines between "======" and ">>>>>>> origin/master" are the contents of the file in the remote repository.

At this point you will need to decide how to handle the conflict. It may be as simple as deciding to use one section or the other, or you may need to manually merge the lines together. Consult with the other users working on the project if necessary.

Once you have decided how to resolve the conflict, make the changes in your local copy of index.php that has been marked up by Git. In the example above, assume that the decision was made to use the HEAD contents. That would mean the lines that were marked by Git will be changed to just this:

                <div id="other-header" class="clearfix">

Now that the conflict has been resolved, you can stage, commit and push as you normally would.

[edit] Additional

[edit] Boost

[edit] Administrative Articles

[edit] Creating a Bare Repository

It will sometimes be necessary to create a bare repository which will act as the master remote repository for a project. From any standard Git repository a bare repository can be generated using the clone command:

git clone --bare /var/www/vhosts/
Personal tools
Wiki Navigation