주석
이번 과정을 설명하는 데 QGIS 문서를 예로 들긴 했지만, 다음 단락부터 보여줄 모든 명령어 및 단계는 QGIS 웹사이트에도 적용할 수 있습니다.
Now that you know the rules to follow to write a clean doc for QGIS, let’s dive in the process of production of this documentation and how quickly and safely share your changes with the community.
Assuming you already have a GitHub account, you first need to clone the source files of the documentation in order to have your own copy you can work on: go to the QGIS-Documentation repository page (for convenience, this repository is called below qgis/QGIS-Documentation) and click on the Fork button in the upper right corner.
Few seconds later, in your GitHub account you find a QGIS-Documentation repository (https://github.com/<YourName>/QGIS-Documentation). This repo is a safe copy in which you have full write access and can push all your contributions without a risk to affect the official documentation. At the beginning, this repository contains the same branches as qgis/QGIS-Documentation and is defaulted to master branch. Branches are parallel lines of development containing different snapshots of the doc that may merge or diverge. Preferably create a branch for each issue you want to tackle and you can create as many branches as you want.
참고
Do your changes in an ad’hoc branch, never in master
By convention, avoid making changes in your master branch except merging the modifications from the master branch of qgis/QGIS-Documentation (called qgis:master). And use it as model to create new branches for a clean history and snapshot.
There are different ways to contribute to QGIS documentation. Though we expose them below separately, they are not mutually exclusive, meaning that you can, at any moment, switch from one process to another without any harm because they both follow the scheme below:
From your cloned repository, you can now propose changes to the main documentation. Indeed, GitHub web interface offers you ways to easily:
다음 단락에서 이용할 몇몇 기본 용어 및 액션을 숙지하기 위해 GitHub Hello-world 프로젝트를 읽어보시기 바랍니다.
Documentation can be improved by addressing issues reported at https://github.com/qgis/QGIS-Documentation/issues or issues you may have encountered while browsing the doc. They can be of different types: typo error, missing feature, wrong or out of date description...
The QGIS project provides an easy way to reach source file from online documentation. Indeed, instead of browsing the source files in GitHub to find the one that suits the issue, or if you find an issue while reading the manuals, you simply have to click the “Fix Me” link at the bottom of the page to open its source file in Edit mode.
This will open the file in the qgis:master branch with a message at the top of the page telling you that you don’t have write access to this repo and your changes will be applied in a new branch of your repository.
Note that if you have commit rights to QGIS-Documentation repository, then no message will show and you’ll directly modify qgis:master branch itself unless you save your changes in another branch.
Do your changes following guidelines available at http://docs.qgis.org/testing/en/docs/documentation_guidelines/
When you finish, at the bottom of the page, comment a bit what your changes are about and click on Propose File change. This will generate a new branch (patch-xxx) in your repo.
참고
If your master branch is even with qgis:master, you can safely replace in the link qgis by <YourName>. In this case, once your changes are done, you need to check Create a new branch for this commit and start a pull request and avoid modifying master.
GitHub web interface helps you update the repo with your contribution in an easier way but it doesn’t offer tools to:
작성자의 변경 사항을 테스트하기 위한 문서를 빌드
You then need to install git on your hard drive in order to get access to more advanced and powerful tools and have a local copy of the repository. Some basics you may often need are exposed below. You’ll also find rules to care about even if you opt for the web interface.
다음에 나오는 코드 예시에서, # 로 시작하는 줄은 주석을 의미하지만 $ 로 시작하는 줄은 작성자가 입력해야 하는 명령어를 나타냅니다.
이제 작성자의 QGIS 문서 저장소의 로컬 사본을 받을 준비가 됐습니다.
$ cd ~/Documents/Development/QGIS/
$ git clone git@github.com:<YourName>/QGIS-Documentation.git
이 명령줄은 예시일 뿐입니다. 작성자는 <YourName> 을 작성자의 사용자명으로 대체하여 경로 및 저장소 URL 둘 다 작성자의 로컬 환경에 맞춰야 합니다.
다음 예시를 확인해보세요.
$ git remote -v
origin git@github.com:<YourName>/QGIS-Documentation.git (fetch)
origin git@github.com:<YourName>/QGIS-Documentation.git (push)
$ git branch
* master
origin 은 작성자의 QGIS 문서 저장소의 원격 저장소의 명칭입니다.
master 는 기본 주 분기입니다. 기고하는 데 절대로 이 분기를 이용해서는 안 됩니다! 절대로요!!
여기서 작업을 시작해도 괜찮지만, 길게 봤을 때 작성자의 작업 내용을 푸시할 경우 (GitHub 처리 과정에서는 풀 요청이라고 합니다) 작성자의 로컬/원격 저장소에서 QGIS 문서 저장소의 주 분기가 갈라져 나올 것이기 때문에 수많은 문제점이 발생할 것입니다.
주 프로젝트에서 작업을 추적할 수 있으려면, 작성자의 로컬 저장소에 새 원격 저장소를 추가하십시오. 이 새 원격 저장소가 QGIS 프로젝트에서 나온 QGIS 문서 저장소입니다.
$ git remote add upstream git@github.com:qgis/QGIS-Documentation.git
$ git remote -v
origin git@github.com:<YourName>/QGIS-Documentation.git (fetch)
origin git@github.com:<YourName>/QGIS-Documentation.git (push)
upstream git@github.com:qgis/QGIS-Documentation.git (fetch)
upstream git@github.com:qgis/QGIS-Documentation.git (push)
이제 두 원격 저장소들 사이에서 선택할 수 있습니다.
작성자 의 원격 저장소에 작성자의 로컬 분기를 푸시하는 origin
공식 문서로 작성자의 작업 내용을 (그럴 권한이 있을 경우) 통합하거나, 공식 저장소의 마스터 분기에서 나온 작성자의 로컬 저장소의 마스터 분기를 업데이트하는 upstream
주석
upstream 은 라벨일 뿐으로, 일종의 표준 명칭이지만 원하는 대로 명명할 수 있습니다.
새 작성 작업을 시작하기 전에, 항상 작성자의 로컬 저장소에 있는 로컬 마스터 분기를 업데이트해야 합니다. 다음 명령어를 수행하십시오.
# switch to master branch (it is easy to forget this step!)
$ git checkout master
# get "information" from the master branch in upstream repository
# (aka qgis/QGIS-Documentation's repository)
$ git fetch upstream master
# merge update from upstream/master to the current local branch
# (which should be master, see step 1)
$ git merge upstream/master
# update **your** remote repository
$ git push origin master
이제 작성자는 QGIS.org의 QGIS 문서와 동일한 master 분기를 보유한 로컬 및 원격 저장소를 얻었습니다. 문서를 작성하기 시작할 수 있습니다.
Along the testing documentation, we continue to fix issues in QGIS 2.18 doc, meaning that you can also contribute to it. Following the previous section sample code, you can easily do that by selecting the corresponding branch.
저장소를 복사할 경우 (로컬 저장소 참조) 작성자의 복사본은 upstream 저장소의 모든 분기들을 보유하게 됩니다. 앞의 내용처럼, 작성자는 자신의 분기가 upstream 의 분기와 동일한지 확인해야 합니다.
# change branch e.g. for 2.14 LTR
$ git checkout manual_en_2.14
# get "information" from the manual_en_2.14 branch in upstream repository
$ git fetch upstream manual_en_2.14
# merge update from upstream/manual_en_2.14 to the current local branch
$ git merge upstream/manual_en_2.14
# update **your** remote repository
$ git push origin manual_en_2.14
In this way your local and remote branches for the 2.14 version are up to date with the one of the official upstream repository.
이제 작성자의 기반 분기가 업데이트됐으니, 작성 내용을 추가할 전용 분기를 생성해야 합니다. 언제나 기반 분기가 아닌 다른 분기에서 작업하십시오! 언제나요!
$ git checkout -b myNewBranch
# checkout means go to the branch
# and -b flag creates a new branch if needed, based on current branch
$ git branch
master
manual_en_2.14
* myNewBranch
# a list of existing branch where * means the current branch
# You can now add your contribution, by editing the concerned file
# with any application (in this case, vim is used)
$ vim myFile
# once done
$ git add myFile
$ git commit
커밋/푸시(commit/push) 명령어에 대해:
오직 하나의 (원자 단위의 변경) 내용만, 예를 들어 오직 문제점 하나만 다루도록 해보십시오.
작성자의 커밋 제목 및 설명에 무엇을 변경했는지 꼼꼼히 서술해보십시오. 첫 줄은 제목으로, 대문자로 시작해야 하고 문자 80개의 길이 제한이 있으며 . 로 끝나서는 안 됩니다. 제목은 간결하게 적으십시오. 설명은 더 길어도 되고, . 로 끝나며, 더 상세하게 서술할 수 있습니다.
어떤 문제점인지 식별하기 위해 # 뒤에 문제점 번호를 적으십시오. 해당 버그 티켓을 해결했다면 그 앞에 Fix 를 입력하십시오. 작성자의 커밋이 해당 티켓을 폐지할 것입니다.
Now that your changes are saved and committed in your local branch, you need to send them to your remote repository in order to create pull request:
$ git push origin myNewBranch
작성자의 풀 요청이 공식 QGIS 문서에 통합된 다음, 작성자의 분기를 삭제할 수 있습니다. 이런 방식으로 많은 작업을 하는 경우, 몇 주만 지나도 쓸데없는 분기들을 많이 보유하게 될 겁니다. 따라서 다음 방법을 통해 작성자의 저장소를 말끔히 유지하십시오.
# delete local branch
$ git branch -d myNewBranch
# Remove your remote myNewBranch by pushing nothing to it
$ git push origin :myNewBranch
그리고 작성자의 로컬 저장소에 있는 master 분기를 업데이트하는 것도 잊지 마십시오!