All Annotations of A tour of git: the basics[Preview]

saved by5 people, first byMarko on 2007-10-26, last byDaniel Jomphe on 2008-08-11

• it's useful to use "git clone" even when
  just making a local copy of a repository. Using "git clone" will be
  much faster and will use much less space than a normal copy.
• git clone hello hello-clone
• A good commit message will generally have a single line that
  summarizes the commit, a blank line, and then one or more paragraphs
  with supporting detail. Since many tools only print the first line of
  a commit message by default, it’s important that the first line stands
  alone.

• Note that we didn't use "commit -a" this time. This means that "git
  commit --amend" will amend only the commit message and not any of the
  actual files being tracked, (even if some of them had been modified
  between the commits).

  
  
  

  It's also possible to use "git commit -a --amend" to similarly fix up
  mistakes noticed in code. That will replace the most recent commit
  with a different commit based on any new changes to files.

• Sometimes you may not know if you want to pull in the changes from the
  remote repository or not. It's useful to be able to examine them
  before accepting them into our branch. The "git pull" command shown in
  the previous section is conceptually the combination of two commands,
  "git fetch" and "git merge". We can use these commands separately to
  examine the change before accepting it.
• The most convenient way to examine the fetched changes is with the
  "master..origin" range notation
• You'll notice that we've been seeing the phrase "fast forward" several
  times. This is a special-case operation performed by "git merge" where
  a branch can be advanced along a linear sequence. This happens
  whenever you pull changes that build directly on top of the same
  commit you have as your most recent commit. In other words, there was
  never any divergence or simultaneous commits created in parallel in
  multiple repositories. If there had been parallel commits, then "git
  merge" would actually introduce a new merge commit to tie the two
  commits together.

• If you have a situation where you want to pull a single time from some
  repository, then you can simply give the path or URL of the repository
  on the "git pull" command line. However, it's often the case that if
  you want to pull changes from a repository once, you'll want to pull
  changes from that same repository again in the future. This is where
  the "git remote" notion is extremely useful---it allows you to
  associate simple names, (and behaviors), with remote repository URLs

  
  
  

  We've already seen one instance of "git remote" which is the creation
  of the "origin" remote which happens automatically during "git
  clone". Let's now create another. Let's assume you are going to be
  working in the hello-remote repository and you'd like to pull changes
  from the hello-pull repository, where your friend "fred" has been
  making changes. Here's how to setup the new remote:

• git remote add fred ../hello-pull
• So that's a "git remote add" command line followed by an arbitrary
  name you'd like for the new remote (fred) and the URL of the remote
  (../hello-pull). Obviously, the URL could be a git:// URL or any other
  git-supported URL in addition to a local path.
• The "git remote" command is really just a helper for adding some
  entries to the .git/config file. You might find it more convenient to
  edit that file directly once you get comfortable with things.
• At this point the name "fred" will work much like the name "origin"
  has worked in previous examples. For example, we can fetch the changes
  fred has made with "git fetch fred":
• git fetch fred
• We can also list all known remote-tracking branches with "git branch
  -r":
• git branch -r
• These remote-tracking branches make it very easy to collaborate with
  people as they are working on experimental features not yet ready for
  upstream inclusion. For example, if fred's latest code is still
  trashing filesystems then he might not want to push it out to the
  project's primary repository. But he may still want my help with
  it. So he can push it to a branch in his own repository for which I've
  got a remote. Then on my next "git fetch fred" I might notice a new
  branch called fred/trashes-filesystems and I can examine his code with
  a command such as "git log ..fred/trashed-filesystems".

• Now, generally the
  purpose of pushing to a repository is to have some "collaboration
  point" where potentially multiple people might be pushing or
  pulling. Because there might be multiple people pushing into the
  repository at any point, it wouldn't make sense to have a
  working-directory associated with this repository.

  
  
  

  For this, git has the notion of a "bare" repository, which is simply a
  repository with no working directory. Let's create a new bare
  repository and push some changes into it:

• git --bare init --shared
• The --shared option sets up the necessary group file permissions so
  that other users in my group will be able to push into this repository
  as well.
• Now lets return to our hello repository and push some changes to this
  new repository. Since this is our very first push into this repository
  we need to tell git which branches to push. The easiest way to do this
  is to use --all to indicate all branches:
• git push ../hello-bare --all
• For subsequent pushes we don't need to specify --all as "git push" by
  default pushes all branches that exist in both the local and remote
  repositories.