Page 1 of 1

git basics

PostPosted: Wed May 27, 2009 5:27 pm
by blittergames
So after following a couple tutorials on git I have managed to install it and use it with github. Now as I am still new to git and source code management, these seem like the most important things so far.

> git init

Get git started and have it make the .git folder

> git add .

Have git add everything in the folder

> git commit -m "new changes"

Have git check what files have been changed and submit to local repo?

> git push origin master

Have git push updated files to master repo

===========================================

1. When I do git commit, where are the files getting sent to or updated? Is it a local repo and if so where is it?

2. How do they keys work when it comes to transferring data? Is my code encrypted with my public key then sent to git hub and then it gets decrypted there? Or does this only happen when pulling data? Such as ...github.com already has my public key, they encrypt data and then it gets sent to me and decrypted with my private key. Is that right?

3. Are there any other major important things to know? So far I am just updating my project files and then pushing them to the repo on github.

Re: git basics

PostPosted: Wed May 27, 2009 7:24 pm
by jacius
blittergames wrote:> git commit -m "new changes"

Have git check what files have been changed and submit to local repo?

`git commit` does submit the changes to the local repo, but it's not (except in the cases below) the command that checks the changes. Rather, it was `git add` that "scheduled" the changes, i.e. added them to git's list of changes that should be sent during the next commit. Note that this means if you do `git add`, then edit the files again, then do `git commit` (without adding again), the changes that you made since adding won't be committed.

There are two notable exceptions, though. "git commit" will check what has changed (and commit the changes) in these situations:

  • `git commit -a` ("commit all"). This commits all the changes in all files in the repository. It's like a shortcut for doing `git add the/top/project/directory/` and then `git commit`, since it's very common to want to commit all the changes.
  • `git commit myfile1.rb [myfile2.rb [...]]`. This commits all the changes to the specified files, but not any changes to any other files, even if you have done `git add` for those other files.
1. When I do git commit, where are the files getting sent to or updated? Is it a local repo and if so where is it?

The changed/new code is stored as a new revision (also sometimes called a commit) in the local repo, which is contained inside the .git directory. It doesn't just copy the whole files into there, though. It's more complicated and geeky than that. :lol:

By the way, you should avoid editing most files in the .git folder, except for .git/config, which you can edit carefully (but you won't lose your repository data if you break it), and .git/info/exclude, which can store a list of filenames or patterns (e.g. *.txt) of files and directories that git should ignore. The git documentation has more information about ignoring files, including other ways, like the .gitignore file.

2. How do they keys work when it comes to transferring data? Is my code encrypted with my public key then sent to git hub and then it gets decrypted there? Or does this only happen when pulling data? Such as ...github.com already has my public key, they encrypt data and then it gets sent to me and decrypted with my private key. Is that right?

For github (and any other repository that you access with a "ssh://" url), git uses SSH (Secure SHell) tunneling for sending and (maybe) receiving data. SSH uses a type of public-key cryptography. I'm not a cryptography expert, so I probably wouldn't do a very good job of trying to explain it in detail.

3. Are there any other major important things to know? So far I am just updating my project files and then pushing them to the repo on github.

It's somewhat important to understand cloning (`git clone`), which means downloading a copy (clone) of a repository.

Also, it's very important to eventually learn and understand about branching (`git branch`) and merging (`git merge`). This allows you to create multiple lines of development (e.g. a bugfix branch and a new feature branch), then combine them later.

Git also allows you to fix mistakes in recent commits. You should not do that if you have pushed that commit (or any of its descendents) to github, but it's nice if you just made a little mistake in a commit 5 minutes ago. I wrote a simple tutorial about fixing past commits on my blog last June. It also briefly covers `git stash`, which is another very useful tool.

Re: git basics

PostPosted: Thu May 28, 2009 7:28 pm
by blittergames
thanks Jacius! 8-)