<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="version-control" xml:lang="ko">

  <info>
    <link type="guide" xref="index#general-guidelines"/>

    <credit type="author copyright">
      <name>Philip Withnall</name>
      <email its:translate="no">philip.withnall@collabora.co.uk</email>
      <years>2015</years>
    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>git으로 소스 코드 버전 관리하기</desc>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>조성호</mal:name>
      <mal:email>shcho@gnome.org</mal:email>
      <mal:years>2016.</mal:years>
    </mal:credit>
  </info>

  <title>버전 관리</title>

  <synopsis>
    <title>요약</title>

    <p>모든 그놈 프로젝트의 버전 관리에 git을 사용합니다. 이 페이지에서는 독자 여러분이 적절한 git 활용 지식을 갖추고 있다고 간주합니다. 일부 기초 자료는 <link href="https://www.atlassian.com/git/tutorials/">여기</link>에 있고, <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">git 간편 길잡이는 이곳에 있습니다</link>.</p>

    <list>
      <item><p>최소화 한, 복원 가능한 커밋을 만드십시오(<link xref="#guidelines-for-making-commits"/>).</p></item>
      <item><p>커밋 메시지에 완전한 근거와 관련 버그 보고서, 명세 링크를 추가하십시오(<link xref="#guidelines-for-making-commits"/>).</p></item>
      <item><p>이름 바꾸기 같은 규모가 큰 변경 이력은 커밋을 따로 분리하십시오(<link xref="#guidelines-for-making-commits"/>).</p></item>
      <item><p>기능 브랜치에서 리베이스 처리하여 변경 사항을 병합하십시오(<link xref="#use-of-git"/>).</p></item>
    </list>
  </synopsis>

  <section id="use-of-git">
    <title>git 사용</title>

    <p>대부분 그놈 저장소에서는 다음 규칙을 따릅니다:</p>
    <list>
      <item><p>강제 푸쉬를 하지 않습니다. <code>wip/</code> 접두부(work-in-progress)가 붙어있는 브랜치를 제외하고, 기여자가 의존하는 커밋 이력 정보는 수정하면 안됩니다.</p></item>
      <item><p>커밋을 병합하기 보단 리베이스 처리하여, 선형 내역을 만드십시오(흐름을 살펴보기 쉽습니다).</p></item>
      <item><p><code>wip/</code> 브랜치에 있는 그놈 git의 기능 브랜치에서 작업한 다음, 마스터 브랜치에서 리베이스를 수행하고, 변경 사항을 진행 정방향으로 병합하십시오. <code>wip/nickname/feature</code>와 같이 브랜치 이름에 여러분의 별명을 넣는 방식도 좋습니다.</p></item>
      <item><p>병합 처리 전 커밋을 합쳐서 <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">줄줄이 형상</link>을 숨기십시오.</p></item>
    </list>
  </section>

  <section id="guidelines-for-making-commits">
    <title>커밋 지침</title>

    <p>커밋은 최대한 작아야 하지만, 그렇다고 더 작아선 안됩니다. 각각의 커밋은 단일 문제를 해결해야 하며, 문제에 대해 바꾼 내용만 들어있어야 합니다. 각각의 커밋의 메시지에는 문제를 설명하고, 어디서 문제가 생겼는지, 수정 사항이 분명하지 않다면 어떻게 수정했는지 설명해야합니다. 커밋이 버그 보고서와 관련있을 경우 버그 보고서의 전체 URI를 커밋 보고서의 가장 윗 부분에 넣어야합니다. 동일하게 git commit의 ID(<cmd>git log --oneline</cmd>)를 커밋을 푸시한 버그 보고서에 복사하여 다른 사람이 쉽게 찾아볼 수 있도록 해야합니다.</p>

    <p>각 커밋에서 바뀐 내용은 쉽게 알아볼 수 있어야합니다. 예를 들어 불필요한 공백 내지는 들여쓰기 같은 내용이 있어서는 안됩니다. 파일 또는 함수의 이름을 바꾼다거나 하는식으로 기술적으로 바뀐 경우 파일 또는 함수에서 바꾼 내용과는 커밋을 별도로 나누어서 이전에 작업한 내용이 어딘가에 파묻히거나 없어지지 않게 해야합니다.</p>

    <p>다음 몇가지 원칙은 위에서 제시한 권고의 이유입니다:</p>
    <list>
      <item><p>각 커밋에서 저장소의 어떤 작업 상태를 다른 작업 상태로 전환해야 하며, 그렇지 않으면 <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">바이섹션</link>이 불가능합니다.</p></item>
      <item><p>각 커밋은 개별적으로 되돌릴 수 있어야합니다. 커밋이 잘못되었다고 생각이 바뀌면, <cmd>git revert <var>commit ID</var></cmd> 명령으로 어떤 작업 상태로부터 다른 작업 상태로 저장소 상태를 전환해야합니다.</p></item>
      <item><p>각 커밋의 설명, 명세 및 버그 보고서 같은 외부 자료와의 관계는 명확해야 하며, 과거 오래전에 어떤 개발자가 작성한 커밋에 이르기까지, 굳이 어떤 작업을 했는지 바뀐 내용을 찾아보지 않고도 그 다음 개발자가 알아볼 수 있어야합니다.</p></item>
      <item><p>각 커밋은 한 번만 작성하고 여러 검토자와 앞으로의 프로그래머가 여러 번 보도록 설계해야합니다.</p></item>
    </list>
  </section>

  <section id="merging-procedure">
    <title>병합 절차</title>

    <p><code>my-branch</code>라는 특정 브랜치를 마스터 브랜치로 병합하려면, 다음 명령을 활용하십시오:</p>
    <code mime="application/x-shellscript">
git checkout master
git pull

git checkout wip/<var>my-branch</var>
git rebase --interactive master
# Ensure the rebase is successful; test the changes

git checkout master
git merge wip/<var>my-branch</var>
git push

# wip/<var>my-branch</var> can now be deleted
git push origin :wip/<var>my-branch</var>
git branch -D wip/<var>my-branch</var></code>
  </section>

  <section id="external-links">
    <title>외부 링크</title>

    <list>
      <item><p><link href="https://sethrobertson.github.io/GitBestPractices/">Git best practices</link></p></item>
      <item><p><link href="https://help.github.com/categories/using-git/">Git FAQ</link></p></item>
      <item><p><link href="https://www.atlassian.com/git/tutorials/">Atlassian git tutorial</link></p></item>
      <item><p><link href="http://git-scm.com/docs/gittutorial">Official git tutorial</link></p></item>
      <item><p><link href="https://try.github.io/">Interactive git tutorial</link></p></item>
      <item><p><link href="http://www.git-tower.com/learn/">git-tower tutorial</link></p></item>
    </list>
  </section>
</page>
