수요일부터 해결하고자 하였다.
나이트 멘토님과의 고군분투
심화과정 rebase까지 나왔다.
목요일에 경래 멘토님과 문제 정리
수요일 새로 생긴 오류를 해결하기 위해서는, 월요일의 이전 오류부터 다 고려 해야 한다!
나의 상황들을 다 정리해놓았다.
Project 1 - 4일차 문제해결
내가 거의 깃허브 관리 담당이였다. 제대로 말하자면, 깃허브 branch에 분리해서 코드를 올리는 사람. 즉, 코드도 치고 올리는 사람. 팀원들이 코드를 주긴 하는데, 틀린 코드도 있고 실행하는 사
pm-developer-justdoit.tistory.com
그런데 말로는 쉬운데 혼자 하다보니, 그 구체적 과정이 어려웠다.
어디에다가, 어디에 가서 하는지. branch! 폴더! 나의 현재 위치!
금요일에 승윤 멘토님과 다시,
cherry pick 까지 나옴 ㅎ
계속 이건 지금 계속 월요일부터, 내가 지금은 몰라도 될 응용부분 까지 하고 있다고.
그런데 내가 계속 해결하는 중이니 뿌듯한?
(사실 월요일에 내가 같은 실수 1번을 승윤멘토님과 해결했었던.. ㅎ)
수요일 새로 생긴 오류를 해결하기 위해서는, 월요일의 이전 오류부터 다 고려 해야 한다!
나의 상황들을 다 정리해놓았다.
[1] 초기화 세팅에 들어가서, user service 작업 한 뒤에, 싸그리 다 push 해 버림
처음에 나는 초기화세팅 branch를 판 상태에서
초기화세팅 작업을 한 뒤, commit-push-pr 했다.
그 초기화 세팅 branch에서 user service 작업을 하고,
초기화 세팅 branch 를 commit - push - pr하는 바람에,
초기화 세팅 branch 안에
초기화 서비스와 user service가 모두 들어가 있다.
[해결]
초기화 세팅 branch 와 user service branch로 분리는 해야 하는데,
user service 를 하는 데에, 초기화 세팅 서비스가 어짜피 필요하니까,
초기화 세팅 branch 를 user service branch 안에서 복사해서 (= 생성)
(main에서 user service branch 생성하면 안 됨.
main은 초기화세팅의 내용을 모른다.
그러기에 초기화세팅 branch 안에서 user service branch를 파야지, 초기화세팅 branch에 들어간
초기세팅 service + user service 의 내용을 다 가져간다)
즉, 1. branch 생성 (= 복사)
현재,
main - 초기세팅 - user service branch
2. 이제 다시 초기세팅 branch로 돌아가서,
user service branch 를 오른쪽 마우스로 delete!
그리고 변화가 있으니까, commit 해야함!
작업이 끝날때마다 commit 해야함.
나는 초보 입문자니까, user에 대한 내 작업이 끝났더라도,
이후에 한줄씩 추가될거 같아서 commit을 안했는데,
그러면 또 commit하면 되니까 했어야 함
3. 다시 user service branch로 돌아가서,
user 작업 마무리 하고
commit 하면 됨.
[2] 내가 user service branch 안에 있는 상태에서, post service 작업을 했음.
그리고 한꺼번에 commit- push를 했음.
처음부터 짚어보면, 나는
2개의 실수를 함.
1. user service branch 에서 post 작업을 한 것
2. user service branch에서 user 작업을 한 뒤, commit을 했어야 함
(그럼 commit으로 라도 분리가 가능했음 --> 체리콕 이용)
자, 원래대로라면,
원래의 깃허브를 알아보자.
이런 경우,
정석을 알고
내가 실수해서 해결하는 과정은 분리해서 알아야 한다.
엮어서 하면 안 된다.
그리고 현업에서 많이 쓰려면 최대한 많은 실수를 접하는 게 좋다
그리고 실수를 기록하는데
순차적으로 되는게 아니라 한번에 되는 경우가 있으니까
그리고, 내가 막 이렇게 저렇게 해서
실수한 것은, 어떻게든 실수를 만회할 수 있다.
branch는 서로 독립돼 있고, 서로 다른 branch에서 무엇을 하는지 모르기에,
<원래 정석>
main에서 branch인, feature/userSerivce 를 만들고 push 하고
--> main과 feature/userService 를 merge
이 하나의 것이, 이런게 여러개가 있는 것
[2]-1 나는 [1]에서 이미 겪었었던 거라, 자연스럽게
main에서 post branch를 팠다가 그 branch를 지우고,
다시 user service branch에 post service branch에 팠는데
일단 정석대로 볼 때,
위치로는
main - user service branch
main - post service branch 가 맞고
내용으로 볼 때는
main에 아무것도 없으니,
이런 경우에는 어쩔 수 없이
[해결책]: user service branch 안에 post service branch를 판다.
근데 이게 'user service branch 밑에,
post service branch 가 있다'는 게 아니다
'종속된 게 아니다.'
user service branch 밑에 post servcie branch를 팜으로써,
post service branch가 user service branch 의 내용과 변경, 저장 사항들을 기억한다는 것이다.
도대체 branch를 또 판다는 게 뭔가 하고 알아보았다.
만약, user service branch에서
'post service.js 파일 삭제를 하면 휴지통'에 가는데,
그럼 post service branch에서는
'post service.js 파일이 없어지는거 아닌가?'
아니다. branch 별개이기에
post service branch로 가면,
다시 생긴다.
즉, post service branch에 있을 거는 다 남고, 영향을 받지 않는다.
진짜다!
내가 main으로 갔는데,
진짜로 내가 userServices에서 만든 user service, post service 다 사라져서
"헐 어디 갔어 " 하고 멘붕 왔는데,
그것은 내가 main branch에 와 있어서 그런 거였다.
만약, 내가 commit을 작업이 끝난 뒤에 했다면,
다른 해결책으로 가능했을 것이다.
내가, commit을 바로바로 안했기 때문에,
user + post service 작업이 다 올라간 것.
만약 내가 user 작업 후에 commit하고
post 작업 후에 commit했으면,
---> commit 단위별로 분리하는 cherry pick 사용 가능
그렇다면 언제? 얼마나 자주 commit 해야 하나?
작업 하나 끝날 때마다.
ex.
- user 작업 끝나면 commit
- post 작업 끝나면 commit.
"나는 초보 입문자니까,user에 대한 내 작업이 끝났더라도,
이후에 한줄씩 추가될거 같아서 commit을 안했는데,"
그러면 또 commit하면 되니까 했어야 함
+
그리고 나의 오류
나는 자꾸 파일과, 문서 파일로 생각해서,
파일을 복사했으면 ,
꽉 차 있는 파일을 빈 문서에 복사 붙여넣기를 하는 건데,
깃허브는
branch를 새로 생성하면, 빈 문서가 아니라
vscode에 이미 꽉 차 있으니까,
분리가 안 돼서 헷갈리는 거였다.
여기까지는
1) '원래 정석대로 하는 내용과
2) 내가 어떤 부분을 실수했는지,
3) 간단하게, 내가 실수한 부분을 해결하는 방법과 그럴 경우 일어나는 일,
4) 만약 내가 조금 다르게 했다면, 바뀔 다른 대안' 까지 다루어보았다.
자, 이제 해결해보자.
위의 정석 방법과,
지금 실수를 해결하는 과정은 분리해야 할 것.
일단, post service branch를 user service branch 안에 팠다.
post service branch 안에는, user + post service 작업 내용이 있다. 후행 작업이니 냅두기로 하고.
user service branch로 가서,
post service 작업 내용을 삭제한다.
오른쪽 마우스, 클릭 delete.
자, 이제 변동 사항 있으니?
commit을 해야 한다!
아까 바로 안했는데,
userservice branch에서 삭제 후에도 commit 을 해야 했다.
commit 하는 습관!
그리고 post service에서도 commit.
이렇게 하고 post service 안에 user service 연동 돼있는 상태에서,
user service는 다시는 수정하거나 건드리면 안된다.
엄마 branch (user service) 에 연결된, 자식 branch (post service)가 있다.
그런데, 이렇게 다 commit 한 뒤에,
엄마 branch에 변동이 있으면, 자식 branch인 post service는 영문을 모르게 될 것이다.
아까 초기세팅 commit, push 한 상황
userbranch commit, push 하려니 변화가 없다고 한다. 깃허브에도 변화가 없고.
이 건은 캐쉬 삭제, module 삭제 후 해결!
자, 그런데 pull request 후
[3] 이미 merge 한 branch를 수정
초기세팅 branch 를
merge 후에 수정하고 싶어서
local에 다 수정한 상태
그러면, 다시 pr 하면 됨. 그 branch를 삭제 하지 않았기에.
1. 로컬을 최신화 시켜줘야 함 --> git pull origin main
로컬에서 깃허브에 올린 뒤에 merge 를 했으니까,
늘 최신화는 항상 main에서 하는 것 (local 의 main 이 가장 늦게 최신화 됨)
merge 후에 버려진 branch가 아니기 때문에,
branch 삭제를 안 했기에,
지금 갖고 있는 branch에서 수정하고 다시 commit 할 수 있음!
** 만약
branch를 삭제 했다면, remote에서는 merge라는 변화가 있으니까.
pull 받고나서, 이미 있는 초기화 branch에서 수정 후, 다시 commit/push 하면 됨
그럼 다시 pr 할 수 있음
new pr
대신 우리가 원래 pr 할 때처럼 초록 안내창이 안 뜨겠지만,
그냥 하면 됨.
다시 올리기
그런데 이미 commit 됏다고 변경 사항 없다고 하는 이유는,
내가 실수로,
main - user( 초기 + user) 이라,
user branch에서 commit 해서
main 과 merge된 초기 branch도 영향 받아서 변경 돼 있는 것!
이건 원래 없어야 하는 상황 ㅋㅋ
pull request 들어가보면 comment 하단에 conflict 확인,
충돌이 나면, local에 똑같이 충돌 만들어서, local에서 충돌 해결해서
해결한 것을 다시 remote에 올려야 한다. 그러면 remote에는 충돌 안 나겠지 ~
remote 에 있느 것을 local에 pull 로 최신화 해서 내려받기 git pull origin main
git merge main
>>>> 하면 merge 오류 위치 보여줌
수정 후, 다시 add. commit push 로 올리기 (변경 사항 있으면 무조건 commit, push) --> push 는 안하더라도 commit은 남기기 -> commit 은 git log로 남겨지니
git log를 하면 commit 시점을 확인할 수 있다.
이런 문제를 해결할 때마다, 멘토분들이 commit 시점을 여쭤보시는 이유는,
바로 체리 픽을 사용하기 위해서 인 거 같다.
git log에서 이거를 보는 방법은,
feature/user-services 안에, featurel/user-services feature/post-services가 들어있어서이다.
하면서 추가 궁금한 점 모아서 질문과 답변
1.
git branch post-service에서
git branch user-service 로 이동할 떄,
꼭 git checkout main으로 main을 거치치 않아도 된다.
'Wecode - Project 1 (부트캠프) > Project 1 과정' 카테고리의 다른 글
| Project 1- 5일차: 통신 완료! 마지막날 (jwt 토큰, bcrypt, hash) (0) | 2023.09.15 |
|---|---|
| Project1: 5일차 아침: 통신 전, 마지막날 코드 수정 (self 코드 리뷰) (0) | 2023.09.15 |
| Project 1- 5일 차: chat gpt AI와 상생하기 2탄 (0) | 2023.09.15 |
| Project 1 - 4일차 : 깃허브 branch 문제해결 [1차 시도]/ 코드 질문 / '본질에 집중' (0) | 2023.09.15 |
| Project 1- 3일차 : 코드 리뷰, 비교 - threadService / 포스트 Posting 목록 조회, 생성 (0) | 2023.09.14 |