241231 - Git & GitHub의 협업 워크플로우와 심화 학습(branch, merge)

▷ 코드 문제풀이

[SQL] 코드카타 - (21)~(25)

[SQL] 코드카타 - (21)~(25)

[SQL] 코드카타 - (26)~(30)

[SQL] 코드카타 - (26)~(30)

 

 

 

▷ 오늘 배운 것

 

지난 git과 github에 대한 기초 사용방법에 이어 merge와 branch에 대해 배운 것을 정리하고자 한다.

 

241223 - Git과 GitHub 버전 관리 및 협업 기초

241223 - Git과 GitHub 버전 관리 및 협업 기초

---

 

목차

1. branch과 merge에 대하여 

2. github에서의 merge

3. 실제 협업에서의 문제점

4. 실제 협업에서 git과 github 사용과정

5. fork와 collaborator의 차이점

6. .gitignore에 대하여

 

 

---

 

1. branch과 merge에 대하여 

Branch는 협업을 하기위한 도구로, 개발자 각 개인마다 코드를 쓰고 다른 팀원들과 코드를 합치기 위해 복사본을 만들 때 사용된다.

 

- branch 생성 명령어

git branch 브랜치명
git branch

 

- git branch 브랜치명: branch 생성

- git branch: 브랜치 확인 명령어 (*: 현재 branch를 표기) -> 이후 q버튼으로 빠져나올 수 있다.

 

 

- branch 이동 명령어

git switch 브랜치명
git checkout 브랜치명

 

- git switch 브랜치명: branch 이동

- git checkout 브랜치명: branch 이동

 

git switch -c 브랜치명
git checkout -b 브랜치명

- git switch -c 브랜치명: branch 생성 및 이동

- git checkout -b 브랜치명: branch 생성 및 이동

 

 

이후 새로운 branch에서 

git add .

git commit -m "커밋이름"

으로 코드를 수정 및 커밋하면 된다.

 

 

 

- branch merge 명령어

git switch 최종브랜치명(main)
git merge 합칠브랜치명(feature)

 

- git switch 최종브랜치명(main): 위치를 main으로 옮긴다

- git merge 합칠브랜치명(feature): 현재 위치의 branch(main)와 기능을 작성한 branch(feature)을 합친다.

 

 

 

---

 

2. github에서의 merge

그러나 실제 협업에서는 github환경에서 pull reguest(PR)과정을 거쳐 merge를 한다.

 

개인 개발자가 branch를 만들어 기능을 추가했다면 이를 push할 수 있다.

Git push origin 브랜치명(dev)

 

Git push origin 브랜치명(dev): branch에 작성한 코드를 push할 수 있음

 

 

그러면 github에서 pull reguest를 이용해 어떤 기능을 만들어서 올렸는지 설명할 수 있고, 다른 협업개발자(reviewer)들은 이를 확인해 메세지를 남기거나 코드리뷰를 할 수 있다. 이후 협업개발자들의 검토를 마치면 merge 할 수 있다.

 

 

1) branch에 push했을때

 

 

2) pull request 작성

 

 

3) (선택) File changed에서 코드리뷰

 

 

4) 협업개발자에게 승인을 받으면 Merge Full Request

 

 

5) 승인과정을 거치면 merge된 dev branch는 자동으로 close

 

 

merge과정을 마치면 merge된 branch를 내 터미널로 가져와 merge된것을 확인 할 수 있다.

git pull origin main

 

---

 

 

3. 실제 협업에서의 문제점

 

실제 협업에서는 어떤 문제점이 있을까.

 

문제점1) main은 배포용으로 굳어지는 경우가 많아 main으로 merge하려면 완벽하게 기능개발을 해야 merge가 가능하다.

—> 해결방법: main으로 merge하기 전, 기능적용을 확인하기 위해 dev branch를 만든다.

—> 구성 - main(배포용), dev(테스트용), feature(기능개발용)

 

 

문제점2) feature branch에서 개발을 완성했다고, dev와 바로 merge하는 것은 충돌문제로 위험할 수 있다.

—> 해결방법: 로컬로 git pull origin dev을 하여 충돌을 확인한 후 수정 -> 수정한 것을 git push origin feature -> merge

 

 

---

 

 

4. 실제 협업에서 git과 github 사용과정

 

팀장 case 🙋 초기 코드 작성 및 github 업로드 1) 폴더 및 초기 코드 작성 2) Git init  3) Git add . 4) Git commit -m “” 5) GitHub에서 repository 생성 6) Git push origin main 7) 브런치 생성(git branch dev) 8) github에서 dev를 default로 설정(setting >     default branch) 9) 팀원설정 (setting>collaboration)	팀원 case 🙋 Git clone 주소 .: dev branch를 가져옴(dev를 default로 설정했기떄문에 dev를 기본으로 가져오게됨)
⬇️	⬇️
공통 case 👯 1) 각 팀원별 기능 branch를 생성(git switch -c feature) 2) 수정 후 add&commit + git push origin feature 3) 만든 feature branch를 merge하고자 한다면 dev와 충돌이 발생하지 않는지 사전 확인(git pull origin dev) 4) 충돌 수정 후 add&commit + git push origin feature 5) dev와 merge를 위해 full request 요청 6) reviewer설정 7) reviewer들은 file changed를 확인하고 검토&코멘트를 달고 전송 8) merge를 완료하면 git pull origin dev

 

 

 

 

 

---

5. fork와 collaborator의 차이점

Collaborator: 다른 사람의 repository에 push 가능

Fork: 다른 사람의 repository를 복사해서 내 repository로 사용할 수 있음.(다른 사람의 repository에 push도 가능하긴 함)

 

 

6. .gitignore에 대하여

gitignore 파일은 Git에서 특정 파일이나 디렉토리를 추적하지 않도록 설정. 불필요하거나 민감한 파일이 저장소에 추가되는 것을 방지.

• 저장소에 포함될 필요가 없는 임시 파일, 환경별 설정 파일, 출력 결과물 등을 제외.
• 기밀 정보(예: API 키, 데이터베이스 자격 증명)가 포함된 파일 보호.
• 작업 환경에서 생성된 불필요한 파일(예: 캐시, 로그) 방지.
• 특정 IDE나 도구에서 자동 생성된 파일을 무시.

 

 

 

▷ 앞으로

git과 github가 어떻에 협업에 사용되는지 알게된 만큼 자주 사용하면서 연습해야함을 느꼈다.