Category: git

Git Tutorial Part 3: Ignoring Files (Gitignore)

Git Ignoring Files

In most projects we have a set of files that we do not want to track these are usually logs or compilation or runtime files. In these cases we make use of:

.gitignore

To create a file listing to match the files we don’t want to track:

cat .gitignore
*.[oa]
*~

This tells git to ignore all files ending in .o or .a and all files that end with a tilde.

It s important to setup your .gitignore before you get going on the project so you don’t accidentally commit unnecessary files.

Gitignore Rules:

  • # : are comments
  • standard glob patterns work
  • Patterns ending in forward slash (/) specify a directory
  • You can negate a pattern by starting it with an exclamation point

Gitignore Manual Notes

 man git
Name

Gitignore: specifies intentionally untracked files to ignore.

Description

Files already tracked by git are not affected. Each gitignore file has a pattern, and have an order of precedence as follows:

  • Patterns read from command line
  • Patterns read from .gitignore in the same directory path and up, with those on a higher level of the directory tree being overridden by those below.
  • Patterns read from $GIT_DIR/info/exclude
  • Patterns read from the file specified by the config variable core.excludesfile.

Gitignore patterns should be version controlled and distributed to other repositories in the .gitignore file. Patterns specific to a single user should go into the $GIT_DIR/info/exclude file.

Files / patterns that should be ignored in all situations should go into the core.excludesfile in ~/.gitconfig

Pattern Format
  •  Blank lines serve as seperators for readability
  • A line starting with # is a comment
  • ‘!’ negates the pattern
  • Pattern ending in a slash ‘/’ will match a directory and those under it. Will not match a regulat file or symbolic link.
  • If the patterns does not contain a slash ‘/’ git treats it as glob patterns
  • If the patterns does contain a slash ‘/’ it is still treated as glob patterns
  • A leading slash matches files in the root directory
 Important Gitignore Notes

To ignore uncommited changes in a file that is already tracked:

git update-index --assume-unchanged

To stop tracking a file that is currently tracked:

git rm --cached

Taken from: Git Pro

Git Tutorial Part 2: Repository, Cloning, Tracking and Staging

This article gives the basics for a beginner user who needs to start tracking and contributing to projects managed with git.

The Git Repository

Initialising from an existing directory
git init

This command creates the .git directory.At this point nothing is tracked though.

git add *
git add README
git commit -m 'Initial Commit'
Cloning an Existing Repository

Cloning pulls an existing repo from a remote location to your local machine. This is usually the case when you want to contribute to an open source project. Remember the entire history is cloned. The latest copy of the project is checked our into the working directory.

git clone https://github.com/yiisoft/yii.git yiimod

The above command clones the yii framework into a folder called yiimod in the current directory.

Recording Changes

Each file in your working directory is of a certain state: tracked or untracked.

Tracked Files: In previous repo snapshot as unmodified, modified or staged.

Untracked Files: Files not in last snapshot and not in staging area.

When you first clone a directory all files will be tracked and unmodified. When files are edited they become modified, they are staged and then commited.

Checking File Statii

git status

This command tells you what branch you are on and the statii of files.

Adding a new file to the repo will give a response of:

 untracked files:

If you want to start tracking the newly added file you must explicitly:

git add <new file>

You must explicitly do so as it is possible that you application during compilation or runtime, additional unnecessary files were created.

Once you have added the file it is now staged as git status will give:

Changes to be commited:

If you modify a tracked file, without adding git status gives:

Changes not staged for commit:

This means the file is tracked and modified but not staged. If you add the modified file, the new file and modified file will show up under:

Changes to be commited:
new file: <new file>
modified: <modified file>

If you modify the <modified file> again, after git add, it will show up under both staged and unstaged changes. You will need to stage those unstaged changes.

Taken from: Pro Git

Git Tutorial Part 1: Git Configuration

This Git Config Basics Tutorial will help you find out how configuration works and how you can configure your git

Types of Configuration

System Wide:

This configuration file is found at: /etc/gitconfig. This contains the default values for all users on the system.

git config --system

Global/Per User:

Found at: ~/.gitconfig. This is the configuration of a specific user.

git config --global

Project/Repo Specific:

Found at .git/config of each project.

So the configuration process is much like that of apache with the system: httpd.conf

global: mywebsite-vhost.conf
project: .htacess

Configure you Git Identity:

This is the identity data that is stored with every commit you make, o it is good practice to make the email valid and name professional.

git config --global user.name "Number 1"
git config --global user.email admin@number1.co.za

You can use (–system, –global or no argument for project specific config)

Configure your Git Editor:

Configuring your git editor is an important step, as we all have out favourite editors. The default for most system is vim however you change it using the following command:

git config --global core.editor emacs

The same editor can be used as your diff tool and mergetool:

git config --global merge.tool meld
git config --global diff.tool meld

I find that using a graphical merge and diff tool is easier for me.

Checking your Git Settings:

git config --list
user.name=Number 1
user.email=admin@number1.co.za
color.status=auto

Git Config Basics Help

git help config
git help <verb>
git <verb> --help
man git-<verb>

Taken from Chapter 1: Pro Git