#git
노트 22개
Frontend › UI Design
디자이너는 어떻게 코드를 배우나디자이너가 코드를 배우는 목적은 엔지니어가 되는 것이 아니라 디자인의 재료를 이해하는 것이다. 터미널과 코드 에디터, Git의 포크·커밋·풀 리퀘스트, 시맨틱 HTML과 CSS 기초, 토큰·컴포넌트·DRY 같은 공학 개념을 순서대로 익히고, 공학적 결정은 엔지니어에게 맡긴다.
Tools › Dev Environment
Windows 개발 환경: 터미널, Git 설치, 줄바꿈터미널·셸의 뜻과 CMD·PowerShell·Git Bash의 차이, Windows용 Git 설치 때 고를 옵션, 그리고 Windows에서 자주 만나는 CRLF 줄바꿈 오류(Prettier의 Delete ␍)를 정리한 노트.
Tools
Git코드의 변경 이력을 기록하고 여러 사람이 동시에 작업할 수 있게 해 주는 분산 버전 관리 시스템.
Tools › Git
대형 저장소에서 Git 빠르게 쓰기: 얕은 클론, refspec, 부분 클론, 희소 체크아웃커밋 이력과 파일이 많은 모노레포에서 clone·checkout·status가 느려지는 원인과 줄이는 방법을 정리했다. 이력을 자르는 얕은 클론, 받을 브랜치를 좁히는 단일 브랜치·refspec, 파일 내용을 나중에 받는 부분 클론, 작업 트리를 일부만 펼치는 희소 체크아웃, 파일 감시와 백그라운드 유지 보수까지 다루고 CI와 개발자 PC에서 각각 무엇을 쓰는지 정리한다.
Tools › Git
모노레포와 폴리레포여러 서비스의 코드를 저장소 하나에 두는 모노레포와 서비스마다 저장소를 나누는 폴리레포(마이크로레포)를 구조·권한·의존성 버전·코드 품질 기준·도구 면에서 비교하고, 폴리레포에서 의존성 버전을 맞추는 방법으로 버전 세트 기반 빌드 시스템(Amazon Brazil)의 구조를 정리했다.
Tools › Git
브랜치 전략: Git Flow, GitHub Flow, 트렁크 기반 개발팀이 브랜치를 어떻게 나누고 언제 합치는지 정한 규칙. 릴리스 주기가 긴 제품에 맞는 Git Flow(main·develop·feature·release·hotfix), 지속 배포에 맞는 GitHub Flow(main + 짧은 기능 브랜치 + PR), 하루 단위로 trunk에 합치는 트렁크 기반 개발을 비교하고 고르는 기준과 git-flow 도구의 현재 상태, 중앙 집중·기능 브랜치·포크 워크플로의 차이를 정리했다.
Tools › Git
영어 커밋 메시지 동사 사전영어 커밋 메시지는 작문이 아니라 패턴이다. Fix·Add·Remove·Use·Update·Improve·Make·Ensure·Prevent·Avoid 같은 동사 20여 개와 in·to·for·when·where 같은 전치사 패턴만으로 대부분의 커밋을 쓸 수 있다. 동사별 쓰임과 서로 헷갈리는 동사의 구분, 간결하게 쓰는 규칙을 정리한다.
Tools › Git
원격 저장소와 GitHubGit(버전 관리 도구)과 GitHub(호스팅·협업 서비스)의 차이, remote·push·pull·fetch·clone으로 로컬 저장소를 GitHub 같은 원격 저장소와 동기화하는 방법과, 이력을 유지한 채 다른 서비스로 옮기는 미러링.
Tools › Git
자주 쓰는 Git 설정 옵션개발자들이 실제로 켜 두는 git config 옵션을 pull·merge·rebase·diff·전역 설정별로 묶었다. 대부분 기본값의 불편함을 고치는 한 줄 설정이다.
Tools › Git
작업 중인 변경 다루기: stash, worktree, clean커밋하기 애매한 작업을 잠시 치워 두는 stash, 브랜치를 바꾸지 않고 다른 브랜치를 옆 폴더에 펼치는 worktree, 추적하지 않는 파일을 지우는 clean을 정리했다. 잠깐 끼어든 일이면 stash, 오래 병행할 일이면 worktree가 기본이다.
Tools › Git
커밋 컨벤션과 자동 검사좋은 커밋 메시지의 7가지 규칙(빈 줄, 50/72자, 명령문 제목, 무엇·왜 본문)과 type(scope): subject 형식의 컨벤션, 커밋 템플릿 설정, husky와 commitlint로 규칙을 자동 검사하는 방법.
Tools › Git
Git 기본 명령과 파일 상태Git이 분산 버전 관리 시스템으로서 중앙 집중식(SVN)과 다른 점, 저장소를 만들고 add·commit으로 버전을 기록하며, 파일이 untracked·modified·staged·committed 상태를 오가는 흐름, 작업 디렉터리·스테이징·로컬·원격 네 곳 사이에서 명령이 코드를 옮기는 방식. 커밋을 식별하는 해시도 함께 다룬다.
Tools › Git
Git 되돌리기와 이력 다루기reflog로 지나온 상태를 찾아 되돌리는 법과 상황별 복구 레시피(마지막 커밋 고치기, 다른 브랜치에 잘못한 커밋 옮기기, 파일 하나 되돌리기, 원격 상태로 초기화), reset·revert로 커밋을 되돌리고, cherry-pick으로 커밋 하나를 옮기며, 진행 중인 merge·rebase를 --abort로 취소하고, 푸시한 민감 정보·작성자를 filter-repo로 정리하는 방법. 공유된 이력이면 revert, 내 로컬 이력이면 reset이 기본이다.
Tools › Git
Git 브랜치원본에 영향을 주지 않고 독립적으로 작업할 수 있도록 커밋 흐름을 나누는 Git의 핵심 기능.
Tools › Git
Git 브랜치 병합갈라진 브랜치를 하나로 합치는 방법으로, Fast-Forward·3-Way Merge·Merge Conflict 세 가지 상황이 있다.
Tools › Git
Git 이력 검색: log 필터, grep, pickaxe, blame, bisect커밋 이력에서 원하는 것을 찾는 방법을 질문별로 정리했다. 범위 표기(A..B, A...B)와 log 필터(작성자·기간·메시지·파일), 지금 코드에서 찾는 git grep, 코드가 생기거나 사라진 커밋을 찾는 pickaxe(-S, -G)와 log -L, 줄마다 마지막 수정을 보는 blame, 버그를 넣은 커밋을 이진 탐색하는 bisect까지 다룬다.
Tools › Git
Git의 내부 구조: 객체와 인덱스.git 폴더 안의 objects(blob·tree·commit)와 index가 add·commit 때 어떻게 만들어지는지, 내용 기반 해시(체크섬)로 데이터를 관리하고 변경분이 아닌 스냅숏을 저장하는 원리.
Tools › Git
GitHub 이슈·프로젝트로 진행 상황 관리하기GitHub Issues를 작업 목록으로, Projects를 우선순위·상태 보드로 쓰고, 이슈를 브랜치·커밋·PR과 연결하면 저장소 하나에서 팀의 진행 상황이 투명하게 보인다. 이슈 크기 기준, 마일스톤·하위 이슈·프로젝트 보드(Status 칸과 기본 워크플로)로 묶어 보는 법, 스크럼 대응, 팀 개발 흐름과 리뷰 제출 종류, 문서화 원칙을 정리했다.
Tools › Git
GitHub 협업 저장소 설정팀 저장소를 처음 세팅할 때 할 일: 협업자·브랜치 보호 규칙·CODEOWNERS·이슈/PR 템플릿(마크다운 템플릿과 YAML 이슈 폼, config.yml)·라벨, 그리고 PR 알림 도구와 기능별 브랜치 습관.
Tools › Git
merge·squash·rebase 언제 쓰나PR을 합칠 때 merge 커밋, squash, rebase·인터랙티브 rebase를 상황에 따라 고르는 기준. 기본은 merge 커밋(진짜 이력, 쉬운 되돌리기, 잘게 쪼개진 bisect), 작은 diff에 WIP가 많으면 squash, 큰 diff에 WIP가 많으면 인터랙티브 rebase로 다듬는다.
Tools
The Missing Semester: CS 교육에서 빠진 도구 학기MIT의 무학점 과정 The Missing Semester는 전공 수업이 가르치지 않는 셸, 편집기, Git, 디버깅, 패키징, 코드 품질 도구와 코딩 에이전트 활용을 9강으로 다룬다. 강의별 핵심 개념과 도구, 이 창고의 관련 노트를 지도처럼 묶었다.
Career › Work
오픈소스 프로젝트 운영: 도입, 포크, 문서, 확산, 유지오픈소스는 공개만으로 쓰이지 않는다. 쓸 라이브러리는 인기·문서·인터페이스로 고르고, 포크할 때는 당위와 계획으로 신뢰를 얻는다. 문서와 예제가 성패를 가르고, 공개 후에는 이슈 대응·로드맵·메인테이너의 지속 가능성이 프로젝트를 살린다.