git & github 기초(2) - github Pull Request, issues, Fork, github.io

728x90

1) github

1-1) Pull Request

1-2) issues

1-3) Fork

1-4) github.io

1) github

1-1) Pull Request

중요 point : 절대 main branch는 건들지 않는다!!

(pull request 진행 순서)
프로젝트를 진행하는 과정에서 git 관리자(main 개발자)가 우선 본인의 local main branch에서 최초 commit(init commit)을

하나 생성(init commit은 예를 들어 최초 작업으로서 index.html을 생성하는 commit으로 보면 됨!!)한 뒤 이를 원격 저장소로

push한다!
그럼 github의 원격 저장소에는 main branch에 init commit이 하나 생성되어 있을 것이다!

이후 git 관리자는 pull을 진행한 뒤에 본인의 main branch는 그대로 둔 상태에서 새로운 branch를 따로 하나 생성하여

거기서 본인이 맡은 기능 작업을 구현하여 commit을 쌓아 나간다!

다른 sub 개발자들의 경우, 앞서 git 관리자가 원격 저장소에 push해놓은 최신 github 내용(init commit이 생성된 버전)을

pull을 써서 각자 본인의 local main branch에 가져온 뒤 그들 모두 branch를 새로 하나씩 만들어 거기서 각자가 맡은 기능 작업을

구현하며 commit을 쌓아 나간다!
그 후 git 관리자와 다른 sub 개발자들 중 본인이 맡은 기능 구현 작업이 마무리된 사람은 상호 공유 중인 github 원격 저장소에

그동안 작업하면서 쌓은 commit이 담겨있는 branch를 push로 보낸다!

그러고나서 바로 merge를 진행하는 것이 아니라 git 관리자가 다른 sub 개발자들이 push한 내용(코드)을 확인한 뒤
내용에 이상이 없으면 그때 git 관리자가 직접 merge를 진행(merge를 허용하는 버튼이

github에 따로 있어 이를 클릭하면 merge가 됨!)하고,
merge가 완료되면 기존의 작업 branch는 삭제하여 원격 저장소에는 main branch만 남겨둠!

(여기서 point는 merge 시점이 누군가 push를 하자마자 바로 진행되는 것이 아니라 프로젝트용 github 원격 저장소를 생성하고

이에 대한 접근 권한을 공유한 git 관리자, 즉 main 개발자가 다른 sub 개발자들이 push한 내용을 보고 이상이 있으면 이를 closed하고,

이상이 없으면 그제서야 merge를 진행하므로 merge 시점을 git 관리자가 조율할 수 있다는 점이다!!)

위와 같이 main branch로 branch를 변경해 pull을 써서 수시로 다른 사람들이 새로 merge한 내용이 없는지 확인할 수 있음!!

1-2) issues

issues : github에서 코드 에러 혹은 이슈를 참여자들(개발자)끼리 공유하는 일종의 커뮤니티같은 공간

프로젝트 진행 시 작업과정에서 문제가 생기면 해당 이슈(문제)를 프로젝트에 참여하고 있는 개발자들과 공유하는
용도로 사용하며, 해당 이슈가 해결되면 "closed"로 표시함!!

(참고) README.md 파일은 github 원격 저장소에 올라가는 순간 원격 저장소에서 해당 README.md 파일을

github 사이트 이용자가 눈으로 볼 수 있도록 화면에 그려줌!!