Changes between Version 86 and Version 87 of DeveloperGuidelines/Git


Ignore:
Timestamp:
01/02/14 13:08:08 (7 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelines/Git

    v86 v87  
    104104from trunk, then either "rebasing" or "merging" to include them in the branch you want to update.
    105105
    106 Rebasing lifts your commits off of the common base your branch shared with trunk, then inserts the new
    107 trunk revisions, then applies your commits on top of those.  Merging leaves your commits where they are,
    108 and adds the trunk revisions alongside them.
     106Although rebasing and merging may end up with the same code, the process and "side effects" differ:
     107* Rebasing lifts your commits off of the common base your branch shared with trunk, then inserts the new
     108  trunk revisions, then applies your commits on top of those.  Merging leaves your commits where they are,
     109  and adds the trunk revisions alongside them.
     110* Rebasing ends with a linear sequence of commits -- each commit has a single child.  Merging ends up with
     111  a directed acyclic graph of commits -- some commits will have multiple child commits, or multiple parents.
     112* If you encounter conflicts while rebasing, you will fix up each of your commits to deal with the conflicts,
     113  so when you're done, each of your commits will still be self-contained, free of conflicts, and consistent
     114  with the trunk commits that are its ancestors. Conflicts during a merge are handled together at the end of
     115  the merge, in a separate "merge commit" that consists of all the new commits that came from trunk, along
     116  with any edits you make to deal with merge conflicts.  Your commits will still contain their conflicts --
     117  those were fixed externally.
     118* There is also a difference in how your commits will appear in the log, and in particular, what order
     119  they will be in once they are accepted into trunk.  Rebased commits will be shown after the new trunk
     120  commits -- this is the same order in which users of the code will receive the changes if they are updating
     121  their deployments.  Merged commits are shown at the time they were written, not at the time they became
     122  publicly available in trunk.
     123
     124For these reasons, it is preferable to use rebase rather than merge to include trunk changes into your local
     125repository.
     126
     127Regardless of whether you rebase or merge, neither of these is a "safe" operation -- you may make a mistake
     128during the process, or encounter errors or conflicts.  So before starting, a simple way to be sure you can
     129go back to your unmodified branch is to make a copy of the branch.  This assumes you are working on branch
     130mychanges and want to save your work on branch mychanges_backup, and that you have a remote called upstream
     131that points to the trunk repository:
     132
     133{{{
     134# Check whether you have uncommitted changes
     135git log
     136
     137# Commit any new and changed files
     138git add ...
     139git commit ...
     140
     141# Make a backup branch
     142git checkout -b mychanges_backup
     143
     144# Switch back to the branch you want to update
     145git checkout mychanges
     146
     147# Update your branch from trunk
     148git pull --rebase upstream master:mychanges
    109149==== Resolving Merge Conflicts ====
    110150If you encounter conflicts during the rebase, the conflicts will be tagged in the files with: