dragonhyeon 님의 블로그

초기 커밋: README.md, .gitignore 등의 설정 파일들을 main 브랜치에 커밋main 브랜치에서 develop 브랜치를 분기하고, 개발에 필요한 템플릿 코드 등을 develop 에 커밋기능 단위로 develop 브랜치에서 feature/ 브랜치를 분기하고 작업 진행ex. feature/add-user-profile기능 개발이 완료되면 해당 feature 브랜치를 develop 에 병합병합 이후 develop 브랜치에서 버그가 확인되면 develop 브랜치에서 바로 수정develop 브랜치에서 발견된 버그의 규모가 크다면 feature/ 브랜치로 분기하여 작업 진행후 다시 develop 에 병합실제 Git Flow 모델에서도 "버그 수정도 새로운 feature 로 간주할 수 있다" 는 유연..

Git Flow 브랜칭 전략을 전제로 합니다. develop 브랜치에서 feature 브랜치로 분기한 상황입니다. feature 브랜치 개발 완료 후 develop 에 merge 시, develop 에 이미 새로운 커밋 이력이 생겨있는 경우merge 사용이 일반적히스토리를 그대로 보존하므로, 이력이 안전하게 남고 협업에 적합merge 정책에 따라 rebase 혹은 squash 를 사용할 수 도 있지만 기본적으로는 merge 사용feature 브랜치에서 개발 진행중에 develop 에서 코드 수정이 발생해 수정된 develop 코드 기반에서 개발을 이어가야 하는 경우rebase 사용이 일반적커밋 히스토리가 깔끔해지고, develop 의 최신 상태를 기반으로 개발 가능merge 를 사용하면 불필요한 병합 커..

fetch원격 브랜치의 최신 상태를 로컬의 원격 추적 브랜치로 업데이트하는 명령어입니다.git fetch / 에서 fetch 해옴git fetchremote alias 가 origin 으로 설정된 원격 저장소에서 모든 브랜치 정보를 가져옴git fetch --pruneremote alias 가 origin 으로 설정된 원격 저장소에서 모든 브랜치 정보를 prune 방식으로 가져옴git fetch --all모든 원격 저장소에서 모든 브랜치 정보를 가져옴git fetch --all --prune모든 원격 저장소에서 모든 브랜치 정보를 prune 방식으로 가져옴

