핵심 쏙속 Git 3

PR - 제 작업을 반영해주시겠어요? (1)

PR(Pull Request, 풀리퀘스트)이란 경우에 따라 작업한 내용을 리뷰하고 프로젝트에 최종적으로 반영하는데 이때 작업한 내용을 리뷰, 검토하는 것을 의미한다.

즉, 작업 내용을 바로 merge하지 않고 이 branch를 merge해도 될까요? 하고 요청을 먼저 보내는 것입니다.

실전에서는 다음과 같이 사용합니다.

• (오픈소스에서) 프로젝트 제안 사항이 있으면 PR 날려주세요
• (회사에서) 00씨, PR 날려주세요. 코드 리뷰해드릴께요

그러면 예시를 보겠습니다.

소스트리로 본 commit의 상태

github에서 본 jjim 브랜치

jjim 브랜치를 메인에 merge하려고 합니다. github을 보니 위에 This branch is 1 commit ~~ 라고 하며 현재 브랜치가 메인보다 하나 앞서있다고 합니다.

여기서 주의할 것은 위 소스트리의 그래프를 보면 main이 jjim보다 2개 커밋이 앞서있다고 생각할 수 있습니다. 그러나 main은 로컬 repo이며 github은 원격 repo이기 때문에 origin/mian을 봐야합니다. 이를 헷갈릴 수 있으니 주의하길 바랍니다.

 

이제 여기서 Pull Request를 하기 위해서 github 사진에서 Contribute을 클릭해 Open pull request를 클릭하면 다음과 같이 화면이 바뀌게 됩니다.

해당 브랜치를 다른 브랜치에 merge할텐데 PR을 해달라고 할 수 있게 되는 겁니다. 그러면서 PR의 내용을 작성합니다.

PR마다 양식이 있기 때문에 그에 맞춰서 PR 내용을 맞춰주면 됩니다.

다 작성했으면 Create pull request를 눌러 PR을 완성합니다.

완성된 PR 모습

이렇게 만들었으면 사람들이 검토한 다음 아래 댓글에 의견을 적어 내용을 검토합니다.

이후 내용을 추가하면 그림에서 보이는 branch에 추가가 되면서 진행된 commit 내역을 확인할 수 있습니다. 즉, 브랜치 단위로 PR한다는 것을 기억하면 되겠습니다.

검토를 끝마쳤으면 merge pull request를 눌러 commit할 때처럼 제목과 내역을 적고 merge하면 타 branch에 merge 됩니다.

그러면 PR이 역할을 마쳤음으로 자동으로 close 됩니다. 이후 delete branch하여 branch까지 삭제합니다.

지금까지 한 내용을 정리해보겠습니다.

B브랜치를 main 브랜치에 merge하기 전에 원격 repo에서 B브랜치를 merge해도 되는지 PR(Pull Request)를 해서 문제가 없으면 merge해도 상관이 없습니다.

그러나 코드를 보완한다면 로컬 repo의 브랜치에서 작업을 한 다음에 원격 repo 브랜치에 다시 push를 합니다. 그러면 원격 repo 깃헙의 PR 페이지에서는 다음과 같이 나타납니다.

PR 후 올린 파일이 내역에 나타난 모습

A가 제시한 의견을 받아들여 파일을 수정해 올렸더니 PR에 수정된 파일이 커밋되었음을 알려주고 있는 것을 확인할 수 있다.

 

 

PR - 제 작업을 반영해주시겠어요? (2)

내 작업을 반영하는데 다른 repo에 PR날릴 때 fork(포크, 일종의 프로젝트 복사)가 필요합니다. 이는 내가 관리자가 아니여서 곧바로 repo에 push가 되지 않기 때문입니다. 또한 merge할 권한이 없음으로 PR을 반영하려면 상대방이 직접해야 합니다.

v로 갈라진 브랜치 아이콘이 fork됐음을 알려준다.

이렇게 포크한 repo를 내 컴퓨터에 클론한 다음 브랜치를 만들어 작업 후 push를 하고 PR을 날립니다. 그러면 상대방이 내가 보낸 PR을 보고 반영할지 말지 결정합니다.

 

그럼 정리해보겠습니다.

fork는 타인의 원격 repo를 복사해 가져오는 것을 의미합니다. 이는 타인의 repo에 PR하기 위함입니다.

이렇게 가져온 repo를 pull로 로컬 repo에 저장한 다음 브랜치를 만들어 작업하고 로컬 repo에 커밋 후 원격 repo에 push하여 타인에게 PR을 보내 fork한 목적을 달성합니다.

 

 

