본문 바로가기

CI.CD

(30)
[GIT] Git 자동화 스크립트 (Hooks & Husky) 이번 포스팅에서는 [생산성 향상 & 팁] 파트의 세부 주제인 Git 자동화 스크립트 (Hooks & Husky)에 대하여 상세히 알아보겠습니다.1. Git Hooks의 원리Git Hooks는 데이터베이스의 트리거(Trigger)처럼, commit, push, merge 등의 특정한 Git 이벤트가 발생하기 직전(pre) 또는 직후(post)에 사용자가 정의한 쉘 스크립트가 자동으로 실행되도록 하는 훅(Hook) 매커니즘입니다. 이를 통해 빌드 에러가 나는 코드나 코드 컨벤션(Lint)을 지키지 않은 코드가 아예 커밋되지 못하도록 원천 차단할 수 있습니다.2. 프론트엔드 환경에서의 Husky 도입Git 내장 Hooks는 쉘 스크립트로 작성해야 하고 동료들에게 공유하기 까다롭다는 단점이 있습니다. JavaS..
[GIT] 명령어 단축어(Alias)로 생산성 극대화 이번 포스팅에서는 [생산성 향상 & 팁] 파트의 세부 주제인 명령어 단축어(Alias)로 생산성 극대화에 대하여 상세히 알아보겠습니다.1. Alias의 강력함개발을 하다 보면 하루에도 수십 번씩 git status, git checkout 등의 명령어를 타이핑하게 됩니다. Git은 이러한 명령어들을 자신이 원하는 짧은 단어로 축약(Alias)하여 사용할 수 있는 자체 설정 기능을 제공합니다.2. 추천 Alias 설정 목록아래의 명령어들을 터미널에 한 번씩만 입력해 두면, 영구적으로 축약어를 사용할 수 있습니다.# 기본 명령어 축약$ git config --global alias.st status$ git config --global alias.co checkout$ git config --global a..
[GIT] 프로페셔널한 커밋 메시지 작성 가이드 이번 포스팅에서는 [생산성 향상 & 팁] 파트의 세부 주제인 프로페셔널한 커밋 메시지 작성 가이드에 대하여 상세히 알아보겠습니다.1. 커밋 메시지는 문서다자신이 작성한 코드를 6개월 뒤에 다시 보거나, 다른 동료가 인수인계를 받을 때 가장 먼저 들여다보는 것이 바로 커밋 메시지 이력입니다. 코드의 '변경 내용(How)'은 소스 코드의 diff를 통해 알 수 있지만, '변경 이유(Why)'는 오직 커밋 메시지를 통해서만 파악할 수 있습니다.2. Conventional Commits 규약오픈소스 커뮤니티를 중심으로 정립된 규약으로, 머리말(Prefix)을 달아 커밋의 성격을 직관적으로 분류하는 방식입니다. 자동화된 릴리스 노트 작성 도구 등과 연동하기에도 매우 유리합니다.feat: 어플리케이션에 새로운 기능..
[GIT] 성공적인 협업을 위한 필수 권장 사항 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 성공적인 협업을 위한 필수 권장 사항에 대하여 상세히 알아보겠습니다.1. 출근 후 첫 작업은 최신화부터로컬 컴퓨터에서 코드 작성을 시작하기 전, 습관적으로 git pull을 수행하여 메인 브랜치의 최신 상태를 로컬과 동기화해야 합니다. 하루 이틀 동기화를 미룬 채 구버전 코드 위에서 작업하다 보면, 추후 병합 시 감당할 수 없는 엄청난 충돌(Conflict) 폭탄을 맞게 됩니다.2. Pull 시 Rebase 옵션 활용 (선택적)일반적인 git pull은 원격의 변경 사항과 로컬의 변경 사항을 섞으면서 불필요한 'Merge Commit'을 무수히 생성하게 됩니다. 이를 방지하고 히스토리를 선형으로 깔끔하게 유지하기 위해 rebase 옵션을 사용할 수..
[GIT] 저장소 안의 저장소 (Submodule) 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 저장소 안의 저장소 (Submodule)에 대하여 상세히 알아보겠습니다.1. 서브모듈(Submodule)의 개념여러 개의 마이크로서비스 프로젝트나 다양한 프론트엔드 프로젝트에서 공통적으로 사용하는 핵심 라이브러리 코드가 있다고 가정해 보겠습니다. 코드를 복사해서 붙여넣는 방식은 유지보수 측면에서 재앙에 가깝습니다. Git 서브모듈은 하나의 상위 Git 저장소 내부에 완전히 독립된 다른 Git 저장소를 하위 디렉토리로 삽입하고 관리할 수 있게 해주는 기능입니다.2. 서브모듈 추가 및 클론서브모듈은 상위 저장소와 완전히 분리된 커밋 이력을 가집니다. 상위 저장소는 단지 "서브모듈의 특정 커밋 해시(버전)"만을 가리키는 형태로 관리됩니다.# 현재 진행 ..
[GIT] 오픈소스 기여의 첫걸음 (Fork) 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 오픈소스 기여의 첫걸음 (Fork)에 대하여 상세히 알아보겠습니다.1. Fork 워크플로우의 필요성보안과 관리의 목적으로, 대규모 오픈소스 프로젝트나 타 팀의 프로젝트에는 직접적으로 코드를 밀어 넣을(Push) 수 있는 권한이 제한되어 있습니다. 이처럼 쓰기 권한이 없는 저장소의 코드를 수정하여 기여(Contribute)하고 싶을 때 사용하는 방식이 Fork 워크플로우입니다.2. Fork 기반 협업 단계Fork는 GitHub 상에서 원본 저장소 전체를 내 계정 공간으로 완벽하게 복제해 오는 행위입니다.GitHub 원본 저장소 페이지 우측 상단의 Fork 버튼을 클릭하여 내 계정으로 프로젝트를 복사합니다.내 계정에 생성된 복사본 저장소를 내 로컬 컴..
[GIT] 코드 리뷰의 중심, Pull Request (PR) 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 코드 리뷰의 중심, Pull Request (PR)에 대하여 상세히 알아보겠습니다.1. Pull Request의 개념Pull Request(이하 PR)는 자신이 작업한 브랜치의 코드를 메인 베이스 브랜치로 병합(Merge)해 달라고 프로젝트 관리자나 동료들에게 요청하는 과정입니다. 이는 Git 자체의 기능이 아닌 GitHub, GitLab과 같은 원격 저장소 호스팅 서비스가 제공하는 기능으로, 현대적인 코드 리뷰 문화를 정착시킨 핵심 시스템입니다.2. 올바른 PR 생성 및 리뷰 절차PR은 단순히 코드를 합치는 행위가 아니라, 내가 작성한 코드를 타인에게 설명하고 피드백을 수용하는 소통의 장입니다.목적 명시: PR 제목과 본문(Description)..
[GIT] 성공적인 협업을 위한 브랜치 전략 모음 이번 포스팅에서는 [협업 워크플로우] 파트의 세부 주제인 성공적인 협업을 위한 브랜치 전략 모음에 대하여 상세히 알아보겠습니다.1. 브랜치 전략(Branching Model)의 중요성다수의 개발자가 동일한 프로젝트 저장소를 공유할 때, 규칙 없이 브랜치를 생성하고 병합하면 필연적으로 코드 충돌과 배포 지연이 발생합니다. 이를 방지하기 위해 소프트웨어 업계에서는 검증된 몇 가지 브랜치 전략 패턴을 표준으로 채택하여 사용합니다.2. 주요 브랜치 전략 비교프로젝트의 성격과 배포 주기에 따라 적합한 전략을 선택하는 것이 중요합니다.Git Flow가장 전통적이고 엄격한 모델입니다. master(배포), develop(개발 중심), feature(기능 단위), release(배포 준비), hotfix(긴급 버그 수..
[GIT] 장애 원인 추적: Blame & Bisect 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 장애 원인 추적: Blame & Bisect에 대하여 상세히 알아보겠습니다.1. 라인별 작성자 추적 (Blame)운영 중인 서비스에서 특정 코드 라인으로 인해 치명적인 에러가 발생했을 때, 해당 코드를 누가, 언제, 어떤 커밋 메시지와 함께 추가했는지 즉각적으로 파악해야 합니다. git blame은 파일의 각 줄(Line)마다 수정된 마지막 커밋 내역을 보여줍니다.# utils.js 파일의 모든 줄에 대한 변경 이력 조회$ git blame src/utils.js# 너무 길 경우 특정 라인(예: 50~60번 줄)만 지정해서 조회$ git blame -L 50,60 src/utils.js2. 이진 탐색으로 버그 커밋 찾기 (Bisect)수십..
[GIT] 소프트웨어 릴리스 버전 마킹 (Tag) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 소프트웨어 릴리스 버전 마킹 (Tag)에 대하여 상세히 알아보겠습니다.1. Tag의 목적과 특성소프트웨어 개발 과정에서 의미 있는 마일스톤(예: v1.0.0 정식 출시)에 도달했을 때, 해당 시점의 소스 코드를 쉽게 찾을 수 있도록 북마크를 남기는 기능이 바로 태그(Tag)입니다. 브랜치(Branch)와 유사하게 특정 커밋을 가리키는 포인터 역할을 하지만, 커밋이 추가되더라도 태그가 가리키는 위치는 절대 변하지 않는다는(Read-only) 결정적인 차이가 있습니다.2. Tag의 두 가지 종류와 생성 방법Git은 가벼운 태그(Lightweight)와 주석 태그(Annotated) 두 가지 형식을 지원합니다.Lightweight Tag: 이름..
[GIT] 사라진 커밋 구출 작전 (Reflog) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 사라진 커밋 구출 작전 (Reflog)에 대하여 상세히 알아보겠습니다.1. 최후의 보루, Reflog터미널 조작 중 실수로 git reset --hard 명령어를 실행하여 수 일간 작업한 커밋이 허공으로 증발해버린 경험은 누구나 한 번쯤 겪게 됩니다. git log를 쳐도 기록이 나오지 않아 절망스럽지만, Git은 내부적으로 사용자의 브랜치 이동 경로와 모든 행위(커밋, 리셋, 병합 등)를 기록하는 일지인 Reference Log(Reflog)를 유지하고 있습니다.2. 복구 절차Reflog를 열람하면 이미 삭제되어 일반 히스토리에는 보이지 않는 커밋 해시들까지 전부 조회할 수 있습니다.# 1. 모든 조작 기록과 당시의 커밋 해시 출력$ g..
[GIT] 최근 커밋 덮어쓰기 및 편집 (Amend) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 최근 커밋 덮어쓰기 및 편집 (Amend)에 대하여 상세히 알아보겠습니다.1. 방금 한 실수 만회하기 (--amend)커밋을 남기고 엔터를 치는 순간 오타를 발견하거나 변경 파일 하나를 누락한 사실을 깨달을 때가 있습니다. 이럴 때 불필요한 '수정 커밋'을 추가로 남기지 않고 직전의 커밋 자체를 뜯어고쳐 덮어쓰는 옵션이 --amend 입니다.# 누락했던 파일을 뒤늦게 준비 영역에 추가$ git add missed_file.css# 직전 커밋에 해당 파일을 슬쩍 포함시키고, 메시지 편집창 열기$ git commit --amend# 에디터 화면 생략하고 바로 메시지만 수정하여 덮어쓰기$ git commit --amend -m "결제 오류 수정..
[GIT] 특정 커밋만 선별하여 가져오기 (Cherry-pick) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 특정 커밋만 선별하여 가져오기 (Cherry-pick)에 대하여 상세히 알아보겠습니다.1. Cherry-pick 이란?전체 브랜치를 하나로 묶는 Merge나 Rebase와 달리, 다른 브랜치에 존재하는 여러 커밋 중 오직 내가 원하는 1~2개의 특정 커밋 패치 내용만을 복사하여 현재 브랜치 끝에 붙여넣는 섬세한 기술입니다. 마치 체리 바구니에서 잘 익은 체리만 쏙 골라내는 것과 같아 붙여진 이름입니다.2. 실무 활용 사례 및 명령어일반적으로 다음과 같은 상황에서 진가를 발휘합니다.핫픽스 브랜치에서 긴급하게 고친 버그 커밋 하나만 현재 개발 중인 메인 브랜치로 이식할 때실수로 다른 브랜치에서 작성한 커밋을 원래 의도한 브랜치로 가져오고, 이..
[GIT] 과거 시점으로 되돌리기 (Reset & Revert) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 과거 시점으로 되돌리기 (Reset & Revert)에 대하여 상세히 알아보겠습니다.1. 과거의 커밋 자체를 지우고 돌아가기 (Reset)reset은 특정 커밋 시점으로 완전히 시계를 돌려버리며, 그 이후의 미래 커밋 내역을 히스토리에서 삭제합니다. 돌아가는 방식에 따라 3가지 모드가 있습니다.--soft: 지정한 커밋으로 돌아가지만 수정한 코드는 보존되며 '준비 영역(Staged)'에 그대로 둡니다. (주로 커밋 메시지 재작성에 쓰임)--mixed: (기본값) 코드는 보존되지만 '준비 영역'에서 내려온 상태(Unstaged)로 둡니다.--hard: 시점 이후의 코드 수정 사항마저 모조리 파기하고 완벽히 과거로 회귀합니다. (매우 주의해서..
[GIT] 미완성 작업 임시 저장하기 (Stash) 이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 미완성 작업 임시 저장하기 (Stash)에 대하여 상세히 알아보겠습니다.1. Stash의 필요성과 원리개발을 진행하던 중 긴급하게 운영 환경 버그를 처리해달라는 요청을 받는 경우가 흔히 발생합니다. 이 때 작업 중인 코드를 강제로 Commit하면 이력이 더러워지고, 그렇다고 브랜치를 그냥 이동(Checkout)하자니 현재 파일들의 변경 사항 때문에 이동이 거부됩니다. 이러한 난감한 상황을 해결하는 임시 클립보드가 바로 Stash입니다. 코드를 안전하게 보관함에 넣고 워킹 디렉토리를 이전 커밋 상태로 깨끗하게 비워줍니다.2. 주요 Stash 명령어Stash는 스택(Stack) 구조로 동작하므로 여러 개의 작업을 차곡차곡 보관할 수 있습니다...
[GIT] 안전하고 깔끔한 브랜치 관리 전략 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 안전하고 깔끔한 브랜치 관리 전략에 대하여 상세히 알아보겠습니다.1. 종료된 브랜치의 정리병합이 완료되어 더 이상 사용하지 않는 기능 브랜치는 방치하지 않고 즉각 삭제하는 것이 로컬 저장소 관리에 이롭습니다. 브랜치 수가 너무 많아지면 추적과 관리가 힘들어집니다.# 현재 브랜치에 안전하게 병합된 로컬 브랜치 삭제 (-d 소문자)$ git branch -d feature-login# 병합 여부와 상관없이 강제로 로컬 브랜치 삭제 (-D 대문자)$ git branch -D feature-experimental# 원격 저장소(origin)에 존재하는 브랜치 삭제$ git push origin --delete feature-login2. 브랜치 동기화 최적..
[GIT] Merge와 Rebase의 차이 및 선택 기준 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 Merge와 Rebase의 차이 및 선택 기준에 대하여 상세히 알아보겠습니다.1. 병합 방식의 근본적인 차이두 명령어 모두 코드를 합친다는 목적은 동일하지만, 기록을 남기는 철학이 다릅니다.Merge (병합): 두 갈래의 역사를 있는 그대로 보존합니다. 어디서 분기되었고 언제 합쳐졌는지(Merge Commit)에 대한 족적이 남습니다. 하지만 수십 개의 기능 브랜치가 동시에 병합될 경우, 로그 그래프가 거미줄처럼 매우 복잡해지는 단점이 있습니다.Rebase (재배치): 커밋들을 뜯어내어 한 줄로 다시 이어 붙입니다. 병합 커밋이 발생하지 않으며, 그래프가 마치 한 사람이 순차적으로 개발한 것처럼 일직선으로 매우 깔끔해집니다. 단점은 실제 커밋이 발생..
[GIT] 히스토리를 선형으로 정리하기 (Rebase) 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 히스토리를 선형으로 정리하기 (Rebase)에 대하여 상세히 알아보겠습니다.1. Rebase의 원리Rebase는 직역하면 베이스(Base)를 다시(Re) 설정한다는 의미입니다. 파생된 브랜치의 시작점을 대상 브랜치의 가장 최신 커밋으로 재배치하는 작업을 수행합니다. 병합 커밋(Merge Commit)을 남기지 않기 때문에 여러 갈래로 뻗은 복잡한 브랜치 구조를 단일 선형 히스토리로 깔끔하게 정리해 주는 특성이 있습니다.2. Rebase 수행 방법Rebase를 수행할 때는 Merge와 반대로 내가 작업 중인 브랜치에 머무른 상태에서 기준이 될 브랜치를 지정합니다.# 1. 작업 중인 기능 브랜치로 이동$ git switch feature-login# 2..
[GIT] 충돌(Conflict) 발생 원인과 해결 가이드 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 충돌(Conflict) 발생 원인과 해결 가이드에 대하여 상세히 알아보겠습니다.1. 충돌(Conflict)이 발생하는 이유병합 과정에서 빈번하게 겪게 되는 난관이 바로 병합 충돌(Merge Conflict)입니다. 이는 두 개의 브랜치가 동일한 파일의 동일한 라인을 서로 다르게 수정했을 때 발생합니다. Git은 어느 코드를 최종적으로 선택해야 할지 판단할 수 없기 때문에, 자동 병합을 중지하고 사용자에게 직접 결정을 맡깁니다.2. 충돌 해결 절차충돌이 발생하면 당황하지 말고 아래의 절차에 따라 순차적으로 코드를 정리합니다.# 1. 병합 시도 시 충돌 메시지 확인 후 상태 파악$ git status# (Both modified 상태로 표기된 파일들이 ..
[GIT] 작업 내용 합치기 (Merge) 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 작업 내용 합치기 (Merge)에 대하여 상세히 알아보겠습니다.1. Merge의 개념 및 목적분기되어 개별적으로 진행된 브랜치의 작업 내역들을 다시 메인 코드 라인으로 통합하는 과정을 병합(Merge)이라고 부릅니다. 기능 개발이나 버그 픽스가 완료된 시점에서, 파편화된 소스 코드를 하나로 모으기 위해 필수적으로 거치는 단계입니다.2. Merge 수행 방법 및 종류병합을 수행할 때는 항상 코드를 '받아들일' 목적지 브랜치로 먼저 이동(Checkout)한 뒤에, 합쳐질 대상 브랜치를 지정해야 합니다.# 1. 기준이 되는 브랜치(주로 main)로 먼저 이동$ git switch main# 2. 작업이 완료된 브랜치를 main으로 병합$ git merge..
[GIT] 브랜치 만들기 (Branch) 이번 포스팅에서는 [브랜치와 병합] 파트의 세부 주제인 브랜치 만들기 (Branch)에 대하여 상세히 알아보겠습니다.1. 브랜치(Branch)의 개념소프트웨어 개발 중에는 기존의 안정적인 소스 코드를 유지하면서, 실험적인 기능 추가나 치명적인 버그 수정을 동시에 진행해야 하는 경우가 발생합니다. 브랜치는 메인 코드 라인에서 분기하여, 원본에 영향을 주지 않는 독립적인 작업 환경을 만들어주는 강력한 도구입니다. 각 브랜치는 마치 브랜치처럼 서로 간섭 없이 개별적인 커밋 히스토리를 쌓아갈 수 있습니다.2. 브랜치 생성 및 관리명령어를 통해 현재 생성된 브랜치 목록을 확인하거나, 새로운 분기를 생성하고 이동할 수 있습니다.# 로컬 및 원격 저장소의 모든 브랜치 목록 확인$ git branch -a# 'feat..
[GIT] 불필요한 파일 무시하기(.gitignore) 이번 포스팅에서는 [Git 기초] 파트의 세부 주제인 불필요한 파일 무시하기에 대하여 상세히 알아보겠습니다.1. .gitignore 파일의 역할프로젝트 디렉토리 내에는 빌드 결과물, 의존성 라이브러리 폴더(예: node_modules), IDE 설정 파일, 혹은 데이터베이스 비밀번호가 포함된 환경 변수 파일 등 버전 관리에 포함되어서는 안 되는 파일들이 다수 존재합니다. 이러한 파일들이 실수로 git add되는 것을 방지하기 위해 프로젝트 최상단에 .gitignore 파일을 생성하고 규칙을 명시합니다.2. 작성 규칙 및 예시.gitignore 파일 내에는 정규 표현식과 유사한 패턴을 사용하여 무시할 대상을 지정할 수 있습니다.# 특정 디렉토리 전체를 무시 (후행 슬래시 사용)node_modules/bui..
[GIT] 코드 올리고 내려받기 이번 포스팅에서는 [Git 기초] 파트의 세부 주제인 코드 올리고 내려받기에 대하여 상세히 알아보겠습니다.1. 변경 내역 업로드 (push)로컬 저장소에 커밋된 변경 사항들을 원격 저장소로 업로드하여 동기화할 때 git push 명령어를 사용합니다. 이 과정을 통해 다른 팀원들도 나의 작업 결과를 원격 서버에서 확인할 수 있게 됩니다.# 'origin' 원격 저장소의 'main' 브랜치로 로컬의 커밋들을 업로드$ git push origin main# -u 옵션을 사용하여 기본 추적 브랜치로 설정 (이후에는 git push만 입력해도 됨)$ git push -u origin main2. 최신 변경 내역 다운로드 (pull)다른 팀원이 원격 저장소에 새로운 커밋을 업로드했다면, 로컬 환경을 최신 상태로 갱..
[GIT] 원격 저장소(Remote) 연결 이번 포스팅에서는 [Git 기초] 파트의 세부 주제인 원격 저장소(Remote) 연결에 대하여 상세히 알아보겠습니다.1. 원격 저장소의 개념로컬 컴퓨터에서 버전을 관리하는 것만으로는 데이터 백업이나 팀원과의 원활한 협업이 불가능합니다. 이를 위해 로컬 저장소를 GitHub, GitLab, Bitbucket과 같은 인터넷상의 호스팅 서비스에 연결해야 하는데, 이 클라우드 공간을 원격 저장소(Remote Repository)라고 칭합니다.2. 원격 저장소 등록 및 관리로컬 저장소에 새로운 원격 저장소 주소를 매핑할 때는 git remote add 명령어를 사용합니다. 관례적으로 메인 원격 저장소의 이름(별칭)은 origin으로 설정합니다.# 'origin'이라는 이름으로 원격 저장소 주소 등록$ git re..

티스토리툴바