# 관련링크 - [재생목록](https://www.youtube.com/playlist?list=PLE0hRBClSk5JCC6R5w_wAt8_GC67h3eAM) - [GIT 인터렉티브 - https://learngitbranching.js.org/?locale=ko](https://learngitbranching.js.org/?locale=ko) - [몰입코딩 - 팁/기술 - slog.gg/p/13836 - 5강](https://slog.gg/p/13836#5강) - GITHUB PROJECT 도입 없이 리포지터리의 이슈게시판만으로 할일을 관리하는 방법 - [몰입코딩 - 팁/기술 - slog.gg/p/13836 - 6강](https://slog.gg/p/13836#6강) - GITHUB PROJECT 도입하여 리포지터리의 이슈게시판만에 접속하지 않고도 이슈 칸반 스타일로 관리하는 방법 # 명령어 - git log --oneline --all --graph - git config --global init.defaultBranch main - git branch --all # 1강 - [25 01 15, p 13988, 1강, GITHUB FLOW 수업 시작합니다.](https://youtu.be/NVXnCwcpdB0) ## GIT FLOW ![img, 출처 : https://quangnguyennd.medium.com/git-flow-vs-github-flow-620c922b2cbd](https://i.imgur.com/glX3oUC.png) ## GITHUB FLOW ![img, 출처 : https://quangnguyennd.medium.com/git-flow-vs-github-flow-620c922b2cbd](https://i.imgur.com/IFaWwOu.png) ## GIT FLOW vs GITHUB FLOW | 구분 | GIT FLOW | GITHUB FLOW | | -- | -- | -- | | 브랜치 전략 | 복잡함(main, develop, feature, release, hotfix) | 단순함(main, feature) | | 적합한 분야 | 버전 관리가 필요한 패키지/앱 | 지속적 배포가 필요한 웹 서비스 | | 배포 주기 | 길다(주 단위, 월 단위) | 짧다(일 단위, 시간 단위) | | 장점 | 체계적인 버전 관리 가능 | 빠른 배포와 피드백 가능 | | 단점 | 프로세스가 복잡하고 느림 | 안정성이 떨어지지만 자동화 테스트로 극복가능 | # 2강 - [25 01 15, p 13988, 2강, GITHUB FLOW 예시](https://youtu.be/_HtR8Yl9R1I) ## 명령어 설명 - `git pull origin main` : 현재 내가 작업하고 있는 로컬 브랜치에 리모트(origin)의 main 브랜치 내용을 가져와서 적용한다.(병합방법 : merge) - `git pull origin main --rebase` : 현재 내가 작업하고 있는 로컬 브랜치에 리모트(origin)의 main 브랜치 내용을 가져와서 적용한다.(병합방법 : rebase) ## git pull origin main 의 내부적인 작동방식 - git pull origin main 은 내부적으로 아래의 2개의 명령이 순차적으로 실행되는 것과 같다. - git fetch origin main - 리모트(origin)의 main 브랜치의 내용을 로컬로 가져온다. - git merge FETCH_HEAD - 가져온 내용을 현재 브랜치에 병합한다. - FETCH_HEAD란 가장 최근에 fetch 명령으로 가져온 브랜치의 최신 커밋을 가리키는 참조입니다. git fetch 명령을 실행하면 원격 저장소의 데이터를 로컬로 가져오고, 이 데이터의 최신 커밋이 FETCH_HEAD에 기록됩니다. ## `git pull origin main` 와 `git push origin main` 의 적용대상 차이 | 구분 | git pull origin main | git push origin main | | -- | -- | -- | | 적용대상 | 로컬의 현재 브랜치에 리모트의 main 브랜치를 적용 | 로컬의 main 브랜치를 리모트의 main 브랜치에 적용 | | 예시 | (b1) git pull origin main
- b1 브랜치에 리모트의 main 브랜치 내용이 적용됨 | (b1) git push origin main
- 로컬의 main 브랜치가 리모트의 main 브랜치에 적용됨
- 현재 브랜치가 b1이어도 main 브랜치가 push 됨 | ## `git pull origin main` vs `git pull origin main --rebase` 비교 표 | 구분 | git pull origin main | git pull origin main --rebase | | -- | -- | -- | | 병합 방식 | merge | rebase | | 커밋 히스토리 | 병합 커밋이 생성되어 복잡해짐 | 깔끔한 일자형 커밋 히스토리 | | 충돌 해결 | 한 번에 모든 충돌 해결 | 커밋별로 순차적 충돌 해결 | | 장점 | 이력이 보존됨 | 깔끔한 이력 관리 가능 | | 단점 | 이력이 복잡해짐 | 이력이 변경됨 | | 권장 상황 | 팀원간 동일 파일 작업이 적을 때 | 팀원간 동일 파일 작업이 많을 때 | ## GITHUB FLOW 예시 | 작업순서 | 프로젝트 매니저 | 개발자 1 | | -- | -- | -- | | 1 | 리포 생성
readme.md 생성
main 브랜치에 PR 룰 걸기 | | | 2 | `개발자 1`을 협력자로 초대 | | | 3 | | 초대수락 | | 4 | 이슈생성
번호 : 1번
라벨 : enhancement
양수인 : `개발자 1` | | | 5 | | 1번 이슈 확인
or
양수인 없는 이슈를 직접 양수 | | 6 | | git clone 깃헙주소 .
or
(main) git pull origin main | | 7 | | (main) git checkout -b enhancement/1 | | 8 | | (enhancement/1) 작업 | | 9 | | (enhancement/1) git add .; git commit -m "작업내용" | | 10 | | (enhancement/1) git pull origin main --rebase | | 11 | | (enhancement/1) 작업 | | 12 | | (enhancement/1) git add .; git commit -m "작업내용" | | 13 | | (enhancement/1) git pull origin main --rebase | | 14 | | (enhancement/1) git push origin enhancement/1
or
(enhancement/1) git push origin enhancement/1 -f | | 15 | | 깃허브 접속, pr 생성하라는 버튼 확인 | | 16 | | pr 생성(enhancement/1 => main)
양수인과 리뷰어를 `프로젝트 매니저`로 지정 | | 17 | pr로 들어온 소스코드 확인
PR 리젝(즉 병합거부) | | | 18 | | 리젝확인 | | 20 | | (enhancement/1) git pull origin main --rebase | | 21 | | (enhancement/1) 작업 | | 22 | | (enhancement/1) git add .; git commit -m "작업내용" | | 23 | | (enhancement/1) git pull origin main --rebase | | 24 | | (enhancement/1) git push origin enhancement/1
or
(enhancement/1) git push origin enhancement/1 -f | | 25 | PR 승인 | | | 26 | squash merge
- 이렇게 해야 커밋결과가 보기 좋게 쌓인다. | | | 27 | delete branch : enhancement/1
- PR을 머지하면 해당 브랜치를 삭제하겠냐고 물어보는데 삭제하는게 좋다. | | | 28 | 이슈 1 닫기(자동으로 닫힐 수 도 있음) | | | 29 | | (enhancement/1) git checkout main | | 30 | | (main) git pull origin main | | 31 | | (main) git branch -D enhancement/1 | | 32 | | (main) git fetch --prune | | 33 | 4번 내용부터 다시 반복 | | # 3강 - [25 01 15, p 13988, 3강, GITHUB FLOW 작업 1 ~ 3](https://youtu.be/oWeJTyG02YI) - [리포지터리 - https://github.com/jangka2048/git-co-work-2025-01-15](https://github.com/jangka2048/git-co-work-2025-01-15) ## GITHUB FLOW 예시 역할 - jangka2048 : 프로젝트 매니저 - jhs512 : 개발자 1 ## main 브랜치에 룰 세팅 - ![img](https://i.postimg.cc/fb7ztLx7/image.png) - Require a pull request before merging - 병합하기 전에 반드시 PR을 거치도록 강제하는 옵션 - Require approvals - PR을 승인하기 위해 필요한 승인자 수를 지정하는 룰 - 체크를 하면 기본값은 1명이며, 지정된 수만큼의 승인이 있어야 PR 병합이 가능함 # 4강 - [25 01 15, p 13988, 4강, GITHUB FLOW 작업 4 ~ 5](https://youtu.be/oZQ9vjRY1PA) - [이슈 1 - https://github.com/jangka2048/git-co-work-2025-01-15/issues/1](https://github.com/jangka2048/git-co-work-2025-01-15/1) # 5강 - [25 01 15, p 13988, 5강, GITHUB FLOW 작업 6 ~ 28](https://youtu.be/hlowwDi5A-k) - [PR 2 - https://github.com/jangka2048/git-co-work-2025-01-15/pull/2](https://github.com/jangka2048/git-co-work-2025-01-15/pull/2) - [스쿼시 병합 커밋 - https://github.com/jangka2048/git-co-work-2025-01-15/commit/](https://github.com/jangka2048/git-co-work-2025-01-15/commit/c93803a) # 6강 - [25 01 15, p 13988, 6강, GITHUB FLOW 작업 29 ~ 33](https://youtu.be/Iyozz2vEDNc) # 7강 - [25 01 15, p 13988, 7강, 시나리오 시작, 1 단계 : 팀장이 리포지터리와 프로젝트를 생성 및 세팅](https://youtu.be/URpnfBMFpO8) - [리포지터리 - https://github.com/jhs512/spring-work-2025-01-16](https://github.com/jhs512/spring-work-2025-01-16) - [프로젝트 - https://github.com/users/jhs512/projects/26](https://github.com/users/jhs512/projects/26) - [커밋](https://github.com/jhs512/spring-work-2025-01-16/commit/656c9b7) ## 시나리오 전제 - 스프링부트 백엔드 API를 2명이서 GITHUB FLOW 방식으로 개발하는 시나리오 - 실습에서는 jhs512가 혼자서 팀장 개발자, 사원 개발자 역할을 모두 수행하는 시나리오 - 실습 편의상 오거니제이션을 만들지 않고 진행 - 할일 관리는 GITHUB PROJECT로 진행 - main 브랜치에 직접 commit 금지를은 걸겠지만 - 혼자작업을 진행하기 때문에 PR MEGER에 타인의 동의가 필요하지 않도록 설정 ## 시나리오, 1 단계 - 팀장 : 리포지터리 생성 - 팀장 : main 브랜치에 readme.md 생성 - 팀장 : main 브랜치에 직접 커밋 금지 룰 설정 - 팀장 : 프로젝트 생성 # 8강 - [25 01 15, p 13988, 8강, 시나리오, 2 단계 : 팀장이 할일을 생성하고 사원이 수행](https://youtu.be/QbvMcx5lmt0) - ![img](https://i.postimg.cc/X7B8NJq2/image.png) - [이슈 1 - https://github.com/jhs512/spring-work-2025-01-16/issues/1](https://github.com/jhs512/spring-work-2025-01-16/issues/1) - [이슈 1 in 프로젝트](https://github.com/users/jhs512/projects/26/views/1?pane=issue&itemId=93926968&issue=jhs512%7Cspring-work-2025-01-16%7C1) - [이슈 1의 PR(PR 2)](https://github.com/jhs512/spring-work-2025-01-16/pull/2) - [이슈 1의 COMMIT(COMMIT c2684ba)](https://github.com/jhs512/spring-work-2025-01-16/commit/c2684ba) ## 시나리오, 2 단계 - 팀장 : `backend 폴더에 스프링부트 프로젝트 세팅` 할일(이슈 1)을 생성 - 사원을 assignees에 추가 - 사원 : 본인에게 할당된 이슈를 `In Progress` 상태로 변경 후 작업 시작 - 변경의 의미 : 작업 시작, 다른 작업자에게 이 일을 하지 말라는 의미 - 사원 : 본인의 PC에 git clone - 사원 : `git pull origin main --rebase` - 작업전에 해야 하는 명령어(충돌이 난다면 해결) - 사원 : 브랜치 `enhancement/1` 생성 후 checkout - 사원 : backend 폴더에 스프링부트 프로젝트 세팅 - 사원 : backend 폴더기준으로 `git add ..; git commit -m "스프링부트 프로젝트 세팅"` - 사원 : `git pull origin main --rebase` - 커밋후에 해야 하는 명령어(충돌이 난다면 해결) - 사원 : `git push origin enhancement/1` - 사원 : PR 생성(enhancement/1 => main), 내용에 `Close #1` 추가 - 이 `Close #1` 덕분에 추후에 해당 PR이 완결되면 관련 이슈가 자동으로 닫히고 상태가 `Done`으로 변경됨 - PR에 관련 프로젝트 지정하면 추후 해당 프로젝트에 PR 완료사실이 DONE에 추가됨 - 사원 : 이슈의 상태를 `In Review`로 변경 - 변경의 의미 : 다른 팀원들에게 리뷰를 요청하는 것 - 팀장 : 사원의 PR 확인 - 팀장 : 사원의 PR 승인 - 팀장 : squash merge - 팀장 : 브랜치 `enhancement/1` 삭제 - 팀장 : 이슈 1 닫기(자동으로 닫힘) - 팀장 : 프로젝트 이슈 1 상태 `Done`(자동으로 상태가 `Done`으로 변경될 수 도 있음) - 사원 : `git checkout main` - 사원 : `git pull origin main --rebase` - 사원 : `git branch -D enhancement/1` - 사원 : `git fetch --prune` # 9강 - [25 01 15, p 13988, 9강, 시나리오, 3 단계 : 팀장이 할일을 등록하고 팀장이 진행, PR 리뷰 통과 못한 상태](https://youtu.be/C5Brfewj5P0) - [이슈 3 - https://github.com/jhs512/spring-work-2025-01-16/issues/3](https://github.com/jhs512/spring-work-2025-01-16/issues/3) - [이슈 3 in 프로젝트](https://github.com/users/jhs512/projects/26/views/1?pane=issue&itemId=93929244&issue=jhs512%7Cspring-work-2025-01-16%7C3) - [이슈 3의 PR(PR 4)](https://github.com/jhs512/spring-work-2025-01-16/pull/4) ## 시나리오, 3 단계 - 팀장 : `Member 엔티티, 로그인 구현` 할일(이슈 3)을 생성 - 팀장 본인을 assignees에 추가 - 팀장 : 본인에게 할당된 이슈를 `In Progress` 상태로 변경 후 작업 시작 - 팀장 : 본인의 PC에 git clone - 팀장 : clone 으로 생성된 폴더의 backend 폴더를 인텔리제이로 열기 - 팀장 : 인텔리제이에서 프로젝트 세팅 완료 - 팀장 : `git pull origin main --rebase` - 작업전에 해야 하는 명령어(충돌이 난다면 해결) - 팀장 : `git checkout -b enhancement/3` - 팀장 : 작업 후 `git add ..; git commit -m "Member 엔티티, 로그인 구현"` - 팀장 : `git pull origin main --rebase` - 커밋후에 해야 하는 명령어(충돌이 난다면 해결) - 팀장 : `git push origin enhancement/3` - 팀장 : PR 생성(enhancement/3 => main), 내용에 `Close #3` 추가 - 이 `Close #3` 덕분에 추후에 해당 PR이 완결되면 관련 이슈가 자동으로 닫히고 상태가 `Done`으로 변경됨 - PR에 관련 프로젝트 지정하면 추후 해당 프로젝트에 PR 완료사실이 DONE에 추가됨 - 팀장 : 이슈의 상태를 `In Review`로 변경 - 사원 : 팀장의 PR 확인, 결격사유 발견, 통과시키지 않음 - 사유 : Member 엔티티는 구현했지만 로그인 기능은 구현하지 않았음 # 10강 - [25 01 15, p 13988, 10강, 시나리오, 4 단계 : 팀장이 새 할일을 등록하고 사원이 진행하다가 `git pull origin enhancement/3`](https://youtu.be/g5SgKK2kfBc) - [이슈 5 - https://github.com/jhs512/spring-work-2025-01-16/issues/5](https://github.com/jhs512/spring-work-2025-01-16/issues/5) - [이슈 5 in 프로젝트](https://github.com/users/jhs512/projects/26/views/1?pane=issue&itemId=93931850&issue=jhs512%7Cspring-work-2025-01-16%7C5) - [이슈 5의 PR(PR 6)](https://github.com/jhs512/spring-work-2025-01-16/pull/6) - [이슈 5의 COMMIT(COMMIT 387013f)](https://github.com/jhs512/spring-work-2025-01-16/commit/387013f) ## 시나리오, 4 단계 - 팀장 : `Product 엔티티 구현` 할일(이슈 5)을 생성 - 사원을 assignees에 추가 - 사원 : 본인에게 할당된 이슈를 `In Progress` 상태로 변경 후 작업 시작 - 사원 : git pull origin main --rebase - 작업전에 해야 하는 명령어(충돌이 난다면 해결) - 사원 : 브랜치 `enhancement/5` 생성 후 checkout - 사원 : Product.java 생성 후 커밋 - 사원 : 작업을 하다가 `Member.java` 가 필요하다는 사실을 발견 - 현재상태 : 아직 팀장의 PR(4)이 완료되지 않음 - 해결방법 1 : 팀장에게 별도의 채널(카톡, GIST 등)으로 Member.java 파일을 전달받음 - 해결방법 2 : 팀장의 PR(4)이 완료되기를 기다린 후 완료되면 `git pull origin main --rebase` 명령어를 실행 - 왜냐하면 해당 PR(4)이 완료되면 결국 Member.java 파일이 main 브랜치에 병합되기 때문에 위 명령어로 Member.java 얻을 수 있음 - 해결방법 3 : 팀장의 PR(4)이 완료되기를 기다리지 않고 git `pull origin enhancement/3 --rebase` 명령어를 실행 - 왜냐하면 현재 github의 enhancement/3 브랜치에는 Member.java 파일이 있기 때문에 위 명령어로 Member.java 얻을 수 있음 - 사원 : `git pull origin enhancement/3 --rebase` - 자동으로 병합커밋이 생성됨 - 인텔리제이 기준으로(`Ctrl + C` or `ESC` 입력 후 `:wq!` 입력 후 `엔터`) - 만약 자동병합이 안되면 수동으로 병합하면 됨(수동으로 병합커밋을 생성) - 사원 : `git push origin enhancement/5` - 사원 : PR 생성(enhancement/5 => main), 내용에 `Close #5` 추가 - 이 `Close #5` 덕분에 추후에 해당 PR이 완결되면 관련 이슈가 자동으로 닫히고 상태가 `Done`으로 변경됨 - PR에 관련 프로젝트 지정하면 추후 해당 프로젝트에 PR 완료사실이 DONE에 추가됨 - 사원 : 이슈의 상태를 `In Review`로 변경 - 팀장 : 사원의 PR 확인 - 팀장 : 사원의 PR 승인 - 팀장 : squash merge - 팀장 : 브랜치 `enhancement/5` 삭제 - 팀장 : 이슈 5 닫기(자동으로 닫힘) - 팀장 : 프로젝트 이슈 5 상태 `Done`(자동으로 상태가 `Done`으로 변경될 수 도 있음) - 사원 : `git checkout main` - 사원 : `git pull origin main --rebase` - 사원 : `git branch -D enhancement/5` - 사원 : `git fetch --prune` # 11강 - [25 01 15, p 13988, 11강, 시나리오, 5 단계(마지막) : 팀장이 기존의 할일을 완료](https://youtu.be/wJSBJsVk4KA) - [이슈 3 - https://github.com/jhs512/spring-work-2025-01-16/issues/3](https://github.com/jhs512/spring-work-2025-01-16/issues/3) - [이슈 3 in 프로젝트](https://github.com/users/jhs512/projects/26/views/1?pane=issue&itemId=93929244&issue=jhs512%7Cspring-work-2025-01-16%7C3) - [이슈 3의 PR(PR 4)](https://github.com/jhs512/spring-work-2025-01-16/pull/4) - [이슈 3의 COMMIT(COMMIT )](https://github.com/jhs512/spring-work-2025-01-16/commit/) ## 시나리오, 5 단계(마지막) - 팀장 : 할일(이슈 3)을 다시 시작 - 팀장 : `git pull origin main --rebase` - 작업전에 해야 하는 명령어(충돌이 난다면 해결) - 이때 충돌 발생한다면 해결 - 팀장 : 작업 후 `git add ..; git commit -m "로그인 구현 완료"` - 팀장 : `git pull origin main --rebase` - 커밋후에 해야 하는 명령어(충돌이 난다면 해결) - 팀장 : `git push origin enhancement/3` - 안되면 `git push origin enhancement/3 -f` - 사원 : 팀장의 PR 확인 - 사원 : 팀장의 PR 승인 - 팀장 : squash merge - 팀장 : 브랜치 `enhancement/3` 삭제 - 팀장 : 이슈 3 닫기(자동으로 닫힘) - 팀장 : 프로젝트 이슈 3 상태 `Done`(자동으로 상태가 `Done`으로 변경될 수 도 있음) - 팀장 : `git checkout main` - 팀장 : `git pull origin main --rebase` - 팀장 : `git branch -D enhancement/3` - 팀장 : `git fetch --prune`