이번 강의는 병합을 마저 익히고, commit을 리셋하는 내용을 배운다고 한다. 그래서 시작하기 전 현재 main 브랜치 위치에 있는지 확인했다.
이전에 배웠던 브랜치 생성 연습도 하던 중에 VS code에서 ui확인 할 때 현재 브랜치 위치를 보여주고 있다. 그리고 기록한 걸 보니
'Add commit push 과정 거치면서 만약에 다른 브랜치로 push해 올리면… 로컬저장소는 그대로인데 원격저장소에 올라가진다.' 라고 썼는데 아마 원격 저장소 main에다 타 브랜치에서 한 작업 올리면 덮어씌워진다 뜻인가....싶었다.
그런데 원격저장소에 브랜치를 올린 적이 없어서 거기서 못 올린다고 말하더라…
main 브랜치 흐름으로 이렇게 해석되는 모양이다.
Main 브랜치 (메모)-----------------------------------------------------------> 진행 시점
Main 바탕의 브랜치 1 --- (커밋)-> 정상적으로 합쳐짐
Main 바탕의 브랜치 2 ------- (커밋)--> try-1 커밋과 합쳐지고 나서라 충돌 남.
main 브랜치로 가서 try-1을 합쳤다.
참고로 파일 수정한 걸 commit 안 하면 옮겨갈 수 없다는 오류가 떴다. 마무리 다하고 옮기라는 뜻
브랜치 병합 충돌난 걸 해결하는 중이다. 이것도 파일 수정 병합해서 add commit 과정 거쳐야 된다. 그리고 마지막에 push
이렇게 작업하다보니 질문을 했는데 구체적이지 않더라도.
타 브랜치에서 작업한 걸 바로바로 push 하지 않고 (원격저장소에) add – commit만 해서 작업하다 병합해서 올려도 되긴 하나 회사마다 다르다고 한다. 곧바로 확인하게 push 해달라는 곳 있고, 아닌 곳 있고... commit 기록은 전부 남겨질테니 스타일 차이 같다.
브랜치 사용 심화 실습으로 이전에 했던 작업물에서 한 진행.
1. Research/recruitment_1브랜치를 main에 병합
2. Research/recruitment_2 브랜치에서 main 브랜치 pull 받은 뒤 main에 병합
3. Research/recruitment_3 브랜치에서 작업한 걸 main 브랜치에서 병합
브랜치3 병합때는 pull 거치지 않고, 수동 병합하고 업로드 해 브랜치 삭제까지 무사히 했다. 이 실습 동해 병합 관련은 어느정도 연습하게 됐다.
Commit 되돌리기
이 파트가 가장 이해하기 어려웠다. 생각대로 잘 안되는 명령어인데 자주 쓰이는 편이 아니라고 들어 기본적인 과정을 익힌 뒤에 다시 보려고 한다. 질문도 많이 했는데 기록한 대로 남기고자 한다.
Commit 이동 명령어
HEAD~n : n번째 조상 커밋으로 이동
Main ---1 ----2 ----3 ----4 ---5(head) 일 때 Head~1 하면 4로 간다. (5에서 4로.)
HEAD^n : 병합커밋에서 사용하며 n번째 부모로 이동(브랜치 이동 같이 되던가?)
--soft : HEAD(커밋 포인터)만 이동
• 스테이징 영역(index)와 작업 디렉토리(working directory)는 유지됨
• 스테이징에는 올라가 있으며 커밋만 다시 하고 싶을 때 사용
작업한 내용 그대로고 commit 기록만 사라진다.(log로 확인 시) 그래서 작업하고 commit 하면 된다.
--mixed(기본값) : HEAD와 스테이징 영역까지 이동
• 작업 디렉토리는 그대로 유지
• 스테이징, 커밋을 모두 취소하고 다시 하고 싶을 때 사용
--hard : HEAD, 스테이징 영역, 작업 디렉토리 모두 롤백 (복구 불가능하므로 매우 주의!)
• 최근 변경사항을 모두 삭제하고 이전 커밋으로 돌아가고 싶을 때 사용
위치 지정할 시 이전 과정을 전부 없애버린다. 기록도 뭐도 남지 않는다.
--hard는 작업 내용이 완전히 삭제될 수 있으므로, 정말 필요한 경우에만 사용해야 함.
reset은 로컬 히스토리 조작 도구이기 때문에 공유된 리포지토리(푸시한 커밋)에서 사용하면 동료와 충돌이
생길 수 있으니 협업 시 사용을 각별히 주의해야 함, 주로 리셋해도 될까요?하고 협의 오가면서 쓴다고 배웠다.
명령어 적용, 이해가 잘 안돼서 반복적으로 썼는데 만약의 나라면 다시 수정해서 써올리거나, 이전 작업물로 롤백해서 시작하지 않을까 싶어졌다. 실제로도 이 명령어를 자주 쓰지 않는다고 배웠다.
git revert : 기존 커밋의 변경 내용을 취소하는 새로운 "취소 커밋"을 생성하는 명령어
커밋 기록은 절대 지우지 않고, 히스토리를 안전하게 유지함 / 협업 시 안전한 롤백 방법으로 많이 사용됨/ reset 보다 많이 씀
Git reset은 커밋 자체를 없애거나 이동시키지만, Git revert는 해당 커밋의 변경만 반영을 취소한 새로운 커밋을 생성함.
git revert <이동할 커밋 해시> : 주로 이 쪽 명령어를 쓴다.
ex) git revert abc1234
병합 커밋 revert 시 주의사항: 되돌릴 때 어느 부모 기준으로 되돌릴지 지정 : (1: 내 브랜치, 2: 병합된 브랜치)
이하 revert하고자 하는 노력들
여러 시도하다 잘 파악이 안되어서...
Revert는 여전히 아리송한데 add commit push 기본을 잘하는게 우선 같으니 나중에 다시 시도하는 걸로 묻어두기로 했다. 변경될 때마다 add commit 생활화 하는 걸 목표로 했다. 아직 기록 못했지만 python 공부도 백업할 예정이다.
이 다음은 ‘Git 협업’ 수업이다. 이건 이론에 가까운 수업 내용이였다.
Waterfall Model
단순한 모델이라 이해가 쉽고, 단계별로 정형화된 접근이 가능해 문서화가 가능하다.
프로젝트 진행 상황을 한눈에 명확하게 파악 가능하다
변경을 수용하기 어렵고, 시스템의 동작을 후반에 가야지만 확인이 가능하다.
대형 프로젝트에 적용하는 것이 부적합하고, 일정이 지연될 가능성이 크다? (경우따라 다르다.)
Agile
짧은 주기의 개발 단위를 반복해 하나의 큰 프로젝트를 완성해 나가는 것. = 짧은 주기로 설계, 개발, 테스트, 배포 과정을 반복. 요구 사항을 작은 단위로 쪼개 솔루션을 만들고, 빠르게 보여줌으로써 요구 사항에 대한 검증 진행
협력과 피드백 / 유연한 일 진행 + 빠른 변화 대응
폭포 모델과 다르게 순서가 없다보니 누락될 수 있다고 한다.
방법론 설명을 들으면서 용어, 진행 과정 등을 설명하는데 이해한 걸로 기록한다면.
Scrum(스크럼) 대표적인 프레임워크 중 하나.
스프린트(Sprint): 정해진 기간(보통 2~4주) 동안 제품의 일부를 개발하는 반복 주기
작은 기능에 대해 “계획, 개발, 테스트, 기능 완료” 에 대해 주기적으로 시행하는 것
마감 기한을 지킨다/ 명확한 목표 설정/ 끝날 때마다 평가, 개선 도출
제품 백로그(Product Backlog): 제품에 필요한 기능, 개선사항, 버그 수정 목록
스프린트 백로그(Sprint Backlog): 해당 스프린트에서 구현할 작업 목록
데일리 스크럼(Daily Scrum): 매일 15분 내외로 진행되는 짧은 회의, 진행 상황 공유 및 문제점 논의
데일리 스크럼에서 보통 팀원들이 각자의 진행상황 공유한다.
스프린트 계획 회의(Sprint Planning): 스프린트에서 어떤 일을 할지 결정
스프린트 리뷰(Sprint Review): 스프린트 결과물 시연 및 피드백 수집
스프린트 회고(Sprint Retrospective): 스프린트 과정에 대한 개선점 논의
>이는 개발자와 사용자의 이해는 다르기 때문에.
kanban(칸반) 설명
이 다음 협업 스타일도 환경, 목적에 따라 다르다고 한다.
Git 협업은 2명 이상의 개발자가 하나의 프로젝트에서 서로 다른 작업을 하는 것을 말함
브랜치는 하나의 main브랜치에서 여러가지 작업을 위한 브랜치를 생성하는 것으로 소규모 협업에 적당. 그러나 100 이상의 대규모 작업을 하게 되면 브랜치가 복잡하고 관리하기 힘들 거다. 이런 불편한 점을 해결 하기 위한 방법은 저장소를 통째로 복제(fork)하면 됨
여기서 할 협업 방식은 Collaborator
Remote Repo.의 협력자로 등록하여 특정 권한을 부여하고 하나의 Remote Repo.를 공유하는 방법 • 상대적으로 소규모 협업에 적합함- 브랜치 끼리 병합하는 방법.
한번 시도해보기로 했다.
사람 추가 창. 검색하면 유저 프로필이 뜰거다. 받은 사람은 직접 수락해야 확인 가능하다.
콜라보를 다하고 나니 다른 협업 방식도 배워서 여기에 기록하기로 했다.
Fork
다른 사람의 Remote Repo.를 복사(정확히는 Fork)하여 각자의 Remote Repo.에서 작업 후 원본(Upstream) Remote Repo.와 Merge 하는 방법 • 대규모 협업시에 적합함
원본의 원격저장소를 통째로 복제하게 되면 모든 커밋 이력도 복제되어 또 하나의 원격저장소가 생성됨
다른 사람의 Remote Repo.를 복사하여 가져옴
맨날 갖고와야해서 협업은 콜라보가 선호 된다.
원본 Remote Repo.의 소유자 권한이 더 있어. Pull Request를 수락해 Forked Repo.를 origin에 Merge 한다.
그리고 협업 도중 하게 될 작업 수행들.
Pull request 원격저장소 브랜치 규칙 생성하기
Merge를 수행하기 앞서 변동사항 체크 및 허락을 받는 것
규칙을 생성하여 내 원격저장소에 병합을 제한/ 무작위로 병합하여 코드가 오류나는 것을 방지
일반적으로 Forked Repo. -> Origin Repo. 로 Merge 할 때 사용
Collaborator 관계에서도 활용 가능: 공유하는 Remote Repo.에 사용자 별로 Branch를 만들고, 사용자 Branch에서 main Branch로 Merge 요청을 할 때 이용 가능
Repo. 원본 관리자 권한이므로 협력자는 이걸 활성화 할 수 없다.
Pull request은 github에서 코드 병합하는 것과 흡사하다.
Requset 과정 자료 보고 정리해 작성하기.
Repo(원격저장소)에서 한 것이라서 바로 정리가 된다. 로컬저장소에는 적용된 게 아니기 때문에
이를 통해 Github에서 코드 병합해 충돌 해결이 가능하다.
그래서 협업 시, 풀리퀘스트 작성하고 나서 링크를 따서 올려둬야 승인 확인이 쉽다. (직행 링크)
풀리퀘스트 승인 후, 승인 허락한 사람이 메시지로 알려야 하고 승인 요청한 사람이 무조건 병합 실행해줘야 한다. 그리고 다른 이들에게 pull 해달라고 메시지 남긴다.
Closed 확인하면 브랜치나 이런저런 정보 남아있고 삭제할 수 있지만 본인 브랜치만 정리하는 게 가장 이상적이다.
이렇게 실습하면서 따로 기록해둔 명령어 이해들...
git config --global push.default current
지금 이 브랜치 이름으로 원격 브랜치에 올리기.
git config --global push.autoSetupRemote true
로컬 브랜치 명과 리모트 브랜치 명이 동일할 때만 push 가능하도록 설정 제한
이런 식으로 회고록이 끝났다. 이후부터는 python으로 들어가는데 어떻게 공부를 복습해 저장할지 고민이다. 아마 더 느려질 수도 있겠다...
'IT' 카테고리의 다른 글
| [코딩온] 신재생에너지 IoT 개발자 입문_ 파이썬6 (0) | 2025.12.01 |
|---|---|
| [코딩온] 신재생에너지 IoT 개발자 입문_ 파이썬4 (0) | 2025.11.25 |
| [코딩온] 신재생에너지 IoT 개발자 입문_ 파이썬 2 (0) | 2025.11.24 |
| [코딩온] 신재생에너지 IoT 개발자 입문 251107 회고 (0) | 2025.11.11 |
| [코딩온] 신재생에너지 IoT 개발자 입문 251105 회고 (0) | 2025.11.08 |