amend - 최신 commit 고치기

작업을 하다보면 실수, 잘못해서 commit을 할 수 있습니다. 그럴 경우 commit을 되돌릴 수 있습니다. 그러나 다른 누군가가 되돌리기 전의 commit으로 작업했다면 나중에 그 사람의 히스토리가 꼬여버릴 수 있습니다. 그러면 큰 문제가 되겠죠.

그래서 나만 작성하는 특정 브랜치에만 적용해야 합니다.

amend는 가장 최신의 commit을 고칠 수 있습니다. 이전에 있던 다른 commit들은 고칠 수 없습니다.

예를 들어보겠습니다.

1. A와 B를 커밋해야 하는데 A만 커밋한 경우 amend 커밋을 이용하며 B도 함께 커밋할 수 있습니다.

2. A를 커밋했는데 세부 내용을 잘못쓴 경우 amend 커밋을 통해 변경된 내용을 다시 커밋할 수 있습니다.

 

이제 commit 후 push까지 해버린 경우 수정하는 방법에 대해 알아보겠습니다.

이 경우에는 강제 푸시를 사용해야 합니다. 권장하는 방법이 아니기에 기본 설정에서 강제 푸시를 할 수 없고 따로 설정을 해주어야 합니다.

강제 푸시를 하게 되면 원격 repo의 내용을 바꿀 수 있기 때문에 강력하지만 팀원의 작업에 영향을 끼칠 수 있기 때문에 반드시 자신만 사용하는 브랜치에서 사용해야 한다.

 

* 문제 발생 및 해결 *

나는 그동안 소스트리를 사용하는데 문제가 있었다. 토큰 문제였는데 이 때문에 소스트리로 push를 할 수 없어서 깃 데스크탑을 이용해서 작업했다. 그러나 강제 푸시를 깃 데스크탑에서 하는 방법을 찾지 못해서 결국 소스트리의 토큰 문제를 해결하기로 결정했고 3시간의 사투 끝에 방법을 찾아내었다.

아래 블로그의 내용이 내 경우와 완전 같은 경우였고 해결법도 친절히 나와있어서 문제를 해결할 수 있었다.

https://pyoungt.tistory.com/172

 

깃 데스크 탑에서는 amend와 비슷하게 Undo를 사용할 수 있다.

 

 

revert, resert - commmit 관리 한 걸음 더

revert, resert는 가장 최신 커밋이 아니더라도 변경할 수 있습니다.

 

revert는 사람들에게 되돌렸다는 사실을 기록으로 남기면서 되돌립니다.

reset은 commit했던 작업내역을 말 그대로 리셋시킵니다. 리셋이후의 내역이 사라지게 됩니다. 그래서 신중하게 사용해야 합니다. reset은 세 가지 모드가 있습니다.

• soft(소프트)
• mixed(믹스드)
• hard(하드)

 

소스트리에서 commit하기 전의 commit에 마우스 우클릭을 하여 '이 커밋을 현재 브랜치까지 초기화'를 클릭하면 세 가지 모드를 선택할 수 있습니다. 그 중 (믹스드, mixed)를 해보겠습니다.

mixed를 선택하면 앞의 커밋들이 사라지게 됩니다. 단, mixed를 하면 작업 내역까지 사라지지 않습니다. 즉, mixed를 하면 커밋내역만 사라질 뿐 작업 내역은 남습니다.

예를 들면 a, b, c를 순서대로 커밋한 뒤 a에 mixed를 하면 b, c에 했던 커밋이 사라지고 작업내용도 사라지면서 a를 커밋했을 때의 상황으로 되돌아갑니다. 그러나 b, c의 작업 내역은 남아있습니다.

이번에는 hard를 해보겠습니다. hard를 하면 커밋이 사라지고 작업 내역도 사라집니다.

이처럼 reset은 위험한 작업입니다. 그렇기 때문에 사용할 때는 이를 인지하고 사용해야 합니다.

 

 

stash - 변경사항 임시 보관하기

stash(스태시)는 변경사항을 임시적으로 보관해둘 때 사용합니다.

예를 들어 작업한 branch에서 다른 branch로 이동하면 변경사항이 사라지게 됩니다. 이를 막기 위해서는 commit 대신 stash를 사용합니다.

스태시를 클릭한다.

작업 내역을 임시 보관하기 위해 스태시를 클릭해 이름을 붙여 저장한다. 그리고 나서 파일을 열어 확인하면 작업내역이 없는데 사라진 것이 아니라 임시로 보관하고 있어 안보이는 것이다.

