Development/Git For LibreOffice Developers/ko

Git은 분산 버전 관리 시스템(Distributed version control system, DVCS) 입니다. 매우 강력하면서도 단순한 시스템이지만, DVCS에 익숙하지 않은 유저라면 혼란스러울 수 있습니다. 다행히도 웹상에는 Git에 대해 배울 수 있는 훌륭한 자원들이 있습니다. Git에 익숙하지 않다면, 아래를 방문해보세요:
 * https://learngitbranching.js.org/ 멋지게 시각화되어 있는 직접 실행에 따른 학습(learning-by-doing).
 * https://git-scm.com/book/ Scott Chacon과 Ben Straub의 Pro Git book
 * Git is a Directed Acyclic Graph (에 아카이빙됨) -- 만약 당신이 DAG가 무엇인지 알고 있다면 이것은 가장 빠른 이론 설명일 것입니다.
 * https://www.youtube.com/watch?v=1ffBJ4sVUb4 쉬운 시각화 설명.
 * https://who-t.blogspot.com/2009/12/on-commit-messages.html 좋은 커밋 메시지를 작성하는 방법.
 * https://github.com/k88hudson/git-flight-rules 뭔가 잘못되어 갈 때 Git 항해자가 무엇을 하면 되는지에 대한 지침.

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

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

Git 브랜치 관리

 * 참조: Development/Branches

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


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

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


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

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

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

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

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

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

Reorder, squash and in general tweak your local history:
는 당신이 당신의 로컬 히스토리를 "재작성"할 수 있도록 하는 효과적인 도구입니다.

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

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

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

This should bring, in your favorite editor (as set by the variable ) 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" # # 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 # #
 * 1) Rebase 1846533..a18bfb0 onto 1846533
 * 1) Commands:
 * 1)  x, exec = Run a shell command , and stop if it fails
 * 1) If you remove a line here THAT COMMIT WILL BE LOST.
 * 2) However, if you remove everything, the rebase will be aborted.

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

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

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

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

If things are not reverted to the way they should (compounded wrongness :-) you can

to pretend nothing ever happened :-)

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