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