이후 다른 브랜치에 체크아웃하고 나서 다른 작업을 하고 난 뒤 돌아와서 임시 보관한 작업을 가져오고 싶다면 왼쪽 아래에 있는 스태시를 눌러 임시 보관된 작업을 눌러 다시 가져오면 된다. 그리고 나서 임시 보관된 작업을 실수로 가져오지 않게 삭제한다.

예외적인 상황이 존재합니다. 바로 커밋 한 적이 없는 파일은 git이 추적하지 않고 있기 때문에 다른 브랜치로 체크아웃해도 보입니다. 즉, 커밋 한 적 없는 파일은 스태시 할 필요가 없습니다.

⚠ stash는 변경사항을 여러 번 임시 저장 할 수 있어서 잘못했다간 다른 파일을 가져오고 최신 파일을 삭제해버릴 수 있습니다.

그렇기 때문에 내가 어떤 변경사항 stash를 저장했는지 파악하고 파일을 불러와서 작업하는 습관을 들이면 좋습니다.

 

* 실험으로 알아본 revert *

1. 이전의 커밋을 revert하면 그 커밋만 revert되고 그 커밋보다 앞서있던 내용은 그대로이다.
2. 같은 파일을 여러번 수정했을 경우 (ex.2번 다 같은 파일 수정인 경우) merge conflit가 발생한다.

 

 

작업으로 의사소통하기

이번에는 프로젝트 관리 기본 매너들에 대해 알아보겠습니다.

커밋 메세지도 작성하는 규칙이 있습니다. 이를 커밋 메세지 컨벤션이라고 합니다. 이는 서로 조직에서 합의한 규칙입니다. 그렇기 때문에 이에 따라 커밋 메세지를 작성해야 합니다.

다음 주소를 참고하면 도움이 될 것입니다.(영문을 번역한거라 한글과 맞지 않는 부분이 있을 수 있습니다)

https://meetup.toast.com/posts/106

좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 : NHN Cloud Meetup

또한 커밋의 단위도 중요합니다. 적게 하면 너무 많은 내용이 커밋 메세지에 들어가야 하고 자주하면 너무 많아서 문제가 됩니다. 그래서 커밋 단위를 적절하게 끊어서 해줘야 합니다.

예를 들면 메뉴바를 개발하고 커밋, 로그인 기능을 개발하고 커밋 등이 있습니다.

 

좋은 커밋 메세지, 단위로 작성하면

1. 어떤 작업을 했는지 커밋 히스토리만 보고 알 수 있습니다.
2. 버그를 찾을 때, 코드를 고치기 쉽습니다.
3. 다른 사람이 코드 리뷰할 때 편합니다.

 

의사소통을 위한 것이기 때문에 규칙은 프로젝트마다 달라질 수 있습니다. 관심있는 프로젝트에서 어떤 스타일로 커밋 메세지를 작성하는지 살펴보세요.

 

커밋 메세지 템플릿이 있습니다. 이를 이용해서 간단하게 정보를 전달할 수 있습니다.

키워드 - 기능, 단위 #issue번호 (기능, 단위는 commit 단위)

변경사항 : 

# 키워드: 생성, 수정, 추가,고치기,문서화,스타일, 테스트 (위 키워드 대신 들어갈 수 있는 것들)
# "왜", "무엇"을 포함하기 
# 제목은 80자 이내로, 긴 내용은 줄바꿈하고 본문에서

 

 

코드리뷰로 서로에게 피드백 주기

코드리뷰란 누군가 한 코드로 리뷰를 하는 것이다. (ex. 이거 개선하면 어떨까요?)

보통 PR 후 코드리뷰가 이뤄집니다.

코드리뷰를 하는 이유!

• 코드의 품질을 높일 수 있다!
• 다른 사람의 눈으로 버그를 빠르게 발견할 수 있다!
• 서로의 지식을 나누면서, 더 나은 방법을 찾아낼 수 있습니다.

→ 내가 만든 코드가 아니라 팀의 코드의 품질을 높인다! (리뷰과정을 거치면서 팀의 코드가 된다!)

구글의 코드리뷰 가이드 한글(비공식)

https://soojin.ro/review/

Review · Soojin Ro

 

또한 회사의 기술 블로그에는 우리가 어떤 방식으로 코드 리뷰를 하고 있는지 작성하고 있습니다. 조직마다 코드리뷰 스타일, 분위기가 다릅니다.  궁금하시면  구글에 코드리뷰를 검색하고 살펴볼 수 있습니다.

 

 

gitignore - Git 프로젝트 관리

