during my GitHub based development (which is pretty much similar to what
you just described) I do the following:
• fork the original repo, so that my GH account has a copy of it
• clone the forked repo to my machine
• add the original repo as a second remote and name it "base"
• start my feature branch off of base/master: git checkout -b myfeature
base/master. This way, git status tells you immediately if my brange has
diverged from upstream
• code-code-code, occasionally pushing my feature branch to my fork (origin)
• if the coding takes longer than a day, I sometimes fetch from base, and
rebase my work to base/master. This way my feature branch remains up to
date, and less polluted. This, though, requires me to force push to my fork
(origin/myfeature) after the rebase; if this would cause problems, I tag
ORIG_HEAD just in case, but still force push
Hope it helped.
On Dec 28, 2015 10:07 PM, "Magnus Therning" <mag...@therning.org> wrote:
> Ben Rubinger writes:
> > Hi Steve,
> > Thanks for your reply. Your input is helpful. I've spent the past five
> > days reading through this book:
> > http://www.amazon.com/gp/product/B008Y4OR3A
> > My hesitancy around rebasing was around the fact that (if I understood
> > correctly) all rebased checkins are deltas, having different hashes
> > from their original with the implication that if others have checked
> > out your branch, they will feel pain after you perform a rebase. I'm
> > not sure if I captured this correctly, but in general it seemed like
> > rebasing can be inconsiderate to others with whom you're working. What
> > advice do you give to people you're training around this? And, if
> > rebasing does introduce certain risks, is merging possible while
> > avoiding polluted PRs?
> Your intuition is completely correct, rebasing *is* inconsiderate to
> your collaborators. Personally I deal with it like this:
> 1. If possible I do not publish things that I know I'll have to rebase
> later on. Of course that's rather rarely possible :(
> 2. I've chosen a prefix for published branches that may be rebased,
> "devo/". I then make sure to communicate to the rest of the team that
> it's not safe to base any work on branches named liked that.
> 3. Finally I try to keep my "devo/" branches as short-lived as possible.
> I'd love to hearother people's strategies.
> Magnus Therning OpenPGP: 0x927912051716CE39
> email: mag...@therning.org jabber: mag...@therning.org
> twitter: magthe http://therning.org/magnus
> There's a big difference between making something easy to use and
> making it productive.
> -- Adam Bosworth
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.