Changes between Version 16 and Version 17 of WorkingWithGit


Ignore:
Timestamp:
Aug 20, 2016, 9:37:33 PM (8 years ago)
Author:
neverpanic (Clemens Lang)
Comment:

Document git stash for rebasing, add anchors for direct linking

Legend:

Unmodified
Added
Removed
Modified
  • WorkingWithGit

    v16 v17  
    4545== Common `git` tasks while working with MacPorts base ==
    4646
    47 === Checking out a working copy ===
     47=== Checking out a working copy === #clone
    4848The source code of MacPorts itself is no longer managed in the same repository as all ports. Contrary to Subversion, checking out a sub-directory of a repository is not possible with Git. In order to avoid that all port maintainers have to clone the complete history of MacPorts base as well, the Subversion repository has been split into multiple separate repositories. MacPorts base is now available using
    4949{{{
     
    5454See the [#reposplit section on repository splitting during the export] to get an overview of where a path in the old Subversion history is now available in Git.
    5555
    56 === Committing changes in your working copy ===
     56=== Committing changes in your working copy === #commit
    5757A fundamental difference between Subversion and Git working copies is that `svn commit` by default commits all changes in your working copy, but `git commit` by default commits none. Git uses a staging area called "index" that allows you to mark changes for inclusion in the next commit. To add changes to the next commit, use
    5858{{{
     
    8585Note that the push will fail if the remote repository has new changes. Contrary to Subversion, it does not matter whether your changes conflict with the remote ones. If this happens, you must update your local working copy as described in the [#updating section on fetch the latest changes] and re-try the push.
    8686
    87 === Merge a single change from master into a release branch ===
     87=== Merge a single change from master into a release branch === #cherrypick
    8888The equivalent to Subversion's `svn merge -c <revision> .` is `git cherry-pick`. Use `git cherry-pick` to apply a single change from master to a release branch. To do this, look up the commit ID of the commit you want to pick:
    8989{{{
     
    153153}}}
    154154
     155'''Note:''' `git rebase` requires that you do not have uncommitted modifications in your working copy. If you have modifications, you can temporarily save them using `git stash` and restore them after the rebase using `git stash pop`.
    155156'''Warning:''' `git pull` without the `--rebase` flag is a shorthand for `git fetch && git merge origin/master`, which will automatically create a merge commit if it thinks that's necessary.
    156157
     
    165166 1. Wrap the body at 72 characters
    166167 1. Use the body to explain what and why vs. how
    167 
    168 
    169168
    170169=== Repository split === #reposplit