Git Flow브랜치는 크게 main, develop으로 나누며, 이 둘은 항상 유지feature, release, hotfix는 필요할 때마다 생성되고 역할을 다하면 삭제됨 main출시 가능한 production 코드를 모아두는 브랜치버전 태그를 달아(1.0, 1.1 등) 배포 develop다음 버전 개발을 위한 코드를 모아두는 브랜치개발이 완료되면 main으로 머지 feature하나의 기능을 개발하기 위한 브랜치develop 브랜치에서 생성되고 구현 완료 후 develop에 머지feature/{name} release배포 전 QA를 진행하는 브랜치develop 브랜치에서 생성하고 QA가 통과하면 main에 머지수정사항이 있으면 main, develop에 머지release-{version} hotfi..

Git에서 merge와 rebase는 한 브랜치의 변경 사항을 다른 브랜치에 통합하기 위한 두 가지 방법이다. merge두 브랜치를 통합한다.분기(branch)가 유지된다.merge commit이 생성된다.기존 커밋 해시가 유지된다. M이라는 merge commit이 생성되며, 기존 커밋 기록이 그대로 보존되어 히스토리가 분기된 형태로 남는다.# feature 브랜치에서:git checkout featuregit merge mainmain: A --- B --- C \ \feature: D --- E --- M rebase한 브랜치의 커밋들을 다른 브랜치 위로 옮긴다.히스토리가 직선(linear) 형태로 정리된다.기존 커밋을 재작성(re..

git revertgit revert는 커밋을 지우지 않는다“되돌리는 커밋”을 하나 더 만든다즉, 히스토리는 살아 있고, 결과물만 바뀐다 시나리오1. dev에서 A작업을 한 후 해당 커밋 위치(C1)에서 feature 브랜치를 만듦dev:C0 ── C1(A 작업)feature: └── C1(A)2. dev에서 A를 revert 한 경우dev:C0 ── C1(A) ── R1(A revert)feature: └── C1(A) Case 1. 아무것도 하지 않고 feature -> dev 머지git checkout devgit merge feature 결과A + feature 작업 전부 dev에 들어옴이유: feature에는 revert가 없기 때문 Case 2. feature d..

에이블스쿨에서 사용했던 노트북을 정리하며 실습 코드 및 프로젝트 파일들 백업을 위해 github에 업로드한 후 다른 PC에서 접근하는 방식을 택했다.프로젝트를 하면서 git에 대한 기본 개념을 익혔기 때문에 쉽게 pull/push가 가능해졌는데(다들 고마워요!)가끔가다 등장하는 대용량 파일들(ex. csv 파일로 된 데이터)을 push 하는 과정에서 오류를 만나곤 했다. git만 있으면 쉽게 저장할 수 있을 거라고 생각했지만, 이런 상황이 발생할 것이라고는 생각조차 못해봐서 열심히 git에 대해 찾아본 결과Git 리포지토리에 업로드할 수 있는 파일 용량은 최대 500 MB로 제한되어 있다고 한다.그래서 대용량 파일을 업로드하기 위해서는 Git LFS(Large File System)를 사용했다. Gi..