| |
| |
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.
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.
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
..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".
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.
--
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/6d16f8ab-83b9-39bd-f24b-468c03047b18%40seriss.com.
[ Direct Link to Message ] | |
|
| |
