Changes between Version 10 and Version 11 of GitCrashCourse


Ignore:
Timestamp:
11/05/12 16:55:57 (11 years ago)
Author:
David Sommerseth
Comment:

Added info about git rebase

Legend:

Unmodified
Added
Removed
Modified
  • GitCrashCourse

    v10 v11  
    265265And it will create a new branch, enter it, from the latest commit where you where.  You can now even commit into this branch.
    266266
     267== Getting up-to-speed with the official repository ==
     268
     269If you have done local changes and added your own commits on top of a git branch, you might at some point want to submit these patches to the mailing list.  Or you might just want to test these patches on the latest stuff from the official upstream git repository.  The best way to do this is to rebase your branch against the latest changes in the official repositories.  This operation is often referred to as "rebasing against upstream".
     270
     271First we want to get a fresh update from the official upstream repository.  If you used ''git clone'' against one of the official repositories, downloading the latest stuff is done like this:
     272 {{{
     273 git fetch origin
     274 }}}
     275
     276The name ''origin'' is a name of the default repository used when you did the ''git clone'' operation.  To see which remote repositories you have configured, you can use this command:
     277 {{{
     278 git remote -v
     279 }}}
     280This reports the ''alias'' and the URL for the repository.  If the upstream tree is not named ''origin'', you need to replace that with the appropriate git remote ''alias''.
     281
     282When you have done the ''git fetch'', you have only downloaded the latest stuff into your copy of the remote repository.  No files in your checked-out git branch has been modified yet.  So to really apply those changes to your own branch, make sure that you have a clean git tree with no modified files (use ''git status'' to see the status of your currently checked out branch).  Then run this command:
     283 {{{
     284 git rebase origin
     285 }}}
     286This will first rewind the git branch you are working on, temporarily taking out all your local changes.  Then it will add all the modifications done in the remote tree.  When that is done, it will apply all your local changes on top of the latest remote branch.  If you want to rebase against a particular upstream branch, you do this by also mentioning the branch name:
     287 {{{
     288 git rebase origin/master
     289 }}}
     290
     291It might be that there are some conflicts when doing such rebases.  Sometimes it is not so easily for git to understand which version you want to use, your local changes or the upstream version.  In these cases, ''git rebase'' will stop and ask for your help.  You need to use ''git status'' or ''git diff'' to see which files have issues, and edit each of them manually - removing the code which is not supposed to be there.  Then you use ''git add <file(s)>'' to indicate you are done with the files.  If ''git status'' now does not list any modified files, then you need to use ''git rebase --skip'' - as the patch is not relevant any more (the upstream tree have already applied these changes) - otherwise you must run ''git rebase --continue''.
     292
     293Sometimes there are a lot of conflicts, and this job takes a little while.  Other times, there are no conflicts and this ''git rebase'' operation is done in just a few minutes.  For massive conflicts, it might be worth checking out ''git mergetool''.  This also needs a separate tool, and ''meld'' is one such tool which can be used.
     294
     295If you are worried about messing up such rebases, just checkout a test branch and try it there first.  Then you'll see how it goes without messing up anything else.
     296
     297When ''git status'' shows a clean status ("working directory clean") or just lists files not committed to your branch, then you have successfully rebased your tree to the latest upstream branch.
     298
    267299== Merge branches ==
    268300