개발/LibreOffice 개발자를 위한 Git

    From The Document Foundation Wiki
    This page is a translated version of the page Development/Git For LibreOffice Developers and the translation is 67% complete.
    Other languages:

    Git은 분산 버전 관리 시스템(Distributed version control system, DVCS) 입니다. 매우 강력하면서도 단순한 시스템이지만, DVCS에 익숙하지 않은 유저라면 혼란스러울 수 있습니다. 다행히도 웹상에는 Git에 대해 배울 수 있는 훌륭한 자원들이 있습니다. Git에 익숙하지 않다면, 아래를 방문해보세요:

    이 문서의 나머지 부분에서는 Git에 대한 기본적인 실무 지식을 전제로 할 것입니다.

    대부분의 LibreOffice 소스 코드는 core Git 저장소에 있지만, translations, help 그리고 dictionaries와 같은 몇몇 모듈들은 개별적인 저장소에 있습니다. 대부분의 경우 이 저장소들을 수정할 필요가 없을 것입니다.

    Git 브랜치 관리

    참조: Development/Branches

    A tip for displaying branch in your terminal prompt (Linux)

    It is possible to display the branch you are working on in a style like this:

    ~/git/core/helpcontent2 (master)$

    To achieve this, you can modify your PS1 prompt variable by adding the following to your $HOME/.bashrc:

    source /usr/share/git/completion/git-prompt.sh # <span lang="en" dir="ltr" class="mw-content-ltr">Note: the exact location of this file can vary depending on your system. On Debian-based systems, you can find the location with: dpkg -L git | grep prompt</span>
    export PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \W\[\033[31m\]$(__git_ps1 " (%s)")\[\033[01;34m\]$\[\033[00m\] '

    Another visual aid for the terminal is delta, which provides syntax highlighting for git, diff, and grep output.

    안정 브랜치에서의 수정 및 커밋

    릴리즈 및 추가적인 유지 보수 업데이트를 위한 코드 베이스를 안정화하기 위해, 안정 브랜치(stable branch)는 master 브랜치 혹은 또 다른 안정 브랜치로부터 생성됩니다. 베타 단계 동안에는 몇 가지 규칙 이 있습니다:

    • 모든 번역상의 변경이 허용됩니다.
    • 모든 버그 수정이 허용됩니다.
    • Engineering Steering Committee에서 승인된 모든 최신 기능이 허용됩니다.

    릴리즈 후보 단계에는 더 엄격한 규칙이 있습니다:

    • 다른 사람에게 검토를 받은 안전한 수정이 허용됩니다, 아래를 참고하세요
    • 번역상의 변경이 허용됩니다; 110n 메일링 리스트상의 원어민에게 검토 요청을 하는 것을 권장합니다.

    릴리즈 후보 단계에서 직접 변경사항을 커밋하지 마십시오. 대신에, 패치 내용을 gerrit으로 보내주시거나 libreoffice@lists.freedesktop.org 메일링 리스트, 개인 메일, IRC 또는 관련 버그 항목을 통해 다른 개발자에게 검토를 요청하세요. 변경 사항은 반드시 다음 사항을 사용해 검토자에 의해 커밋되어야 합니다:

    git commit -s --author='<span lang="en" dir="ltr" class="mw-content-ltr">Author name <author@mail.address></span>'

    git pull -r가 동작하지 않을때 해야 할 일

    일반적으로 당신의 저장소에서 있었던 로컬 변경점에 인해 발생합니다. 이 변경점을 다음 항목을 사용해 제거하거나:

    git checkout -f
    git pull -r

    혹은 일시적으로 변경점들을 숨겨 두었다가, git pull -r을 수행한 다음 다시 돌려 놓을 수 있습니다:

    git stash
    git pull -r
    git stash pop

    수정된 저장소를 “vanila” 저장소로 되돌리기

    $ git reset --hard origin/master

    를 수행하면 당신의 모든 로컬 변경점들(커밋했든 커밋하지 않았든)을 삭제하고 현재 저장소를 원격 저장소의 현재 분기로 초기화합니다.

    Untracked 또는 ignored 파일들 삭제하기

    임시 파일이나 오래된 개발 로그를 삭제하고 깨끗한 작업 디렉토리를 만들기 위해.

    $ git clean -fdx

    Improve git cloning for slow network

    If your network is slow, you can clone/checkout only the branch you need, or do a shallow/partial clone. You can do this from the LibreOffice mirror in GitHub, but remember to add a remote for the original repository.

    For example, cloning from Github with depth=1 is like this:

    git clone --depth=1 https://github.com/libreoffice/core

    Then, you have to make sure the remote is set to the original repository. To do that, edit the .git/config file, so that the remote section is like this:

    [remote "origin"]
    	url = git://git.libreoffice.org/core
    	fetch = +refs/heads/*:refs/remotes/origin/*

    Reorder, squash and in general tweak your local history: git rebase -i

    git rebase -i는 당신이 당신의 로컬 히스토리를 "재작성"할 수 있도록 하는 효과적인 도구입니다.

    Warning.svg

    Warning:
    This should only be done on commits that have not been pushed to master or a release branch yet!


    당신이 master에 있고 A,B,C=HEAD 3개의 커밋이 있지만, C는 당신이 B를 커밋하기 전에 깜빡한 커밋 A에 대한 수정이라고 해봅시다. 그래서 당신이 하고싶은 것은 A와 C를 머지하고 A',B로 히스토리를 마무리하는 것입니다.

    그렇게 하기 위해서 아래 내용을 할 수 있습니다.

    git branch safehead HEAD

    이것은 오직 무언가가 정말 잘못되고 있는 경우 모든 것을 처음의 상태로 돌리기 원할 때 사용합니다.

    git rebase -i HEAD~3

    This should bring, in your favorite editor (as set by the variable $EDITOR) a list of the last 3 commits, from the oldest to the newest (the reverse order than normally in git log), so C is the last of the list:

    pick 726fe9c enable localization of extension descriptions in mysqlc
    pick 9ab6ecf fix en-US only build
    pick a18bfb0 Revert "enable localization of extension descriptions in sdext"
    
    # Rebase 1846533..a18bfb0 onto 1846533
    #
    # Commands:
    #  p, pick = use commit
    #  r, reword = use commit, but edit the commit message
    #  e, edit = use commit, but stop for amending
    #  s, squash = use commit, but meld into previous commit
    #  f, fixup = like "squash", but discard this commit's log message
    #  x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
    #
    # If you remove a line here THAT COMMIT WILL BE LOST.
    # However, if you remove everything, the rebase will be aborted.
    #
    

    Edit it, moving commit C one-up and changing its action to squash:

    pick 726fe9c enable localization of extension descriptions in mysqlc
    squash a18bfb0 Revert "enable localization of extension descriptions in sdext"
    pick 9ab6ecf fix en-US only build
    

    저장하고 에디터를 나갑니다.

    Now you can edit the commit message of the merged commit:

       # This is a combination of 2 commits.
       # The first commit's message is:
       
       enable localization of extension descriptions in mysqlc
       
       Change-Id: I7141eea0fe7f72408da0d2a5ebe4a5e2891b6b7d
       
       # This is the 2nd commit message:
       
       Revert "enable localization of extension descriptions in sdext"
       
       Change-Id: Iff01d31792a13a14ea720c477417217af0c01642
    
    Note pin.svg

    Note:
    If you intend to push the commit to gerrit, the ChangeId line is crucial: gerrit uses it to find an existing patch that will be updated with a new revision. So make sure to take the ChangeId line from the appropriate commit (usually the one you already uploaded to gerrit before), do not edit it, and remove the ChangeId line of the less important commit that you want to get rid of.

    Once you have combined the 2 commit messages, save and exit again.

    If everything went nicely you should be on master with your HEAD on B and A+C fused into one commit A', just before B. If things went wrong and you are lost:

    git rebase --abort

    If things are not reverted to the way they should (compounded wrongness) you can say this to pretend nothing ever happened:

    git reset --hard safehead

    커밋 접근 가져오기 및 사용하기

    커밋 액세스를 얻기 위해서는 "후원"을 받아야 합니다. 우선 패치를 제출하고, 이것이 문제가 되지 않는다고 당신 스스로 인정받습니다, 그러나 요청을 받을 때까지 기다리는 것이 가장 좋습니다. 우선 요청을 받거나 (또는 당신을 후원해주기를 누군가가에 요청한다면), 당신은 계정을 가지기를 할 필요가 있습니다.