We recently [made it easy][init-post] to initialize a repository when you create

it [via the API][repo-create]. One of the options you can pass when creating a

repository is `gitignore_template`. This value is the name of one of the

templates from thethepublic [GitHub .gitignore repository][templates-repo].

templates from the public [GitHub .gitignore repository][templates-repo].

The [Gitignore Templates API][new-api] makes it easy to list those templates:

Now that the GitHub API is[serving the v3 media type by default][v3-default], we are deprecating the legacy[beta media type][beta].

We will eventually remove support for the beta media type, but we have no official retirement date toannouce at the moment. When the time comes, rest assured that we'll announce the retirement with plenty of notice. In the meantime, existing API clients that rely on the beta media type should start making plans to migrate to v3. The beta media type differs from v3 in[just a few places][differences]. In most cases, migrating an application from the beta media type to the v3 media type is smooth and painless.

We will eventually remove support for the beta media type, but we have no official retirement date toannounce at the moment. When the time comes, rest assured that we'll announce the retirement with plenty of notice. In the meantime, existing API clients that rely on the beta media type should start making plans to migrate to v3. The beta media type differs from v3 in[just a few places][differences]. In most cases, migrating an application from the beta media type to the v3 media type is smooth and painless.

As always, if you have any questions, please[get in touch][contact].

author_name:atmos

On November 4th, 2014, we will begin sending a new format for[deployment][1] and[deployment status][2] payloads for webhooks. In the meantime we'll be running in acompatability mode that will give integrators the time needed to start taking advantage of the new format. Integrators who are working with webhooks and deployments are advised to upgrade to the new payload format to avoid service interruption.

On November 4th, 2014, we will begin sending a new format for[deployment][1] and[deployment status][2] payloads for webhooks. In the meantime we'll be running in acompatibility mode that will give integrators the time needed to start taking advantage of the new format. Integrators who are working with webhooks and deployments are advised to upgrade to the new payload format to avoid service interruption.

This change brings the payloads for these events more inline with the responses you'd receive from the API. Instead of having deployment and deployment status attributes as top-level keys, we will now nest them under`deployment` and`deployment_status` keys. Since we're still in the[preview period][3] for the deployments API we felt it was best to correct this inconsistency now.

Beginning Monday, November 3rd, we will trim existing data sets that exceed this limit, deleting the oldest

records first. Attempts to create statuses beyond that limit will result in a[validation error].

If you have any feedback or questions, please don'thesistate to[contact] us.

If you have any feedback or questions, please don'thesitate to[contact] us.

[statuses]:/v3/repos/statuses/

[validation error]:https://developer.github.com/v3/#client-errors

Since OAuth access tokens function like passwords, they should be treated with

care. Today we are making it easier to more securely work with authorizations

via the Authorizations API. We are deprecating the useuseof the`token`

via the Authorizations API. We are deprecating the use of the`token`

attribute in the majority of the[Authorizations API](/v3/oauth_authorizations/)

responses. For the[affected APIs][authorizations-token-deprecation-notice], the

`token` attribute will soon return an empty string. To get ready for that

[OAuth applications listing on GitHub][app-listing].

*[Get-or-create an authorization for a specific app and fingerprint][get-or-create-for-app-fingerprint]

is a new API that isanalagous to the

is a new API that isanalogous to the

[Get-or-create an authorization for a specific app][get-or-create-for-app]

API, but adds support for the new`fingerprint` request parameter.

Now, license information will also be included inreponses from endpoints that list multiple repositories, such as[List organization repositories](/v3/repos/#list-organization-repositories):

Now, license information will also be included inresponses from endpoints that list multiple repositories, such as[List organization repositories](/v3/repos/#list-organization-repositories):

and a`description`. Although these values are optional, it's helpful to use

for logging and representing information.

When a new deployment is created, a completely separate event istrigged. That's

When a new deployment is created, a completely separate event istriggered. That's

why we have a new`switch` case in the event handler for`deployment`. You can

use this information to be notified when a deployment has been triggered.

If we wanted to get fancy, we could also grab the previous and next pages, in

order to generate links for back (`<<`) andfoward (`>>`) elements:

order to generate links for back (`<<`) andforward (`>>`) elements:

prev_page_href= client.last_response.rels[:prev]? client.last_response.rels[:prev].href :"(none)"

If you need the full contents of the file, you can make a`GET` request to the URL specified by`raw_url`. Be aware that for files larger than ten megabytes, you'll need to clone the gist via the URL provided by`git_pull_url`.

In addition to a specific file's contents being truncated, the entire files list may betrucated if the total number exceeds 300 files. If the top level`truncated` key is`true`, only the first 300 files have been returned in the files list. If you need to fetch all of the gist's files, you'll need to clone the gist via the URL provided by`git_pull_url`.

In addition to a specific file's contents being truncated, the entire files list may betruncated if the total number exceeds 300 files. If the top level`truncated` key is`true`, only the first 300 files have been returned in the files list. If you need to fetch all of the gist's files, you'll need to clone the gist via the URL provided by`git_pull_url`.

Name | Type | Description

-----|------|--------------

`verified`|`boolean` | Does GitHub consider the signature in this commit to be verified?

`reason`|`string` | The reason for`verified` value. Possible values and their meanings are enumerated in the tablebellow.

`reason`|`string` | The reason for`verified` value. Possible values and their meanings are enumerated in the tablebelow.

`signature`|`string` | The signature that was extracted from the commit.

`payload`|`string` | The value that was signed.

Name | Type | Description

-----|------|--------------

`verified`|`boolean` | Does GitHub consider the signature in this tag to be verified?

`reason`|`string` | The reason for`verified` value. Possible values and their meanings are enumerated in the tablebellow.

`reason`|`string` | The reason for`verified` value. Possible values and their meanings are enumerated in the tablebelow.

`signature`|`string` | The signature that was extracted from the tag.

`payload`|`string` | The value that was signed.

*`use_lfs` - describes whether the import has been opted in or out of using Git LFS. The value can be`opt_in`,`opt_out`, or`undecided` if no action has been taken.

*`has_large_files` - the boolean value describing whether files larger than 100MB were found during the`importing` step.

*`large_files_size` - the total size in gigabytes of files larger than 100MB found in the originating repository.

*`large_files_count` - the total number ofoffiles larger than 100MB found in the originating repository. To see a list of these files, make a "Get Large Files" request.

*`large_files_count` - the total number of files larger than 100MB found in the originating repository. To see a list of these files, make a "Get Large Files" request.

Name | Type | Description

-----|------|--------------

`verified`|`boolean` | Does GitHub consider the signature in this commit to be verified?

`reason`|`string` | The reason for`verified` value. Possible values and their meanings are enumerated in the tablebellow.

`reason`|`string` | The reason for`verified` value. Possible values and their meanings are enumerated in the tablebelow.

`signature`|`string` | The signature that was extracted from the commit.

`payload`|`string` | The value that was signed.

hooks for a repository. Webhooks can be managed using the JSON HTTP API,

or the[PubSubHubbub API](#pubsubhubbub).

If you would like to set up a single webhook to receive events from all of your organization'srespositories, check out our[API documentation for Organization Webhooks][org-hooks].

If you would like to set up a single webhook to receive events from all of your organization'srepositories, check out our[API documentation for Organization Webhooks][org-hooks].