Skip to main content

이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-09-25. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

추가 정보

리포지토리에 추가 정보 파일을 추가하여 프로젝트가 유용한 이유, 프로젝트로 수행할 수 있는 작업 및 프로젝트 사용 방법을 다른 사용자에게 알릴 수 있습니다.

About READMEs

You can add a README file to a repository to communicate important information about your project. A README, along with a repository license, citation file and contribution guidelines, communicates expectations for your project and helps you manage contributions.

For more information about providing guidelines for your project, see "Setting up your project for healthy contributions."

A README is often the first item a visitor will see when visiting your repository. README files typically include information on:

  • What the project does
  • Why the project is useful
  • How users can get started with the project
  • Where users can get help with your project
  • Who maintains and contributes to the project

If you put your README file in your repository's hidden .github, root, or docs directory, GitHub Enterprise Server will recognize and automatically surface your README to repository visitors.

If a repository contains more than one README file, then the file shown is chosen from locations in the following order: the .github directory, then the repository's root directory, and finally the docs directory.

When your README is viewed on GitHub, any content beyond 500 KiB will be truncated.

If you add a README file to the root of a public repository with the same name as your username, that README will automatically appear on your profile page. You can edit your profile README with GitHub Flavored Markdown to create a personalized section on your profile. For more information, see "Managing your profile README."

Auto-generated table of contents for README files

For the rendered view of any Markdown file in a repository, including README files, GitHub Enterprise Server will automatically generate a table of contents based on section headings. You can view the table of contents for a README file by clicking the menu icon at the top left of the rendered page.

Screenshot of the README for a repository. In the upper-left corner, a dropdown menu, labeled with a list icon, is expanded to show a table of contents.

You can link directly to any section that has a heading. To view the automatically generated anchor in a rendered file, hover over the section heading to expose the icon and click the icon to display the anchor in your browser.

Screenshot of a README for a repository. To the left of a section heading, a link icon is outlined in dark orange.

For more detailed information about section links, see "Section links."

You can define relative links and image paths in your rendered files to help readers navigate to other files in your repository.

A relative link is a link that is relative to the current file. For example, if you have a README file in root of your repository, and you have another file in docs/CONTRIBUTING.md, the relative link to CONTRIBUTING.md in your README might look like this:

[Contribution guidelines for this project](docs/CONTRIBUTING.md)

GitHub Enterprise Server will automatically transform your relative link or image path based on whatever branch you're currently on, so that the link or path always works. The path of the link will be relative to the current file. Links starting with / will be relative to the repository root. You can use all relative link operands, such as ./ and ../.

Your link text should be on a single line. The example below will not work.

[Contribution 
guidelines for this project](docs/CONTRIBUTING.md)

Relative links are easier for users who clone your repository. Absolute links may not work in clones of your repository - we recommend using relative links to refer to other files within your repository.

Wikis

A README should contain only the necessary information for developers to get started using and contributing to your project. Longer documentation is best suited for wikis. For more information, see "About wikis."

Further reading