日韩黑丝制服一区视频播放|日韩欧美人妻丝袜视频在线观看|九九影院一级蜜桃|亚洲中文在线导航|青草草视频在线观看|婷婷五月色伊人网站|日本一区二区在线|国产AV一二三四区毛片|正在播放久草视频|亚洲色图精品一区

分享

gerrit 權(quán)限控制--好

 ala咪s 2016-08-25

sed. Every user account is a member of one or more groups, and access and privileges are granted to those groups. Access rights cannot be granted to individual users.

在gerrit中權(quán)限控制是基于群組的. 每個用戶有一個或者多個群組, 訪問權(quán)限被賦予這些群組.訪問權(quán)限不能賦予個人用戶.

System Groups

Gerrit系統(tǒng)自帶下面的群組

  • Anonymous Users
  • Change Owner
  • Project Owners
  • Registered Users

Anonymous Users

所有用戶都是匿名用戶成員, 所有用戶都能繼承Anonymous Users所有訪問權(quán)限. 
當(dāng)前只有Read access權(quán)限值得賦予給Anonymous Users群組, 因為其他權(quán)限都需要認(rèn)證. 
這里寫圖片描述

Project Owners

Project Owners的訪問權(quán)限在Project范圍內(nèi)有效 
這里寫圖片描述

Change Owner

Change Owner的訪問權(quán)限在Change范圍內(nèi)有效

Registered Users

所有在頁面上登錄成功的用戶都會自動注冊為gerrit用戶,屬于Registered Users群組 
Registered Users群組通常被賦予Code-Review -1..+1權(quán)限, 允許給需要審查代碼投票, 但不會引起審查被批準(zhǔn)和拒絕 
這里寫圖片描述

Predefined Groups

system groups在Gerrit系統(tǒng)內(nèi)部就定義好了, 而普通群組信息被保存在ACCOUNT_GROUPS表中,Predefined groups群組信息也保存在ACCOUNT_GROUPS表中. Predefined groups群組在Gerrit初始化時創(chuàng)建并且擁有唯一的UUID 
All-Projects -> meta/config -> groups文件內(nèi)容

# UUID                                      Group Name
#
5210215f92225c45a5ad123016c8706336f55a7d    Administrators
df9b717d413c614cb51e39525619b311f077ec15    Non-Interactive Users
global:Anonymous-Users                      Anonymous Users
global:Project-Owners                       Project Owners
global:Registered-Users                     Registered Users
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Gerrit自帶兩個predefined groups:

  • Administrators
  • Non-Interactive Users

Administrators

AdministratorsGerrit root角色, 在Gerrit初始化時Administrate Server權(quán)限被賦予給這個Predefined Groups群組. 
Administrators組的成員可以管理所有項目, 但是不意味著任何其他權(quán)限. Administrators組不會自動獲得代碼審查批準(zhǔn)和提交權(quán)限.

Non-Interactive Users

Interactive Users比如在web頁面上審查代碼, 在提交/獲取代碼的用戶 
Non-Interactive Users是可以通過Gerrit接口進(jìn)行操作的組, 在Gerrit初始化時Priority BATCHStream Events權(quán)限被賦予給這個Predefined Groups組. 
Non-Interactive UsersInteractive Users使用不同的線程池, 防止交互式用戶搶占線程. 當(dāng)系統(tǒng)資源緊張時確保了交互式的用戶可以繼續(xù)工作.

Project Access Control Lists

All Projects

All Projects項目中的訪問權(quán)限會自動被其他項目繼承, 只有Administrate Server capability能夠編輯All-Projects權(quán)限. 
這里寫圖片描述

Per-Project

先計算子項目的訪問權(quán)限, 再計算All Projects的訪問權(quán)限, 允許一些權(quán)限可以被覆蓋. 
對一個群組賦予DENY限制時, 通常只對READ權(quán)限有效. 
這里寫圖片描述

Special and magic references