Git Flow 기반 워크플로에서의 브랜치 관리 방식develop:main 브랜치에 병합한 뒤에도 삭제하지 않는것이 일반적 (프로젝트의 지속적인 개발 흐름을 담당하는 브랜치이므로)main 브랜치로 병합 시 merge 방식이 일반적 (릴리즈 단위의 기록을 보존하려는 목적, 여러 feature 통합 흔적 유지)feature/*:develop 브랜치에 병합한 뒤 삭제하는 것이 일반적 (기능 개발이 완료되어 develop 에 반영되었기 때문에 더 이상 해당 브랜치가 필요 없음. GitHub, GitLab 등에서는 PR 을 머지할 때 자동으로 브랜치를 삭제하는 옵션도 있음)develop 브랜치로 병합 시 squash 또는 rebase 방식이 일반적 (커밋을 정리해서 develop 히스토리를 깔끔하게 유지하려는 목..

로컬 브랜치 이름 변경로컬 브랜치 이름 바꾸기git branch -m 현재 체크아웃 중이라면 아래 명령어로도 간단하게 변경 가능git branch -m 원격 저장소에 반영로컬에서 변경된 브랜치의 이름을 원격 저장소에 반영하는 방법은 원격 저장소에 있는 브랜치의 이름을 실제로 바꾸는 방식이 아니라 새 브랜치로 푸시하고 이전 브랜치를 삭제하는 방식입니다.git push # 변경된 이름의 브랜치 원격 저장소로 푸시git push --delete # 이전 이름의 브랜치 원격 저장소에서 삭제

tagGit 에서 태그 (tag) 는 특정 커밋을 식별하기 위해 붙이는 일종의 이름표로 릴리즈나 특정 버전을 표시할 때 사용되어 프로젝트의 버전 관리와 릴리즈 관리를 체계적으로 할 수 있도록 돕는 중요한 도구입니다. Git 태그는 경량 태그와 (Lightweight Tag) 주석 태그 (Annotated Tag) 두 가지 종류로 나눌 수 있습니다.경량 태그 (Lightweight Tag)단순히 특정 커밋을 가리키는 포인터 역할입니다.추가적인 메타 데이터 (작성자, 날짜 등) 가 포함되지 않습니다.주로 내부적이거나 임시적으로 사용할 때 적합합니다.git tag # 현재 HEAD 가 가리키고 있는 커밋에 적용 (다른 브랜치에서도 해당 커밋에 자동 적용)git tag # 특정 커밋에 경량 태그 추가주..

로컬 브랜치 삭제다른 브랜치에 merge 된 브랜치 삭제git branch -d 다른 브랜치에 merge 된 & merge 되지 않은 브랜치 삭제git branch -D 원격 브랜치 & 원격 추적 브랜치 삭제원격 저장소의 원격 브랜치 삭제 (로컬에 해당 원격 브랜치에 대한 원격 추적 브랜치도 존재한다면 함께 삭제됨)git push --delete 로컬에 있는 원격 추적 브랜치 삭제git branch -r -d # -r 옵션을 사용하여 원격 추적 브랜치 삭제. -rd 형식으로도 사용 가능로컬 저장소를 원격 저장소와 동기화시켜 로컬의 원격 추적 브랜치 정리git fetch --prune 은 로컬상의 원격 추적 브랜치를 항상 원격 저장소의 원격 브랜치에 정확히 일치시킵니다.원격 저장소에 존재하는 원격 브..

Git 병합Git 에서 여러 브랜치에서 작업한 내용을 하나의 브랜치로 합치는 작업을 병합 (merge) 이라고 하며, 대표적으로 fast-forward merge 방식과 3-way merge 방식이 있습니다. 병합이 성공할 경우 3-way merge 에서는 병합 커밋이 자동으로 생성됩니다.비병합 커밋 (Non-merge commit): 단일 브랜치에서 발생하는 커밋으로 하나의 부모 커밋만 가지며, 다른 브랜치와의 병합 없이 그 브랜치에서만 변화가 일어난 커밋입니다.병합 커밋 (Merge Commit): 두 개 이상의 브랜치를 병합할 때 Git 이 자동으로 생성하는 커밋으로 두 개 이상의 부모 커밋을 가집니다. 하나의 병합을 진행하며 병합 충돌이 여러 번 발생하여도 병합 커밋은 최종적으로 병합이 성공하는 ..

git clone저장소 (Repository) 구성원인 경우 원본 저장소를 clone 해서 바로 작업을 진행할 수 있습니다.git clone https://github.com/dragonHyeon/some-repository.git # 원격 저장소 clonecd some-repository # clone 한 저장소의 디렉터리로 이동 git clone 시 원격 저장소의 모든 브랜치, 커밋, 심볼릭 레퍼런스 (origin/HEAD), 태그를 가져옵니다. 기존 작업 디렉터리에서 일부 브랜치 추가를 하는 경우가 아니라면 수동으로 fetch 를 하여 특정 브랜치의 업데이트 정보만을 가져오기 보다는 git clone 을 사용하는것이 더 ..

원격 브랜치 (Remote Branch)원격 저장소에 존재하는 브랜치로 원격 저장소에서 관리되고 있는 브랜치입니다.원격 추적 브랜치 (Remote Tracking Branch)로컬에서 원격 브랜치를 추적하는 참조이자 브랜치입니다. 예를 들어, origin/develop 은 원격 저장소 origin 의 develop 브랜치를 참조하는 원격 추적 브랜치입니다. 즉, 원격 저장소 origin 의 develop 브랜치를 참조하는 브랜치입니다.git branch -r 을 통해 원격 추적 브랜치 목록을 확인할 수 있습니다.트래킹 브랜치 (Tracking Branch)로컬 브랜치가 원격 추적 브랜치를 통해 간접적으로 원격 브랜치를 추적하는 상태인 경우 해당 로컬 브랜치를 트래킹 브랜치라고 합니다. 예를 들어, dev..