Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
git
提交
2389460a
G
git
项目概览
李少辉-开发者
/
git
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
git
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
2389460a
编写于
6月 01, 2020
作者:
J
Junio C Hamano
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
MaintNotes: adjust for pinbox->lore, mention CoC
上级
b965c39e
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
16 addition
and
9 deletion
+16
-9
MaintNotes
MaintNotes
+16
-9
未找到文件。
MaintNotes
浏览文件 @
2389460a
...
...
@@ -34,14 +34,14 @@ becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://
public-inbox
.org/git/
http://
lore.kernel
.org/git/
http://marc.info/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://nntp.lore.kernel.org/org.kernel.vger.git
nntp://news.public-inbox.org/inbox.comp.version-control.git
nntp://news.gmane.org/gmane.comp.version-control.git
are available.
...
...
@@ -49,7 +49,7 @@ When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:
http://
public-inbox
.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
http://
lore.kernel
.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
...
...
@@ -69,6 +69,12 @@ Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/). To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.
For our expectations on the behaviour of the community participants
towards each other, see CODE_OF_CONDUCT.md at the top level of the source
tree, or:
https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md
* Reporting bugs
...
...
@@ -118,7 +124,6 @@ My public git.git repositories are (mirrored) at:
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
This one shows not just the main integration branches, but also
individual topics broken out:
...
...
@@ -127,7 +132,7 @@ individual topics broken out:
A few web interfaces are found at:
http://git.kernel.org/
cgit
/git/git.git
http://git.kernel.org/
pub/scm
/git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
...
...
@@ -152,11 +157,11 @@ of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch. They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but
recently w
e
named with three dotted decimal digits (e.g. "1.8.5"), but
we hav
e
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
The last such release was 2.
15 done on Oct 30th, 2017
. You can expect
The last such release was 2.
27 done on Jun 1st, 2020
. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.
...
...
@@ -169,8 +174,8 @@ of last-minute issues. The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release). These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.
12
.1"
was the first maintenance release for the "2.
12
" series).
incrementing the last digit of three-dotted decimal name (e.g. "2.
26
.1"
was the first maintenance release for the "2.
26
" series).
New features never go to the 'maint' branch. It is merged into "master"
primarily to propagate the description in the release notes forward.
...
...
@@ -214,6 +219,8 @@ The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.
A natural consequence of how "next" and "pu" bundles topics together
is that until a topic is merged to "next", updates to it is expected
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录