Table of Contents

패치 배포

패치는 Github에서 pull 명령어를 이용하거나 메일링 리스트를 통해 받을 수 있습니다 .

Submission은 다음과 같은 가이드라인을 따라서 할 수 있습니다:


Github에서 작업하기

여기에 소스가 저장된 Github 미러가 있습니다.
Github 웹 인터페이스를 이용해서 프로젝트를 개인 저장소로 포크하고 로컬 컴퓨터로 복사한 뒤 바뀐 점을 브랜치하고 Github로 push한 뒤 pull 요청을 보내세요.

만약 방법을 모른다면 계속 읽으세요.

Github 계정을 생성하면 LEDE 소스의 포크를 호스팅하고 Github의 작업에 사용됩니다.

PC에 git을 설치하고 git 설정에 올바른 이름과 메일이 있는지 확인하세요.
git config --global user.name “my name”
git config --global user.email “my@email.address”

원한다면 기본 git 에디터가 아닌 선호하는 에디터로 바꿀 수 있습니다. (linux의 GUI 버전을 사용하고 있다면 geany, kwrite, pluma, gedit를 사용할 수 있고 , 커맨드 라인을 사용한다면 nano가 좋은 선택이 될 수 있습니다.)
git config --global core.editor “editor-name-here”

다음으로 문서들을 따라 저장소에 포크하고 포크에 대한 클론을 만들 수 있습니다.

설명한 대로 설정이 끝났다면 git checkout -b my-new-branch-name을 통해 브랜치할 수 있습니다. (“my-new-branch-name” 예시의 이름이고 다른 이름을 사용하세요).
이 명령 뒤에 하는 모든 커밋은 이 브랜치에서 그룹화 됩니다. 이후에 각 PR마다 여러 브랜치를 가질 수 있습니다.
이미 생성한 분기를 바꾸려면 git checkout my-branch-name를 사용하세요.

변경한 후에 git add -i를 이용하여 인터페이스를 통해 발견되지 않은(새로운) 파일을 추가하고 기존 파일을 업데이트 하세요.

그 후에 git commit --signoff를 통해 기본 git 에디터를 열고 커밋 메시지를 작성할 수 있습니다. 첫 번째 줄은 커밋 제목이고 빈줄을 하나 만든 후에 커밋 상세정보를 작성하세요. 이 명령어가 자동으로 Signed-off-by line에 위에 설정한 이름과 메일주소를 추가합니다.

Github 저장소로 로컬에서 작업한 변경 사항을 보내고 싶다면, git push --all을 사용하세요.
이 과정에서 Github ID와 비밀번호를 묻습니다.

GIthub 저장소에 코드가 업로드 되고 나면, Github 웹 인터페이스를 사용하여 PR을 보낼 수 있습니다, Github의pull 요청 생성하기에 대한 문서를 다시 보세요.


이메일을 통해 패치 전송

개발 메일링 리스트로 메일을 보내세요. 모든 패치는 패치워크에 작성된 포맷에 따라 전송되어야 합니다. 패치워크에 없는 패치라면 처리될 수 없습니다. 이메일 클라이언트들은 공백을 넣고 서식을 이상하게 만들거나, 알수 없는 문자를 추가하는 경우가 있기 때문에 git send-email 를 사용하는 것을 추천합니다.

커밋하기

PR에 커밋하거나 메일로 보내려면, 검토자가 PR에서 바뀐점을 일일이 찾아서 바꿀 수 없으므로 merge할 변경 사항이 있어야 합니다.

그러므로 커밋을 새로 작성해야 될 경우가 있으므로 항상 정상적인 커밋으로 끝을 내야 합니다.

PR의 로컬 git 브랜치에선 git 커맨드라인을 이용해서 작업하세요.

git reset HEAD~X (X는 삭제하려는 커밋의 수이며 마지막 커밋에서부터 계산 됨)로 커밋을 삭제 한 후 시작합니다. 이 경우 수정된 파일은 변경되지 않으며 커밋만 삭제됩니다.
git add -i를 이용하여 git tracking에 파일을 추가하고 git commit --signoff을 사용하여 다시 커밋하세요.
git push -f을 사용하여 업데이트 된 브랜치를 github에 보냅니다.

패치 합병과 트리의 생명주기

우리는 커미터들이 패치들을 저장해둔 트리를 호스트할 것을 권장합니다. 트리가 검토되고 테스트를 마치면 마스터 브랜치에 포함되도록 제안 할 수 있습니다.

  1. 트리는 언제든 마스터에 합병될 수 있습니다.
  2. 마스터 브랜치에 직접적으로 버그 수정을 할 수 있습니다.
  3. PR은 어떤 소스든 패치 메일링 리스트로 보낼 수 있으며 좋은 질의 트리와 제출 형식이 올바른 경우에 얼마든지 포함 될 수 있습니다.
  4. Staging 트리는 git 인프라, 개인 서버, Github의 일부로 호스팅 될 수 있습니다.