基本用法
新的應用程式或發行版本
使用 rebar3 專案組織程式碼主要有兩種方式：單一應用程式或傘型專案。
單一應用程式專案在目錄的根目錄中包含一個單獨的頂層應用程式，其 Erlang 原始碼模組直接位於 src/ 目錄中。 此格式適用於發佈到 GitHub 或 hex 上的可共享函式庫，也可用於 發行版本，允許發佈可直接啟動應用程式的 Erlang 執行時系統。
傘型專案的定義特徵是它們可以包含多個頂層 Erlang/OTP 應用程式，通常位於頂層 apps/ 或 lib/ 目錄中。 每個應用程式都可能包含自己的 rebar.config 檔案。 此格式僅適用於具有一個或多個頂層應用程式的發行版本。
Rebar3 提供了用於建立任一類型專案的範本，可透過 rebar3 new <template> <project-name> 指令呼叫。 <template> 值可以是以下任何一種：
app：具有監督樹的狀態化 OTP 應用程式，作為單一應用程式專案lib：函式庫 OTP 應用程式（沒有監督樹），適用於將各種模組組合在一起，作為單一應用程式專案release：準備發行的傘型專案umbrella：release的別名escript：一種特殊形式的單一應用程式專案，可以建置為可執行的腳本plugin：rebar3 插件的結構cmake：產生用於建置 C/C++ 程式碼的c_src目錄和Makefile
例如：
$ rebar3 new app myapp
===> Writing myapp/src/myapp_app.erl
===> Writing myapp/src/myapp_sup.erl
===> Writing myapp/src/myapp.app.src
===> Writing myapp/rebar.config
===> Writing myapp/.gitignore
===> Writing myapp/LICENSE
===> Writing myapp/README.md
有關 new 和可用選項的更多資訊，請查看 指令 文件，以及了解如何建立和使用自定義範本，請前往 範本教學。
新增相依性
相依性列在 rebar.config 檔案的 deps 鍵下
{deps, [
{elli, "~> 3.3.0"}, % package
{elli, {git, "git://github.com/elli-lib/elli.git", {tag, "3.3.0"}}} % alternatively, source
]
}.
現在，您可以將相依性新增到專案應用程式的 .app.src 檔案的 applications 區段下，以便 Erlang 知道您的應用程式需要此相依性才能正常運作
{application, <APPNAME>,
[{description, ""},
{vsn, <APPVSN>},
{registered, []},
{modules, []},
{applications, [kernel,
stdlib,
elli]},
{mod, {<APPNAME>_app, []}},
{env, []}
]}.
<APPVSN> 值可以是以下任何一種：
| 版本類型 | 結果 |
|---|---|
string() |
字串按原樣用於版本。範例："0.1.0" |
git | semver |
使用儲存庫上的最新 git 標籤來建構版本。 |
{cmd, string()} |
使用在 shell 中執行 string() 內容的結果。範例，使用檔案 `VERSION`：`{cmd, "cat VERSION | tr -d '[:space:]'"}` |
{git, short | long} |
使用目前提交的簡短（8 個字元）或完整 Git 參考。 |
{file, File} |
使用檔案的內容。例如，使用 `VERSION` 檔案比使用 `cmd` 更好的方法是：`{file, "VERSION"}` |
有關相依性處理的更多資訊，請查看 相依性文件
建置
只需要一個指令 compile 即可擷取相依性並編譯所有應用程式。
$ rebar3 compile
===> Verifying dependencies...
===> Fetching elli v3.3.0
===> Analyzing applications...
===> Compiling elli
===> Analyzing applications...
===> Compiling custom_hex_repos
輸出格式
安裝相依性、建置發行版本和寫入磁碟的任何其他輸出的輸出位於專案根目錄的 _build 目錄中。
_build/
└── default
└── lib
└── elli
有關設定檔和 _build 目錄的更多資訊，請參閱 設定檔文件頁面。
測試
預設情況下，測試應位於 test/ 目錄下，但個別模組中的 eunit 除外。
僅執行測試所需的相依性可以放在 test 設定檔中
{profiles, [
{test, [
{deps, [
{meck, "0.9.0"}
]}
]}
]}.
現在，第一次執行 rebar3 ct 時，meck 將安裝到 _build/test/lib/。但它不會新增到 rebar.lock。
_build/
└── test
└── lib
└── meck
發行版本和目標系統
發行版本使用 relx 建置。
使用發行版本結構和 rebar.config 檔案中的預設 relx 設定建立新專案，請執行
$ rebar3 new release myrel
===> Writing myrel/apps/myrel/src/myrel_app.erl
===> Writing myrel/apps/myrel/src/myrel_sup.erl
===> Writing myrel/apps/myrel/src/myrel.app.src
===> Writing myrel/rebar.config
===> Writing myrel/config/sys.config
===> Writing myrel/config/vm.args
===> Writing myrel/.gitignore
===> Writing myrel/LICENSE
===> Writing myrel/README.md
在 rebar.config 中，我們發現了一些在應用程式範例中沒有的元素。
{relx, [{release, {myrel, "0.0.1"},
[myrel]},
{dev_mode, true},
{include_erts, false},
{extended_start_script, true}
]
}.
{profiles, [
{prod, [{relx, [{dev_mode, false},
{include_erts, true}]}
]}
]}.
此設定提供了一些使用 Relx 建置開發發行版本（預設設定檔）和生產發行版本（prod 設定檔）的良好預設值。 在建置生產發行版本時，我們很可能想要建立目標系統（包含 erts），並且絕對不希望發行版本包含應用程式的符號連結（dev_mode 設為 false）。
$ rebar3 release
===> Verifying default dependencies...
===> Compiling myrel
===> Starting relx build process ...
===> Resolving OTP Applications from directories:
_build/default/lib
/usr/lib/erlang/lib
===> Resolved myrel-0.1.0
===> Dev mode enabled, release will be symlinked
===> release successfully created!
使用預設的 rebar.config，將發行版本的壓縮檔案建立為目標系統就像將設定檔設定為 prod 並執行 tar 一樣簡單
$ rebar3 as prod tar
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling relx_overlays
===> Assembling release myrel-0.1.0...
===> Release successfully assembled: _build/prod/rel/myrel
===> Building release tarball myrel-0.1.0.tar.gz...
===> Tarball successfully created: _build/prod/rel/myrel/myrel-0.1.0.tar.gz
更多詳細資訊，請前往 發行版本章節。