Ruby on Rails에 기여하기

이 가이드는 Ruby on Rails의 지속적인 개발에 참여하는 방법을 다룹니다.

이 가이드를 읽고 나면 다음을 알 수 있습니다:

• GitHub를 사용하여 문제를 보고하는 방법.
• main을 복제하고 테스트 스위트를 실행하는 방법.
• 기존 문제를 해결하는 데 도움을 주는 방법.
• Ruby on Rails 문서에 기여하는 방법.
• Ruby on Rails 코드에 기여하는 방법.

Ruby on Rails는 “누군가 다른 사람의 프레임워크"가 아닙니다. 수년에 걸쳐 수천 명의 사람들이 Ruby on Rails에 기여했습니다. 이는 단일 문자에서부터 중요한 아키텍처 변경 또는 중요한 문서화에 이르기까지 다양합니다. 이는 모두 Ruby on Rails를 더 나은 것으로 만들기 위한 것입니다. 아직 코드나 문서를 작성할 준비가 되지 않았더라도 문제 보고와 같은 다양한 방법으로 기여할 수 있습니다.

Rails’ README에 언급된 바와 같이 Rails 및 하위 프로젝트의 코드베이스, 문제 추적기, 채팅 룸, 토론 게시판 및 메일링 리스트에서 상호 작용하는 모든 사람은 Rails 행동 강령을 따르는 것이 예상됩니다.

Ruby on Rails는 GitHub 문제 추적을 사용하여 문제(주로 버그 및 새 코드 기여)를 추적합니다. Ruby on Rails에서 버그를 발견한 경우 여기가 시작할 곳입니다. GitHub 계정(무료)을 만들어야 문제를 제출하고, 문제에 댓글을 달거나 풀 요청을 만들 수 있습니다.

참고: 최신 릴리스된 Ruby on Rails 버전의 버그가 가장 많은 관심을 받을 것입니다. 또한 Rails 코어 팀은 항상 엣지 Rails(현재 개발 중인 Rails 버전의 코드)를 테스트할 시간을 내는 사람들의 피드백에 관심이 있습니다. 이 가이드의 후반부에서 엣지 Rails를 테스트하는 방법을 알아볼 수 있습니다. 지원되는 버전에 대한 정보는 유지 관리 정책을 참조하십시오. 보안 문제는 절대 GitHub 문제 추적기에 보고하지 마십시오.

Ruby on Rails에서 보안 위험이 아닌 문제를 발견한 경우 GitHub의 문제를 검색하여 이미 보고되었는지 확인하십시오. 해당 문제를 다루는 공개 GitHub 문제를 찾을 수 없는 경우 새 문제 열기가 다음 단계입니다. (보안 문제 보고에 대해서는 다음 섹션을 참조하십시오.)

우리는 문제를 만들 때 필요한 모든 정보를 포함할 수 있도록 문제 템플릿을 제공했습니다. 각 문제에는 제목과 문제에 대한 명확한 설명이 포함되어야 합니다. 재현할 수 있는 코드 샘플이나 실패한 테스트와 같은 관련 정보를 최대한 많이 포함하십시오. 목표는 자신과 다른 사람이 버그를 쉽게 재현하고 수정할 수 있도록 하는 것입니다.

문제를 열면 즉시 활동이 있지 않을 수 있습니다. 이는 "세상이 끝나는 중요한 버그"가 아니라는 뜻이 아닙니다. 단지 처리해야 할 많은 문제와 풀 요청이 있다는 뜻일 뿐입니다. 동일한 문제가 있는 다른 사람들이 문제를 찾아 버그를 확인하고 수정하는 데 협력할 수 있습니다. 버그를 수정할 수 있는 경우 풀 요청을 열면 됩니다.

문제를 재현할 수 있는 방법이 있으면 사람들이 문제를 확인, 조사 및 최종적으로 수정할 수 있습니다. 실행 가능한 테스트 케이스를 제공하여 이 프로세스를 더 쉽게 만들 수 있습니다. 이 프로세스를 더 쉽게 만들기 위해 다음과 같은 버그 보고 템플릿을 준비했습니다:

• Active Record(모델, 데이터베이스) 문제에 대한 템플릿: 링크
• Active Record(마이그레이션) 문제 테스트를 위한 템플릿: 링크
• Action Pack(컨트롤러, 라우팅) 문제에 대한 템플릿: 링크
• Action View(뷰, 헬퍼) 문제에 대한 템플릿: 링크
• Active Job 문제에 대한 템플릿: 링크
• Active Storage 문제에 대한 템플릿: 링크
• Action Mailer 문제에 대한 템플릿: 링크
• Action Mailbox 문제에 대한 템플릿: 링크
• 기타 문제에 대한 일반 템플릿: 링크

