Git Configuration

Now that Git is installed, let’s do a minimum amount of configuration by setting your name and email address in the Git configuration tool so that this information will be shown for commits that you make (a commit being the act of placing a new version of your code in the repository). We can do this using the git config tool:

$ git config --global user.name "Chad Russell"
$ git config --global user.email [email protected]

We can verify that these settings took by using the git config tool again, this time using the property key as the setting we want to check:

$ git config user.name
Chad Russell
$ git config user.email
[email protected]

Notice that you will run the same configuration commands in both Windows and Unix environments.

Initializing Your Repository

To create your first Git repository , you will simply use the git init command. This will initialize an empty Git repository in your source code directory. Once you initialize, you can then perform your first commit to your new repository. For this example, we have an empty directory that we’ll initialize in, then we will add a README file, and finally we’ll add and commit the file to our new repository .

Remember that Git will initiate based on the directory in which the Git command will be called. For instance, if you are in

C:Program Files (x86)Git

then the result will be

Initialized empty Git repository in C:/Program Files (x86)/Git/bin/.git/

We’ll use the following repository and directory as the book progresses to track various code examples that we’ll use:

$ git init
Initialized empty Git repository in /Apress/source/.git/

Initial Commit

Now that we have initialized our empty repository, we’ll add a very basic README file to it and then perform our initial commit :

$ echo "This is our README." > README.md

Now, if we look at the current status of our repository using git status we’ll see that we now have one untracked file, meaning one file that isn’t yet added to our repository or being tracked for changes by Git. You can use git status any time you’d like to view the status of the working branch of your repository:

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

Now, we’ll add the file to our repository using git add:

$ git add README.md

If we view the git status again, we’ll see our file has been added, but not yet committed (saved) to the repository:

$ git status
On branch master

                    Initial commit                                                    

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

Lastly, we’ll commit our change, and our new README will now be in our repository and be tracked for changes going forward:

$ git commit -m "Initial commit. Added our README"
[master (root-commit) e504d64] Initial commit. Added our README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

We can see from the message we received back from git commit that our commit was saved. Now, if we check the git status one more time we’ll see we currently have nothing else to commit:

$ git status
On branch master
nothing to commit, working directory clean

Staging Changes

We have our initial tracked file in our repository and have seen how to add a new file to Git to be tracked. Let’s now change the README and then stage and commit this change.

I’ve added a change to the README.md file, altering the initial text we added to something slightly more informative. Let’s run git status again and see what it shows:

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README.md                                                

It shows that our README was modified, but that it’s not staged for commit yet. We do this by using the git add command. We’ll add it and check the status one more time:

$ git add README.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   README.md

Lastly, we’ll make this new commit, which will wrap up the change to the file we made:

$ git commit -m "Updated README"
[master ca476b6] Updated README
 1 file changed, 1 insertion(+), 1 deletion(-)

Viewing History

With all of the changes we’ve just made, it is helpful to be able to go back and view the history of our repository. One of the easiest ways to do this is to use the git log command. When no arguments are passed to it, git log will show you all of the commits in your repository, starting with your most recent changes and descending chronologically from there:

$ git log
commit ca476b6c41721cb74181085fd24a40e48ed991ab
Author: Chad Russell <[email protected]>
Date:   Tue Mar 31 12:25:36 2015 -0400

    Updated README

commit dc56de647ea8edb80037a2fc5e522eec32eca626
Author: Chad Russell <[email protected]>
Date:   Tue Mar 31 10:52:23 2015 -0400


    Initial commit. Added our README

There are a number of options and arguments you can pass to git log. You can limit the number of results by passing in a number as an argument; you can view the results for just a specific file; and you can even change the output format using the --pretty argument along with a number of different options. For example, if we wanted to see only the last commit to our README.md file and summarize the commit onto one line, we could use the following:

$ git log -1 --pretty=oneline -- README.md
ca476b6c41721cb74181085fd24a40e48ed991ab Updated README

To break down this command, we’re telling it to limit it to -1 one result, to use the oneline pretty format, and -- README.md only for our README.md file.

Ignoring Specific Files

