본문 바로가기
시작/TIL(Today I Learned)

221125 Linux - Github 기능

by 백씨네 2022. 11. 26.

오늘 내가 배운 것

1. Pull Request (PR)

2. fork

3. issues

4. wiki

5. README

 

1. Pull Request (PR)

 

pull requests (PR)

- 절대 main branch는 건들지 않는다.
새로운 작업을 할 때마다 새로운 branch를 생성해서 작업을 하고 깃허브에 새로 작업한 branch를 push 해준다.

 

main이 아닌 다른 branch를 github로 push 하면 코드에 브랜치가 따로 표현이 된다.

 


github에서 merge를 해준다. 자동으로 하는 것이 아니라 버튼을 눌러야한다.
( 자동으로 진행되는 것이 아니기 때문에 다른 사람의 브랜치를 확인을 할 수 있다.) 
그리고 머지했던 브랜치를 지워준다. 

 

1. push 후에 github 홈페이지에 이렇게 뜬다 2. push 한 내용에대해 적어준다.
1,2 사진 머지 진행 / 3번 사진 branch delete



브랜치를 커밋했을 때 브랜치가 넘어오자마자 바로 머지가 되는 것이 아니기 때문에 머지 전에 팀끼리 코드 리뷰를 하던가 취소하여 수정사항이 있을 경우 본인의 로컬에서 수정하고 다시 올릴 수 있다.

 

 

 

(우형 기술 블로그에 있는 git-flow를 참고하여 만들어 보았고, 작업을 하면서 같은 브랜치의 커밋이 많았다면, squash를 하는 방법도 알게 되었다.)

 

github에 공유되어 있던 main을 pull로 받았다면 내 로컬 저장소의 main이 원격 저장소의 main 보다 낮은 위치에 있기 때문에 merge로 맨 위에 커밋으로 main이 올라가야 한다.

 

 

 

2. fork

오픈 소스에 기여하기 순서도

fork


특정한 사람만 머지를 하고 싶을 때, 같은 팀이 아닌 다른 사람의 github를 보고 의견을 내고 싶을 때 사용할 수 있는 기능이다. 

fork : 타인의 github 원격 저장소에 있는 내용을 내 원격 저장소로 가져오고 싶을 때 사용한다.

 


 오픈소스에 기여하기


타깃 프로젝트를 fork로 내 원격 저장소에 저장한 후 내 깃허브의 원격 저장소를 로컬 저장소로 복사하고 원하는 작업을 한 뒤에 PR로 수정사항에 대한 merge를 요청한다. 원격 저장소의 소유자가 원하는 코드에 대해서 만 승인하여 merge 할 수 있고, 재수정을 요청(반려) 시킬 수 있다.

 

 

 

3. issues

 

이슈는 프로젝트를 진행하면서 생기는 버그 수정, 새로운 추가될 기능, 개선해야 하는 기능 등 모든 활동 내역에 대해 이슈를 등록하고 그 이슈를 처리하는 방식으로 작업을 진행한다. 
이슈를 만들면 이슈를 열었다(open)라고 하고, 작업이 끝나 이슈를 정리하면 이슈를 닫았다(close)라고 말한다. 이렇게 이슈가 생긴 부분에 대해 흔적을 남기고 그 이슈를 처리했는지도 확인할 수 있다.

 

4. wiki

 

위키는 프로젝트를 진행하면서 생기는 문서작업을 할 수 있는 곳이다.
프로젝트에 대한 설명을 추가할 수 있다. README는 프로젝트의 소개 같은 느낌이라면 wiki는 설명서 같은 느낌이다.

 

5. README

 

 

Read me에는 어떤 프로젝트인지, 기술 스택, 팀원 소개 등 이 프로젝트에 대한 내용을 소개하거나 요약해서 중요한 부분을 볼 수 있도록 쓰인 것이다. 해당 프로젝트의 버전, 이전 버전과 변경사항들, 등을 작성하여 이용자들이 특이 사항들을 바로 알 수 있다.

요약하여 한눈에 볼 수 있게 만들기 때문에 나중에 내가 만든 프로젝트를 하나하나 다 기억 못 해도 이걸 보면 바로 어떤 내용의 프로젝트였는지 다시 떠올릴 수 있게 하는 일기장 같은 느낌의 역할도 할 수 있다.

README문서가 있다면 원격 저장소 메인에 그 내용이 보인다.

 

 

댓글