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.) -- 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.