There will often be a number of files and directories within your project that you do not want Git to track. Git provides an easy way of specifying this by way of a Git Ignore file , called . gitignore. You can save these anywhere within your project, but usually you’ll start with one in your root project directory.

Once you create and save this file, you can edit it within your IDE or text editor and add the files and/or paths that you want to ignore. For now, I want to ignore the settings files that my IDE, PHPStorm, creates. PHPStorm creates a directory called .idea where it stores a number of files that are specific to my IDE’s settings for this project. We definitely don’t want that in our repository, as it’s not related to the project specifically, and it could cause problems for other developers that clone this code and use PHPStorm. Our initial .gitignore file will now look like this :

# Our main project .gitignore file
.idea/*

For now, we have two lines; the first is a comment, which can be added anywhere in the file using the number sign #. The second is the line to tell Git to ignore the .idea folder and anything inside of it, using the asterisk to denote a wildcard match. We will then want to commit this file to our repository so that it’s distributed to anyone else who may clone this repository and contribute back to it.

As your project grows and you have new files or directories that you don’t want in your repository, simply continue to add to this file. Other items that are commonly ignored are configuration files that contain passwords or other system-specific information, temporary files such as caches, other media, or resources that are not directly needed by your project or even maintained within your development team.

Removing Files

At times you will need to remove files from your repository. There are a few different ways to approach removing files depending on the intentions of what you’re doing.

If you want to completely remove a file from both the repository and your local working copy, then you can use the git rm command to perform this task. If you delete the file from your local copy using your operating system or within your IDE, then it will show up as a deleted file that needs to be committed.

Let’s take a look. First, we’ll create a simple text file to add to our repository, commit it, then delete it:

$ touch DELETEME
$ git add DELETEME
$ git commit -m "Adding a file that we plan on deleting"
[master 5464914] Adding a file that we plan on deleting
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 DELETEME
$ git rm DELETEME
rm 'DELETEME'
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)


        deleted:    DELETEME

$ git commit -m "Removed our temporary file"
[master 6e2722b] Removed our temporary file
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 DELETEME

$ git status
On branch master
nothing to commit, working directory clean

Now, we’ll delete it first on the local system and then remove it from Git, and then we will commit the change:

$ touch DELETEME
$ git add DELETEME
$ git commit -m "Adding another temporary file to delete"
[master b84ad4f] Adding another temporary file to delete
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 DELETEME
$ rm DELETEME
$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    DELETEME

no changes added to commit (use "git add" and/or "git commit -a")
$ git rm DELETEME
rm 'DELETEME'
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    DELETEME

$ git commit -m "Removing our second temporary file"
[master e980b99] Removing our second temporary file
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 DELETEME

Lastly, you may find that you want to delete a file from Git so it’s no longer tracked, but you want to keep the file locally. Perhaps you accidentally committed a configuration file that has now been added to your .gitignore file; you want to remove it from Git but keep it locally, for obvious reasons. For that you will use the --cache option along with the git rm command:

$ touch DELETEME
$ git add DELETEME
$ git commit -m "Adding a temporary file to delete one more time"
[master f819350] Adding a temporary file to delete one more time
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 DELETEME
$ git rm --cached DELETEME
rm 'DELETEME'
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    DELETEME

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        DELETEME

$ git commit -m "Removed temporary file just in the repository"
[master 26e0445] Removed temporary file just in the repository
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 DELETEME
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        DELETEME                                                

Merging

Once we’re ready for our changes in the test branch to appear in the master branch, we’ll need to perform a merge. When performing a merge , Git will compare changes in both branches and will attempt to automatically merge the changes together. In the event of a collision of changes, meaning that the same lines of code were changed in both branches, it will have you manually intervene to resolve the conflict. Once resolved, this will be tracked as another commit, and you can finish your merge.

Let’s merge our branch-example changes into the master branch:

$ git merge branch-example
Updating e504d64..a6b7d2d
Fast-forward
 test.php | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test.php

Now that we’ve merged this in, in this case we don’t need our branch-example any longer. We can simply delete it using the git branch command again:

$ git branch -d branch-example

Stashing Changes

There will be many times when working with your project that you might need to pull changes from a remote repository before you’re ready to commit what you’re working on, or you might need to switch to another branch to do some other work before you’re ready to commit and don’t want to lose your changes. This is where the git stash command comes in handy.

To stash your changes, you simply invoke the git stash command. You can view the stashes you’ve saved by passing in the list sub-command, and you can reapply the changes by using the apply sub-command. Let’s see it in action:

$ git status
On branch master

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   test.php

$ git stash
Saved working directory and index state WIP on master: 08e9d29 adding a test file
HEAD is now at 08e9d29 adding a test file
$ git status
On branch master

nothing to commit, working directory clean

You can see we had changes to test.php that weren’t yet committed; after calling git stash we now have a clean working directory. See here:

$ git stash list
stash@{0}: WIP on master: 08e9d29 adding a test file
$ git stash apply
On branch master

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   test.php

no changes added to commit (use "git add" and/or "git commit -a")
$ git status
On branch master

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)


        modified:   test.php

We can see the stash we have saved using git stash list. We can reapply it and see it back in our working directory after calling git stash apply. By default, calling git stash apply will apply the most recent stash in the list. If you want to apply a specific stash, then you must supply the stash number that you see when calling git stash list. Using the preceding list output as an example, we would use the following:

$ git stash apply stash@{0}

Tagging

Tagging within Git allows you to tag any given commit with a label for future reference. For example, you can use it to tag specific releases of your code or other important landmarks along the way during development.

Git provides two different tag types. There’s lightweight tags, which are just label pointing to a commit. Annotated tags are instead full checksummed objects that contain the name and email of the person tagging, and can include a message. It’s highly recommended that you always use annotated tags unless you need to temporarily tag something, in which case a lightweight tag will do.

$ git tag v0.0.1

$ git show v0.0.1
commit a6b7d2dcc5b4a5a407620e6273f9bf6848d18d3d
Author: Chad Russell <[email protected]>
Date:   Thu Feb 26 10:44:11 2015 -0500

    Added a test file to our branch

diff --git a/test.php b/test.php
new file mode 100644
index 0000000..e69de29                                                                          

$ git tag -d v0.0.1
Deleted tag 'v0.0.1' (was a6b7d2d)

$ git tag -a v0.0.1 -m "Initial Release"

Show the details of the annotated tag:
$ git show v0.0.1
tag v0.0.1
Tagger: Chad Russell <[email protected]>
Date:   Sun Mar 15 18:54:46 2015 -0400

Initial Release

commit a6b7d2dcc5b4a5a407620e6273f9bf6848d18d3d
Author: Chad Russell <[email protected]>
Date:   Thu Feb 26 10:44:11 2015 -0500

    Added a test file to our branch

diff --git a/test.php b/test.php
new file mode 100644
index 0000000..e69de29

Undoing Changes

There will come times when you might accidentally commit something that you want to undo, or where you might want to reset your local working copy back to what it was from the last commit or a given commit within the repository history. Undoing changes in Git can be broken down in the following ways:

• Amend

• Un-stage

• File Reset

• Soft Reset

• Mixed Reset

• Hard reset

$ git add second.php
$ git commit -m "Updated commit message" --amend

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   first.php
        new file:   second.php

$ git reset HEAD second.php
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   first.php

Untracked files:
  (use "git add <file>..." to include in what will be                                                           committed)

        second.php

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   first.php

$ git checkout -- first.php
$ git status
On branch master
nothing to commit, working directory clean

$ git reset a659a55 first.php

$ git reset –soft 26e0445

$ git reset 26e0445

$ git reset --hard e504337
HEAD is now at e504337 Added our first .gitignore file

Bitbucket

Let’s get started with Bitbucket. When you first visit their site, you will create a new account. Once your account is created, you will log in and be provided with the option to set up a new repository. Before we proceed with creating our repository, there’s a single step we can do that will make interacting with this repository a lot easier for us, which is adding an SSH key to use for authentication.

One of the most important advantages of Bitbucket is that it is JIRA integrated and also supports Mercurial.

$ ssh-keygen -t rsa -C "[email protected]"

$ git remote add origin [email protected]:intuitivereason/pro-php-mysql.git
$ git push -u origin --all
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (6/6), 524 bytes | 0 bytes/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To [email protected]:intuitivereason/pro-php-mysql.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

GitHub

Instead of using Bitbucket, you might want to use GitHub, and when comparing them we can say that they have very different billing structures and they also differ in history viewer and collaboration features.

The steps using Github are very similar. You first find and click the New Repository button, which will then present you with a Repository Create form similar to what we had with Bitbucket. From here, you’ll fill out the form and create the repository. On the next screen, you’ll be presented with instructions based on whether this is a new or existing repository, just as with Bitbucket. We can add this repository just like we did with Bitbucket:

$ git remote add origin [email protected]:intuitivereason/pro-php-mysql.git
$ git push -u origin --all

PHPStorm

If you’re not familiar with PHPStorm, it is a popular, cross-platform (Linux, Mac OS X, and Windows) PHP IDE developed by JetBrains. It is the IDE that I use throughout the various examples; however, you do not have to have PHPStorm to do any of the exercises in this book.

You can download PHP Storm at:

https://www.jetbrains.com/phpstorm/download/

If you have a Git repository in your project root folder in PHPStorm, it will automatically detect it and provide menu entries to perform a number of different actions, as shown in Figure 1-1.

Figure 1-1. PHPStorm Git menu entries

Here we see there are a number of actions available to us when viewing these options while on our test.php file. From here we can commit or add the file, if it hasn’t been added yet. We can also do a diff to compare our local file with the same version in the repository or with what the latest version might be on a remote repository. We can also compare it with another branch within our repository or see the history of all of the changes for this one file. Another function is the “Revert” function, which allows you to quickly revert any uncommitted changes in your file back to the state it was in for the last local commit.

Figure 1-2 shows the Repository sub-menu entry and the actions it provides within this sub-menu.

Figure 1-2. Git Repository sub-menu entry in PHPStorm

From this entry we can view branches, tag, merge, stash or un-stash our current changes, or fetch, pull, or push changes from and to a remote repository.

SourceTree

The SourceTree application is a free Git client for Windows and Mac users that is built by Atlassian, the same company that runs Bitbucket. It is a very powerful Git GUI client that makes working and interacting with Git repositories, both locally and remote, quite easy.

Adding a Repository

To add a Git repository to SourceTree, you will click on the New Repository button and choose whether you are cloning an existing remote repository, adding an existing local repository, or creating a new local or remote repository (Figure 1-3).

Figure 1-3. Adding a new repository to SourceTree

Add the new repository that you created earlier in this chapter by selecting “Add existing local repository.” This will have you navigate to the directory where the repository was initialized, and then click the Add button. This repository will now be visible in the SourceTree bookmark/browser window. Simply double-click the name of the repository to bring up the full GUI (Figure 1-4).

Figure 1-4. SourceTree repository view

From here, you can continue to work with Git for all of the actions we have discussed so far and others, including committing, branching, merging, pushing and pulling to and from a remote repository, and more.

GitHub GUI

GitHub has their own Git GUI that’s freely available as well. It’s very clean and intuitive to use, but lacks some of the advanced features you’ll find in SourceTree. However, if you’re looking for a nice, clean interface to use with Git, it’s definitely worth looking at.

Adding a Repository

One interesting feature of the GitHub GUI is that it can find Git repositories on your system and provide them to you during setup, with the option of importing them in to start working with them in GitHub GUI. If you choose not to do that, you can also add or create a new repository later using the menu entry. Once your repository has been added to the GitHub GUI, you will be presented with the repository view, as shown in Figure 1-5.

Figure 1-5. GitHub GUI repository view

gitg

gitg is an open source Git GUI that’s made by the Gnome foundation and is for Linux users only.

Adding a Repository

To add a repository using gitg, you click the “cog wheel” icon, which then reveals a sub-menu for opening a local repository or cloning a remote repository. Once added, you can click to open the repository view, as seen in Figure 1-6.

Figure 1-6. gitg repository view