보안상 다른 사람과 공유하면 안되는 내용(비밀번호, API key 등)들은 모두에게 공개할 수 없습니다. 공개 Github repo에 올라가면 곤란하겠죠. Git에서 이런 파일들을 없는 것처럼 무시하게 하는 설정이 바로 .gitignore입니다.

메모장을 열어 파일명을 .gitignore 로 만들고 여기에 Git이 무시해야할 파일 또는 폴더이름을 적어주면 됩니다. 그리고 나서 내 프로젝트의 최상위 폴더에 저장하면 됩니다.

그리고 git이 무시할 파일명을 .gitignore에 적어주면 소스트리에 보이질 않습니다.

test 파일이 .gitignore에 적혀서 소스트리 항목에 보이질 않는다

 

웹 기술, 사용하는 언어마다 .gitignore 세팅이 다릅니다. 이것을 다음 주소에서 참고해서 작성하세요

https://gitignore.io

gitignore.io

 

 

README - Git 프로젝트 관리

프로젝트를 소개하는 내용이 들어간 파일을 README.md라고 합니다. 파일 전부를 하나하나 살펴볼 수 없으니 설명서처럼 적어두는 겁니다. (md는 마크다운(amrkdown)의 약자입니다)

다음 주소에서 README를 어떻게 써야하는지 알 수 있습니다.

https://github.com/ohahohah/readme-template

GitHub - ohahohah/readme-template: Fork from README.md template for your open-source project

 

위의 주소에 있는 README.md 양식을 가져오고 싶으면 깃헙에서 파일을 클릭하고 raw를 누르면 파일의 코드를 보여줍니다.

 

README.md는 서식이 적용될 수 있게 markdown이라는 형식의 파일로 작성합니다.

간단하게 마크다운 문법에 대해 알아보겠습니다..

# 제일 크게 - heading1
## 그 다음 크게 - heading 2
### 그 다음 크게 - heading 3

* 글머리기호(bullet point)
  * 앞에 두 칸 띄고 적으면 한 탭 들어간 글머리 기호

1. 순서를 줄 수도 있어요.
2. 두번째
3. 세번째!

**굵은 글씨(문자열 앞 뒤로 빈 칸이 없어야함)**
*이탤릭채(문자열 앞 뒤로 빈 칸이 없어야함, 기울어진 글꼴)*

