Copyright 2021.devkimsonAll rights reserved.
Categories
Tags
8
16
32
여태까지는 Git Commit을 관리하는 방법을 잘 알고 있다고 생각했습니다. 하지만 실제 프로젝트에서는 예상치 못한 상황들이 생기면서, 기존의 흐름을 되짚어보는 일이 많아졌습니다. 이런 경험을 통해, 지금까지 이해했던 방식이 실제 현장에서는 다르게 작동할 수 있다는 걸 느꼈습니다. 이번 포스팅은 브랜치 관리와 이전에 이해하고 있던 브랜치 머지 방식이 다시 보니 잘못된 것에 대한 내용을 다룹니다. 고민이 생긴 이유 이직 이후 백엔드 인수인계를 받으면서 깃 관리에 대해 설명을 듣다가 문득 생각이 들었습니다. "브랜치가 이렇게 다양한 이유는 무엇일까?" 브랜치가 많은 이유는 납득할 수 있지만, 어떻게 이 많은 브랜치를 관리해야 할지 관리 방안에 대해 고민이 깊어졌습니다. 현재 프로젝트의 깃 상황은 아래와 같습니다.
2025년 04월 28일
Commit 수정 매번 사용하는 커멘드가 아니면 한 번 써봤더라도 잊기마련입니다. 이번에는 커밋 메세지를 수정하는 것에 대해 짧게 기록하려합니다. 커밋을 수정하고자 할 때는 크게 세 가지가 있다고 생각합니다. 1. 아직 푸시 하지 않은 커밋 메세지 수정 2. 방금 푸시 한 커밋 메세지 수정 3. 예전에 푸시했던 커밋 메세지 수정 위 순번에 따라 커멘드를 입력하고 수정하는 절차가 좀 늘어나거나 명령을 바꿔서 써줘야하는 번거로움이 있다고 생각이 듭니다.
2023년 06월 05일깃 브랜치 덮어쓰기 main 브랜치를 새로운 브랜치로 교체할 일이 생겨 시도하다보니 아래와 같은 메세지가 나왔습니다.
2022년 01월 17일