이러한 템플릿에는 테스트 케이스를 설정하는 데 필요한 보일러플레이트 코드가 포함되어 있습니다. 적절한 템플릿의 내용을 .rb 파일에 복사하고 필요한 변경 사항을 수행하여 문제를 보여줍니다. 터미널에서 ruby the_file.rb를 실행하여 실행할 수 있습니다. 모든 것이 잘 되면 테스트 케이스가 실패하는 것을 볼 수 있습니다.

그런 다음 실행 가능한 테스트 케이스를 gist로 공유하거나 문제 설명에 내용을 붙여넣을 수 있습니다.

경고: 공개 GitHub 문제 보고서를 통해 보안 취약점을 보고하지 마십시오. Rails 보안 정책 페이지에 보안 문제에 대한 절차가 자세히 설명되어 있습니다.

GitHub 문제에 "기능 요청” 항목을 넣지 마십시오. Ruby on Rails에 새 기능을 추가하고 싶다면 직접 코드를 작성하거나 다른 사람과 협력하여 코드를 작성해야 합니다. 이 가이드의 후반부에서 Ruby on Rails에 패치를 제안하는 방법에 대한 자세한 지침을 찾을 수 있습니다. 코드 없이 위시리스트 항목을 GitHub 문제에 입력하면 검토되자마자 “무효"로 표시될 것입니다.

때때로 ‘버그'와 '기능'의 경계는 명확하지 않습니다. 일반적으로 기능은 새로운 동작을 추가하는 것이고, 버그는 잘못된 동작을 유발하는 것입니다. 때로는 코어 팀이 판단을 내려야 합니다. 그렇지만 일반적으로 구분은 패치가 릴리스되는 시기를 결정합니다. 우리는 기능 제출을 사랑합니다! 그러나 유지 관리 브랜치에는 백포트되지 않습니다.

기능에 대한 아이디어에 대한 피드백을 받고 싶다면 rails-core 토론 게시판에서 토론을 시작하십시오. 응답이 없을 수 있는데, 이는 모두가 무관심하다는 뜻입니다. 그 기능을 구축하는 데 관심이 있는 사람을 찾을 수도 있습니다. "이것은 받아들여지지 않을 것입니다"라는 답변을 받을 수도 있습니다. 그러나 새로운 아이디어를 논의하는 적절한 장소입니다. GitHub 문제는 새 기능이 필요로 하는 때로는 긴 토론을 하기에 적절하지 않습니다.

문제 보고 외에도 기존 문제를 해결하는 데 도움을 줄 수 있습니다. 피드백을 제공하면 Rails 코어 개발에 익숙해질 수 있습니다.

GitHub 문제 목록을 확인하면 관심을 기다리는 많은 문제가 있습니다. 이에 대해 어떤 일을 할 수 있습니까? 꽤 많은 일을 할 수 있습니다:

우선 버그 보고서를 확인하는 것이 도움이 됩니다. 컴퓨터에서 보고된 문제를 재현할 수 있습니까? 그렇다면 동일한 문제를 겪고 있다고 문제에 댓글을 달 수 있습니다.

문제가 매우 모호한 경우 더 구체적으로 좁힐 수 있습니까? 재현하기 위한 추가 정보를 제공하거나 문제를 보여내는 데 필요하지 않은 단계를 제거할 수 있습니다.

테스트 없는 버그 보고서를 찾은 경우 실패하는 테스트를 기여하는 것이 매우 유용합니다. 이것도 소스 코드를 탐색하는 좋은 방법입니다. 기존 테스트 파일을 보면 더 많은 테스트를 작성하는 방법을 배울 수 있습니다. 새 테스트는 이후 설명된 대로 패치 형태로 기여하는 것이 가장 좋습니다.

버그 보고서를 더 간단하고 재현하기 쉽게 만드는 것은 버그를 수정하려는 사람들에게 도움이 됩니다. 직접 코드를 작성하든 아니든 상관없습니다.

GitHub에 제출된 Ruby on Rails 풀 요청을 검토하여 도움을 줄 수도 있습니다. 누군가의 변경 사항을 적용하려면 먼저 전용 브랜치를 만드십시오:

$ git checkout -b testing_branch

그런 다음 해당 원격 브랜치를 사용하여 코드베이스를 업데이트할 수 있습니다. 예를 들어 GitHub 사용자 JohnSmith가 "orange” 토픽 브랜치에 포크하고 푸시했다고 가정해 보겠습니다: https://github.com/JohnSmith/rails.

