Git 및 GitHub와 함께 작업¶

게시 작업¶

다음을 실행하여 GitHub에 작품을 게시할 수 있습니다.

git push origin ticket_xxxxx

GitHub 페이지로 이동하면 새 분기가 생성되었음을 알 수 있습니다.

Trac 티켓을 작업하는 경우 GitHub repo의 branch ticket_xxxxxx에서 작업을 수행할 수 있음을 티켓에 언급해야 합니다. 분기에 대한 링크를 포함합니다.

위의 분기를 Git parance에서 “토픽 분기”라고 합니다. 예를 들어 “gitrebase”를 사용하여 이 지점의 기록을 자유롭게 다시 작성할 수 있습니다. 커밋을 편집할 때 복제본이 손상되기 때문에 다른 사용자는 이러한 분기에 기반하여 작업을 수행해서는 안 됩니다.

“public branches”도 있습니다. 이것들은 다른 사람들이 포크해야 하는 지점들이기 때문에, 이 지점들의 역사는 절대 바뀌어서는 안 됩니다. 공용 분기의 좋은 예로는 django/django 저장소에 있는 ``main``와 ``stable/A.B.x` 분기가 있습니다.

작업을 Django로 풀 할 준비가 되었다고 생각되면 GitHub에서 풀 요청을 작성해야 합니다. 좋은 풀 요청은 다음을 의미합니다.

• coding style 1,에 따라 각각 하나의 논리적 변경으로 커밋합니다.
• 각 커밋에 대한 올바른 형식의 메시지: 요약 줄과 72자로 요약된 단락 - 자세한 내용은 :ref:”커밋 지침”을 참조하십시오.
• 설명서 및 테스트(필요한 경우)는 문서 변경을 제외하고 실제로 항상 테스트가 필요합니다.

테스트 제품군을 통과해야 하며 설명서는 경고 없이 작성되어야 합니다.

풀 요청을 만든 후에는 관련 Trac 티켓에 사용자가 수행한 작업을 설명하는 설명을 추가해야 합니다. 특히 ” SQLite 및 MySQL에서 통과하는 모든 테스트”와 같은 테스트를 실행한 환경에 주목해야 합니다.

GitHub의 Pull 요청에는 열린 상태와 닫힌 상태 두 가지 상태만 있습니다. 풀 요청을 처리할 병합에는 병합 또는 닫기의 두 가지 옵션만 있습니다. 이러한 이유로 코드가 병합될 준비가 되거나 병합이 자체적으로 완료될 정도로 충분히 가까워질 때까지 풀 요청을 하는 것은 유용하지 않습니다.

브랜치 리베이스하기¶

위의 예에서는 “Fixed ticket_xxxx” 커밋과 “Test 2개 추가” 커밋이라는 두 가지 커밋을 만들었습니다.

작업 프로세스의 전체 이력을 리포지토리에 저장하지 않습니다. “테스트 두 개 추가”라는 약속은 도움이 되지 않는 잡음이 될 것입니다. 대신, 우리는 당신의 모든 일을 포함하는 하나의 약속만을 원합니다.

분기 기록을 다시 작성하려면 대화형 rebase를 사용하여 커밋을 하나로 스쿼시할 수 있습니다.

git rebase -i HEAD~2

위의 HEAD~2는 최근 두 가지 커밋의 약자입니다. 위의 명령어는 “pick”이라는 단어 앞에 있는 두 개의 커밋을 보여주는 편집기를 엽니다.

대신 두 번째 줄의 “선택”을 “파쇄”로 변경합니다. 이렇게 하면 첫 번째 커밋이 유지되고 두 번째 커밋이 첫 번째 커밋으로 스쿼시됩니다. 편집기를 저장한 후 종료합니다. 두 번째 편집기 창이 열리면 커밋 메시지에 대한 단어를 바꿀 수 있습니다. 이제 커밋 메시지에 두 단계가 모두 포함됩니다.

rebase에서 “edit” 옵션을 사용할 수도 있습니다. 이 방법으로 단일 커밋을 변경할 수 있습니다. 예를 들어, 문서 문자열의 오타를 수정합니다.

git rebase -i HEAD~3
# Choose edit, pick, pick for the commits
# Now you are able to rework the commit (use git add normally to add changes)
# When finished, commit work with "--amend" and continue
git commit --amend
# Reword the commit message if needed
git rebase --continue
# The second and third commits should be applied.

예를 들어 리뷰를 고려하기 위해 사소한 변경을 하는 경우처럼 주제 분기가 GitHub에 이미 게시되어 있는 경우 변경 사항을 강제로 푸시해야 합니다.

git push -f origin ticket_xxxxx

이렇게 하면 ticket_xxxxx의 기록이 다시 작성됩니다. GitHub에서 작업 전후에 커밋 해시를 확인하면 커밋 해시가 더 이상 일치하지 않음을 알 수 있습니다. 분기는 주제 분기로, 누구도 작업에 기반을 두어서는 안 되기 때문에 이는 허용됩니다.

업스트림 변경 후.¶

업스트림(django/django)이 바뀌면 작업을 다시 기본으로 해야 합니다. 이렇게 하려면 다음을 사용합니다.

git fetch upstream
git rebase

이 작업은 “upstream/main”을 사용하는 예에서와 같이 사용자가 분기한 분기를 사용하여 자동으로 리베이스화됩니다.

rebase 명령은 일시적으로 모든 로컬 커밋을 제거하고 업스트림 커밋을 적용한 다음 로컬 커밋을 작업에 다시 적용합니다.

병합 충돌이 있는 경우 이를 해결하고 “gitrebase –continue”를 사용해야 합니다. 언제든지 “git rebase –abort”를 사용하여 원래 상태로 돌아갈 수 있습니다.

업스트림을 *머지*하지 않고 업스트림에 *리베이스*를 지정하려고 합니다.

그 이유는 기본 재배치함으로써 커밋은 항상 업스트림의 작업과 *혼합*되는 것이 아니라 *업스트림의 작업에 *상위*되기 때문입니다. 이렇게 하면 분기에 해당 주제와 관련된 커밋만 포함되므로 쉽게 스퀴싱할 수 있습니다.

검토후¶

검토자가 요청한 변경 사항 없이 사소한 양의 코드를 코어로 가져오는 것은 드문 일입니다. 이 경우 변경 사항을 작업에 대한 하나의 증분 커밋으로 추가하는 것이 좋습니다. 이렇게 하면 검토자는 사용자가 변경한 내용을 쉽게 확인할 수 있습니다.

이 경우 검토자가 요구하는 내용을 변경하십시오. 필요한 만큼 자주 커밋합니다. 변경 내용을 게시하기 전에 작업 내용을 다시 정의하십시오. 두 개의 커밋을 추가한 경우 다음을 실행합니다.

git rebase -i HEAD~2

두 번째 커밋을 첫 번째 커밋으로 밀어 넣습니다. 다음 행에 커밋 메시지를 작성합니다.

Made changes asked in review by <reviewer>

- Fixed whitespace errors in foobar
- Reworded the docstring of bar()

마지막으로 GitHub 저장소로 작업을 다시 푸쉬하십시오. 기본 재배치 중에 공개 커밋을 건드리지 않았으므로, 다음을 강제로 푸시할 필요가 없습니다.

git push origin ticket_xxxxx

이제 풀 요청에도 새 커밋이 포함됩니다.

병합은 코드를 커밋할 때 검토 커밋을 이전 커밋으로 압축할 가능성이 높습니다.