GIT - Mai-Nova/AIssue-Overview GitHub Wiki

• Git 의 명령어 정리 및 설명
• 출처 : https://git-scm.com/book/ko/v2

1. git conflict가 지속적으로 났다.

   1-1. merge 할 때 PR에서 conflict 난 경우

   1-2. branch를 기존의 branch에서 분기해서 새로 파는 경우

1-1. push 하기 전 마지막 실행(Postman)

• merge를 함으로서 side effect 가 발생하기 때문에 서로의 코드가 잘 되는지 먼저 확인한다 → 실행도 시켜보기

1-1. 작은 단위로 수정했으면 commit을 한다 → 더해서 PR 을 작게 자주 날린다.

1-2. 새 작업은 항상 main에서 시작하되, 반드시 git pull origin main으로 최신화 후 브랜치 파기! (참고 - 브랜치 분기쪽 보기)

1-2. 현재 브랜치에서 새 브랜치를 파는 경우는 현재 작업 중인 내용을 이어서 확장하거나 세분화

• 워킹 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나눈다.
• Tracked 파일은 이미 스냅샷에 포함돼 있던 파일이다. Tracked 파일은 또 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 상태 중 하나이다. 간단히 말하자면 Git이 알고 있는 파일이라는 것이다.
• 그리고 나머지 파일은 모두 Untracked 파일이다. Untracked 파일은 워킹 디렉토리에 있는 파일 중 스냅샷에도 Staging Area에도 포함되지 않은 파일이다. 처음 저장소를 Clone 하면 모든 파일은 Tracked이면서 Unmodified 상태이다. 파일을 Checkout 하고 나서 아무것도 수정하지 않았기 때문에 그렇다.
• 마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서 어떤 파일을 수정하면 Git은 그 파일을 Modified 상태로 인식한다. 실제로 커밋을 하기 위해서는 이 수정한 파일을 Staged 상태로 만들고, Staged 상태의 파일을 커밋한다. 이런 라이프사이클을 계속 반복한다

파일이 어디에 위치한지 확인

• Changes to be committed:Staged 상태라는 것을 의미한다.
• Changes not staged for commit : 이것은 수정한 파일이 Tracked 상태이지만 아직 Staged 상태는 아니라는 것이다.

• Staged 상태이면서 동시에 Unstaged 상태 : git add 명령을 실행하면 Git은 파일을 바로 Staged 상태로 만든다. 지금 이 시점에서 커밋을 하면 git commit 명령을 실행하는 시점의 버전이 커밋되는 것이 아니라 마지막으로 git add 명령을 실행했을 때의 버전이 커밋된다. 그러니까 git add 명령을 실행한 후에 또 파일을 수정하면 git add 명령을 다시 실행해서 최신 버전을 Staged 상태로 만들어야 한다.

• 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다. 이 명령은 리모트 저장소의 단축 이름을 보여준다.

git remote

origin

git remote show <리모트 저장소 이름> 명령으로 리모트 저장소의 구체적인 정보를 확인할 수 있다

리모트 저장소의 URL과 추적하는 브랜치를 출력한다. 이 명령은 git pull 명령을 실행할 때 master 브랜치와 Merge 할 브랜치가 무엇인지 보여 준다. git pull 명령은 리모트 저장소 브랜치의 데이터를 모두 가져오고 나서 자동으로 Merge 할 것이다. 그리고 가져온 모든 리모트 저장소 정보도 출력한다. 브랜치명을 생략하고 git push 명령을 실행할 때 어떤 브랜치가 어떤 브랜치로 Push 되는지 보여준다. 또 아직 로컬로 가져오지 않은 리모트 저장소의 브랜치는 어떤 것들이 있는지, 서버에서는 삭제됐지만 아직 가지고 있는 브랜치는 어떤 것인지, git pull 명령을 실행했을 때 자동으로 Merge 할 브랜치는 어떤 것이 있는지 보여준다.

git remote show origin

remote origin
Fetch URL: https://github.com/Mai-Nova/AIssue-BE-Express.git
Push URL: https://github.com/Mai-Nova/AIssue-BE-Express.git
HEAD branch: main
Remote branches:
    backup/feature-repository tracked
    feature/DBconnect tracked
    feature/login tracked
    feature/repository tracked
    main tracked
Local branches configured for 'git pull':
   feature/database merges with remote feature/database
   feature/repository merges with remote feature/repository
   main merges with remote main
Local refs configured for 'git push':
   feature/repository pushes to feature/repository (up to date)
   main pushes to main (local out of date)

stale (use 'git remote prune' to remove)

• stale(지연된 브랜치 참조) : 더이상 원격 저장소에 존재하지 않는 참조(refs)를 말한다.
• 원격 저장소(origin)에서는 feature/repository-merge 브랜치를 삭제했지만
• 로컬의 .git/refs/remotes/origin/ 디렉터리에는 여전히 남아 있는 경우

로컬에 남아 있는 stale 원격 브랜치들을 정리하는 명령어

• 내부 동작
  • .git/refs/remotes/origin/에 있는 브랜치 중, 실제 원격 저장소(origin)에서 사라진 브랜치들을 삭제합니다.

• 파일 또는 디렉토리의 경로를 아규먼트로 받는다. 디렉토리면 아래에 있는 모든 파일들까지 재귀적으로 추가한다.

