git main branch - how to use it, or not use it
There is a lot of discussion and ideas about git work flows right now. It will probably take some time for best practices to evolve and gain acceptance on d.o Regarding the main branch, others have said it seems pretty useless when a release (dev in particular) cannot be attached to it anyway. I think the only thing 'special' about main is that it is the default checked out branch when cloning a repository. So, what to do with it... I like the way the rules project seems to be handling it: Just have a readme on the main branch noting that all files are located on other branches and all work should be done there. (Even though this might be a carryover from the good ole CVS days.) Any other suggestions or words of wisdom?
You seem to be talking about the default 'master' branch. In general, we recommend not using a 'master' branch any more. For a release branch (one that can have a dev release following it), use a branch name like 7.x-1.x For a topic branch, you can use any name you want, but it's often good to use a naming convention. For local topic branches I use something like [description]_[issue] or [description]_[issue]/[comment_number]. So for example, fix_broken_headers_99394 or fix_broken_headers_99394/22. For topic branches that you will push up, you may want to use a username on the front in some cases, to point out who the "owner" is. Then a branch could be named like rfay/fix_broken_headers_99394 I did a recent screencast about pushing and deleting topic branches, http://randyfay.com/node/96, that might be useful. -Randy On Tue, Mar 1, 2011 at 12:25 PM, Arlin Sandbulte <arlinsandbulte@gmail.com>wrote:
There is a lot of discussion and ideas about git work flows right now. It will probably take some time for best practices to evolve and gain acceptance on d.o
Regarding the main branch, others have said it seems pretty useless when a release (dev in particular) cannot be attached to it anyway. I think the only thing 'special' about main is that it is the default checked out branch when cloning a repository. So, what to do with it...
I like the way the rules project seems to be handling it: Just have a readme on the main branch noting that all files are located on other branches and all work should be done there. (Even though this might be a carryover from the good ole CVS days.) Any other suggestions or words of wisdom?
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Yes, Sam recommended the same thing in IRC. Here is the relevant issue: http://drupal.org/node/1074960 - Let maintainers set a default branch on git repositories Discussion can continue there. This lets module maintainers delete the master branch without creating a big WTF when someone clones the repository that does not have a master branch, or it does have a master branch, but it is not relevant to anything. On Wed, Mar 2, 2011 at 8:23 AM, Randy Fay <randy@randyfay.com> wrote:
You seem to be talking about the default 'master' branch.
In general, we recommend not using a 'master' branch any more.
For a release branch (one that can have a dev release following it), use a branch name like 7.x-1.x
For a topic branch, you can use any name you want, but it's often good to use a naming convention.
For local topic branches I use something like [description]_[issue] or [description]_[issue]/[comment_number]. So for example, fix_broken_headers_99394 or fix_broken_headers_99394/22.
For topic branches that you will push up, you may want to use a username on the front in some cases, to point out who the "owner" is. Then a branch could be named like
rfay/fix_broken_headers_99394
I did a recent screencast about pushing and deleting topic branches, http://randyfay.com/node/96, that might be useful.
-Randy
On Tue, Mar 1, 2011 at 12:25 PM, Arlin Sandbulte <arlinsandbulte@gmail.com
wrote:
There is a lot of discussion and ideas about git work flows right now. It will probably take some time for best practices to evolve and gain acceptance on d.o
Regarding the main branch, others have said it seems pretty useless when a release (dev in particular) cannot be attached to it anyway. I think the only thing 'special' about main is that it is the default checked out branch when cloning a repository. So, what to do with it...
I like the way the rules project seems to be handling it: Just have a readme on the main branch noting that all files are located on other branches and all work should be done there. (Even though this might be a carryover from the good ole CVS days.) Any other suggestions or words of wisdom?
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Until that is resolved, you can follow the process that many of us did in CVS forever (but back then master was called HEAD :). So I usually just place a README.txt in there saying this is not the right branch, and they should check out branches for Drupal version compatibility (6.x, 7.x respectively). Gábor On Wed, Mar 2, 2011 at 5:24 PM, Arlin Sandbulte <arlinsandbulte@gmail.com> wrote:
Yes, Sam recommended the same thing in IRC. Here is the relevant issue: http://drupal.org/node/1074960 - Let maintainers set a default branch on git repositories Discussion can continue there.
This lets module maintainers delete the master branch without creating a big WTF when someone clones the repository that does not have a master branch, or it does have a master branch, but it is not relevant to anything.
On Wed, Mar 2, 2011 at 8:23 AM, Randy Fay <randy@randyfay.com> wrote:
You seem to be talking about the default 'master' branch.
In general, we recommend not using a 'master' branch any more.
For a release branch (one that can have a dev release following it), use a branch name like 7.x-1.x
For a topic branch, you can use any name you want, but it's often good to use a naming convention.
For local topic branches I use something like [description]_[issue] or [description]_[issue]/[comment_number]. So for example, fix_broken_headers_99394 or fix_broken_headers_99394/22.
For topic branches that you will push up, you may want to use a username on the front in some cases, to point out who the "owner" is. Then a branch could be named like
rfay/fix_broken_headers_99394
I did a recent screencast about pushing and deleting topic branches, http://randyfay.com/node/96, that might be useful.
-Randy
On Tue, Mar 1, 2011 at 12:25 PM, Arlin Sandbulte <arlinsandbulte@gmail.com> wrote:
There is a lot of discussion and ideas about git work flows right now. It will probably take some time for best practices to evolve and gain acceptance on d.o
Regarding the main branch, others have said it seems pretty useless when a release (dev in particular) cannot be attached to it anyway. I think the only thing 'special' about main is that it is the default checked out branch when cloning a repository. So, what to do with it...
I like the way the rules project seems to be handling it: Just have a readme on the main branch noting that all files are located on other branches and all work should be done there. (Even though this might be a carryover from the good ole CVS days.) Any other suggestions or words of wisdom?
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
participants (3)
-
Arlin Sandbulte -
Gábor Hojtsy -
Randy Fay