[이전 포스트]
[Git] 위험한데, 내 커밋 히스토리가 깔끔해져요! - Rebase
Git - Rebase 하기Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다. 새 커밋을 서버에 Push 하고 동료 중 누군가가 그 커밋을 Pull 해서 작업을 한다고 하자
300-29-1.tistory.com
Git - GitHub 프로젝트에 기여하기
과거에는 “Fork” 가 좋은 의미로 쓰이지 않았다. 오픈 소스 프로젝트를 “Fork” 한다는 것은 복사해서 조금은 다른 프로젝트를 만드는 것을 의미했고 때때로 원래 프로젝트와 경쟁하거나 기여
git-scm.com
'깃북 6.2 GitHub - GitHub 프로젝트에 기여하기'에 대한 발췌 및 정리에 더해,
추가로 GitHub에 대한 간단한 이해와 함께
남의 프로젝트에 기여하는 법을 정리한 포스트입니다.
다음 포스트는 GitHub 프로젝트를 “관리”하는 법에 대한 내용입니다.
GitHub
가장 큰 Git 원격 저장소입니다.
수많은 개발자가 모여 수많은 프로젝트를 수행하는 중추입니다.
전 세계적으로 프로젝트의 Git 저장소를
GitHub에 만들어 운영하는 비율이 상당히 높습니다.
많은 오픈 소스 프로젝트는 GitHub을 이용해
Git 호스팅, 이슈 트래킹, 코드 리뷰 등의 일을 합니다.
또한 프로젝트의 버전관리 기능을 넘어
배포 및 운영 단에서의 부가기능도 존재합니다.
GitHub Action을 이용해 CI/CD 파이프라인을 많이 구축합니다.
GitHub는 개인 개발자부터 대규모 기업까지 폭넓게 사용되며,
오픈 소스 생태계의 중심지 역할을 하고 있습니다.
코드 공유, 버전 관리, 협업 등
소프트웨어 개발의 거의 모든 측면을 지원하는 종합적인 플랫폼입니다.
Git을 많이 사용하다 보면 Git 프로젝트 자체에는 참여하지 않더라도,
분명 GitHub을 사용해야하는 상황이 오거나
스스로 사용하고 싶어질 것입니다.
GitHub 프로젝트에 기여하기
(우선 GitHub 계정이 필요합니다.)
프로젝트 fork 하기
참여하고 싶은 프로젝트가 생기면
아마 그 프로젝트 자체에 Push할 권한은 없어
“Fork” 부터 해야 합니다.
“Fork”를 하면, Github이 프로젝트를 통째로 복사해줍니다.
이 복사본은 사용자 네임스페이스에 존재하고,
여기에 Push 할 수도 있습니다.
사용자 네임스페이스에 존재한다는 말은 다음을 의미합니다.
이미 널리 알려진 프로젝트(ex. 오픈소스 프로젝트)는 GitHub 상에 존재하긴 합니다.
그러나 내가 만든 프로젝트가 아니어서 여러 권한도 없고, 작성자도 제가 아닙니다.
이를 Fork하면, 이 프로젝트의 전체 복사본을 GitHub 상의 내 개인 레포지토리에
개인 프로젝트로 가져올 수 있다는 의미입니다.
이러한 방식에서는 사람들을 프로젝트에 추가하고 Push 권한을 줘야 할 필요가 없습니다.
사람들은 프로젝트를 “Fork”하여 개인 프로젝트로 가져오고, 여기에 Push 합니다.
그리고 Push한 변경 내용을 원래 프로젝트 저장소로 보내,
원래 프로젝트에 기여(Contribution) 합니다.
이를 Pull Request라 하는데, 나중에 다시 설명합니다.
Pull Request를 위해서는 토론 스레드를 만들고 코드리뷰를 하면서…
마음에 들어 Merge 할 때까지 긴 과정이 소요됩니다.
프로젝트의 Fork 자체는 쉽게 할 수 있습니다.
프로젝트 페이지의 오른쪽 상단 “Fork” 버튼을 클릭하면 됩니다.
이렇게 Fork 한 새 프로젝트의 소유자는
Fork 한 사람 자신이기 때문에 쓰기 권한이 존재합니다.
GitHub Flow
GitHub는 Pull Request가 중심인 협업 워크플로우를 위주로 설계되었습니다.
이 워크플로는 Fork해서 프로젝트에 기여하는 형태인데,
단일 저장소만 사용하는 작은 팀이나
전 세계에서 흩어져서 일하는 회사,
혹은 한 번도 본 적 없는 사람들 사이에서도 유용합니다.
Git 브랜치 에서 설명했던
토픽 브랜치 중심으로 일하는 방식을 차용한 형태입니다.
그래서 보통 어떤 Flow를 따라 일을 할까요?
(1) 프로젝트를 Fork 한다.
(2) master 기반으로 토픽 브랜치를 만든다.
(3) 뭔가 수정해서 커밋한다.
(4) 자신의 GitHub 프로젝트에 브랜치를 Push 한다.
(5) GitHub에 Pull Request를 생성한다.
(6) 토론하면서 그에 따라 계속 커밋한다.
(7) 프로젝트 소유자는 (마음에 들면) Pull Request를 Merge하고 닫는다.
예시
GitHub에 있는 오픈소스 프로젝트에 이 워크플로우를 이용해서
무너가 기여하는 예제를 살펴봅시다.
Pull Request 만들기
Tony는 자신의 Arduino 장치에서 실행해 볼 만한 코드를 찾다가,
GitHub에 있는 https://github.com/schacon/blink 에서 매우 흡족한 프로그램을 찾았습니다.
다 좋았는데, 너무 빠르게 깜빡이는(blink) 게 마음에 안 들었습니다.
매초 깜빡이는 것보다 3초에 한 번 깜빡이는 게 더 좋을 것 같았습니다.
그래서 프로그램을 수정하고 원 프로젝트에 다시 보내기로 했습니다.
이를 위해 우선 앞서 설명했던 것처럼
‘Fork’ 버튼을 클릭해 프로젝트를 복사합니다.
사용자 이름이 ‘tonychacon’ 이라면 https://github.com/tonychacon/blink 에 프로젝트가 복사됩니다.
<https://github.com/><사용자 이름>/<프로젝트 이름>
이 프로젝트는 본인 프로젝트이고, 수정가능합니다.
이 프로젝트를 수정하기 위해,
로컬에 Clone 해서 토픽 브랜치를 만들고
코드를 수정하고 나서 내 GitHub 프로젝트에 다시 Push 합니다.
$ git clone <https://github.com/tonychacon/blink> (1)
Cloning into 'blink'...
$ cd blink
$ git checkout -b slow-blink (2)
Switched to a new branch 'slow-blink'
$ sed -i '' 's/1000/3000/' blink.ino (macOS) (3)
# If you're on a Linux system, do this instead:
# $ sed -i 's/1000/3000/' blink.ino (3)
$ git diff --word-diff (4)
diff --git a/blink.ino b/blink.ino
index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
[-delay(1000);-]{+delay(3000);+} // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
[-delay(1000);-]{+delay(3000);+} // wait for a second
}
$ git commit -a -m 'three seconds is better' (5)
[slow-blink 5ca509d] three seconds is better
1 file changed, 2 insertions(+), 2 deletions(-)
$ git push origin slow-blink (6)
Username for '<https://github.com>': tonychacon
Password for '<https://tonychacon@github.com>':
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To <https://github.com/tonychacon/blink>
* [new branch] slow-blink -> slow-blink
위 과정을 다시 정리해 볼까요?
(1) Fork 한 개인 저장소를 로컬에 Clone 합니다.
(2) 무슨 작업을 하는지 설명 가능한 이름의 토픽 브랜치를 만듭니다(다른 사람이 이해할 수 있게)
(3) 코드를 수정합니다.
(4) 잘 고쳤는지 확인(테스트)합니다.
(5) 토픽 브랜치에 커밋합니다.
(6) GitHub의 개인 저장소에 토픽 브랜치를 Push 합니다.
이후, Fork 한 내 개인 저장소에 가면
GitHub는 토픽 브랜치가 하나 Push 됐다는 것을 알려주고
본래 저장소에 Pull Request를 보낼 수 있는 큰 녹색 버튼을 보여줍니다.
혹은 저장소의 “branch” 페이지(https://github.com/<user>/<project>/branches)로 가서
해당 브랜치의 “New pull request” 버튼을 이용합니다.
녹색 버튼을 클릭하면 Pull Request의 제목과 설명을 입력하는 화면이 보입니다.
이 때 적는 내용은 원래 프로젝트 소유자가 판단을 내릴 수 있을 정도로 공을 들여 작성해야 합니다.
왜 수정했는지, 얼마나 가치 있는지 설명해서 관리자를 설득해야 합니다.
그리고 “ahead” 토픽 브랜치가 master 브랜치에서 달라진 커밋도 보여주고
수정된 내용을 “unified diff” 형식으로 보여줍니다.
이 수정 내용이 프로젝트 관리자가 Merge 할 내용입니다.
화면에 있는 'Create pull request' 버튼을 클릭하면,
프로젝트 원소유자는 누군가 코드를 보냈다는 알림을 받습니다.
그 알림에는 해당 Pull Request에 대한 모든 것을 보여주는 페이지의 링크가 들어 있습니다.
Pull Request는 보통 공개 프로젝트에서 사용합니다.
컨트리뷰터, 즉 기여자는 수정하고 나서 원 저장소에 Pull Request를 엽니다.
개발 초창기에는 프로젝트 내부에서도 많이 사용합니다.
이미 Pull Request를 열어 놓은 토픽 브랜치라고 할지라도, 계속 Push 할 수 있습니다.
마지막이 아니라 처음부터 Pull Request를 열면
여러 주제를 가지고 팀 동료와 함께 토론할 수 있어서 좋습니다.
Pull Request를 보내고 난 이후
프로젝트 소유자는 전송받은 PR(Pull Request)에 대해
변경 점이 무엇인지 확인한 후,
Merge 혹은 거절하거나 코멘트를 달 수 있습니다.
소유자가 아이디어 자체 만을 마음에 들어 한다면(근데 구현은 마음에 들지 않아한다면)
빛을 보기까지 좀 더 공을 들여야 합니다.
프로젝트 소유자는 ‘unified diff’ 형식의 변경사항을 검토하고,
즉각 해당 라인에 코멘트(주석)를 달 수 있습니다.
이렇게 관리자가 코멘트를 달면,
PR을 만든 사람에게 알림이 갑니다.
실제로는 저장소를 “Watch”하는 사람 모두에게 알림이 갑니다.
알림 정책도 설정 가능합니다.
중요한 점은
누구나 Pull Request에 코멘트를 달 수 있다는 점입니다.
위 그림처럼 PR 토론 페이지에서는
프로젝트 소유자가 코드에 코멘트를 달거나
Pull Request 자체에 코멘트를 달면서 토론하는 것을 보여줍니다.
코드 코멘트도 맥락을 이뤄 커뮤니케이션을 할 수 있습니다.
위 예시의 토론을 보고 컨트리뷰터는
무엇을 해야 자신의 코드가 받아 들여질지 알 수 있습니다.
GitHub에서는 해당 토픽 브랜치에 이어서 커밋하고,
Push하면 끝입니다.
(이렇게 PR이 열린 이후 코드를 또 수정하고 커밋하면
예전 코드에 달렸던 코멘트는 아래 최종 PR 페이지에서 보이지 않습니다.
추가된 커밋으로 인해 코드가 수정되었기 때문입니다.)
기존 PR에 이어서 Push를 하면 알림이 가지 않기 때문에,
보통 컨트리뷰터는 자신이 작업한 내용을 코멘트로 남깁니다.
그러면 프로젝트 소유자는 무슨 일이 있었는지 쉽게 알 수 있습니다.
중요한 것
Pull Request의 “File Changed” 탭에서 “unified diff”를 볼 수 있습니다.
이 PR이 main branch에 Merge 되면 어떻게 달라지는지 보여주는 부분입니다.
다음 링크에서 자세히 설명합니다.
Git - 프로젝트 관리하기
위 명령을 실행하면 Patch 파일 내용에 따라 현재 디렉토리의 파일들을 변경한다. 위 명령은 patch -p1 명령과 거의 같다. 하지만, 이 명령이 patch 명령보다 훨씬 더 꼼꼼하게 비교한다. git diff 로 생
git-scm.com
또한 GitHub은 Pull Request가 Merge 될 수 있는지 검사해
서버에서 Merge 할 수 있도록 Merge 버튼을 제공합니다.
이 버튼은 저장소에 쓰기 권한이 있는 사람만 볼 수 있고,
이 버튼으로 Merge 하면 Merge 커밋이 생깁니다(Trivial Merge).
“Fast-forward” Merge가 가능할 때도 “non-Fast-forwrd” 로 Merge 합니다.
(PR의 히스토리를 명확히 보존하기 위해, ff merge가 가능해도 non ff merge를 사용합니다.)
로컬에 Pull Request 브랜치를 당겨와서 Merge 해도 됩니다.
master 브랜치에 Merge 해 GitHub에 Push 하면
자동으로 해당 Pull Request가 닫힙니다.
이런 방식이 바로 대부분의 GitHub 프로젝트가 사용하는 기본 워크플로입니다.
토픽 브랜치를 만들고 Pull Request를 엽니다.
여기서 토론을 계속 하고 그 브랜치에 커밋을 하기도 합니다.
마지막에는 Merge하고 Request를 닫습니다.
Fork는 선택사항이다
Fork는 옵션
한 저장소의 두 브랜치를 두고도 Pull Request를 열 수 있습니다.
한 저장소에 쓰기 권한이 있는 동료 둘이서 어떤 기능을 추가하려고 하고 있다면
보통 토픽 브랜치를 만들고 Push 합니다.
그리고 나서 같은 저장소의 master 브랜치에 대해
Pull Request를 만들어 코드 리뷰와 토론을 시작합니다.
여기서는 이미 쓰기 권한이 존재하기 때문에 Fork를 사용하지 않았습니다.
이처럼 Fork는 필수사항이 아닙니다.
Pull Request 팁
지금까지 GitHub에서 프로젝트에 기여하는 방법 중
가장 기본적인 방법을 살펴보았습니다.
이번 챕터에서는 PR을 사용할 때 도움되는
몇 가지 유용한 팁을 살펴보겠습니다.
완벽하지 않은 Patch를 Pull Request로 보내기
보통 프로젝트에선 PR의 Patch가 완벽하고
꼭 순서대로 적용되어야 한다고 생각할 수 있습니다.
그러나 GitHub의 PR은 어떤 주제를 두고 논의하는 자리이기 때문에,
완벽하지 않아도 됩니다.
PR을 통해 초기부터 프로젝트 관리자와 소통할 수 있도록 해주기 때문에
혼자 답을 찾는 게 아니라 커뮤니티에서 함께 찾을 수 있습니다.
누군가 Pull Request를 열면,
관리자와 커뮤니티는 어떻게 수정하는 게 좋을지 의견을 공유합니다.
의견을 계속 조율하면서 서서히 수정하고,
수정한 만큼만 해당 브랜치에 커밋해 나아가는게 핵심입니다.
최종 PR로 돌아가서 다시 보면,
contributor 커밋을 Rebase 하거나 PR을 다시 열지 않았을 때가 있습니다.
그냥 기존 브랜치에 좀 더 커밋하고 Push 했을 뿐입니다.
나중에 시간이 지나서 이 PR을 다시 읽으면,
왜 이런 방향으로 결정했는지에 대한 맥락을 쉽게 알 수 있습니다.
웹사이트에서 Merge 버튼을 눌러 Merge 하는건
Merge 커밋을 일부러 남기겠다는 뜻이 됩니다.
이 Merge 커밋은 PR 정보를 포함하기 때문에
필요할 때 언제든지 맥락을 확인할 수 있습니다.
Pull Request를 최신으로 업데이트하기
PR을 만든 지 오래됐거나, 깨끗하게 Merge되지 않으면
메인테이너가 쉽게 Merge 할 수 있도록 수정합니다.
좋은 게,
GitHub은 자동으로 Merge할 수 있는 PR인지 아닌지 PR 페이지 하단에서 알려줍니다.
메인테이너가 conflict 를 고치지 않아도 되도록,
스스로 해당 브랜치를 고쳐 녹색으로 만들어야 합니다.
이러한 문제를 해결하는 방식에 일반적으로 두 가지가 존재합니다.
- 대상 브랜치(보통은 master)를 기준으로 Rebase를 하는 방법
- 대상 브랜치를 Pull Request 브랜치에 Merge 하는 방법
GitHub은 원격 저장소이기 때문에, Rebase 하면 히스토리른 깔끔해질 수 있어도
훨씬 어렵고, 에러가 나기 쉽기 때문에 보통 후자를 고릅니다.
Pull Request가 Merge 될 수 있도록 대상 브랜치를 Merge 하려면
먼저 원 저장소를 리모트로 추가합니다.
그리고 나서 Fetch 하고 그 저장소의 대상 브랜치를
해당 토픽 브랜치에 Merge 합니다.
이후 문제를 해결하고 그 브랜치에 도로 Push 합니다.
Conflict를 해결하는 예시
“tonychacon” 예제에 이 워크플로를 적용해봅시다.
원저자가 뭔가 수정을 했는데 Pull Request와 충돌이 나는 이 때부터 살펴봅시다.
$ git remote add upstream <https://github.com/schacon/blink> (1)
$ git fetch upstream (2)
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From <https://github.com/schacon/blink>
* [new branch] master -> upstream/master
$ git merge upstream/master (3)
Auto-merging blink.ino
CONFLICT (content): Merge conflict in blink.ino
Automatic merge failed; fix conflicts and then commit the result.
$ vim blink.ino (4)
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \\
into slower-blink
$ git push origin slow-blink (5)
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To <https://github.com/tonychacon/blink>
ef4725c..3c8d735 slower-blink -> slow-blink
(1) 원 저장소를 “upstream” 이라는 이름의 리모트로 추가한다
(2) 리모트에서 최신 데이터를 Fetch 한다
(3) 대상 브랜치를 토픽 브랜치에 Merge 한다
(4) 충돌을 해결한다
(5) 동일한 토픽 브랜치에 다시 Push 한다
이렇게 하면 Pull Request는 자동으로 업데이트되고,
깨끗하게 Merge 할 수 있는지 다시 확인됩니다.
Git의 구조상 장점에 의한 프로젝트 관리 연속성
Git은 구조상 브랜칭이 쉽고, Merge 하기도 쉽기 때문에
쉽게 무언가를 오랫동안 만들 수 있습니다.
다 마칠 때까지 Merge하고 또 하고 또 할 수 있습니다.
Merge 할 때 발생하는 충돌만 해결하면 됩니다.
이렇게 지속적으로 개발 프로세스를 관리할 수 있습니다.
이미 열린 PR에 대해 Rebase는 금지
브랜치를 깨끗하게 유지하고 싶어서
Rebase를 해야 한다고 생각해도
이미 열어놓은 PR에 대해 Rebase한 걸 Push하면 안됩니다.
그럼 이 브랜치를 가져다가 Merge 해 놓은 사람들은 충격에 빠질 것입니다.
대신에 브랜치를 새로 만들어 Push하는 겁니다.
그리고 PR도 새로 여는데, 원래 PR이 뭔지 알 수 있도록 참조를 달고
원래 PR은 닫습니다.
Pull Request 참조
어떻게 Pull Request를 참조시킬까요? 방법은 매우 많습니다.
GitHub에 쓰기 가능한 곳 어디에서든 참조를 달 수 있습니다.
방법은 다음처럼 많습니다.
- Issue와 Pull Request를 서로 참조시키기
- 커밋의 SHA id 참조하기
- GitHub Flavored Markdown 형식으로 참조시키기
- 이슈, PR 설명, 코멘트, 코드 주석 등에서 사용
Issue와 Pull Request를 서로 참조시키기
모든 Pull Request와 Issue에는 프로젝트 내에서 유일한 번호를 하나 할당받습니다.
고유한 번호인데,
예를 들어 #3인 Pull Request와 #3인 Issue는 동시에 있을 수 없습니다.
이를 #<num> 과 같은 형태로 코멘트나 설명에 적어
Pull Request와 Issue를 참조시킬 수 있습니다.
이 방법은 단일 프로젝트 범위에서만 유효해, Fork 저장소의 Issue나 PR을 참조하려 한다면
<username>#<num> 이라 작성해야 하고,
아예 다른 저장소면 <username>/<repository name>#<num> 이라 작성해야 합니다.
설명을 위해 이미 브랜치를 Rebase 했고,
Pull Request를 새로 만들었다고 해봅시다.
그럼 예전 Pull Request가 뭔지 알 수 있도록 새것에서 예전 것을 참조하게 하고,
같이 Fork한 저장소의 이슈나 아예 다른 저장소의 이슈도 참조하게 해봅시다.
Pull Request의 본문 해석
- 💡 첫 줄
- This PR replaces #2 as a rebased branch instead.
- 이 PR은 #2 PR을 Rebase한 브랜치입니다. (해당 프로젝트의 #2 PR을 참조하고 있습니다.)
- This PR replaces #2 as a rebased branch instead.
- 💡 두 번째 줄
- You should also see tonychacon#1 and of course schacon/kidgloves#2.
- tonychacon#1 과 schacon/kidgloves#2 PR도 봐야 합니다.또한 아예 다른 사람인 schacon의 kidgloves저장소에서 #2 PR을 참조하고 있습니다.)
- (tonychacon 이라는 사용자의 Fork 저장소에서 #1 PR을 참조하고 있습니다.
- You should also see tonychacon#1 and of course schacon/kidgloves#2.
- 💡 세 번째 줄
- Though nothing compares to https://github.com/schacon/kidgloves/issues/1
- schacon의 kidgloves저장소 #1 이슈와는 아무런 연관이 없습니다.
이런 Pull Request를 보내면,
아래처럼 보입니다.
GitHub URL을 전부 입력해도 딱 필요한 만큼으로 줄어듭니다.
그리고 원래 있던 Pull Request를 닫으면,
새 Pull Request에는 기존 Pull Request가 닫혔다고 언급됩니다.
GitHub은 Pull Request 타임라인에 트랙백 이벤트를 자동으로 만듭니다.
그래서 이 Pull Request에 방문하는 사람은 예전 Pull Request가 닫혔는지 알 수 있고,
그 링크가 있어서 바로 클릭해서 예전 것을 볼 수 있습니다.
이 링크는 닫은 Pull Request의 트랙백처럼 생겼습니다.
커밋의 SHA 참조하기
이슈뿐만 아니라,
커밋의 SHA도 참조할 수 있습니다.
40자의 SHA를 적으면, GitHub는 자동으로 해당 커밋에 링크를 걸어줍니다.
Fork 저장소나 아예 다른 저장소의 커밋도 이슈와 동일한 방식으로 링크시킬 수 있습니다.
<user>#<commit id> 나,
<user>/<repository name>#<commit id> 이런 방식입니다.
GitHub Flavored Markdown
다른 이슈를 링크하는 것은 GitHub 글쓰기의 첫걸음에 불과합니다.
“GitHub Flavored Markdown” 이라는 형식으로
이슈나 Pull Request의 설명, 코멘트, 코드 주석 등에서 글을 쓸 수 있습니다.
Markdown 형식으로 글을 쓰면 처음에 그냥 텍스트로 쓴 글이
형식을 갖춰 아름답게 렌더링됩니다.
GFM(Github Flavored Markdown)의 기능 중에서,
Pull Request에 사용하면 좋은 기능을 알아봅시다.
Task list
간단히 말해서, 완료했다고 표시할 수 있는 체크박스의 목록입니다.
이슈나 Pull Request에서 다 했다고 표기하고 싶을 때 사용합니다.
즉, Merge 하기 전에 꼭 처리해야 하는 일의 목록을 표현할 때 사용합니다.
Markdown을 직접 수정하지 않고 체크박스만 클릭해도
해당 태스크가 완료됐다고 업데이트 되기 때문에
상당히 좋은 기능입니다.
태스크 리스트는 아래처럼 사용할 수 있습니다.
- [X] Write the code
- [ ] Write all the tests
- [ ] Document the code
코멘트나 이슈, PR에 사용하면 다음처럼 렌더링 됩니다.
GitHub는 이슈나 PR에 있는 Task list를 집계해서 목록에 보여줍니다.
이를 통해 아래처럼 PR을 여러 개로 쪼개 두면
해당 브랜치가 얼마나 진행됐는지 알기 쉽습니다.
이처럼 Pull Request부터 열어 두고 일을 하면 해당 기능이 얼마나 진행됐는지 쉽게 알 수 있습니다.
Code snippet
코드 조각을 의미합니다.
실제로 구현해서 브랜치에 커밋하기 전에
뭔가 아이디어를 코드로 표현해 볼 때 좋습니다.
단순 코드 예제나 해당 PR에서 구현한 것이 무엇인지 보여줄 때도 사용합니다.
백틱으로 된 “Fence” 안에 코드 조각을 넣습니다.
💡
```java
for(int i=0 ; i < 5; i++)
{
System.out.println(”i is : “ + i);
}
```
코드 조각 최상단에 언어 이름을 쓰면
GitHub은 구문강조(Syntax Highlight)도 해줍니다.
아래 예시는 “[구문강조로 시인성이 좋아진 코드](<https://git-scm.com/book/ko/v2/ch00/_md_code>)” 인데,
이는 언어 이름을 넣어서 구문 강조된 결과입니다.
인용하기
아주 긴 글에서 딱 한 부분만 집어서 논의하고 싶을 때,
> 문자로 해당 부분을 인용하고 그 밑에 코멘트를 달 수 있습니다.
이 방법은 매우 흔히 사용하는 방법이라, 상당히 유용하고, 단축키도 지원합니다.
인용하고 싶은 텍스트를 선택하고 r 키를 누르면 바로 코멘트 상자에 해당 텍스트가 인용됩니다.
> Whether 'tis Nobler in the mind to suffer
> The Slings and Arrows of outrageous Fortune,
How big are these slings and in particular, these arrows?
이는 아래 tonychacon의 코멘트처럼 렌더링 됩니다.
[다음 포스트]
[GitHub] GitHub 프로젝트 관리하기 - 프로젝트 관리자 입장에서
Git - GitHub 프로젝트 관리하기GitHub 계정 없이 Clone 할 수 있기 때문에 공개 프로젝트를 공유할 때는 SSH보다 HTTP URL를 더 많이 공유한다. SSH URL을 사용하려면 계정도 있어야 하고 SSH 키도 GitHub에 등
300-29-1.tistory.com
Ref.
Git - GitHub 프로젝트에 기여하기
과거에는 “Fork” 가 좋은 의미로 쓰이지 않았다. 오픈 소스 프로젝트를 “Fork” 한다는 것은 복사해서 조금은 다른 프로젝트를 만드는 것을 의미했고 때때로 원래 프로젝트와 경쟁하거나 기여
git-scm.com
Git - 계정 만들고 설정하기
6.1 GitHub - 계정 만들고 설정하기 GitHub은 가장 큰 Git 저장소 호스트이다. 수백만 개발자가 모여서 수백만 프로젝트를 수행하는 중추다. Git 저장소를 GitHub에 만들어 운영하는 비율이 높다. 많은 오
git-scm.com
GitHub git — Key Puncher
#3 in a multi-part series on Git.
www.keypuncher.net
'프로젝트 생산성' 카테고리의 다른 글
| [GitHub] 프로젝트 관리자가 여러 명일 때 - Organization 관리하기 (2) | 2024.09.20 |
|---|---|
| [GitHub] GitHub 프로젝트 관리하기 - 프로젝트 관리자 입장에서 (0) | 2024.09.20 |
| [Git] 위험한데, 내 커밋 히스토리가 깔끔해져요! - Rebase (0) | 2024.09.18 |
| [Git] 협업 필수, 원격 브랜치(remote branch) (0) | 2024.09.14 |
| [Git] 버전 관리의 꽃 3, 기본이자 유용한 전략 (0) | 2024.09.14 |