개발/LibreOffice 개발자를 위한 Git

From The Document Foundation Wiki
Jump to: navigation, search

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

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

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

Git 브랜치 관리

참조: Development/Branches

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

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

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

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

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

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

git commit -s --author='Author name <author@mail.address>'

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

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

Delete untracked or ignored files

To clean out junk like temp files and old development logs and create a pristine working directory

$ git clean -fdx

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

git rebase -i is a powerful tool that allows you to “rewrite” your local history.

Gnome-dialog-warning.svg

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


Let’s say you are on master and the last 3 commits are A,B,C=HEAD but C is actually a correction of the commit A that you missed before committing B. So what you would want to do is to merge A and C together and end-up with A',B as history.

To do that you can

git branch safehead HEAD

This is just in case something goes very wrong and you want to just undo everything and go back to the initial sate

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

Then save and exit the editor.

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
Im-jabber.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

git reset --hard safehead

to pretend nothing ever happened :-)

Getting and using commit access

In order to get commit access you need to be “sponsored”. Once you’ve submitted patches and got yourself recognised this won’t be a problem, but it’s best to wait until you’re asked. Once you’ve been asked (or asked for someone to sponsor you), you need to get an account