On Mon, Apr 21, 2014 at 4:35 PM, Konstantin Khomoutov <flatw...@users.sourceforge.net> wrote: > On Mon, 21 Apr 2014 05:53:41 -0700 (PDT) > Simon Joseph Aquilina <saquilina...@gmail.com> wrote: > >> Thanks for your reply. Reading your reply make me think that it is >> common practice to delete branches after development on these has >> finished (for example branches used only to solve a bug or add a >> feature). Is this so. I was planning to also have branches for >> releases. For example when I am at release 1.0 I create a branch and >> then I continue development on master. When I am ready for 2.0 >> release I create another branch and so on. Is this common practice? >> Or version mile stone should not be managed this way? > > Yes, this is a common practice precisely because in Git, merging a > branch preserves all commits done on it so there's no much sense to > keep such a branch after merging. (Of course, if no further > development on it is planned; otherwise it's perfectly fine to continue > development and merge again after some time -- Git handles this > situation just fine for before merge it locates the last common between > the two sides of the merge and if it finds one it performs a three-way > diff using all these tree commits so already committed textual data is > not considered.)
AFAIK there is also no record of what branch a commit was made on so once two branches are merged there is no telling which path is the result of which branch. I believe this is often touted as a flaw of Git. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- 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.