최신 문서 워크플로는 소프트웨어 개발 워크플로와 점점 더 얽혀 있습니다. GitHub 또는 Jira에서 문서 문제를 추적하거나 코드 주석 또는 Markdown 파일에 문서를 작성할 수 있습니다. 팀의 개발자는 기술 작성자와 직접 작업하거나 독립적으로 문서를 작성할 수 있습니다. 문서는 종종 코드 리포지토리에 저장되고, 린터를 사용하여 품질을 테스트하고, 정적 사이트에 지속적으로 게시됩니다. 기술 작성자는 최근에 문서와 유사한 코드라는 용어를 만들어냈습니다. 또는 코드로 문서 이러한 유형의 워크플로를 설명합니다.
코드로서의 문서는 자동화에 의해 정의됩니다. 여기에는 친숙한 개발 도구를 사용하여 문서를 작성, 업데이트, 검토 및 승인하는 작업이 포함됩니다.
- 문제 추적기
- 버전 관리 도구
- 일반 텍스트 파일
- 텍스트 및 코드 편집기
- 정적 사이트 생성기
- 지속적인 출판
문서는 관련 코드와 동일한 리포지토리에 저장할 수 있으므로 문서가 코드 자체와 함께 업데이트되도록 하기가 더 쉽습니다.
이 워크플로는 유연하고 다양한 도구 및 방법 조합에 적용할 수 있습니다. 설명을 위해 이 자습서에서는 Jekyll과 같은 Ruby 기반 도구를 사용하여 Rails 앱에 대한 코드로서의 문서 워크플로를 개발합니다. 문서는 GitHub의 앱과 함께 저장되고 GitHub 문제, 레이블, 프로젝트 및 pull 요청 검토를 사용하여 관리됩니다. 이 예는 다른 도구에 적용하고 다른 워크플로에 통합할 수 있는 코드로서의 문서 원칙을 보여줍니다.
전제조건
이 가이드는 개발자를 대상으로 합니다. Git, 코드 편집기 및 Markdown 도구에 익숙해야 합니다. 이 문서에서는 이러한 도구를 사용하여 문서 워크플로를 만드는 방법을 설명합니다.
이 기사와 함께 Netlify에서 호스팅하는 라이브 샘플 사이트와 샘플 GitHub 리포지토리가 있습니다.
이 기사를 따라 하려면 몇 가지 명령을 사용하여 Rails에서 간단한 블로그 애플리케이션을 만드십시오.
gem install rails
rails new blog
cd blog
rails generate scaffold Post title:string body:text
config/routes.rb에서 , 색인 페이지 생성:
Rails.application.routes.draw do
resources :posts
root 'posts#index'
end
마지막으로 데이터베이스 마이그레이션을 실행하고 Rails 서버를 시작하여 모든 것이 제대로 작동하는지 확인합니다.
rails db:migrate
rails s
localhost:3000으로 이동합니다. . 빈 게시물 목록과 새 게시물을 생성할 수 있는 링크가 표시되어야 합니다.
콘텐츠 전략 수립
계획은 소프트웨어와 마찬가지로 문서 워크플로를 개발하는 첫 번째 단계입니다. 문서 계획에는 문서화해야 할 주제와 방법을 결정하는 콘텐츠 전략이 포함되어야 합니다.
콘텐츠 전략 개발을 시작하려면 다음 질문에 답하십시오.
- 당신의 의도된 청중은 누구입니까?
- 개발자입니까, 덜 기술적인 사용자입니까, 아니면 둘 다입니까?
- 그들이 귀하의 코드나 문서에 기여할 수 있습니까?
- 귀하의 회사 내부 또는 외부 또는 둘 다입니까?
- 사용자가 달성하려는 것은 무엇입니까?
- 사용자가 문서를 참조하여 어떤 문제를 해결하려고 합니까?
- 사용자가 문서를 어떻게 참조합니까?
- 간단한 readme로 충분합니까?
- 사용자가 문서에 액세스하려면 특별한 권한이 필요합니까?
예를 들어 API가 포함된 Rails 앱이 있다고 가정해 보겠습니다. 고객의 경우 모든 UI 기능에 대한 공개 사용자 가이드를 개발할 수 있습니다. 사용자 스토리는 "사용자로서 블로그 게시물을 만들고 싶습니다."
일 수 있습니다.개발자를 위한 참조 문서를 만들 수도 있습니다. 개발자 이야기는 "개발자로서 특정 사용자의 모든 블로그 게시물을 검색하고 싶습니다."
일 수 있습니다.Jekyll 또는 WordPress와 같은 정적 사이트 생성기를 사용하여 브랜드화된 사용자 친화적인 환경에서 사용자 문서를 표시할 수 있습니다. 내부 개발자의 경우 간단한 YARD 생성 사이트로 충분할 수 있습니다. 이 자습서에서는 두 가지 예를 모두 보여줍니다.
문서를 현재 워크플로에 통합할 수도 있습니다. 예를 들어 팀에서 2주 스프린트로 코드를 작성하는 경우 동일한 일정으로 문서를 관리하는 것이 좋습니다.
코드 문제와 함께 문서 문제를 추적할 수도 있습니다. 모든 문서 기능 또는 버그에 대한 문제를 만듭니다. 기능은 새 기사 또는 콘텐츠 섹션이고 버그는 오류, 누락, 오타 또는 수정이 필요한 기타 문제입니다.
피드백을 수집하는 것은 콘텐츠 전략의 중요한 부분입니다. 사용자가 모든 문서 페이지에 대한 피드백으로 귀하에게 연락하거나 GitHub를 통해 문서에 기여할 수 있는 방법을 추가하는 것을 고려하십시오. 의견 버튼은 일반적으로 회사 이메일 주소로 연결되는 양식일 뿐입니다. 이 작업에 할당된 사람은 각 피드백 항목을 가져와 검토 및 구현을 위해 Jira 또는 GitHub 문제로 전환할 수 있습니다.
일관된 스타일과 정확한 용어 사용을 위해 회사 스타일 가이드를 만들거나 기존 가이드를 따르세요. 다음은 대부분의 소프트웨어 프로젝트에 사용할 수 있는 문서 스타일 가이드의 몇 가지 예입니다.
- Google 개발자 문서 스타일 가이드
- GitLab 문서 스타일 가이드
- Microsoft 작문 스타일 가이드
다음은 시작하는 데 도움이 되는 콘텐츠 전략에 대한 추가 정보입니다.
- 개발자 포털을 통한 DX 콘텐츠 전략
- 문서 콘텐츠 전략 입문서
문서 사이트 구축
콘텐츠 전략에서 문서가 의도한 청중에게 표시되는 방식을 결정할 수 있습니다. 누구 결정 이 결정을 알리는 데 도움이 될 문서를 작성할 것입니다. 예를 들어 개발자와 기여자가 코드 주석으로 문서를 작성하는 경우 RDoc 또는 YARD를 사용하여 이러한 주석에서 간단한 정적 문서 사이트를 만들 수 있습니다. 사용자 문서가 Markdown 파일로 작성되는 경우 Jekyll과 같은 정적 사이트 생성기가 문서 게시에 더 나은 선택이 될 것입니다. 물론 팀과 프로젝트에 적합한 사이트를 처음부터 만들 수도 있습니다.
이 기사에서는 Jekyll과 YARD를 사용하여 Rails 앱에 대한 두 가지 유형의 문서 사이트를 설명합니다. Jekyll은 Ruby 기반이며 Rails 앱에 잘 통합됩니다.
지킬
Jekyll의 목적은 일반 텍스트를 정적 웹사이트로 변환하는 것입니다. Jekyll은 _site를 생성합니다. 모든 호스팅 서비스에서 게시할 수 있는 정적 사이트 파일이 포함된 폴더입니다. 이 파일을 GitHub에 푸시하면 Netlify와 같은 지속적인 게시 도구를 사용하여 문서를 게시할 수 있습니다.
Jekyll의 가장 간단한 워크플로는 Markdown 파일에 문서를 작성하고 GitHub에 푸시하는 것입니다. Netlify를 사용하는 경우 이러한 변경 사항을 저장소에 병합할 때 Netlify가 자동으로 사이트를 배포합니다. 이 과정은 다음 섹션에 자세히 설명되어 있습니다.
Jekyll 사이트를 만들려면 Rails 앱의 루트 디렉터리(예:/blog)에서 Jekyll과 Bundler를 설치하세요. ):
gem install jekyll bundler
Jekyll 사이트를 만들고 로컬 개발 서버에서 실행하려면 다음 세 가지 명령만 있으면 됩니다.
jekyll new docs
cd docs
bundle exec jekyll serve
이것은 /docs를 생성합니다. 최소한의 Jekyll 사이트를 포함하는 디렉토리(기본값은 Minima라는 블로그 테마입니다). 이것을 사용자 정의 Jekyll 문서 사이트의 기반으로 사용할 수 있습니다. 또는 just-the-docs와 같은 문서 테마를 설치할 수 있습니다. , 사이드바 탐색 및 사이트 검색 기능과 함께 제공됩니다.
이 튜토리얼에서는 just-the-docs를 사용합니다. 주제. 설치하려면 /docs에서 다음을 실행하세요. 디렉토리:
bundle add just-the-docs
minima 제거 더 이상 사용하지 않을 기본 테마이기 때문에 Gemfile에서 테마를 제거합니다. posts을 삭제할 수도 있습니다. 디렉토리.
다음으로 이 테마를 Jekyll의 _config.yml에 추가합니다. 파일. 여기 있는 동안 사이트의 제목과 설명을 맞춤설정할 수도 있습니다.
title: Docs Site
email: your-email@example.com
description: >-
A Jekyll docs site for a Rails app.
baseurl: "" # the subpath of your site, e.g. /blog
url: "" # the base hostname & protocol for your site, e.g. https://example.com
twitter_username: ""
github_username: ""
# Build settings
theme: just-the-docs
서버를 다시 시작하면 대부분 비어 있는 문서 사이트가 표시됩니다.
마크다운 파일을 보관해야 하는 디렉토리를 확인하려면 Jekyll 테마 문서를 확인하세요. just-the-docs의 경우 , 마크다운 파일은 사이트의 기본 경로에 해당하는 루트 디렉터리에 있을 수 있습니다. 작동 방식을 보려면 루트 디렉터리에 새 Markdown 파일을 만듭니다.
---
layout: default
title: Sample Doc
nav_order: 1
---
# Models
{: .no_toc }
## Table of contents
{: .no_toc .text-delta }
1. TOC
{:toc}
---
## Markdown header
Write **Markdown** here!
새 샘플 문서를 보려면 서버를 다시 시작하세요.
이제 /docs에 기본 Jekyll 사이트가 있습니다. Rails 앱 디렉토리에 있는 폴더! Jekyll 테마를 사용자 정의하거나 나만의 테마를 작성하는 데 도움이 필요하면 Jekyll 문서를 참조하세요.
야드
Rdoc 및 YARD와 같은 문서 생성기는 코드 주석에서 개발자 문서를 생성합니다. Rdoc 및 기타 구문을 허용하는 YARD를 사용하여 독립 실행형 문서 사이트를 만들 수 있습니다. 이 예에서는 기존 Jekyll 사이트에 YARD 문서를 추가합니다. Jekyll은 YARD에서 생성한 정적 파일을 /dev와 같은 경로에 게시할 수 있습니다. . YARD를 자체적으로 사용하여 문서 사이트를 만들 수도 있습니다.
Rails는 앱을 생성할 때 몇 가지 기본 코드 주석도 생성합니다.
# app/controllers/posts_controller.rb
class PostsController < ApplicationController
before_action :set_post, only: %i[ show edit update destroy ]
# GET /posts or /posts.json
def index
@posts = Post.all
end
# GET /posts/1 or /posts/1.json
def show
end
# GET /posts/new
def new
@post = Post.new
end
# GET /posts/1/edit
def edit
end
# code omitted
end
YARD가 이러한 주석을 사용하여 문서 사이트를 만드는 방법을 보려면 yard doc를 실행하세요. 또는 yardoc Rails 앱의 루트 디렉토리에서 명령:
yardoc --output-dir docs/dev app/**/*.rb
yardoc 명령이 작동하지 않으면 bundle install yard로 YARD gem을 설치하세요. .
YARD는 출력 파일을 output-dir에 배치합니다. , Jekyll 디렉토리 /docs/dev로 설정됩니다. 위의 명령에서. Jekyll은 이제 기본 경로가 /dev인 YARD의 사이트 파일을 게시할 수 있습니다. .
RDoc 또는 다른 구문을 사용하여 더 복잡한 문서를 만들 수 있지만(YARD 문서 참조) 여기에서는 기존 문서를 그대로 사용합니다.
Jekyll 서버를 시작하고 localhost:4000/dev로 이동합니다. YARD 생성 문서 보기:
현재로서는 메인 Jekyll 사이트에서 이러한 개발자 문서로 이동할 수 있는 방법이 없습니다. Jekyll 사이트에서 개발자 문서로의 링크를 추가하려면 docs/_config.yml에 다음을 추가하세요. :
# Aux links for the upper right navigation
aux_links:
"Developer Documentation":
- "/dev"
이것으로 지킬과 야드에 대한 논의를 마칩니다. 이제 문서 사이트가 설정되었으므로 개발자와 작성자는 Markdown 파일(또는 코드 주석)에 콘텐츠를 작성하고 GitHub에 푸시할 수 있습니다. 다음 섹션에서는 이러한 문서를 지속적으로 배포하는 방법을 설명합니다.
Netlify를 통한 지속적인 게시 및 배포
문서에 대한 변경 사항이 승인되고 저장소에 병합되면 라이브 사이트가 자동으로 업데이트될 수 있으므로 문서 사이트에 지속적인 게시가 편리합니다. 이 튜토리얼에서는 이를 위해 Netlify를 사용하지만 GitHub Pages, GitLab Pages, Firebase와 같은 다른 도구도 사용할 수 있습니다.
지금까지 구축한 사이트는 Netlify:Docs Site에서 호스팅하고 있습니다.
문서 사이트에 Netlify를 설정하려면 먼저 Netlify 계정에 가입하고 Rails 앱이 포함된 GitHub 저장소에 연결하세요.
다음 설정을 사용하십시오.
Repository
github.com/your-username/your-rails-repo
Base directory
docs
Build command
jekyll build
Publish directory
docs/\_site
Builds
Active
Netlify 사이트를 생성할 때 일부 설정을 사용할 수 없는 경우 배포를 클릭합니다. 지금은. 그런 다음 취소하고 배포 설정으로 돌아갈 수 있습니다. . 기본 디렉토리를 docs로 설정 Netlify가 Rails 앱이 아닌 Jekyll 문서 사이트를 배포하도록 합니다.
Netlify가 Jekyll 사이트 배포를 마치면 라이브 사이트로 이동하여 모든 것이 제대로 보이는지 확인하세요.
Netlify를 사용하는 한 가지 이점은 각 pull 요청에서 직접 실시간 미리보기 링크를 제공한다는 것입니다.
그런 다음 pull 요청을 병합하고 사이트의 재배포를 트리거하기 전에 변경 사항이 올바르게 게시되는지 확인할 수 있습니다. 다음 섹션에서는 이 워크플로를 더 자세히 다룹니다.
GitHub에서 편집 워크플로 설정
문서 작성 전략과 이를 게시할 사이트를 통해 문서 작성을 시작하고 이를 소프트웨어 워크플로에 통합할 준비가 되었습니다.
일반적인 편집 워크플로에는 문서 초안 작성, 문서 검토 및 게시가 포함됩니다. 작가는 자신의 작업에 대한 자체 검토를 수행해야 하지만 편집자, 관리자 및 이해 관계자는 종종 최종 검토 프로세스의 일부입니다. 이는 소프트웨어 개발 프로세스와 유사하기 때문에 소프트웨어 개발 도구를 사용하여 프로세스를 보다 효율적으로 만들 수 있습니다.
다음은 GitHub를 사용하는 팀의 편집 워크플로 예입니다.
- [Writer] 문서 기능 요청 또는 버그에 따라 파일을 만들거나 업데이트합니다(GitHub 문제에 언급됨).
- [Writer] GitHub 분기에 변경 사항을 푸시합니다.
- [작가] 풀 리퀘스트를 엽니다.
- [검토자] 변경 사항을 검토합니다.
- [검토자/관리자] 문서 사이트의 새 빌드를 트리거해야 하는 저장소에 변경 사항을 병합합니다.
GitHub는 콘텐츠의 변경 내역을 자동으로 관리하며, 이는 코드로서의 문서 워크플로에서도 핵심입니다. 무엇이 변경되었는지, 누가 변경했는지, 언제 변경되었는지, 왜 또는 어떻게 변경되었는지 확인할 수 있습니다(댓글, 토론 또는 관련 문제에 언급된 경우). 이것은 팀의 모든 구성원이 언제든지 볼 수 있도록 한 곳에 저장됩니다.
이슈 및 라벨
코드에 사용하는 것과 동일한 문제 템플릿을 새 문서에 사용할 수 있습니다. 이를 통해 커뮤니티 구성원은 누락되었을 수 있는 문서를 요청하거나 팀에 오류를 알릴 수 있습니다. 관리자는 문제를 사용하여 개발자나 작성자를 문서 작업에 할당할 수도 있습니다.
문서 문제와 코드 문제를 구별하기 위해 레이블을 사용할 수 있습니다. documentation 추가 문서와 관련이 있음을 나타내는 레이블입니다. docs::feature와 같은 특정 문서 문제에 대한 레이블을 만들 수도 있습니다. 또는 docs::fix .
코드 관련 문제의 경우와 마찬가지로 문제 제목이나 적절한 레이블에 관한 지침을 문제 템플릿에 추가할 수 있습니다.
docs::in progress와 같은 워크플로 레이블 및 docs::in review , 도 유용합니다. 현재 작업 중인 내용을 반영합니다.
문서화 프로세스를 정의할 때 이러한 레이블을 변경할 책임이 있는 사람과 시기를 지정해야 합니다. 예를 들어, 초안을 작성하는 사람은 레이블을 docs::in progress로 변경합니다. 그들이 초안을 쓰기 시작할 때. 검토자가 초안을 받으면 문제 레이블을 docs::in review로 변경해야 합니다. .
워크플로 관리
소규모 팀 및 프로젝트의 경우 GitHub 프로젝트를 사용하면 GitHub에서 직접 편집 콘텐츠를 관리할 수 있는 편리한 방법입니다. Trello와 같은 프로젝트 관리 보드와 유사하지만 열을 문제 및 풀 리퀘스트에 직접 연결할 수 있습니다.
예를 들어, "검토가 포함된 자동화된 칸반" 템플릿을 사용하여 새로운 문제와 끌어오기 요청이 자동으로 게시판에 추가되도록 합니다. 검토자가 검토를 시작하거나 pull 요청을 승인하면 발행 카드가 다음 열로 이동합니다. 이를 통해 활성 문제와 해당 문제가 편집 과정에서 어디에 있는지 추적할 수 있습니다.
문서보다 더 많은 것을 포함하는 대규모 프로젝트의 경우 project-bot를 사용하세요. 자동화 규칙을 설정하는 GitHub 앱. 예를 들어 특정 레이블을 추가하거나 특정 검토자를 지정하면 자동 카드 이동이 트리거됩니다. 또는 Jira와 같은 도구를 사용하여 문서 관리를 더 큰 프로젝트 관리 워크플로에 통합할 수 있습니다.
project-bot 데모는 샘플 앱을 참조하세요. GitHub 프로젝트의 앱.
문서 작성
이 섹션에서는 초안 작성에서 출판에 이르기까지 문서 작성에 대해 자세히 설명합니다.
문서 작성 및 수정
편집 워크플로의 첫 번째 단계는 몇 가지 문서를 작성하는 것입니다. 문서 작성에 대한 팁은 문서 작성에서 문서 작성에 대한 초보자 가이드를 참조하십시오.
예를 들어 Rails 블로그 앱에 대한 기사를 작성하려면 blog-posts.md라는 새 Markdown 파일을 작성하십시오. Jekyll documentation에서 디렉토리:
---
layout: default
title: Blog Posts
nav_order: 1
---
## Creating a Blog Post
...
코드를 작성할 때 구문 형광펜과 코드 린터를 사용하여 작성할 때 구문을 확인하고 있을 것입니다. 코드 편집기에서 문서를 작성하는 경우 작성 시 맞춤법 오류 및 문법 문제를 검사하는 유사한 린터를 사용할 수 있습니다. 마크다운 형식을 확인하는 린터도 있습니다.
예를 들어 VSCode를 사용하면 편집기에서 직접 Markdown 파일을 미리 볼 수 있으며 Markdown 구문의 오류를 확인하는 Markdownlint 린터용 확장자가 있습니다.
VSCode 및 기타 편집기에서 확장 기능이 있는 Vale라는 인기 있는 산문 린터도 있습니다.
코드 편집기에서 Markdown을 작성하는 또 다른 이점은 프로젝트에 대한 문서와 코드를 작성하기 위해 편집기 간에 전환할 필요가 없다는 것입니다. Rails 앱과 동일한 디렉토리에 문서를 저장하면 분할 레이아웃을 사용하여 코드를 보면서 문서를 작성할 수 있습니다.
변경 사항 커밋
VSCode에서 새 문서를 작성하고 철자 오류 및 구문 오류가 있는지 확인했습니다. 다음 단계는 새 분기를 만들고 변경 사항을 Git에 커밋하는 것입니다.
git checkout -b docs/blog-posts
git add docs/blog_posts.md
git commit -m "Create doc: Blog Posts"
git push -u origin docs/blog-posts
이 커밋을 docs/blog-post에 푸시합니다. 원격 GitHub 저장소의 분기
마지막으로 GitHub에서 새 분기와 마스터(또는 기본) 분기 간에 pull 요청을 만듭니다. 이 풀 리퀘스트를 사용하면 프로젝트의 다른 코드와 마찬가지로 변경 사항을 검토하고 승인할 수 있습니다.
문서 검토 및 승인
문서 변경 사항을 저장소에 병합하는 것은 소프트웨어 개발에서만큼이나 위험할 수 있습니다. 고객과 사용자가 의존하는 문서에 대한 변경 사항을 배포하고 있으므로 검토 프로세스가 엄격한지 확인해야 합니다. 개발자, 제품 관리자, 기술 작가 및 편집자를 포함하여 여러 검토자를 참여시키는 것이 좋습니다.
모든 사람이 파일에 적용한 변경 사항을 추적하고 필요한 추가 수정 사항에 대해 논의합니다. GitHub 및 이와 유사한 도구를 사용하면 변경된 내용, 변경한 시기, 변경한 사람 등 파일의 변경 내역을 볼 수 있습니다.
또한 누군가가 코드 기반에 병합하기 전에 마크다운 파일을 자동으로 확인하도록 GitHub 작업을 추가할 수 있습니다. VSCode에서 사용하는 각 린터에 대해 해당 GitHub 작업이 있는 경우 추가합니다.
- 베일 액션
- 마크다운린트 작업
다음 작업은 문서 변경 사항이 적용되기 전에 Markdown 파일에서 다양한 철자 및 구문 오류를 검사합니다.
세부정보를 클릭합니다. 수표가 통과하지 못하는 이유를 확인하려면:
풀 요청 검사에 Vale 및 Markdownlint를 추가하려면 샘플 리포지토리에서 docs.yml 워크플로 파일을 복사하세요.
Vale 작업이 작동하려면 .github/styles/vocab.txt를 만들어야 할 수도 있습니다. 당신의 저장소에 있는 파일. 이것은 회사 이름이나 팀 구성원의 이름과 같이 Vale에서 무시할 단어 목록(한 줄에 하나씩)입니다.
GitHub Pro, Team 또는 Enterprise 계정이 있는 경우 분기 보호 규칙을 생성할 수 있습니다. 이러한 규칙은 상태 확인을 통과하거나 한 명 이상의 팀 구성원의 승인을 얻는 것과 같은 특정 요구 사항이 충족되지 않는 한 사용자가 변경 사항을 병합하는 것을 방지합니다.
Netlify는 검사 목록에서 사이트의 미리보기도 제공하므로 검토자가 전에 모든 것이 잘 보이는지 확인할 수 있습니다. 변경 사항을 병합하고 사이트를 다시 배포합니다.
문서에 대한 변경 사항을 철저히 검토하고 병합하면 Netlify가 사이트를 다시 배포합니다. 라이브 Jekyll 사이트로 이동하여 변경 사항을 확인하세요.
결론
이제 Rails 앱 또는 다른 프로젝트에 대한 GitHub의 기본 문서 워크플로가 있어야 합니다. 코드와 같은 문서를 관리하는 것은 필요한 만큼 간단하거나 복잡할 수 있습니다. 소규모 프로젝트의 경우 GitHub의 약간의 자동화만 있으면 됩니다. 더 큰 프로젝트는 다른 부서 및 팀과 더 밀접하게 통합될 수 있으며 따라서 다른 도구와도 더 밀접하게 통합될 수 있습니다.
Rails 앱용 샘플 GitHub 리포지토리와 이 기사에서 만든 샘플 Jekyll 사이트를 반드시 살펴보세요. 리포지토리에는 샘플 문제와 풀 리퀘스트, 라벨이 포함되어 있습니다. 또한 자동화된 GitHub 프로젝트와 작성자, 검토자 및 유지 관리자가 코드 기반에 문서를 추가할 때 따라야 하는 샘플 풀 요청 템플릿이 있습니다.
더 많은 정보를 원하시면 GitLab의 문서화 과정을 확인하세요. 그들의 문서 가이드라인도 영감을 줄 수 있습니다.