2023.10.24.<협업을 위한 Github>_Pull request, dev branch

1. 깃허브와 브랜치

 

먼저 깃허브를 왜 쓰는지에 대해 생각을 해보자.

만약 레포트를 쓴다고 가정할때 최종.docx / 찐최종.docx 이렇게 파일을 만든 경험이 있을 것이다.

이렇게 계속 하나하나 추가하는 것은 설계쟁이 일때는 비일비재한 일이였지만 개발에 있어서는 비효율적인 방법이다.

 

먼저 브랜치에 대한 기본적인 명령어로는

1. 브랜치 생성 : git branch 브랜치명
2. 브랜치 이동 : git switch 브랜치명 or git checkout 브랜치명
3. 둘을 한번에 : git switch -c 브랜치명 or git checkout -b 브랜치명
4. 브랜치 합치기 : git merge 합칠 브랜치명 (만약 login → main 합치고 싶다면 login으로 와서 해야한다)

 

2. Pull requset

 

현업에서는 앞서 알고있던 것처럼 터미널을 통해 올리기보단 Pull Request를 활용하여 올린다.

쉽게말해 github홈페이지에서 직접 합친다. 왜? 코드리뷰가 가능하기 때문에

 

만약 login 브랜치와 main(배포용) 브랜치가 있다고 가정했을 경우,

1. 수정 후 login branch에서 에커를 한다(git add. → git commit -m "메세지")

2. git push origin 브랜치명

3. gitHub 홈페이지로 이동해  Compare &Pull request 클릭

4. Pull request 메세지 입력 후 Create pull request 클릭

5. 이곳에서 코드 변경점, 커밋메세지 등을 확인할 수 있다.

6. 이상이 없다면 Merge pull request 를 클릭해 코드 합치기

7. 문제가 없다면 Pull reuqest seccessfully  merged and closed

7. 로컬 내에서는 아직 반영이 되지 않았기에 git pull origin main으로 최신화 시켜준다.

 

3. 실제 협업에 있어서

정말 협업할 때는 어떻게 사용하는가?

이렇게 Main 브랜치와 기능 브랜치 사이에 테스트용으로 develop 브랜치를 하나 새로 만든다.

만약 프로젝트를 하는데 내가

 

팀장이라면

1. 초기 코드 작성 및 github 업로드

1.  폴더 생성
2. 초기코드 작성
3. git init, 에커
4. Github 레포지토리 생성
5. Github 업로드(gIt push)

2. dev 브랜치 생성

1. git switch -c dev(로컬)
2. git push origin dev(Github)
3. 실수할 수 있으니 dev 브랜치를 default로 설정해주기(미리 대비해서 나쁠거 없다)
4. 팀원 등록(collaborator)

팀원이라면 앞선 과정들을 팀장이 한 이후에

1. 폴더 생성 후 git clone 하기
2. < 2. Pull request>의 과정 따라하기

 

3. 센스쟁이 되는 법..

예를 들어 login 기능을 구현한다고 가정했을 경우 branch를 새로 만들 때

git switch -c feature/signup

이렇게 feature/기능 이런식으로 만들기

이후에 Pull request 생성하고 merge 후에  reviewers에서 리뷰어 추가해서 리뷰 받기