> How, then, do I update code? ie. I perform my initial clone, make
> some changes and commit / push them. Someone else then comes along,
> makes some changes and commits them. The next day, I do Remote ->
> Fetch from -> origin to update my code to the latest in Git but
> c:\git\test\clone\README is exactly the same as it was before. How do
> I update the initial clone such that I can edit the updated files?
As Dmitry already said, you can either merge in the upstream changes,
or rebase your own changes on top of the upstream changes. I usually
rebase.
Here's my typical workflow. It may not be elegant, but it works well
for me. Hopefully it's useful for you, because understanding workflow
was one of the most intimidating parts of learning git for me.
git pull # equivalent of git fetch + git merge
# ... my local master is always clean; this is a fast-forward
git checkout -b exp_smoothing
# create a new branch to work
vi # start making my intended changes
git add # stage my changes
vi # make some more changes I don't want to commit, like enabling
# debug, bypassing some uninteresting code, etc.
gcc # oops, there were syntax errors
vi
git add # to stage just the relevant fixes (or git add -p)
git commit # save my progress
run # discover some things to fix
... # repeat the bit from gcc to here many times over
run # It works .. maybe it's a few days since I started
# By now, my history is an ugly mess
git rebase -i exp_smoothing^
# I re-order, combine, and split commits
# When I'm done, the history is neat and logical
git checkout master
# switch back to master (which is still clean)
git pull origin
# get any updates from the last couple days
# there will be no conflicts; it's a fast-forward
My history looks like this:
exp_smoothing branch
|-- a <-- b <-- c <-- d
v
master: Z <-- Y <-- X <-- W <-- V
Before switching back to master and doing pull, I only knew about Z
and Y, and in my own local repository, I added a, b, c, d, which are
the cleaned-up version of my exp_smoothing development. When I did
a git pull, I incorporated X, W, and V.
Picking up with the workflow again...
git checkout exp_smoothing
# back to my work-in-progress branch
git rebase master
# replay exp_smoothing on top of the new master (now
# at V instead of Y)
# resolve conflicts, if X, W, V conflict with a, b, c, d
History is now:
exp_smoothing branch
|-- a' <-- b' <-- c' <-- d'
master: v
Z <-- Y <-- X <-- W <-- V
git checkout master
git merge exp_smoothing
# because I resolved all the conflicts during the rebase
# this should merge conflict-free, as a fast-forward.
git push origin
# publish my changes (to master) for the rest of the world
git branch -d exp_smoothing
# exp_smoothing is merged into master; no need to keep it
# around anymore
The last four steps occur very quickly. The final history is:
master: Z <-- Y <-- X <-- W <-- V <-- a' <-- b' <-- c' <-- d'
Given my workflow, why branch at all? Sometimes I may be working
on more than one branch at a time, or I may get interrupted on
exp_smoothing development to make a regression fix to master, or
maybe I discover that I don't want to merge exp_smoothing until the
next major version release. It's just easier to manage as a separate
branch up until the last four or six steps. I can rebase exp_smoothing
on top of master over and over again until I finally merge and publish
it.
Tait
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html