$ git remote add JohnSmith https://github.com/JohnSmith/rails.git
$ git pull JohnSmith orange

원격에 연결하는 대신 [GitHub CLI 도계속해서 Ruby on Rails에 기여하는 방법을 설명하겠습니다.

Ruby on Rails에는 두 가지 주요 문서 세트가 있습니다. 사용자가 Ruby on Rails를 배우는 데 도움이 되는 가이드와 참조 역할을 하는 API입니다.

Rails 가이드 또는 API 참조를 더 일관되고 일관성 있게 만들거나 가독성을 높이고, 누락된 정보를 추가하고, 사실적 오류를 수정하거나 최신 엣지 Rails와 일치시킴으로써 이를 개선할 수 있습니다.

이를 위해 Rails 가이드 소스 파일(GitHub의 여기에 있음)이나 소스 코드의 RDoc 주석을 수정하십시오. 그런 다음 메인 브랜치에 적용할 풀 요청을 엽니다.

[ci skip]을 풀 요청 제목에 사용하여 문서 변경에 대한 CI 빌드를 건너뛰십시오.

풀 요청을 열면 문서의 미리보기가 배포되어 쉽게 검토하고 협업할 수 있습니다. 풀 요청 페이지 하단에 상태 확인 목록이 있는데, buildkite/docs-preview를 찾아 “details"를 클릭하십시오.

이렇게 하면 Buildkite 빌드 페이지로 이동합니다. 작업이 성공적이면 작업 목록 위에 API 및 가이드에 대한 링크가 있는 주석이 표시됩니다.

문서 작업 시 API 문서 지침 및 Ruby on Rails 가이드 지침을 고려하십시오.

Rails 가이드를 번역하는 자원봉사자를 환영합니다. 다음 단계를 따르십시오:

• https://github.com/rails/rails를 포크하십시오.
• 언어에 대한 소스 폴더를 추가하십시오. 예: guides/source/it-IT은 이탈리아어입니다.
• guides/source의 내용을 언어 디렉토리에 복사하고 번역하십시오.
• HTML 파일은 자동으로 생성되므로 번역하지 마십시오.

번역은 위에 설명된 대로 귀하의 포크에 제출되지 않습니다. 이는 실제로 패치를 통한 문서 유지 관리가 영어에서만 지속 가능하기 때문입니다.

가이드를 HTML 형식으로 생성하려면 가이드 종속성을 설치하고, guides 디렉토리로 이동한 다음 (예: it-IT의 경우) 다음을 실행해야 합니다:

# 가이드에 필요한 gem만 설치합니다. 실행 취소하려면: bundle config --delete without
$ bundle install --without job cable storage test db
$ cd guides/
$ bundle exec rake guides:generate:html GUIDES_LANGUAGE=it-IT

이렇게 하면 output 디렉토리에 가이드가 생성됩니다.

참고: Redcarpet Gem은 JRuby에서 작동하지 않습니다.

기존 문제를 해결하거나 자신의 코드를 Ruby on Rails에 기여하려면 테스트 스위트를 실행할 수 있어야 합니다. 이 가이드의 이 섹션에서는 컴퓨터에서 테스트를 실행하는 방법을 배웁니다.

조직에 Codespaces가 활성화된 경우 해당 조직에 Rails를 포크하고 GitHub Codespaces를 사용할 수 있습니다. Codespace는 필요한 모든 종속성으로 초기화되며 모든 테스트를 실행할 수 있습니다.

Visual Studio Code와 Docker가 설치된 경우 VS Code 원격 컨테이너 플러그인을 사용할 수 있습니다. 플러그인은 리포지토리의 .devcontainer 구성을 읽고 로컬에서 Docker 컨테이너를 빌드합니다.

또는 Docker와 npm이 설치된 경우 Dev Container CLI를 실행하여 명령줄에서 .devcontainer 구성을 활용할 수 있습니다.

$ npm install -g @devcontainers/cli
$ cd rails
$ devcontainer up --workspace-folder .
$ devcontainer exec --workspace-folder . bash

rails-dev-box를 사용하여 개발 환경을 준비할 수도 있습니다. 그러나 rails-dev-box는 Vagrant와 Virtual Box를 사용하므로 Apple 실리콘이 있는 Mac에서는 작동하지 않습니다.

GitHub Codespaces를 사용할 수 없는 경우 이 다른 가이드를 참조하여 로컬 개발을 설정하는 방법을 확인하십시오. 이는 OS 종속적일 수 있는 종속성 설치로 인해 어려운 것으로 간주됩니다.

코드에 기여하려면 Rails 리포지토리를 복제해야 합니다:

$ git clone https://github.com/rails/rails.git

그리고 전용 브랜치를 만드십시오:

$ cd rails
$ git checkout -b my_new_branch

이름은 크게 중요하지 않습니다. 이 브랜치는 로컬 컴퓨터와 GitHub의 개인 리포지토리에만 존재할 것이기 때문입니다. Rails Git 리포지토리의 일부가 되지 않습니다.

필요한 gem을 설치합니다.

$ bundle install

변경 사항을 테스트할 더미 Rails 앱이 필요한 경우 rails new의 --dev 플래그는 로컬 브랜치를 사용하는 애플리케이션을 생성합니다:

$ cd rails
$ bundle exec rails new ~/my-test-app --dev

~/my-test-app에 생성된 애플리케이션은 로컬 브랜치를 사용하며 특히 서버 재시작 시 모든 수정 사항을 볼 수 있습니다.

JavaScript 패키지의 경우 yarn link를 사용하여 생성된 애플리케이션에서 로컬 브랜치를 소싱할 수 있습니다:

$ cd rails/activestorage
$ yarn link
$ cd ~/my-test-app
$ yarn link "@rails/activestorage"

이제 코드를 작성할 시간입니다! Rails에 대한 변경 사항을 만들 때는 다음 사항을 염두에 두십시오:

• Rails 스타일 및 규칙을 따르십시오.
• Rails 관용구와 헬퍼를 사용하십시오.
• 코드 없이는 실패하고 코드와 함께 통과하는 테스트를 포함하십시오.
• 영향을 받는 문서, 다른 예제 및 가이드를 업데이트하십시오.
• 기능을 추가, 제거 또는 변경하는 경우 CHANGELOG 항목을 포함하십시오. 버그 수정인 경우 CHANGELOG 항목이 필요하지 않습니다.

팁: 안정성, 기능 또는 테스트 가능성에 실질적으로 기여하지 않는 미관상의 변경은 일반적으로 허용되지 않습니다(이 결정의 근거에 대해 자세히 알아보십시오).

Rails는 간단한 코딩 스타일 규칙을 따릅니다:

• 들여쓰기에 공백 2개, 탭 없음.
• 끝에 공백 없음. 빈 줄에는 공백이 없어야 합니다.
• private/protected 후 들여쓰기 및 빈 줄 없음.
• 해시에 Ruby >= 1.9 구문 사용. { a: :b }를 선호하고 { :a => :b }는 피하십시오.
• &&/||를 and/or보다 선호하십시오.
• 클래스 메서드의 경우 self.method보다 class << self 사용.
• my_method(my_arg)를 사용하고 my_method( my_arg )나 my_method my_arg는 피하십시오.
• a = b를 사용하고 a=b는 피하십시오.
• assert_not 메서드를 refute보다 선호하십시오.
• 단일 줄 블록의 경우 method { do_stuff }를 method{do_stuff}보다 선호하십시오.
• 이미 사용된 소스의 규칙을 따르십시오.

위의 내용은 지침일 뿐입니다. 최선의 판단을 사용하십시오.

또한 일부 코딩 규칙을 정의하는 RuboCop 규칙이 있습니다. 풀 요청을 제출하기 전에 수정한 파일에 대해 RuboCop을 로컬로 실행할 수 있습니다:

$ bundle exec rubocop actionpack/lib/action_controller/metal/strong_parameters.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

성능에 영향을 미칠 수 있는 변경의 경우 코드를 벤치마크하고 영향을 측정하십시오. 사용한 벤치마크 스크립트와 결과를 공유하십시오. 커밋 메시지에 이 정보를 포함하는 것이 좋습니다. 이를 통해 향후 기여자가 쉽게 결과를 확인하고 여전히 관련이 있는지 확인할 수 있습니다. (예를 들어 Ruby VM의 향후 최적화로 인해 특정 최적화가 더 이상 필요하지 않을 수 있습니다.)

특정 시나리오를 최적화할 때 다른 일반적인 경우에 대한 성능이 저하될 수 있습니다. 따라서 실제 프로덕션 애플리케이션에서 추출한 대표적인 시나리오 목록에 대해 테스트해야 합니다.

벤치마크 템플릿을 시작점으로 사용할 수 있습니다. 이 템플릿에는 benchmark-ips gem을 사용하여 벤치마크를 설정하는 데 필요한 보일러플레이트 코드가 포함되어 있습니다. 템플릿은 스크립트에 인라인될 수 있는 비교적 자체 포함된 변경 사항을 테스트하도록 설계되었습니다.

Rails에서는 변경 사항을 푸시하기 전에 전체 테스트 스위트를 실행하는 것이 관례가 아닙니다. 특히 railties 테스트 스위트는 시간이 오래 걸리며 /vagrant에 마운트된 소스 코드가 있는 rails-dev-box에서 특히계속해서 Rails 코드에 기여하는 방법을 설명하겠습니다.

모든 테스트를 실행하려면 다음을 수행하십시오:

$ cd rails
$ bundle exec rake test

특정 구성 요소(예: Action Pack)의 테스트만 실행할 수 있습니다. 예를 들어 Action Mailer 테스트를 실행하려면:

$ cd actionmailer
$ bin/test

특정 구성 요소의 특정 디렉토리(예: Active Storage의 모델)의 테스트만 실행할 수 있습니다. 예를 들어 /activestorage/test/models의 테스트를 실행하려면:

$ cd activestorage
$ bin/test models

특정 파일의 테스트를 실행할 수 있습니다:

$ cd actionview
$ bin/test test/template/form_helper_test.rb

-n 옵션을 사용하여 테스트 이름으로 단일 테스트를 실행할 수 있습니다:

$ cd railties
$ bin/test test/application/asset_debugging_test.rb -n test_explicit_class_layout

테스트 실행은 무작위 시드로 실행됩니다. 무작위 테스트 실패를 경험하는 경우 특정 시드를 설정하여 실패하는 테스트 시나리오를 더 정확하게 재현할 수 있습니다.

구성 요소의 모든 테스트 실행:

$ cd actionmailer
$ SEED=15002 bin/test

단일 테스트 파일 실행:

$ cd actionmailer
$ SEED=15002 bin/test test/mail_layout_test.rb

Action Pack 및 Action View 단위 테스트는 기본적으로 병렬로 실행됩니다. 무작위 테스트 실패를 경험하는 경우 시드를 설정하고 PARALLEL_WORKERS=1을 설정하여 이러한 단위 테스트를 직렬로 실행할 수 있습니다.

$ cd actionview
$ PARALLEL_WORKERS=1 SEED=53708 bin/test test/template/test_case_test.rb

먼저 필요한 데이터베이스를 만드십시오. 필요한 테이블 이름, 사용자 이름 및 비밀번호 목록은 activerecord/test/config.example.yml에서 찾을 수 있습니다.

MySQL과 PostgreSQL의 경우 다음을 실행하면 충분합니다:

$ cd activerecord
$ bundle exec rake db:mysql:build

또는:

$ cd activerecord
$ bundle exec rake db:postgresql:build

SQLite3의 경우 이 작업이 필요하지 않습니다.

SQLite3에 대한 Active Record 테스트 스위트를 실행하는 방법은 다음과 같습니다:

$ cd activerecord
$ bundle exec rake test:sqlite3

이제 sqlite3에 대한 테스트를 실행할 수 있습니다. 작업은 각각 다음과 같습니다:

$ bundle exec rake test:mysql2
$ bundle exec rake test:trilogy
$ bundle exec rake test:postgresql

마지막으로,

$ bundle exec rake test

이 세 가지를 차례로 실행합니다.

또한 개별 테스트를 별도로 실행할 수 있습니다:

$ ARCONN=mysql2 bundle exec ruby -Itest test/cases/associations/has_many_associations_test.rb

모든 어댑터에 대해 단일 테스트를 실행하려면 다음을 사용하십시오:

$ bundle exec rake TEST=test/cases/associations/has_many_associations_test.rb

test_jdbcmysql, test_jdbcsqlite3 또는 test_jdbcpostgresql을 호출할 수도 있습니다. Active Record 테스트 실행에 대한 자세한 내용은 activerecord/RUNNING_UNIT_TESTS.rdoc 파일을 참조하십시오.

외부 디버거(pry, byebug 등)를 사용하려면 디버거를 설치하고 일반적으로 사용하십시오. 디버거 문제가 발생하는 경우 PARALLEL_WORKERS=1을 설정하여 직렬로 테스트를 실행하거나 -n test_long_test_name으로 단일 테스트를 실행하십시오.

생성기에 대한 테스트를 실행하는 경우 디버깅 도구가 작동하려면 RAILS_LOG_TO_STDOUT=true를 설정해야 합니다.

RAILS_LOG_TO_STDOUT=true ./bin/test test/generators/actions_test.rb

테스트 스위트는 경고를 활성화하여 실행됩니다. 이상적으로는 Ruby on Rails가 경고를 발생시키지 않아야 하지만 몇 개가 있을 수 있으며 타사 라이브러리에서도 있을 수 있습니다. 무시하거나(또는 수정!) 하고 새 경고를 발행하지 않는 패치를 제출하십시오.

Rails CI는 경고가 도입되면 오류를 발생시킬 것입니다. 동일한 동작을 로컬에서 구현하려면 테스트 스위트를 실행할 때 RAILS_STRICT_WARNINGS=1을 설정하십시오.

Ruby on Rails 가이드는 Rails 기능에 대한 개요를 제공하고 API 문서는 세부 사항을 다룹니다.

PR에서 새 기능을 추가하거나 기존 기능의 동작을 변경하는 경우 관련 문서를 확인하고 필요에 따라 업데이트하거나 추가하십시오.

예를 들어 Active Storage의 이미지 분석기에 새 메타데이터 필드를 추가하는 경우 Active Storage 가이드의 파일 분석 섹션을 업데이트해야 합니다.

CHANGELOG는 각 릴리스의 중요한 부분입니다. 이는 각 Rails 버전의 변경 사항 목록을 유지합니다.

기능을 추가하거나 제거하거나 사용 중단 알림을 추가하는 경우 수정한 프레임워크의 CHANGELOG 맨 위에 항목을 추가해야 합니다. 리팩토링, 사소한 버그 수정 및 문서 변경은 일반적으로 CHANGELOG에 포함되지 않아야 합니다.

CHANGELOG 항목에는 변경 사항에 대한 요약이 포함되어야 하며 작성자의 이름으로 끝나야 합니다. 더 많은 공간이 필요한 경우 여러 줄을 사용할 수 있으며 4개의 공백으로 들여쓰기된 코드 예제를 포함할 수 있습니다. 변경 사항이 특정 문제와 관련된 경우 문제 번호를 첨부해야 합니다. 다음은 CHANGELOG 항목의 예입니다:

*   변경 사항에 대한 요약을 간단히 설명합니다. 80자 정도로 여러 줄을 사용할 수 있습니다. 필요한 경우 코드 예제도 포함할 수 있습니다:

        class Foo
          def bar
            puts 'baz'
          end
        end

    코드 예제 뒤에 계속할 수 있으며 문제 번호를 첨부할 수 있습니다.

    Fixes #1234.

    *Your Name*

기존 애플리케이션을 중단시킬 수 있는 변경은 호환성 변경으로 간주됩니다. Rails 애플리케이션 업그레이드를 용이하게 하기 위해 호환성 변경에는 사용 중단 주기가 필요합니다.

호환성 변경으로 기존 동작을 제거하려면 먼저 사용 중단 경고를 추가하면서 기존 동작을 유지해야 합니다.

예를 들어 ActiveRecord::Base의 공개 메서드를 제거하려고 한다고 가정해 보겠습니다. 메인 브랜치가 출시되지 않은 7.0 버전을 가리키는 경우 Rails 7.0에서 사용 중단 경고가 표시되어야 합니다. 이렇게 하면 Rails 7.0 버전으로 업그레이드하는 모든 사람이 사용 중단 경고를 볼 수 있습니다. Rails 7.1에서 메서드를 삭제할 수 있습니다.

다음과 같은 사용 중단 경고를 추가할 수 있습니다:

def deprecated_method
  ActiveRecord.deprecator.warn(<<-MSG.squish)
    `ActiveRecord::Base.deprecated_method` is deprecated and will be removed in Rails 7.1.
  MSG
  # Existing behavior
end

호환성 변경으로 기존 동작을 변경하려면 프레임워크 기본값을 추가해야 합니다. 프레임워크 기본값은 Rails 업그레이드를 용이하게 하여 앱이 새 기본값으로 전환할 수 있습니다.

새 프레임워크 기본값을 구현하려면 먼저 대상 프레임워크에 액세서를 추가하여 구성을 만드십시오. 기존 동작을 보장하기 위해 기본값을 기존 동작으로 설정하십시오.

module ActiveJob
  mattr_accessor :existing_behavior, default: true
end

새 구성을 통해 새 동작을 조건부로 구현할 수 있습니다:

def changed_method
  if ActiveJob.existing_behavior
    # Existing behavior
  else
    # New behavior
  end
end

새 프레임워크 기본값을 설정하려면 Rails::Application::Configuration#load_defaults에서 새 값을 설정하십시오:

def load_defaults(target_version)
  case target_version.to_s
  when "7.1"
    # ...
    if respond_to?(:active_job)
      active_job.existing_behavior = false
    end
    # ...
  end
end

업그레이드를 용이하게 하기 위해 새 기본값을 new_framework_defaults 템플릿에 추가해야 합니다. 새 값을 설정하는 주석 처리된 섹션을 추가하십시오:

# new_framework_defaults_7_2.rb.tt

# Rails.application.config.active_job.existing_behavior = false

마지막 단계로 구성 가이드의 configuration.md에 새 구성을 추가하십시오:

#### `config.active_job.existing_behavior

| Starting with version | The default value is |
| --------------------- | -------------------- |
| (original)            | `true`               |
| 7.1                   | `false`              |

일부 편집기와 IDE는 rails 폴더 내에 숨겨진 파일이나 폴더를 만듭니다. 각 커밋에서 이를 수동으로 제외하거나 Rails의 .gitignore에 추가하는 대신 자신의 전역 gitignore 파일에 추가해야 합니다.

일부 변경에는 종속성 업그레이드가 필요합니다. 이러한 경우 bundle update를 실행하여 올바른 버전의 종속성을 얻고 변경 사항과 함께 Gemfile.lock 파일을 커밋하십시오.

컴퓨터의 코드에 만족하면 Git에 변경 사항을 커밋해야 합니다:

$ git commit -a

이렇게 하면 커밋 메시지를 작성할 편집기가 실행됩니다. 완료되면 저장하고 닫아 계속하십시오.

잘 구성되고 설명적인 커밋 메시지는 변경 사항을 이해하는 데 매우 도계속해서 Ruby on Rails에 기여하는 방법을 설명하겠습니다.

Rails GitHub 리포지토리로 이동하여 오른쪽 상단 모서리에 있는 "Fork” 버튼을 누르십시오.

로컬 머신의 로컬 리포지토리에 새 원격을 추가하십시오:

$ git remote add fork https://github.com/<your username>/rails.git

로컬 리포지토리를 rails/rails에서 복제했거나 포크된 리포지토리에서 복제했을 수 있습니다. 다음 git 명령은 rails/rails를 가리키는 “rails” 원격이 있다고 가정합니다.

$ git remote add rails https://github.com/rails/rails.git

공식 리포지토리에서 새 커밋과 브랜치를 다운로드하십시오:

$ git fetch rails

새 내용을 병합하십시오:

$ git checkout main
$ git rebase rails/main
$ git checkout my_new_branch
$ git rebase rails/main

포크를 업데이트하십시오:

$ git push fork main
$ git push fork my_new_branch

방금 푸시한 Rails 리포지토리(예: https://github.com/your-user-name/rails)로 이동하고 맨 위 막대(코드 바로 위)에서 “Pull Requests"를 클릭하십시오. 다음 페이지에서 오른쪽 상단 모서리에 있는 "New pull request” 버튼을 클릭하십시오.

풀 요청은 기본 리포지토리 rails/rails와 main 브랜치를 대상으로 해야 합니다. 헤드 리포지토리는 작업한 내용(your-user-name/rails)이 되고 브랜치는 브랜치에 지정한 이름이 됩니다. 준비되면 “create pull request"를 클릭하십시오.

도입된 변경 사항이 포함되어 있는지 확인하십시오. 풀 요청 템플릿을 사용하여 패치에 대한 세부 정보를 입력하십시오. 완료되면 "Create pull request"를 클릭하십시오.

대부분의 풀 요청은 병합되기 전에 몇 번의 반복을 거칠 것입니다. 다른 기여자들은 때때로 다른 의견을 가지고 있으며, 패치를 수정해야 병합될 수 있는 경우가 많습니다.

Rails에 기여하는 일부 사람들은 GitHub 알림을 켜두지만 다른 사람들은 그렇지 않습니다. 또한 (거의) 모든 Rails 작업자는 자원봉사자이므로 풀 요청에 대한 첫 번째 피드백을 받는 데 며칠이 걸릴 수 있습니다. 포기하지 마세요! 때로는 빠르고 때로는 느립니다. 오픈 소스 생활이 그렇습니다.

1주일이 지났는데 아직 아무 소식이 없다면 상황을 조금 더 진척시켜 볼 수 있습니다. Ruby on Rails Discord 서버의 contributions 채널이나 rubyonrails-core 토론 게시판을 사용할 수 있습니다. 또한 풀 요청에 다른 댓글을 남길 수 있습니다.

풀 요청에 대한 피드백을 기다리는 동안 다른 풀 요청을 열어 다른 사람을 돕는 것도 좋습니다. 그들도 자신의 패치에 대한 피드백을 받는 것처럼 감사할 것입니다.

코어 및 커미터 팀만 코드 변경을 병합할 수 있다는 점에 유의하십시오. 누군가가 피드백을 제공하고 "변경 사항을 승인"하더라도 병합할 수 있는 권한이나 최종 결정권이 없을 수 있습니다.

받은 피드백에서 변경이 필요할 수 있습니다. 낙심하지 마세요. 활성 오픈 소스 프로젝트에 기여하는 전체 포인트는 커뮤니티의 지식을 활용하는 것입니다. 사람들이 코드를 조정하도록 권장하는 경우 조정하고 다시 제출하는 것이 가치 있습니다. 코드가 병합되지 않을 것이라는 피드백을 받더라도 gem으로 릴리스하는 것을 고려해 볼 수 있습니다.

우리가 요청할 수 있는 것 중 하나는 "커밋을 압축"하는 것, 즉 모든 커밋을 단일 커밋으로 결합하는 것입니다. 우리는 단일 커밋으로 된 풀 요청을 선호합니다. 이렇게 하면 안정 브랜치로 변경 사항을 백포트하기 더 쉽고, 압축은 나쁜 커밋을 되돌리기 더 쉽게 만들며, Git 기록을 약간 더 쉽게 따라갈 수 있습니다. Rails는 큰 프로젝트이며 많은 불필요한 커밋은 많은 소음을 추가할 수 있습니다.

$ git fetch rails
$ git checkout my_new_branch
$ git rebase -i rails/main

< 첫 번째 커밋을 제외한 모든 커밋에 대해 'squash'를 선택하십시오. >
< 커밋 메시지를 의미 있게 편집하고 모든 변경 사항을 설명하십시오. >

$ git push fork my_new_branch --force-with-lease

GitHub의 풀 요청을 새로 고침하면 업데이트된 것을 볼 수 있습니다.

때때로 코드에 일부 변경 사항을 만들도록 요청받을 수 있습니다. 이는 기존 커밋을 수정하는 것을 포함할 수 있습니다. 이 경우 Git은 푸시된 브랜치와 로컬 브랜치가 일치하지 않기 때문에 변경 사항을 푸시할 수 없습니다. 새 풀 요청을 열지 않고 GitHub의 브랜치에 강제 푸시할 수 있습니다:

$ git commit --amend
$ git push fork my_new_branch --force-with-lease

이렇게 하면 GitHub의 브랜치와 풀 요청이 새 코드로 업데이트됩니다. --force-with-lease를 사용하여 강제 푸시하면 일반적인 -f보다 원격의 작업을 더 안전하게 업데이트할 수 있습니다.

다음 릴리스보다 이전 버전의 Ruby on Rails에 수정 사항을 추가하려면 자신의 로컬 추적 브랜치를 설정하고 전환해야 합니다. 7-0-stable 브랜치로 전환하는 예:

$ git branch --track 7-0-stable rails/7-0-stable
$ git checkout 7-0-stable

참고: 이전 버전에서 작업하기 전에 유지 관리 정책을 확인하십시오. 수명이 다한 버전에는 변경 사항이 허용되지 않습니다.

main 브랜치에 병합된 변경 사항은 Rails의 다음 주요 릴리스용으로 intended됩니다. 때때로 변경 사항을 유지 관리 릴리스에 전파하는 것이 유익할 수 있습니다. 일반적으로 보안 수정 및 버그 수정은 백포팅의 좋은 후보이지만, 새 기능 및 예상 동작을 변경하는 패치는 허용되지 않습니다. 의심스러운 경우 불필요한 노력을 피하기 위해 변경 사항을 백포팅하기 전에 Rails 팀 구성원과 상담하는 것이 가장 좋습니다.

먼저 main 브랜치가 최신 상태인지 확인하십시오.

$ git checkout main
$ git pull --rebase

백포팅할 브랜치(예: 7-0-stable)를 체크아웃하고 최신 상태인지 확인하십시오:

$ git checkout 7-0-stable
$ git reset --hard origin/7-0-stable
$ git checkout -b my-backport-branch

병합된 풀 요청을 백포팅하는 경우 병합 커밋을 찾아 체리 픽하십시오:

$ git cherry-pick -m1 MERGE_SHA

체리 픽 중에 발생한 충돌을 해결하고, 변경 사항을 푸시한 다음 백포팅할 안정 브랜치를 대상으로 PR을 여십시오. 더 복잡한 변경 사항의 경우 체리 픽 문서가 도움이 될 수 있습니다.

모든 기여는 Rails 기여자에 공헌으로 인정됩니다.