What do you get with Print?

Instant access to your digital eBook copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Git Best Practices Guide

Chapter 1. Starting a Git Repository

This chapter covers the basics needed to understand the topics discussed in this book, and of course, to improve your skills in Git. Commands in this chapter are used every day by all Git users. Some of them will not be explained in detail; they will be explained in another chapter.

In this chapter, you will learn about:

Initializing a repository
Cloning an existing repository
Adding and committing files
Pushing commits on remote repositories

Working with the repository

We have to take a few minutes to look at the life cycle of a file inside Git.

A file will go through the following states, and the Git command line will take the file from one state to another. We will explain each state and its command line.

The important part of this schema is the triangle between the three states UNMODIFIED, MODIFIED, and STAGED. This triangle is an infinite loop. Indeed, every time you change a file, its state is set to modified, and then staged; when you commit the file, it returns to the unmodified state, and so on.

UNTRACKED is the first state where the file is created, but this isn't tracked by Git.

To change the state of a file, you have to add it.

Adding a file

When you start an empty repository and add a file, it will be in the untracked state, which means that it isn't in the Git repository.

To track a file, you have to execute this command line:

Erik@local:~/myProject$ touch MyFileName.txt
Erik@local:~/myProject$ echo "test" > MyFileName.txt
Erik@local:~/myProject$ git add MyFileName.txt

So, your file is now tracked by Git.

If you want to add all files because you already have something inside the directory while you create the repository, add a period (.) just after git add to specify to take all files inside the current directory:

Erik@local:~/myProject$ echo "hello" > MyFile2.txt
Erik@local:~/myProject$ echo "hello" > MyFile3.txt
Erik@local:~/myProject$ git add .

The file is currently staged and ready to be committed inside the repository.

Committing a file

As soon as your file is tracked, all changes will be notified by Git, and you have to commit the change on the repository.

Tip

