Tip 4: Just Ignore!

Git has at least three configuration files in which you can list files that you want Git to ignore:

• .gitignore – this file is the right place for anyone who wants to create an exclusion list for all users in their current repository.
• .git/info/exclude – the rules listed here for files to exclude only apply to your individual repository; they do not affect anyone else and only apply on the local machine.
• ~/.gitignore – behaves in a similar way to .git/info/exclude, but applies to all repositories on the local machine.

If you want to use ~/.gitignore globally, use the following command:

git config --global core.excludesfile ~/.gitignore

If you want to learn more about ~/.gitignore, you will find further information online [9]. In addition, a tool from SUSE's senior engineer Adam Spiers might come in handy. Adam developed git check-ignore [10]. This command is built into Git and checks files and path names to discover whether or not they are on one of the local ignore lists. In this way, developers can avoid surprises when working with third-party repositories.

Tip 5: Retroactive…

Thomas offers another tip, but one that developers will not want to apply to public commits. Git lets you retroactively add whole files to a commit. If you have staged files with git add and already checked them into the repository with git commit, but forgot some files, you can add them later with git commit --amend.

First, simply call git add again and specify the forgotten file as a parameter. Then git commit --amend comes into play; this command displays the commit message from the previous commit in the editor. If you want, you can change it now, but it's not absolutely necessary. By the way, amend also supports rm for later removal of files. More information is available in the Atlassian [11] wiki.

Tip 6: Stashing with Stash

Every developer is familiar with this scenario: A developer is working on an important project when The Boss comes in with a new, even more important task. The new task suddenly has priority, but you will need to continue working on the old task at a later time. You will have to check in the code for the new task before you check in the code for the original task.

Git supports a strategy known as stashing for such situations: Changes that the developer has not yet checked in end up in stashes for processing at some later time.

git status first displays the list of changed files; git stash moves these changes to a stash. Now you can work on the new task. After the work is done, call git stash pop, and you can continue working at the point you reached before the interruption. Git Stash can be nested multiple times, so commands like this exist:

• git stash list – lists all stashes
• git stash drop – removes the last stash
• git stash branch test – generates a new branch based on the stash

Attention: Stash only works on added files by default. If you also want to have unmonitored files in your stash, you have to add git add --all and git stash explicitly. You'll find more information at the Git SCM site [12].