• 어떤 내용이 변경됐는지 살펴보려면 쓴다
• 마지막으로 커밋한 후에 수정한 것들 전부를 보여주지 않는다.
• Unstaged 상태인 것들만 보여준다.
• 수정한 파일을 모두 Staging Area에 넣었다면 git diff 명령은 아무것도 출력하지 않는다.
• 만약 커밋하려고 Staging Area에 넣은 파일의 변경 부분을 보고 싶으면 git diff --staged 옵션을 사용한다. 이 명령은 저장소에 커밋한 것과 Staging Area에 있는 것을 비교한다. Staged 상태인 파일은 git diff --cached 옵션으로 확인한다. --staged 와 --cached 는 같은 옵션이다.

• rebase 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.
• https://git-scm.com/book/ko/v2/Git-%eb%b8%8c%eb%9e%9c%ec%b9%98-Rebase-%ed%95%98%ea%b8%b0#_rebasing
• 일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다.

• 변경 사항(diff) 을 파일로 저장한 것
• 어떤 커밋이나 변경사항을 텍스트 형식으로 저장한 것입니다.
  • ex) 현재 작업 디렉토리의 변경사항을 .diff 파일로 저장

git diff > my-change.patch

• Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일들만 저장한다.
• Stash는 Modified이면서 Tracked 상태인 파일과 Staging Area에 있는 파일들을 보관해두는 장소다.
• git stash list : 저장한 stash 확인
• git stash branch <브랜치> 명령을 실행하면 Stash 할 당시의 커밋을 Checkout 한 후 새로운 브랜치를 만들고 여기에 적용한다. 이 모든 것이 성공하면 Stash를 삭제한다.

• “References” 또는 “Refs” 라고 부른다.
• Git 내부에서 커밋 객체들을 참조하는 포인터 시스템

• 어떤 커밋 1a410e 이전의 모든 히스토리를 보려면 git log 1a410e 라고 실행하면 히스토리를 볼 수 있지만, 여전히 1a410e 를 기억해야 한다. SHA-1 값을 날로 사용하기보다 쉬운 이름으로 된 포인터가 있으면 그걸 사용하는 게 더 좋다. 외우기 쉬운 이름으로 된 파일에 SHA-1 값을 저장한다.
• 이 SHA-1 값을 저장하는 파일은 .git/refs 디렉토리에 있다. 예제의 프로젝트에는 아직 .git/refs 디렉토리 안에 파일은 없고 디렉토리만 몇 개 있다

로컬 브랜치를 원격 브랜치에 명시적으로 연결(upstream 설정)

git branch --set-upstream-to=origin/main main

관련 명령어

git push -u origin feature/mybranch

→ 처음 push하면서 자동으로 upstream 연결 (-u = --set-upstream)

커밋 히스토리가 없는 새로운 브랜치 만들기

# master/main 브랜치를 초기화 (index 및 working directory 포함 완전 초기화)
git checkout --orphan wiki
git add -A
git commit -m "Initial commit"

원격 저장소 강제 푸시(모든 커밋 , 커밋 이력 삭제)

git push -f origin main

git origin에 있는 master 지우기

git push origin --delete master

git checkout -b feature/login

• 현재 브랜치(예: develop, feature/xyz)에서 바로 브랜치를 분기
• 현재 작업 중인 내용을 이어서 확장하거나 세분화할 때 자주 사용

• feature/repository에서 세부 기능 추가하려고 feature/repository-validation을 만들 때
• 다른 팀원이 작업 중인 브랜치를 이어받아 추가 기능을 넣을 때

git checkout main
git pull origin main
git checkout -b feature/signup

• 항상 최신의 안정된 코드(main) 를 기반으로 새로운 기능을 시작
• 버그 수정, 신규 기능 개발, hotfix 등에서 가장 많이 사용됨

• 새 기능 시작할 때 (ex. feature/payment)
• 긴 작업 후 코드가 꼬였을 가능성 있을 때, 깨끗한 출발점이 필요할 때

새 작업은 항상 main에서 시작하되, 반드시 git pull origin main으로 최신화 후 브랜치 파기!

Vincent Driessen이 만든 전략 (2010).

버전 릴리즈 중심, 브랜치가 여러 개로 나뉨.

1. main에서 develop 분기
2. develop에서 feature/* 브랜치 생성 → 완료되면 develop에 머지
3. 릴리즈 준비 시 release/* 생성 → 테스트 후 main과 develop에 병합
4. 운영 중 버그는 hotfix/*에서 고치고 → main과 develop에 병합

• 역할이 명확 → 릴리즈 관리, QA, hotfix 구분이 쉬움
• 중대형 프로젝트, 버전 관리, 긴 개발주기에 적합

• 브랜치가 너무 많아짐 → 관리 복잡
• 소규모 팀, 빠른 배포에는 과한 전략

GitHub이 제안한 간단한 전략.

지속적 배포(CD) 환경에 최적화됨.

1. 항상 최신 상태의 main 유지 (CI/CD 연동 필수)
2. main에서 feature/abc 브랜치 생성
3. 커밋 & 푸시 → GitHub PR(Pull Request) 생성
4. 리뷰 & 테스트 → main에 병합 후 즉시 배포

• 단순, 빠른 작업 흐름
• 자동화 배포(CI/CD)와 잘 어울림
• 스타트업, 웹서비스, SaaS에 적합

• 릴리즈 계획이 명확하지 않으면 기능 충돌 발생 가능
• develop이 없기 때문에 복잡한 QA나 기능 조합이 어려움

어떤걸 선택하면 좋을까?

• 스타트업, 빠른 기능 개발 → GitHub Flow
• 엔터프라이즈, 릴리즈/QA가 중요한 경우 → Git Flow
• 하이브리드 전략도 가능 → main + develop + 간소화된 feature