Hello, The point is to rebase before pushing, thus, only rearrange/edit only the commits that haven't gone public yet. Rebasing is only a bad idea if you do it with already pushed commits.
The other use case is rebase on pull. If your upstream changes while you develop your own code, do a git pull --rebase instead of a plain git pull. This will rebase your changes on the fresh state of upstream. Cheers, Gergely On 26 Sep 2013 05:57, "Konstantin Kivi" <konstantin.k...@gmail.com> wrote: > Honestly, I right now I don't have to publish (make public ) branches, as > for current > progects I use git locally, and use svn as main repository. But new > projects use > git only, so I have to return to right track. All documenation says that > rebasing a > branch that was made public is a bad idea, as people who used my branch > will > have numerous conflicts after I do rebase. > > As to recompilations, it of course depend on the nature of changes in > master branch > and in my task branch. If in my task I have heavy header file changes > (C++) > then switching to master ( which is requiried to do svn up or git pull ) > will > cause timestamp changes of that header and thus recompliations. Updates of > master > branch can also change header files, so sometimes it doesn't matter. > > The main reason of not useing rebase is that it is not recommended by > books. > > > > > > среда, 25 сентября 2013 г., 15:37:30 UTC+4 пользователь Marcelo Avila > написал: >> >> Yes, the solution is to switch back to the rebase approach... >> >> I didn't understand some points: Why you "could not publish your task >> branch"? Why the rebase approach "leads to massive recompilations"? >> >> -- >> *Marcelo Ávila de Oliveira* >> CPqD - Information Technology Engineer >> Tel.: +55 19 3705-4125 >> mav...@cpqd.com.br >> www.cpqd.com.br >> >> >> 2013/9/25 Konstantin Kivi <konstan...@gmail.com> >> >>> Hello All. >>> >>> First I must apologize for asking a question in >>> other people's thread (which I don't like myself) , but you are talking >>> about >>> the approach that I am going to use, so decided that this will be >>> appropriate in this case. >>> >>> Here is the question. >>> >>> >>> I recently decided to switch from 'task branch rebase' aproach to >>> 'merge' approach. >>> >>> I used to work in the task branch, periodically switching to master, >>> making pull and >>> rebasing task branch. This worked fine, except I could not publish my >>> task branch. >>> And it also leads to massive recompilations, since I have to switch to >>> master and then back. >>> >>> I decided to switch to merge apporoach, that is do fetch periodically, >>> and then >>> merge 'origin/master' to my task branch. >>> >>> The problem now is how to check what I have done. >>> >>> I always can find what I have done in my branch from the start, by 'git >>> diff origin/master...task_b' >>> but I cannot find my changes between two given commits or by several >>> last commits, as it always >>> shows any merges that have been done in-between. Is there any remedy >>> for this problem ? >>> >>> Regards, Konstantin >>> >>> -- >>> 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+...@**googlegroups.com. >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >> >> -- > 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/groups/opt_out. > -- 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/groups/opt_out.
