| |
| |
On 12/18/21 6:05 PM Greg Ercolano wrote:
On 12/18/21 7:40 AM, Albrecht Schlosser wrote:
Current situation:
remote: origin/master - A - B - C - D
local: master - A
\
local: working . . . . E - F - G
What you want to achieve is that your commits E - F - G are "rebased"
onto the tip of remote branch origin/master after commit D, like this:
remote: origin/master - A - B - C - D
local: master - A - B - C - D
\
local: working . . . . . . . . . . E' - F' - G'
Yes, pretty sure that's what I want to achieve, as I'm working on
a branch, "issue_332",
which I'll want to push in an early state for folks to see (but
not use), then make subsequent
tweaks and keep pushing new changes that can then be tested by
others in that branch.
You can do this w/o rebasing for some time, knowing that your branch is
not up-to-date with current (remote) master if the latest changes don't
affect your branch, but if you rebase from time to time (which is IMHO
okay) then others need to follow your changes (rebase). This makes it
harder for others but if it's useful to rebase, feel free to do it, at
least before the final merge.
So I take it then I can use this slightly simpler form you
mentioned at the end:
git checkout master -- switch from your branch
(working) to master
git pull -- get the latest from the remote.
If your local master is clean, this shouldn't fail
git rebase master working -- rebase your branch 'working' on
'master' and checkout 'working'
..and use that to keep sync'ed during branch development.
Yes, you can do this. But as soon as you push your commits to the remote
repo (your fork) after a rebase you will need to use --force for pushing
(which is why I wrote it will make it harder for others to follow).
Then when everything works, close out the issue by merging the
branch to master
and deleting the no-longer needed branch, which I think ends up
being something like:
git checkout master -- checkout master
git pull -- get latest
git merge issue_332 -- merge in my branch to master
(assuming I've squashed my branch down to some minimal history)
git push origin master -- push the result
I hope you can still follow me ... "assuming I've squashed my branch
down to some minimal history" doesn't include "and rebased on top of
master" which may have been changed by `git pull'.
At this point it may be more convenient to use a PR and GitHub's "merge
button" which lets you rebase and squash with one click. But if you want
to do it manually you can combine both "recipes" like this:
git checkout master -- checkout master
git pull -- get latest
git rebase -i master issue_332 -- rebase and squash development branch
git checkout master -- prepare for final merge
git merge --ff-only issue_332 -- merge in my branch to master
(assuming ... (see above))
git push origin master -- push the result
Note that I added '--ff-only' (fast forward only) to the merge command
to make sure that you don't get a real "merge commit" and that your
commits are all in a clean order on top of master. You may want to do a
"real" merge (w/o '--ff-only') if you leave more than one commit in your
branch or if your branch does not branch off the tip of master (remember
the "knuckle"?).
..and after that, delete the branch from both local and remote:
git branch -d issue_332 -- delete unused branch
from local
git push origin --delete issue_332 -- delete unused branch
from origin
I think others may still see the issue_332 branch in their copies
after a pull,
even though I deleted it, unless they do a "git fetch -prune".
That's correct. I didn't know "git fetch --prune" (note: either double
dash or "-p"). What I'm using in such a case is "git remote prune
origin" or any other remote than 'origin'. This does obviously the same.
Before you do that it's interesting to execute "git remote show
<remote-name>" to get status info about remote and related local branches.
The recipe above does exactly that (replace "<local-branch>") with
"working". Again, commits E' - F' - G' differ from your original E -
F - G in that they have different hashes.
Right, that makes sense.
Where that might get interesting is if devs make "github code
comments" on my branch commits,
i.e. they go into my branch's commit and use "+" on the code diffs
to add a code comment).
If I later do a rebase and push to show my latest branch changes,
I wonder if github is smart enough
to carry those code comments along with the rebased hashes.. hrm.
I don't know the answer, but would that be smart? I would assume that
you replied to those comments (and "closed" each issue/comment) and
fixed any issues related to the comments before you rebased your branch.
How would GitHub "know" whether the code comments still apply to the
rebased and modified branch?
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/cc26863e-80ff-b968-8a73-08b2a1121a42%40online.de.
[ Direct Link to Message ] | |
|
| |
