The build.properties file is a key-value flat file where you store information like your username, password, and Salesforce instance URL. Note that because this file contains your password, you should ensure that it's never committed to source control. Here's an example of a build.properties file:

# build.properties
build.dir=/Users/codefriar/src/AmazingPandas/

#sf target credentials
[email protected]
sftarget.password=SuperS3kr3tP@ssw0rd+0k3n
sftarget.serverurl=https://login.salesforce.com
sftarget.runAllTests=false

#sf source credentials
sfsource.username= [email protected]
sfsource.password=Like1'dPubl1$hThat
sfsource.serverurl=https://test.salesforce.com

#local properties
source.dir=${build.dir}/src
source.metadata=${build.dir}/package.xml

#Git branch to pull From (default is master)
git.branch=master

Conceptually, this file is much simpler! Each of these lines specifies a key (for instance, build.dir), and its corresponding value after the = sign. Note, however, that there are two sets of Salesforce credentials—a target set and a source set. The target set specifies the credentials used for deployments. The source set specifies where metadata and code are retrieved from. With a dual setup like this, you can easily update the metadata on your computer from the source org and then deploy to your production org. Note, however, that you're not limited to two properties. You can just as easily specify sfIntegrationOrg, mySandboxOrg, StevesSandboxOrg, and JensSandboxOrg. This would allow you or your CI system to pull and push metadata, code, and other information between all of the orgs your team is developing in, as well as the integration or testing org, and finally, production. You can set as many variables as you'd like here. Each will be included as ${variable.name} within your build.xml file.