studylida

Git 태그: 특정 순간을 기록하는 라벨Git에서 태그(Tag)는 특정 커밋을 가리키는 라벨과 같습니다. 우리가 중요한 순간을 기억하기 위해 사진을 찍듯이, Git 태그는 코드의 특정 시점을 기록하는 역할을 합니다. 특히 소프트웨어 개발에서는 릴리스(Release) 버전을 나타내는 용도로 널리 사용됩니다.📌 Git 태그란?Git 태그는 브랜치 참조(Branch Reference) 와 비슷하지만, 결정적인 차이점이 있습니다. 브랜치 참조: 새로운 커밋이 추가되면 자동으로 이동 태그(Tag): 특정 커밋을 영구적으로 가리킴 (이동하지 않음) 예를 들어, 아래와 같은 Git 히스토리가 있다고 가정해 봅시다.o---o---o---o (main) ↑ v1.0.0여기서 v1.0.0 태..

Git Interactive Rebase란? – 히스토리를 정리하는 강력한 도구Git을 사용하다 보면 작업이 쌓이며 커밋이 많아지고, 때로는 불필요한 커밋이 섞이기도 합니다. "일단 커밋하고 보자"는 식으로 올린 미완성 커밋이나, 버그가 포함된 커밋, 혹은 너무 자잘하게 나눠진 커밋들을 한눈에 보기 쉽도록 정리하고 싶을 때가 있죠.이럴 때 유용한 Git의 강력한 기능이 바로 Interactive Rebase입니다. 기존의 커밋을 유지하는 것이 아니라, 커밋을 편집하고, 병합하고, 삭제하는 등 히스토리를 재구성할 수 있도록 도와주는 기능이죠.Rebase의 두 가지 활용법Git에서 rebase 명령어는 크게 두 가지 방식으로 활용됩니다.머지(merge) 대체용: 기존 브랜치의 커밋을 새로운 브랜치의 끝으로 ..

리베이스가 어려운 이유, 정말 그럴까?Git을 배우다 보면 rebase라는 명령어를 접하게 됩니다. 그런데, 이 명령어에 대한 개발자들의 반응은 극과 극입니다.어떤 회사에서는 “반드시 rebase를 활용하라”고 강조하는 반면, 어떤 팀은 “절대 rebase를 쓰지 말라”고 말하죠.도대체 왜 이렇게 의견이 나뉘는 걸까요? 리베이스는 정말 어려운 개념일까요?🤔 왜 리베이스가 어려운 개념처럼 느껴질까?강의를 진행한 경험이 있는 개발자는 처음 Git을 배울 때, 스승으로부터 “리베이스는 절대 하지 마라”는 조언을 들었다고 합니다.리베이스는 초보자가 건드리기엔 너무 위험한 기능이므로, 굳이 배울 필요가 없다는 것이 그 이유였습니다.“나나 팀원들이 곤란해질 수 있기 때문이라 하면서, 초보자는 몰라도 된다 했어요...

중앙 집중형 워크플로우의 함정: 가장 단순하지만 가장 위험한 방식1. 중앙 집중형 워크플로우란?소프트웨어 개발에서 협업을 할 때, 가장 직관적이고 단순한 방법은 모든 개발자가 하나의 브랜치에서 작업하는 것이다. 이를 중앙 집중형 워크플로우라고 부른다.💡 중앙 집중형 워크플로우모든 개발자가 기본 브랜치(보통 master 또는 main)에서 직접 작업하고, 변경 사항을 즉시 원격 저장소에 반영하는 방식이 방식은 새로운 브랜치를 만들거나 병합할 필요가 없어 단순하다. 하지만 그만큼 치명적인 단점이 많다.2. 중앙 집중형 워크플로우의 동작 방식중앙 집중형 워크플로우에서는 모든 개발자가 동일한 브랜치에서 작업한다. 예를 들어, 아래와 같은 상황을 가정해 보자.📝 개발자 A, B, C가 한 프로젝트를 진행 중프..

GitHub 저장소 가시성: 공개 vs 비공개GitHub에서 저장소(Repository)를 만들 때 가장 먼저 결정해야 할 사항 중 하나는 저장소의 가시성(Visibility) 입니다. 즉, 공개(Public) 로 만들 것인지 비공개(Private) 로 만들 것인지 선택하는 것이죠. 이 두 가지 설정은 GitHub의 협업 방식과 코드 공유에 큰 영향을 미칩니다.1. 공개 저장소(Public Repository)란?공개 저장소는 누구나 접근할 수 있는 저장소 입니다.아래의 특징을 갖습니다.✅ 인터넷에 공개됨 → 누구나 저장소를 검색하고 찾을 수 있음✅ 누구나 내용을 볼 수 있음 → 코드, 이슈, 위키 등을 확인 가능✅ 클론(Clone) 가능 → 저장소의 코드를 복제하여 사용할 수 있음✅ 변경 권한은 없음 ..

