Phil Pennock wrote:
[...]
> IF you want to make the code available on the server you cloned from as
> a branch, and accept that this involves a non-linear history (eg, a
> major feature change where it's worth keeping a more accurate history)
> then:
And if you just want do have a local branch, to do your work in and
still want to enforce linear history, you can use the same workflow as
Phil described. You just need to "replay" your changes on top of
"master". "git rebase" does that.
> % git push origin feature_foo
> [ do mailing-list stuff here ]
>
> Switch back to master:
> % git checkout master
> and get the most recent changes:
> % git pull
Switch back to the feature branch:
% git checkout feature_foo
Rebase the feature branch on top of new changes that were just pulled:
% git rebase master
This does the following (ASCII graphs from git's manual):
Commit situation before the rebase:
A---B---C topic
/
... D---E---F---G master
And after:
A'--B'--C' topic
/
... D---E---F---G master
This essentially replays the commits from the topic (or feature) branch
on top of master. That creates commits with different SHA1 sums, hence
the apostrophes with the rebased branch.
> then bring in your changes:
> % git merge feature_foo
That merge is a fast-forward then, because it just involves putting the
pointer of the master branch to the tip of the topic branch; because its
linear history again - no real merges involved at all.
> % git commit
> % git push
[...]
> git help tutorial
> git help tutorial-2
> git help gitcore-tutorial
Those are actually pretty helpful indeed.
Regards, Frank
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
-- RFC 1925