Timeline for Git workflow and rebase vs merge questions
Current License: CC BY-SA 2.5
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 9, 2018 at 19:06 | comment | added | Alois Mahdal | I 100% agree with the first paragraph. (@Edward's answer works where that is not the case, but I'd rather have all project in the world work like you suggest). The rest of the answer seems a bit far-fetched in sense that working on C while A and B are in progress is already sort of risky (at least to the extent it really depends on A and B), and even in the end you would not probably keep the merges (C would get rebased on top of the latest & greatest). | |
| Jun 28, 2009 at 15:06 | comment | added | Alex Gontmakher | Indeed I don't want to duplicate the commits. I would like to keep the in-flight structure of my work as clean as possible. But that's a matter of personal taste and is not necessarily right for everybody. | |
| May 25, 2009 at 6:55 | comment | added | odwl | You could achieve the same with just rebases. The merge is actually not necessary here (except if you don't want to duplicate the commits - but I hardly see that as an argument). | |
| May 12, 2009 at 20:54 | history | answered | Alex Gontmakher | CC BY-SA 2.5 |