git fetch,git merge and git rebase

Hi,

I am new to git .Can someone explain in simple terms what git fetch,git merge and git rebase do?..I tried googling but was very confused after going thro it.

Also, can someone prescribe a link which explains git in detail right from scratch.

Akash <bcakashguru <at> gmail.com> writes:

RFTM, with all respect )) http://progit.org/book/

Alexey Shumkin wrote:

More hints:

 - "man git" (or "git help git") has some hints to get started:
   . a tutorial
   . a list of "everyday git" commands to get going
   . a short article on centralized, cvs-style workflow
   . a user's manual

 - when anything is unclear in those documents, I will be very happy
   to learn about it (so cc me in that case :)).  Please be specific
   as possible about what is confusing.

 - people on this mailing list and the #git channel on freenode are
   generally happy to help if you are trying to do something
   specific (or have some other specific question).

 - there's much material on the web in addition to what's mentioned
   above.  For example the old git crash course for svn users at
   http://git.or.cz/course/svn.html taught me a lot about both git and
   svn.  Theoretically, good material from a variety of sources can
   gradually flow into the user's manual and reference manual pages,
   though actual practice does not always match that theory.

Good luck.

Kind regards, Jonathan

Thanks Jonathan:)

and also https://git.wiki.kernel.org/index.php/GitFaq

On 2/9/2011 11:29 PM, Akash wrote:

git fetch: retrieve the latest version of a branch and store it in the /remotes/* "remote tracking branches" of your local repo. you can view these branches with "git branch -a". Once you have that local copy, you can merge it into other branches, checkout objects from it, and run diffs against it. You are not supposed to EVER make commits on a remote/* branch. its sole purpose in life is to maintain an image the the corresponding branchs that its tracking in the remote repo. you update that image by performing git fetch. see man-page for details.

git merge: merges branch(s) into your current branch. see man-page for details. lots and lots of details...

git rebase: takes all the local commits you've made on an old history and rewrites them on-top of the new history. it makes it look like you did your work based on the new history instead of the old history. it keeps your history 'linear' instead of having all these merge DAG's in your history like git-merge produces. see man page for details. lots and lots of details are not easy to understand at first...

hope this helps.

v/r, neal

On 2/9/2011 11:29 PM, Akash wrote:

another definition of git-rebase:

git-rebase: the MOST DANGEROUS command in git. you can easily DESTROY your repo if you don't know what you're doing! Until you get the hang of it, always make a copy of the before-image of the branch your rebasing (mybranch) by doing a "git checkout mybranch" and then "git branch copy-of-mybranch". Then if you destroy mybranch you can recover it from copy-of-mybranch.

v/r, neal

On Thu, Feb 10, 2011 at 04:21:27PM -0600, Neal Kreitzinger wrote:

I won't claim that rebase isn't easy to shoot yourself in the foot with, but I think this advice is a little over-the-top. Rather than backing up branches, you would do better to learn about reflogs, as the reflog of mybranch will contain the original version. As will the reflog of HEAD, though if you have screwed up too badly, the reflog of mybranch will probably be a lot simpler to read.

You can see it with "git reflog show mybranch"; when you see the commit that you want to restore to, you can:

  git branch -f mybranch mybranch@{whatever}

to restore it there. That provides more-or-less the same safety as a backup branch (reflogs do expire, but something like three months later), plus it helps you in all the cases where you forgot to make a backup before screwing things up. :)

-Peff

Thanks Neal:)

On Fri, Feb 11, 2011 at 12:21 AM, Neal Kreitzinger <nkreitzinger@gmail.com> wrote:

What about 'git rebase --hard', or 'git branch -D'? In all cases you can recover by using the reflog.

On 2/11/2011 6:32 AM, Felipe Contreras wrote:

i take you meant 'git reset --hard'...

v/r, neal