```python
# 코드 조각
print("Hello World")
```
[네이버로 연결](https://naver.com)

위의 문법을 적용한 모습

 

마크다운 문법을 어떻게 사용하는지 연습할 수 있는 사이트가 있습니다. 이것을 참고해도 됩니다.

Markdown Tutorial

 

 

Github에서 정보 얻기 - 개발자의 SNS

깃헙에서는 다음과 같은 정보들을 얻을 수 있습니다.

• 유저의 정보 파악(깃헙 활동을 많이 하는 분들을 찾아서 그들의 repo를 보고 정보를 파악할 수 있다)
• 유저가 한 프로젝트 탐색
• 기술 트렌드 파악하는 법 (깃헙에서 explore을 눌러서 topic, trending 등에서 파악할 수 있다)

 

 

오픈 소스 - 다른 프로젝트에 참여하기

오픈 소스란 누구나 프로젝트를 사용하고, 수정하고, 배포할 수 있는 프로젝트를 의미합니다. (단, 라이선스를  따라줘야 합니다. 라이선스에 대한 자세한 정보는 https://www.olis.or.kr/license/compareGuide.do 를 참고하시길 바랍니다. )

오픈 소스의 이러한 특징 덕분에 많은 사람들이 프로젝트에 기여하면서 발전시킬 수 있습니다. 

기여의 범위는 넓습니다.

버그리포트하는 issue에 해결 답변 달기, 오타나 서식 수정 및 문서 작성에 참여, 번역하기, 버그 코드 수정 등등.. 다양합니다. 오픈소스 기여에 대해 좀 더 자세히 알고 싶다면 다음 페이지를 참고해주세요

https://opensource.guide/ko/how-to-contribute/

오픈소스에 기여하는 방법

 

그래도 오픈 소스에 참여하는 것이 어려워보인다면 sprint(스프린트)에 참여해보는 것도 좋습니다. 오늘은 전 세계적으로 우리 프로젝트에 기여하는 날!하고 행사를 여는데 이걸 스프린트라고 합니다. 한국에서는 '스프린트 서울' '파이콘 한국 스프린트' '오픈소스 컨트리뷰톤' 등이 정기적으로 열리니 관심을 가져보는 것도 좋습니다.

기여에 도전할 수 있는 프로젝트들

1. 첫 도전에 친화적인 프로젝트들

https://github.com/showcases/great-for-new-contributors

Great for new contributors

2. 헥토버페스트

https://hacktoberfest.digitalocean.com/

Hacktoberfest '21

3. 파이콘 

http://blog.pycon.kr/2017/07/11/tutorial-and-sprint/

파이콘 한국 2017을 즐기는 방법: 02. 스프린트 튜토리얼의 대장이 되어보자.

4. 스프린트 서울

https://sprintseoul.org/

SprintSeoul - Go further together

 

 

오픈소스 이해에 도움이 될만한 책 추천: 성당과 시장 (https://www.hanbit.co.kr/store/books/look.php?p_code=E8095481781)

팁: 데이터분석에 도움되는 커뮤니티로 판다스가 있는데 초심자 친화적이라 오픈 소스에 기여할 기회가 있을 겁니다. 깃헙에서 검색해서 찾아가보세요!

 

 

Github으로 나를 드러내자

깃헙에서 repo를 만들 때 내 깃헙 아이디로 만들면 나의 프로필이 담긴 repo를 만들 수 있습니다. 거기에 적은 README.md는 나의 프로필에서 크고 먼저 보여줍니다.

 

내가 작업했던 repo를 선택해서 메인에서 보여줄 수 있습니다.

Customize your pins를 클릭하여 내 repo 중에서 선택하여 다른 사람들에게 보여줄 수 있습니다.

 

그리고 깃헙으로 포트폴리오도 작성할 수 있습니다.

깃헙 닉네임.github.io 형식으로 repo에 이름을 붙입니다. 그리고 readme 파일과 license도 추가하고 mit 라이선스를 사용해서 만듭니다.

그러면 repo가 만들어지고 setting에서 pages를 누르면 깃헙 페이지 주소가 나오게 됩니다.

그리고 아래의 change theme을 누르면 페이지의 배경을 설정할 수 있습니다.

이걸로 배경 설정

적용된 모습

 

 

* 요약 *

• PR
    브랜치에서 작업한 것을 메인 브랜치로 merge하기 전에 검토 및 개선하기 위해서 사용. branch 단위로 적용됩니다.
• fork
    타인의 브랜치에 pr을 날릴 때 사용하는 방법으로 타인의 repo를 복사하는 것을 fork라고 합니다. 이렇게 fork한 다음 클론으로 내려받아 작업 후 다시 push합니다. 이후 자신이 만든 branch를 상대의 branch에 merge해도 되는지 pr을 날립니다. 우리에겐 merge 할 권한이 없음으로 상대가 결정합니다.

 

커밋 수정 방법 (자신만 사용하는 브랜치에서 사용하기로 합니다. 타인과 같이 있으면 작업이 꼬일 수 있습니다)

• amend
    최근 커밋한 내역을 수정할 수 있습니다. 강제 푸시를 이용하면 원격 repo도 수정할 수 있습니다. 
• revert
    최근 뿐만 아니라 과거의 커밋 내용도 수정할 수 있습니다. 작업 내역이 남아있지 않습니다. revert한 내용이 커밋에 남습니다. 되돌릴 파일의 커밋이 후에 또다른 것으로 커밋되었다면 충돌이 일어납니다. 즉, 중복된 커밋된 파일은 최신 커밋만 revert 됩니다.
• reset
   - mixed
      커밋을 지워버립니다. 커밋에 reset한 내용이 남지 않습니다. 앞서 작업한 내용은 살아있습니다.
   - hard
      커밋을 지워버립니다. 커밋에 reset한 내용이 남지 않습니다. 앞서 작업한 내용도 사라집니다.
• 스태시
    작업한 브랜치에서 다른 브랜치로 체크아웃할 때 작업한 내용을 임시저장합니다.

 

• 커밋 메세지는 좋은 내용,단위를 가질수록 작업 내용을 알 수 있고 버그를 찾았을 때 코드를 고치기 쉬우며 다른 사람이 코드 리뷰할 때 편합니다.
• 코드 리뷰로 코드의 품질을 높이고 버그를 빠르게 발견하고더 나은 방법을 찾을 수 있습니다.
• 보안상 다른 사람과 공유하면 안되는 내용을 숨기기 위해 .gitignore을 사용합니다.
• README.md 는 프로젝트를 소개하는 내용이 들어갑니다. 양식에 맞게 마크다운 문법으로 작성하면 됩니다.
• 깃헙에서는 유저의 정보, 유저의 프로젝트, 기술 트렌드를 얻을 수 있습니다.
• 오픈 소스란 누구나 프로젝트를 사용하고, 수정하고, 배포할 수 있는 프로젝트