Another common practise for release naming is the usage of tags. In my projects, for example, I have several tags like v1.0.0, v2.4.2 and such. On 21 Apr 2014 14:53, "Simon Joseph Aquilina" <saquilina...@gmail.com> wrote:
> Hi Konstantin, > > 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? > > > > > On Monday, April 21, 2014 12:23:31 PM UTC+2, Konstantin Khomoutov wrote: >> >> On Mon, 21 Apr 2014 02:55:50 -0700 (PDT) >> Simon Joseph Aquilina <saquil...@gmail.com> wrote: >> >> > I am new to git and I would like to know what are the best practices >> > when creating a new branch. For example. If I get a request to do >> > update website title from XYZ to ABC; then should I create a branch >> > named; "Update Title"? Or I should prefix this as suggested here >> > (http://stackoverflow.com/questions/273695/git-branch- >> naming-best-practices). >> > Are there any official prefixes? >> > >> > Also I am concerned about the following; >> > >> > Let us say I create the branch named "Update Title". Finish the >> > change. Merge back with Master. I then get another request to change >> > title from ABC to DEF. Can I create another branch "Update Title". >> > Will not this be confusing? >> >> In Git, a branch is merely a pointer to a commit. The crucial bit is >> "pointer" -- this means any commit might be pointed to by any number of >> branches at the same time, and that's why commits do not "belong" to >> any branch. Hence whatever meaning you put into a branch name is only >> in your head -- this does not affect commits reachable from that branch >> in any way. Moreover, once you merge a branch into another, and >> subsequently delete the merged branch, the commits made on it stay >> there forever while there's no more traces left of the deleted branch -- >> as if it had never existed. >> >> So, do whatever you want with your branches. Giving your branches >> names like "Update Title" is not a common practice but for purely >> technical reason: in Git, a branch is represented by a file on a >> filesystem, and using branch names with "funny characters, spaces >> included" might, in some situations, cause problems. So I'd name your >> branch "update-title" -- that is, no title casing, no spaces. >> >> Another popular approach is to put your bug tracker / ticketing system >> first: when you're given a task to update the site's title, open a bug >> for this first and get that bug's ID back, then simply encode the bug's >> title into the branch name, like "bug-12345". This will give you >> unique branch names. When you merge you branch back to the integration >> branch you mention the bug's ID in the commit message and then close >> the bug in the tracker. >> >> Note that Git has certain means to attach "metadata" to your branches. >> Two of them that I know of are >> >> * `git branch --edit-description` which allows you to set a description >> of the purpose of that branch. This description is used by some other >> Git tools but you can print it back using the `git config` command: >> >> git config branch.bug-12345.description >> >> * `git notes` allows you to attach a note to any commit. Notes are not >> pushed by default (and supposedly the shouldn't be, unless everyone in >> the team agrees to do that as they were supposed to be used locally). >> > -- > 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. > -- 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.
