On 14/01/20 10:07 -0600, Peter Bergner wrote:
As somewhat of a git newbie and given gcc developers will do a git
push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I
don't
screw up the upstream repo by pushing something to the wrong place. :-)
I know enough that I should be using local branches to develop my
changes,
so I want something like:
git checkout master
git pull
git checkout -b <branchNameHere>
<modify and add new files>
git commit -m "My commit message1"
<modify and add new files>
git commit -m "My commit message2"
<modify and add new files>
git commit -m "My commit message3"
<all done!>
At this point, I get a little confused. :-) I know to submit my patch
for review, I'll want to squash my commits down into one patch, but how
does one do that?
This is Git, there are a hundred ways ;-)
Should I do that now or only when I'm ready to
push this change to the upstream repo or ???
Totally up to you. You might want to squash some commits early, e.g.
to fix silly typos, but keep most of the branch history intact until
the last minute (to help you remember what you changed and why).
That's my preference.
Do I need to even do that?
If it's a long-lived feature branch you might want to keep the
separate commits and merge them all to master preserving the branch
history (don't take my word for it, I can't remember what we decided
should be the policy for such long-lived branches).
If it's just a short-lived branch to change one thing, or fix one bug,
then what you push should be a single, self-contained commit (even if
you happened to develop it as a series of mini-commits locally).
Also, when I'm ready to push this "change" upstream to trunk, I'll need
to move this over to my master and then push.
Strictly speaking, you don't need to. You can push that branch
directly to master: git push origin HEAD:master
That will fail unless the current branch is up-to-date with master,
but would work fine if you've already rebased your branch on master,
or if master hasn't moved since you branched.
What are the recommended
commands for doing that? I assume I need to rebase my branch to
current upstream master, since that probably has moved forward since
I checked my code out.
You can either rebase on the new master (i.e. bring the new stuff from
master into your branch) or the other way around (bring the stuff from
your branch into master).
A pretty straightforward way to do the second way is:
git checkout master
git pull
git merge --squash <branchNameHere>
[resolve any merge conflicts]