Remember to commit your change as soon as possible (not for every line, but it's a marker to validate what you have done).

The commit command is local to your own repository, nobody except you can see it.

The commit command line offers various options. For example, you can commit a file, as shown in the following example:

Erik@local:~/myProject$ git commit -m 'This message explains the changes' MyFileName.txt

To commit everything, use the following command:

Erik@local:~/myProject$ git commit -m 'My commit message'

You will create a new commit object in the Git repository. This commit is referenced by an SHA-1 checksum and includes various data (content files, content directories, the commit history, the committer, and so on). You can show this information by executing the following command line:

Erik@local:~/myProject$ git log

It will display something similar to the following:

Commit f658e5f22afe12ce75cde1h671b58d6703ab83f5
Author: Eric Pidoux <contact@eric-pidoux.com>
Date: Mon Jun 2 22:54:04 2014 +0100
My commit message

The file is in the unmodified state because you just committed the change; you can push the files in the remote repository.

Pushing a file

Once committed, you can push the files in the remote repository. It can be on a bare repository, using init with the git init --bare command, so just type the following command:

Erik@local:~/myProject$ git push /home/erik/remote-repository.git

If you create a remote repository on another server, you have to configure your local Git repository.

If you use Git 2.0 or later, the previous command will print out something like this on the screen:

Warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
gitconfig --global push.default matching
To squelch this message and adopt the new behavior now, use:
gitconfig --global push.default simple

The 'matching' value from the push.default configuration variable denotes that git push will push all your local branches to the branches with the same name on the remote. This makes it easy to accidentally push a branch you didn't intend to.

The 'simple' value from the push.default configuration variable denotes that git push will push only the current branch to the branch that git pull will pull from; it also checks that their names match. This is a more intuitive behavior, which is why the default should be changed to this configuration value.

Firstly, check if a remote repository is defined:

Erik@local:~/myProject$ git remote

If it's not, define the remote repository named origin:

Erik@local:~/myProject$ git remote add origin http://github.com/myRepoAddress.git

Now, push the changes using the following command:

Erik@local:~/myProject$ git push -u origin master

After this, you will have a resume of what was pushed.

In fact, the remote repository will check the current Head (the reference to the commit) and compare it with its own. If there are differences between them, it will fail.

Removing a file

If you don't want a file anymore, there are two ways to remove it:

Delete the file manually and commit the changes. This will delete the file locally and on the repository. Use the following command line
```
Erik@local:~/myProject$ git commit -m 'delete this file'
```

Delete the file only through Git:

Erik@local:~/myProject$ git rm --cached MyFileName.txt

Checking the status

There is a way to display the working tree status, that is, the files that have changed and those that need to be pushed, and of course, there is a way to display the conflicts:

Erik@local:~/myProject$ git status

If everything is correct and up to date, you will get this result:

Erik@local:~/myProject$ git status
# On branch master
nothing to commit, working directory clean

If you add a file, Git will warn you to track it by using the git add command:

Erik@local:~/myProject$ touch text5.txt
Erik@local:~/myProject$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   text5.txt
nothing added to commit but untracked files present (use "git add" to track)

If you edit MyFile2.txt and type git status again, then you will have new lines:

Erik@local:~/myProject$ echo "I am changing this file" > MyFile2.txt
Erik@local:~/myProject$ git status
# On branch master
# Changes to be committed:
#   (use "gitreset HEAD<file>..." to unstage)
#
#   new file: text5.txt
# 
# Changes not staged for commit:
#   (use "git add <file>…" to update what will be committed)
#
# modified: MyFile2.txt
#

On these lines, separate paragraphs display all files in each state. The MyFile2.txt file is not tracked by Git and text5.txt is ready to be committed.

If you add text5.txt using the git add command, you will notice the following changes:

Erik@local:~/myProject$ git add MyFile2.txt
Erik@local:~/myProject$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   text5.txt
#   modified:   MyFile2.txt
#

Ignoring files

Git can easily ignore some files or folders from your working tree. For example, consider a website on which you are working, and there is an upload folder that you might not push on the repository to avoid having test images in your repository.

To do so, create a .gitignore file inside the root of your working tree:

Erik@local:~/myProject$ touch .gitignore

Then, add this line in the file; it will untrack the upload folder and its contents:

upload

Files or folders you define in this file will not be tracked by Git anymore.

You can add some easy regex, such as the following:

If you want to ignore all PHP files, use the following regex:
```
*.php
```
If you want to ignore all files having p or l at the end of its name, use the following regex:
```
*.[pl]
```
If you want to ignore all temporary files (finishing by ~), use the following regex:
```
*~
```

If the file is already pushed on the repository, the file is tracked by Git. To remove it, you will have to use the gitrmcommand line by typing this:

Erik@local:~/myProject$ git rm --cached MyFileName.txt

What you will learn

Create a Git repository and learn how to push your code to the repository Discover the easiest Git commands to use and manage your repository Learn how to find and resolve conflicts and mistakes Explore Git with your team members using commands such as clone, pull, and branch Set up Git for Continuous Integration to improve workflow Understand tag commits for mapping the application version An introduction to repository management and other Git tools

What do you get with Print?

Instant access to your digital eBook copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Frequently bought together

€36.99

€22.99

€20.99

Total € 80.97

R. Wenner Apr 13, 2015

First and most annoyingly, the title is misleading. This is not a Best Practices book, this is the bare minimum of commands, cobbled together for people who never used git before. Only the last chapter gets into actual practices, but it is nothing more than an commentated rehash of blog posts on that topic.The book shows commands but does not explain the "why" behind them. For example, it tells you that you can push changes, but does not mention what pushing means or when and why you would do it. It tells you that you can have tracked and untracked branches, but does not say anything on why or why not you would want to do that. It does not even tell anything on why you would want branches at all. From a book called "Best Practices" I would expect a discussion on how to set up my branches and when to merge them. The author explains how you run the rebase command, but not why. From a BestPractices book I expect the pros and cons of rebasing and when and when not to use it.The book is incomplete; it refers to private and public branches without explaining what these are.Some example commands don't work as given. And that is not only because of missing spaces or e.g. botched stash names (stash@"1} instead of stash@{1}). Did this book have a copy editor?Some explanations are imprecise or plain wrong. For example, contrary to what the author states, git status does not magically print which files "need to be pushed". (How could it know what makes sense to push?) While the author mentions pros and cons of different repository access protocols, he doesn't even mention "encryption" when talking about SSH. When the author briefly touches on semantic versioning, he only mentions bug fixes, and as a beginner you may wonder how features fit in here. A hook script uses a /bin/sh shebang line and the author claims it's a bash script. Have fun with that on a system where /bin/sh does not default to bash, like Debian.

Amazon Verified review

Git Best Practices Guide: Master the best practices of Git with the help of real-time scenarios to maximize team efficiency and workflow

What do you get with Print?

Git Best Practices Guide

Chapter 1. Starting a Git Repository

Configuring Git

Initializing a new repository

Cloning an existent repository

Tip

Working with the repository

Adding a file

Committing a file

Tip

Pushing a file

Removing a file

Checking the status

Ignoring files

Summary

Page 1 of 6

Description

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs

Git Best Practices Guide: Master the best practices of Git with the help of real-time scenarios to maximize team efficiency and workflow

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Description

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs