Git 모음

Git이 파일을 어떻게 인식하고 있는지

---

🔴 빨간색	Untracked	Git에 추가되지 않은 새 파일
🟢 초록색	Added	git add 된 새 파일 ( 아직 커밋 전 )Git
🔵 파란색	Modified	이미 커밋된 파일이 수정됨
🟡 노란색	Ignored	.gitignore에 의해 무시된 파일
⚪ 흰색 / 기본색	Unchanged	변경 없는 상태 ( 아무 상태 없음 )
⚫ 회색	Deleted	삭제된 파일

초기 설정

---

git init

git remote add origin <레포 URL>

git pull origin main  # GitHub에서 README를 생성한 경우

git add .

git commit -m "message"

git push origin main

Git URL 설정

---

# 현재 등록된 URL 확인
git remote -v

# 맨 처음 URL 설정
git remote add origin [git 주소]

# URL 변경
git remote set-url origin [git 주소]

Git add 취소

---

# 전체 취소
git reset HEAD

# 부분 취소
git reset HEAD [파일명]

Git commit 메세지 수정

---

커밋을 한 상태에서 커밋 메세지를 수정하고 싶다면 git commit --amend 명령어 사용

vi로 커밋 메세지 수정 가능합니다.

이미 push 한 커밋 메세지 수정하고 싶다면 ?

# 수정하려는 커밋이 포함되도록 N개 이전까지 지정
git rebase -i HEAD~N
...

# 그러면 에디터가 열림
...
pick abc1234 과거 커밋 메시지
pick def5678 그 다음 커밋
pick ghi9012 최신 커밋
...

# 수정하고 싶은 커밋의 `pick`을 `reword`로 변경 후 :wq로 저장
...
reword abc1234 과거 커밋 메시지 수정 ㅎㅎㅎ
pick def5678 그 다음 커밋
pick ghi9012 최신 커밋
...

이제 해당 커밋의 메시지를 수정할 수 있는 에디터가 다시 열리는데, 수정 후 저장

변경 내용을 적용해야 하니 git push origin 브랜치명 --force

이때, 커밋 메시지만 변경해도 해시값이 바뀌기 때문에 Git은 새로운 커밋으로 취급하며, 원격과 히스토리가 달라지므로
--force가 필요합니다. 협업 중이라면 다른 팀원의 히스토리와 충돌할 수 있으므로 주의해야 함

Git commit 취소

---

reset 사용 ( 웬만하면 revert 사용하기 )

reset은 지정한 커밋 시점으로 되돌아가며, 그 이후의 커밋은 히스토리에서 삭제하므로 삭제된 커밋은 복구할 수 없습니다.

[ reset & HEAD 사용 ]

staged : git add를 한 상태 , unstaged : git add를 하지 않은 상태

# 직전 커밋 취소 ( 변경 내용은 staged 상태로 유지 )
git reset --soft HEAD~1

# 직전 커밋 취소 ( 변경 내용은 unstaged 상태로 유지 )
git reset --mixed HEAD~1

# 직전 커밋 취소 ( 커밋도 취소되고 변경했던 파일 내용까지 전부 삭제 )
git reset --hard HEAD~1

# 반드시 "HEAD~1"와 같은 형태로 작성해야 함 

[ reset & commit id 지정 ]

commit A → commit B → commit C → commit D (현재)

만약 commit B 시점으로 돌아가고 싶다면 ?

git reset (commit B의 커밋 id) --hard

revert 사용

이전 커밋의 변경 내용을 되돌리는 새로운 커밋을 생성하는 것이므로, 기존 히스토리는 그대로 유지됩니다.

1번 커밋 ( id : 1 ) → 2번 커밋 ( id : 2 )의 상황

"git revert 2"를 하면 2번 커밋 내용을 삭제한 3번 커밋 생성되고, 2번 커밋은 히스토리에 남아있으니까, 나중에 필요하면
2번 시점으로 다시 돌아갈 수 있음

Git push 취소

---

# 직전 push 취소
git reset --hard HEAD~1
git push origin 브랜치명 --force

로컬에서 커밋을 되돌린 뒤 원격에 강제 반영해야 함

브랜치 작업 및 병합

---

conflict가 없는 병합 작업

A 브랜치에서 작업 후 커밋 및 푸시 → B 브랜치를 생성하여 작업 후 커밋 및 푸시 → C 브랜치를 생성하여 작업 후 커밋 및 푸시

이후 추가하려는 내용이 A 브랜치의 작업과 관련된 내용이라면, A 브랜치로 이동하여 변경 및 추가 작업을 진행한 뒤 C 브랜치를 merge하면 됩니다.

( merge 시 커밋 메시지를 지정할 수 있으며, 기본적으로 Merge branch 'B'라는 메시지가 제공됩니다. 이후 :wq )

‼️ 충돌이 없으면 Git이 자동으로 add와 commit을 해주기 때문에 merge 한 후 push 하면 됨

git checkout A
# 변경 작업 후
git add .
git commit -m "메시지"
git merge B
git push origin A

merge 취소 : merge도 커밋 취급이므로, merge를 취소하기 위해서는 git reset --hard HEAD~1 명령어 사용

CF ) 새 브랜치는 생성 시점의 기존 브랜치 내용을 그대로 이어받아 시작됩니다. 기존 브랜치의 모든 변경사항이 포함된 상태에서 독립적으로 작업을 이어나갈 수 있습니다.

conflict가 있는 병합 작업

브랜치 C에서 BranchA 파일을 수정하고, 브랜치 A로 돌아와 BranchA 파일을 수정한 경우, 브랜치 A에서 브랜치 C를 merge하면 양쪽의 수정 내용이 다르기 때문에 conflict가 발생합니다.

이때 conflict가 발생한 코드를 사용자가 수동으로 해결해줘야하며, 일반적으로 제일 마지막으로 작업한 내용이 최신 내용이므로 브랜치 A로 돌아와 수정한 BranchA 파일을 선택한다고 치면

...
브랜치 C에서 BranchA 파일을 수정 후 add 및 commit 및 push
...
git checkout A
# 변경 작업 후
git add .
git commit -m "브랜치 A로 돌아와 BranchA 파일을 수정"
git merge C # 이때 BranchA 파일에 대해 conflict 발생

# ‼️ 충돌이 있는 경우 따로 add 및 commit 후 push 해줘야 함 ‼️
git add .
git commit -m "BranchA 파일 conflict 해결"
git push origin A