Cartfile

cartfile是描述项目依赖的文件,内容由两部分组成: origin 和 version

origin

GitHub repositories
Git repositories
binary-only frameworks served over https

github  "ReactiveCocoa/ReactiveCocoa" # GitHub.com
git     "https://enterprise.local/desktop/git-error-translations2.git"
binary  "https://my.domain.com/release/MyFramework.json" // Remote Hosted
binary  "file:///some/Path/MyFramework.json" // Locally hosted at file path
binary  "relative/path/MyFramework.json" // Locally hosted at relative path
binary  "/absolute/path/MyFramework.json" // Locally hosted at absolute path

version

# Require version 2.3.1 or later
github "ReactiveCocoa/ReactiveCocoa" >= 2.3.1

# Require version 1.x
github "Mantle/Mantle" ~> 1.0 

# Require exactly version 0.4.1
github "jspahrsummers/libextobjc" == 0.4.1

# Use the latest version
github "jspahrsummers/xcconfigs"

# Use the branch
github "jspahrsummers/xcconfigs" "branch"

# Use a project from GitHub Enterprise
github "https://enterprise.local/ghe/desktop/git-error-translations"

# Use a project from any arbitrary server, on the "development" branch
git "https://enterprise.local/desktop/git-error-translations2.git" "development"

# Use a local project
git "file:///directory/to/project" "branch"

# A binary only framework
binary "https://my.domain.com/release/MyFramework.json" ~> 2.3

# A binary only framework via file: url
binary "file:///some/local/path/MyFramework.json" ~> 2.3

# A binary only framework via local relative path from Current Working Directory to binary project specification
binary "relative/path/MyFramework.json" ~> 2.3

# A binary only framework via absolute path to binary project specification
binary "/absolute/path/MyFramework.json" ~> 2.3

Cartfile.private

非必须依赖的文件需要在cartfile.private里面列出来
Frameworks that want to include dependencies via Carthage, but do not want to force those dependencies on parent projects, can list them in the optional Cartfile.private file, identically to how they would be specified in the main cartfile.

Anything listed in the private Cartfile will not be seen by dependent (parent) projects, which is useful for dependencies that may be important during development, but not when building releases—for example, test frameworks.

Cartfile.resolved

在执行了carthage update命令之后, 会创建一个cartfile.resolved文件. 这个文件精准的指定了所有依赖包括嵌套依赖的版本号.
After running the carthage update command, a file named Cartfile.resolved will be created alongside the Cartfile in the working directory. This file specifies precisely which versions were chosen of each dependency, and lists all dependencies (even nested ones).

这个文件可以确保你能够和当前一样去构建你的项目, 因此强烈建议加入到git仓库中.
The Cartfile.resolved file ensures that any given commit of a Carthage project can be bootstrapped in exactly the same way, every time. For this reason, you are strongly recommended to commit this file to your repository.

不建议人为修改这个文件(o(￣ヘ￣o＃))
Although the Cartfile.resolved file is meant to be human-readable and diffable, you must not modify it. The format of the file is very strict, and the order in which dependencies are listed is important for the build process.

Carthage/Build

Carthage/Build 是在carthage build运行之后产生的文件夹, 里面是二进制的framework文件和debug信息, 你可以上传也可以不上传这部分内容
This folder is created by carthage build in the project’s working directory, and contains the binary frameworks and debug information for each dependency (whether built from scratch or downloaded).

You are not required to commit this folder to your repository, but you may wish to, if you want to guarantee that the built versions of each dependency will always be accessible at a later date.

Carthage/Checkouts

Carthage/Checkouts 文件是由 carthage checkout命令产生的, 里面包含的是非预编译的文件的源码, 是用来后面执行 carthage build命令的文件夹, 这部分内容不建议人为修改,会在后续的carthage checkout命令中被覆写
This folder is created by carthage checkout in the application project’s working directory, and contains your dependencies’ source code (when prebuilt binaries are not available). The project folders inside Carthage/Checkouts are later used for the carthage build command.

You are not required to commit this folder to your repository, but you may wish to, if you want to guarantee that the source checkouts of each dependency will always be accessible at a later date.

Unless you are using submodules, the contents of this directory should not be modified, as they may be overwritten by a future carthage checkout command.

With submodules

If the --use-submodules flag was given when a project’s dependencies were bootstrapped, updated, or checked out, the dependencies inside Carthage/Checkouts will be available as Git submodules. This allows you to make changes in the dependencies, and commit and push those changes upstream.

~/Library/Caches/org.carthage.CarthageKit

缓存目录, 用来干净的prebuild 和分享防止污染其他文件夹
This folder is created automatically by Carthage, and contains the “bare” Git repositories used for fetching and checking out dependencies, as well as prebuilt binaries that have been downloaded. Keeping all repositories in this centralized location avoids polluting individual projects with Git metadata, and allows Carthage to share one copy of each repository across all projects.

If you need to reclaim disk space, you can safely delete this folder, or any of the individual folders inside. The folder will be automatically repopulated the next time carthage checkout is run.

Binary Project Specification

For dependencies that do not have source code available, a binary project specification can be used to list the locations and versions of compiled frameworks. This data must be available via https and could be served from a static file or dynamically.

The JSON specification file name should have the same name as the framework and not be named Carthage.json, (example: MyFramework.json).
The JSON structure is a top-level dictionary with the key-value pairs of version / location.
The version must be a semantic version. Git branches, tags and commits are not valid.
The location must be an https url.

"1.0": "https://my.domain.com/release/1.0.0/framework.zip",
"1.0.1": "https://my.domain.com/release/1.0.1/framework.zip"

carthage文件与配置