refs/heads/*refs/tags/*是Git常用的引用命名空間, 一個用來存儲分支一個用來標(biāo)簽 
refs/*命名空間下的引用都是有效的,Gerrit在refs/*有一些特殊用處的命名空間和引用

Special references

這些特殊的引用的內(nèi)容由Gerrit生成或者包含重要的項目配置信息

refs/changes/*          #用于存儲審查的補(bǔ)丁
#獲取某個補(bǔ)丁集需要審查序號和補(bǔ)丁集序號
#'refs/changes/'<last two digits of change number>/ <change number>/ <patch set number>
refs/meta/config        #項目配置的分支
refs/meta/dashboards/*  #
refs/notes/review       #保存代碼審查信息的分支
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

Magic references

refs/for/<branch ref>  #進(jìn)行代碼審查時需要提交代碼到這個命名空間
refs/publish/*         #和refs/for/*命名空間作用一樣
refs/drafts/*          #用于草案代碼審查,和refs/for/*的區(qū)別在于只有部分人可見
  • 1
  • 2
  • 3
  • 1
  • 2
  • 3

添加新的補(bǔ)丁

#審查者對代碼進(jìn)行修改, 審查的代碼是修改后的補(bǔ)丁
git fetch ssh://admin@localhost:29418/gerrit_ci refs/changes/03/3/1
git branch fix_xxx FETCH_HEAD && git checkout fix_xxx
vi README
git add README
git commit --amend
git push origin HEAD:refs/for/master
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

查看遠(yuǎn)程引用

git ls-remote ssh://admin@localhost:29418/gerrit_ci
61fd289472707d79f73289216a4c5f0ca4cee4e1    HEAD
eeaef9da4ea27d7c23bfb5f9a2ed1b5357ebbba8    refs/changes/01/1/1
5f8ed98b0f88787c22e705595e2818db62874f56    refs/changes/02/2/1
bfdb700f4aab3afc32ec79a29b0e25f8be758f8f    refs/changes/03/3/1
effa7b004eec0b85e722fe10be6468e4ed9b78d3    refs/changes/03/3/2
61fd289472707d79f73289216a4c5f0ca4cee4e1    refs/heads/master
9f282c08d5108c6817dd1504e8bec0e94ba59d47    refs/meta/config
405030285eed7406b1ac7cfa6a5211331165b8e2    refs/notes/review
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

修改項目配置文件

git clone ssh://admin@localhost:29418/All-Projects && scp -p -P 29418 admin@localhost:hooks/commit-msg All-Projects/.git/hooks/

#refs/meta/config 是All-Projects的引用
git fetch origin refs/meta/config:refs/remotes/origin/meta/config
git checkout meta/config
#現(xiàn)在目錄下有g(shù)roups  project.config兩個文件
#提交修改
git add .
git commit -m "modify config"
git push origin meta/config:meta/config
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

Access Categories

Abandon

代碼審查時允許用戶丟棄這個審查。如果對changepush權(quán)限,同時具有push,abandon,restore權(quán)限

Create Reference

用戶可以創(chuàng)建新的references, branches or tags, 創(chuàng)建時引用必須不存在,不能刪除已經(jīng)創(chuàng)建的引用 
如果僅僅推送標(biāo)簽,給refs/tags/*賦予Create Reference權(quán)限 
這個權(quán)限通常用在創(chuàng)建某個命名空間下的分支, 如:某個部門自由創(chuàng)建分支權(quán)限refs/heads/hello/* 
給某用戶自由創(chuàng)建分支權(quán)限, 給refs/heads/sandbox/${username}/*賦予Create Reference權(quán)限 
如果你這樣賦予Create Reference權(quán)限,記得同時賦予push force權(quán)限, 這樣擁有清理 
這里寫圖片描述

Forge Author && Forge Committer && Forge Server

查看提交中AuthorCommitter

git log --format=full
commit 2dfae738781a3ba641ee06c913fd51162335a941
Author: admin <c2290910211@163.com>
Commit: gerrit_test <c2290910211@aliyun.com>

    admin gerrit_test

    Change-Id: I0830cf061306101e977f9adf55270c9b3a3f59c4
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

Author一般表示誰創(chuàng)建了這個提交,也可以用git commit --amend --reset-author等命令修改 
Committer一般表示誰修改了這個提交,在使用git commit --amend等命令時修改 
通常Gerrit需要在Author和提交的Committer認(rèn)證信息中至少一個,與uploading user注冊過的郵箱地址匹配,Forge AuthorForge Committer允許用戶繞過提交時的身份驗證 
Forge Author允許提交中Author信息不經(jīng)過驗證, 這個權(quán)限在下面場景非常有效,通過郵件接收第三方補(bǔ)丁,cherry-pick其他人的分支提交,審查合并前修改其他人的一些次要問題. 
默認(rèn)在All-Projects賦予Registered UsersForge Author權(quán)限. 
Forge Committer允許提交中Committer信息不經(jīng)過驗證和不驗證匿名標(biāo)簽對象,通常在需要其他服務(wù)器自動提交時有用 
Forge Server允許在提交中Committer信息使用Server的用戶名和郵箱. 這個權(quán)限在強(qiáng)制推送git filter-branch修改過信息的提交和由這個Gerrit Code Review server創(chuàng)建的合并提交時有用. 
etc/gerrit.config可以配置Server的用戶名和郵箱,user.name默認(rèn)值Gerrit Code Review, user.email默認(rèn)值在啟動時生成gerrit@hostname 
這里寫圖片描述

Owner

允許修改項目以下配置:

  • 改變項目描述
  • 通過SSH創(chuàng)建新的分支
  • 通過Web界面創(chuàng)建和刪除分支
  • 賦予和撤銷任何訪問權(quán)限,包括Owner權(quán)限

子命名空間的所有權(quán)可以通過命名空間格式來委派. 要委派以qa/開始的所有分支權(quán)限給QA群組,給refs/heads/qa/*添加Owner權(quán)限。 QA小組的成員可以進(jìn)一步細(xì)分訪問權(quán)限,但只能對refs/heads/qa/開始的分支有效.

Push

這類分支控制用戶如何上傳提交到Gerrit. 根據(jù)命名空間賦予的Push權(quán)限, 可以允許繞過代碼審查直接推送到分支, 也可以允許創(chuàng)建新的change進(jìn)行代碼審查.

Direct Push

Direct Push權(quán)限下,任何已經(jīng)存在的分支都接收fast-forward提交,創(chuàng)建新的分支需要Create Reference權(quán)限. 刪除已經(jīng)存在的分支會被拒絕,因為在這個最安全的模式下, 提交不會被丟棄.

Force選項

允許分支被刪除. 由于force push實(shí)際上刪除分支后會創(chuàng)建這個分支,但是這是個原子操作并且會被記錄,也允許force push更新分支. 帶有force選項會導(dǎo)致項目歷史中的提交被丟棄. 
force選項對只想使用Gerrit訪問權(quán)限功能而不需要代碼審查的項目有效, 對于需要進(jìn)行代碼審查的項目不應(yīng)該分配這個權(quán)限.

Upload To Code Review

Upload To Code Review權(quán)限授權(quán)在refs/for/refs/heads/BRANCH命名空間上,允許用戶上傳non-merge提交到refs/for/BRANCH命名空間,創(chuàng)建新的change進(jìn)行代碼審查. 
用戶在自己環(huán)境下提交代碼需要clone/fetch項目代碼,所以必須賦予Read權(quán)限 
對于開源公開的Gerrit安裝方式,All-Projectsrefs/for/refs/heads/*通常給Registered Users賦予ReadPush權(quán)限. 很多私有安裝, 通常refs/for/refs/heads/*通常給all users簡單的賦予ReadPush權(quán)限. 
force選項賦予refs/for/refs/heads/*命名空間沒有作用.

Push Merge Commits

Push Merge Commits權(quán)限允許用戶上傳merge commits.這是Push附加的訪問權(quán)限,所以只賦予Push Merge Commits權(quán)限是不夠的. 一些項目希望只能由Gerrit自動合并提交, 可以通過只賦予Push權(quán)限而不賦予Push Merge Commit權(quán)限. 
賦予Push Merge Commit權(quán)限通常必須以refs/for/為前綴,例如refs/for/refs/heads/BRANCH. refs/heads/BRANCH作為補(bǔ)充, 賦予Read權(quán)限后允許直接推送non-merge提交,賦予Push Merge Commit權(quán)限后也允許直接提交一個merge提交.

Push Annotated Tag

允許推送帶注釋的標(biāo)簽到遠(yuǎn)程倉庫, 標(biāo)簽必須帶有注釋.

#創(chuàng)建帶注釋的標(biāo)簽
git tag -a <tagname> -m <comment>
#提交標(biāo)簽到遠(yuǎn)程倉庫
git push origin --tags
#獲取標(biāo)簽
git fetch --tags
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

標(biāo)簽的email一定會與提交者的郵箱進(jìn)行驗證,如果推送其他人的標(biāo)簽需要同時賦予Push Annotated TagForge Committer Identity權(quán)限.

git show v1.0
tag v1.0
Tagger: username <email>
  • 1
  • 2
  • 3
  • 1
  • 2
  • 3

如果需要推送輕量級標(biāo)簽(不帶注釋), 給refs/tags/*命名空間賦予Create Reference權(quán)限, 輕量級標(biāo)簽就像Git中的分支一樣. 
如果需要刪除或者重寫標(biāo)簽, 給refs/tags/*命名空間賦予帶force選項的Push權(quán)限,刪除標(biāo)簽需要和刪除分支一樣的權(quán)限.

Push Signed Tag

允許推送PGP簽證的標(biāo)簽到遠(yuǎn)程倉庫

git tag -u "gpg-key-id" -m "tag comment" <tagname>
  • 1
  • 1

Read

Read權(quán)限控制查看項目的change,comment,code diff和通過SSH或者HTTP協(xié)議訪問倉庫的權(quán)限 
這個權(quán)限非常特殊, 先計算項目中的Read權(quán)限, 再計算all-projectsRead權(quán)限. 
如果項目中賦予DENY Read權(quán)限,all-projects項目不管是否賦予ALLOW READ都將無效.這個權(quán)限對于隱藏一些項目非常有用.

Rebase

允許用戶在web頁面上進(jìn)行rebase changes, change作者和提交者可以通過頁面進(jìn)行rebase changes(盡管沒有賦予Rebase權(quán)限)

Remove Reviewer

允許用戶從審查者列表中移除其他用戶. 
Change owners能夠移除那些審查分?jǐn)?shù)為0或者負(fù)數(shù)的審查者.(盡管沒有賦予Remove Reviewer權(quán)限) 
Project ownerssite administrators能夠移除任何審查者(盡管沒有賦予Remove Reviewer權(quán)限) 
其他用戶只能將他們自己從審查者列表中移除.

Review Labels

在項目中配置label My-Name,label My-Name和定義好的范圍分?jǐn)?shù)相關(guān)聯(lián). 同時也關(guān)聯(lián)labelAs-My-Name權(quán)限, 可以允許編輯用戶定義的label. 
Gerrit帶有配置好的Code-Review標(biāo)簽

[access "refs/heads/*"]
    label-Code-Review = -2..+2 group Administrators
    label-Code-Review = -2..+2 group Project Owners
    label-Code-Review = -1..+1 group Registered Users
[label "Code-Review"]
    function = MaxWithBlock
    defaultValue = 0
    copyMinScore = true
    copyAllScoresOnTrivialRebase = true
    value = -2 This shall not be merged
    value = -1 I would prefer this is not merged as is
    value =  0 No score
    value = +1 Looks good to me, but someone else must approve
    value = +2 Looks good to me, approved
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

Submit

允許用戶提交審查通過的提交. 提交審查代碼后會合并到對應(yīng)的分支上.

The label that the reviewer selects determines what can happen next. The +1 and -1 level are just an opinion where as the +2 and -2 levels are allowing or blocking the change. In order for a change to be accepted it must have at least one +2 and no -2 votes. Although these are numeric values, they in no way accumulate; two +1s do not equate to a +2.

Code-Review標(biāo)簽+2是通過,-2是否定, -1~+1只是代表意見并不會影響投票, 審查被通過至少需要一個+2投票并且沒有-2投票. 兩個+1并不會等于+2 
這里寫圖片描述

[access "refs/heads/*"]
    submit = group Administrators
    submit = group Project Owners
  • 1
  • 2
  • 3
  • 1
  • 2
  • 3

View Drafts

允許用戶查看其他人提交的draft changes. 
draft changes作者和添加為審查者都能看見draft changes(盡管沒有賦予View Drafts權(quán)限)

Publish Drafts

允許用戶公開其他人提交的draft changes. 
draft changes作者可以公開draft changes(盡管沒有賦予Publish Drafts權(quán)限)

Delete Drafts

允許用戶刪除其他人提交的draft changes. 
draft changes作者可以刪除draft changes(盡管沒有賦予Delete Drafts權(quán)限)

Edit Topic Name

允許修改change的主題topic 
change owner, branch owners, project owners, and site administrators可以修改主題(盡管沒有賦予Edit Topic Name權(quán)限)

Enforcing site wide access policies

通過賦予一個群組Owner訪問權(quán)限在refs/*命名空間, Gerrit管理員可以委派這個項目的訪問控制權(quán)限給這個群組. 
如果需要沒有一個人能更新或者刪除標(biāo)簽, 連項目owners都沒有權(quán)限. ALLOWDENY規(guī)則并不能達(dá)到這樣的目的, 因為項目owners可以賦予任何他們自己想要的訪問權(quán)限. 覆蓋任何從All-Projects或者其他父項目繼承的權(quán)限是非常有效的方法. 
在父項目中BLOCK權(quán)限, 使得就算是子項目owners也不能設(shè)置block權(quán)限為ALLOW. 盡管這樣, 也應(yīng)該保留owners所有non-blocked權(quán)限.

  • Gerrit管理員能夠集中精力管理site wide策略并且提供有意義的默認(rèn)訪問權(quán)限.
  • 在不違反site wide策略的情況下, 項目owners可以管理他們自己項目的訪問權(quán)限.

‘BLOCK’ access rule

BLOCK規(guī)則是全局范圍的權(quán)限. 子項目不能重載繼承的BLOCK規(guī)則. 從父項目鏈表中搜索BLOCK規(guī)則, 忽略在訪問區(qū)域中的獨(dú)占(Exclusive)標(biāo)志. 
push權(quán)限賦予BLOCK規(guī)則, pushforce push等推送都將被阻塞. force push權(quán)限賦予BLOCK規(guī)則只有force push被阻塞, 但是如果push權(quán)限具有ALLOW規(guī)則的話可以進(jìn)行non-forced提交. 
BLOCK也可以賦予label投票范圍. 下面的配置可以阻塞group X+2-2票,仍然可以投-1 ~ +1的票.

[access "refs/heads/*"]
  label-Code-Review = block -2..+2 group X
  • 1
  • 2
  • 1
  • 2

在這個阻塞規(guī)則min..max范圍的目的是: 阻塞-INFINITE..minmax..INFINITE投票,也意味著-1..+1投票范圍不受阻塞影響.

BLOCK’ and ‘ALLOW’ rules in the same access section

當(dāng)相同訪問區(qū)域同時包含BLOCKALLOW規(guī)則, ALLOW規(guī)則會重載BLOCK規(guī)則.

[access "refs/heads/*"]
  push = block group X
  push = group Y
  • 1
  • 2
  • 3
  • 1
  • 2
  • 3

如果群組X和群組Y都包含了同一個用戶, 這個用戶依然能夠pushrefs/heads/*命名空間. 
在同一個項目的同一個訪問區(qū)域,ALLOW規(guī)則才會重載BLOCK規(guī)則.在同一個項目不同訪問區(qū)域和子項目的同一個訪問區(qū)域, ALLOW規(guī)則不會重載BLOCK規(guī)則.

BLOCK規(guī)則示例

確保沒有人能夠更新或者刪除tag

All-Projects中阻塞Anonymous Users組的push權(quán)限

[access "refs/tags/*"]
  push = block group Anonymous Users
  • 1
  • 2
  • 1
  • 2

由于所有人都是Anonymous Users組成員, 所以可以阻塞所有人. 
可能項目owner需要創(chuàng)建tag權(quán)限

[access "refs/tags/*"]
    push = block group Anonymous Users
    pushTag = group Project Owners
    pushSignedTag = group Project Owners
  • 1
  • 2
  • 3
  • 4
  • 1
  • 2
  • 3
  • 4

某個命名空間只讓一個特殊的群組投票

假設(shè)提交到發(fā)布分支Release-Process需要更為嚴(yán)格的過程, 假設(shè)我們需要確信只有Release Engineers群組可以投票,就算是項目owner權(quán)限也不可以投票. 在All-Projects我們定義下面的規(guī)則.

[access "refs/heads/stable*"]
    label-Release-Process = block -1..+1 group Anonymous Users
    label-Release-Process = -1..+1 group Release Engineers
  • 1
  • 2
  • 3
  • 1
  • 2
  • 3

Global Capabilities

這里寫圖片描述

Access Database

允許用戶通過gsql命令訪問數(shù)據(jù)庫, 以及包含代碼審查信息的分支refs/notes/review

Administrate Server

影響Gerrit中owneradministrator角色. 賦予administrateServer能力能夠賦予任何群組訪問權(quán)限.

Priority

Gerrit中有兩類線程池用來給INTERACTIVE UsersNon-Interactive Users使用,防止搶占線程. 
允許其他用戶使用Non-Interactive Users的保留線程池.

  • 默認(rèn)配置, 用戶默認(rèn)使用INTERACTIVE線程池
  • BATCH, 賦予這個群組的用戶使用獨(dú)立的Non-Interactive線程池
  • INTERACTIVE, 除非用戶賦予了BATCH選項,否則使用INTERACTIVE線程池

Stream Events 允許執(zhí)行Gerrit觸發(fā)的事件流.

獲取All-Projectsrefs/meta/config分支并修改權(quán)限配置

git clone ssh://admin@localhost:29418/All-Projects && scp -p -P 29418 admin@localhost:hooks/commit-msg All-Projects/.git/hooks/

#refs/meta/config 是All-Projects的引用
git fetch origin refs/meta/config:refs/remotes/origin/meta/config
git checkout meta/config
#現(xiàn)在目錄下有g(shù)roups  project.config兩個文件
#groups文件包含project.config中需要的用戶組和對應(yīng)的UUID

#提交修改
git add .
git commit -m "modify config"
git push origin meta/config:meta/config
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

在公司文檔看到大神寫的很不錯的一小段話

code review的目的是團(tuán)隊成員在一起共同學(xué)習(xí),而不是相互”挑錯”.將code review稱為代碼回顧好一些, 如果大家放棄”挑錯”來共同學(xué)習(xí),那么代碼回顧中學(xué)習(xí)什么呢? 
代碼回顧的學(xué)習(xí)重點(diǎn)是團(tuán)隊成員共同識別模式,這里的模式是指程序員編寫代碼的習(xí)慣,包括”好模式”和”反模式”. 像富有表達(dá)力的命名, 單一職責(zé)的方法, 良好的格式縮進(jìn)等,都是”好模式”. 團(tuán)隊成員通過閱讀最近編寫的測試代碼和生產(chǎn)代碼來識別”好模式”和”反模式”.既是團(tuán)隊成員之間相互學(xué)習(xí)的過程, 也是團(tuán)隊整體達(dá)成整潔代碼共識的過程.

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點(diǎn)。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點(diǎn)擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多