원격 추적 브랜치란?GitHub에서 협업을 진행하다 보면, 로컬과 원격 저장소의 상태를 동기화하는 것이 중요한데요. 이때 핵심 개념 중 하나가 바로 원격 추적 브랜치(remote tracking branch) 입니다. 아래에서는 원격 추적 브랜치가 무엇이며, 어떻게 생성되고 활용되는지 시각적인 예시와 함께 알아보겠습니다.1. 저장소 클로닝 시 자동 생성클론(복제) 과정저장소를 처음 클론하면, Git은 로컬에 저장소의 파일과 커밋을 복제합니다. 이때 두 가지 주요 구성요소가 생성됩니다:로컬 브랜치: 예를 들어 master나 main과 같이 기본 브랜치가 생성됩니다.원격 추적 브랜치: 원격 저장소의 최신 상태를 가리키는 책갈피 역할을 하는 브랜치가 생성됩니다. 예를 들어 origin/master 또는 ori..

GitHub 사용법 정리GitHub의 역할GitHub는 Git 저장소를 클라우드에서 호스팅하는 서비스다. 단순한 코드 저장소가 아니라 협업 도구로서도 활용된다.원격 저장소 관리: 언제 어디서나 코드 접근 가능팀 협업 지원: 여러 개발자가 동시에 작업 가능코드 리뷰 및 프로젝트 관리: 이슈 트래킹, 풀 리퀘스트(PR) 지원GitHub를 활용한 협업 예시개발자는 feature/login 브랜치에서 로그인 기능을 개발디자이너는 design/ui-update 브랜치에서 UI를 수정각자의 변경 사항을 GitHub에 푸시 후 리뷰를 거쳐 main에 병합GitHub를 사용하는 이유1. 코드 백업 및 협업원격 저장소를 통해 코드 백업 가능여러 브랜치를 활용한 팀 개발 가능2. 오픈 소스 기여React, TensorFl..

이전 커밋 확인하기: Git의 시간 여행Git에서는 과거의 특정 상태를 확인하고 싶을 때, 해당 커밋을 직접 체크아웃할 수 있습니다. 이를 위해 git log --oneline 명령어를 사용하여 원하는 커밋의 해시를 찾고, git checkout 를 실행하면 됩니다. 과거 커밋 체크아웃하기다음과 같은 브랜치 구조가 있다고 가정해봅시다.* (HEAD -> main) c5d3a1d 최신 커밋* a8f1b2c 새로운 기능 추가* 4f1b3e9 버그 수정* 7a3c2d1 개츠비 → 캐츠비 이름 변경* 3d2e1f7 1장과 2장으로 분리* 9c8b7..

Git Stash: 변경 사항 임시 저장과 복원1. Git Stash 개요git stash는 커밋하지 않은 변경 사항을 임시로 저장하고 워킹 디렉토리를 초기 상태로 되돌리는 기능입니다.이를 통해 브랜치를 자유롭게 이동하면서도 변경 사항을 보관할 수 있습니다.📌 Git Stash가 필요한 상황변경 사항을 커밋하지 않고 다른 브랜치로 이동해야 할 때 작업을 중단하고 나중에 다시 이어서 해야 할 때 불필요한 커밋 없이 변경 사항을 임시 저장하고 복원하고 싶을 때 2. 기본 명령어: git stash와 git stash pop🔹 변경 사항 임시 저장git stash스테이징 여부와 관계없이 변경 사항을 임시 저장 워킹 디렉토리는 커밋된 상태로 초기화됨 🔹 저장된 변경 사항 복원git stash po..

Git Diff: 변경 사항 비교와 활용1. git diff 개요git diff는 변경된 내용을 비교하는 명령어입니다.수정된 파일에서 어떤 부분이 추가되거나 삭제되었는지를 한눈에 확인할 수 있습니다.git diff스테이징되지 않은 변경사항을 비교-는 삭제된 줄, +는 추가된 줄 표시2. git diff 실행 결과 읽기diff --git a/colors.txt b/colors.txt@@ -3,4 +3,5 @@- purple+ indigo+ violetdiff --git a/file b/file → 비교하는 파일 정보@@ -3,4 +3,5 @@ → 이전(3번째 줄부터 4줄) vs 수정된 내용(3번째 줄부터 5줄)- purple → 삭제된 내용+ indigo, + violet → 추가된 내용3. 스테이징되지 ..