Git for beginners: The definitive practical guide

Answer 1

How to configure it to ignore files:

The ability to have git ignore files you don't wish it to track is very useful.

To ignore a file or set of files you supply a pattern. The pattern syntax for git is fairly simple, but powerful. It is applicable to all three of the different files I will mention bellow.

• A blank line ignores no files, it is generally used as a separator.
• Lines staring with # serve as comments.
• The ! prefix is optional and will negate the pattern. Any negated pattern that matches will override lower precedence patterns.
• Supports advanced expressions and wild cards
  • Ex: The pattern: *.[oa] will ignore all files in the repository ending in .o or .a (object and archive files)
• If a pattern has a directory ending with a slash git will only match this directory and paths underneath it. This excludes regular files and symbolic links from the match.
• A leading slash will match all files in that path name.
  • Ex: The pattern /*.c will match the file foo.c but not bar/awesome.c

Great Example from the gitignore(5) man page:

$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
#       Documentation/gitignore.html
#       file.o
#       lib.a
#       src/internal.o
[...]
$ cat .git/info/exclude
  # ignore objects and archives, anywhere in the tree.
  *.[oa]
$ cat Documentation/.gitignore
# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
$ git status
[...]
# Untracked files:
[...]
#       Documentation/foo.html
[...]

---

Generally there are three different ways to ignore untracked files.

1) Ignore for all users of the repository:

Add a file named .gitignore to the root of your working copy.

Edit .gitignore to match your preferences for which files should/shouldn't be ignored.

git add .gitignore 

and commit when you're done.

2) Ignore for only your copy of the repository:

Add/Edit the file $GIT_DIR/info/exclude in your working copy, with your preferred patterns.

Ex: My working copy is ~/src/project1 so I would edit ~/src/project1/.git/info/exclude

You're done!

3) Ignore in all situations, on your system:

Global ignore patterns for your system can go in a file named what ever you wish.

Mine personally is called ~/.gitglobalignore

I can then let git know of this file by editing my ~/.gitconfig file with the following line:

core.excludesfile = ~/.gitglobalignore

You're done!

I find the gitignore man page to be the best resource for more information.

Answer 2

Push and pull changes

In an simplified way, just do git push and git pull. Changes are merged and if there's a conflict git will let you know and you can resolve it manually.

When you first push to a remote repository you need to do a git push origin master (master being the master branch). From then on you just do the git push.

Push tags with git push --tags.

Answer 3

How do you compare two revisions of a file, or your current file and a previous revision?

Compare command is git diff.

To compare 2 revisions of a file:

$ git diff <commit1> <commit2> <file_name>

That diffs commit1 against commit2; if you change order then files are diffed the other way round, which may not be what you expect...

To compare current staged file against the repository:

$ git diff --staged <file_name>

To compare current unstaged file against the repository:

$ git diff <file_name>

Answer 4

Console UI - Tig

Installation:

apt-get install tig

Usage

While inside a git repo, type 'tig', to view an interactive log, hit 'enter' on any log to see more information about it. h for help, which lists the basic functionality.

Trivia

"Tig" is "Git" backwards.

Answer 5

Here's a copy of PJ Hyett's post, as it is not available anymore:

Git Isn't Hard

Nov 23, 2008

When we tell people why they should use Git over Subversion, the go-to line is, “Git does Subversion better than Subversion, but it does a lot more than that.”

The “lot more” is comprised of a bunch of stuff that makes Git really shine, but it can be pretty overwhelming for those coming from other SCM’s like Subversion.

That said, there’s nothing stopping you from using Git just like you use Subversion while you’re making the transition.

Assuming you’ve installed the necessary software and have a remote repository somewhere, this is how you would grab the code and push your changes back with Subversion:

$ svn checkout svn://foo.googlecode.com/svn/trunk foo
# make your changes
$ svn commit -m "my first commit"

And how would you do it in Git:

$ git clone git@github.com:pjhyett/foo.git
# make your changes
$ git commit -a -m "my first commit"
$ git push

One more command to make it happen in Git. That extra command has large implications, but for the purposes of this post, that’s all we’re talking about, one extra command.

See, it really isn’t that hard.

Update: I’d be remiss to not also mention that the equivalent of updating your local copy in Subversion compared to Git is svn update and git pull, respectively. Only one command in both cases.

Answer 6

How do you merge branches?

If you want to merge a branch (e.g. master to release), make sure your current branch is the target branch you'd like to merge into (use git branch or git status to see your current branch).

Then use

git merge master

(where master is the name of the branch you want to merge with the current branch).

If there are any conflicts, you can use

git diff

to see pending conflicts you have to resolve.