Git 명령어 정리(with Git Confilct 해결법)

git 저장소

Git 저장소는 4개를 기억해주면 된다!

1) working 저장소 : (내 작업 폴더) = working Directory
Git으로 버전 관리하는 내 컴퓨터 안의 폴더를 의미.

2) staging 저장소 : git add 명령을 실행한 경우 담아지는 저장소

3) .git local 저장소 : 로컬에 있는 git 저장소, commit해서 들어가는 저장소

4) .git remote 저장소 : 원격 git 저장소 orign이라고도 표현된다. push해서 들어가는 저장소

git version

git --version

git branch & checkout(switch)

## 브랜치 만들어짐
git branch <브랜치 이름> 

## 브랜치 뭐 있는지 확인
git branch [-a]

## 브랜치 이름 수정 (해당 브랜치로 이동해야)
git branch -m new-branch-name

## 브랜치 삭제
git branch -d {브랜치명}

## 지정한 브랜치로 이동
git checkout[switch] <브랜치이름>

## 브랜치 만들고 그 브랜치 한번에 이동, 이걸 많이 사용함!
git checkout -b <브랜치 이름> 

• 예시

(편집중...)
git push origin <브랜치 이름>

git checkout main : master로 이동

git merge <브랜치 이름> : master에서 와 <브랜치>합병

origin/master는 첫 원격저장소에 있는 master 브랜치라는 뜻.
즉, origin은 첫 원격저장소을 뜻함!

✳️ 이제 master -> main 브랜치로

사연...
기본 브랜치명을 바꾸게 된 이유는 몇 달 전 큰 이슈가 되었던 '조지 플로이드 사건'을 계기로 인종차별적 요소나 주종 관계의 의미를 업계 전반에 이런 부분을 제거하자는 움직임이 일어났고, 깃헙도 이러한 운동에 발맞추기 위해서이다. (참고 기사)

깃헙은 10월 1일부터 기본 브랜치를 master에서 main으로 적용하였고, 이제 저장소를 생성할 때 초기화 옵션을 선택하면 main 브랜치가 기본 브랜치로 생성됨을 알 수 있다.

이전에는 git이 알아서 기본으로 master를 사용하였지만 main은 그렇지 않기 때문에 명시적으로 git branch -M main으로 브랜치를 생성하는 명령어가 추가해 주어야 한다.

• 명령어

git branch -M main

git pull

git pull 명령어는 로컬에서 remote 리포지토리에 작업한 내용을 가져와 update 하는 명령어다.

IntelliJ에서는 Remote에서 가져올려면 빨간색 박스(Remote)의 branch를 오른쪽 클릭하고 Pull into {브랜치 명} Using Merge하면 Remote의 origin/{헤딩 브랜치} 의 소스를 pull 한 것이다.

단순 git pull 명령어로는 로컬에서 가져오는 것 같다.

git push

--set-upstream : 로컬 브랜치와 원격 브랜치 동기화 작업

git push --set-upstream origin main

이렇게 처음에 해주면 나중에 git push로!

git push

💥 그럼에도 git push 오류!

해결법)

git push -u origin +main

참고) https://doozi316.github.io/errorlog/2019/09/30/error1/

git config

## 여러 config 정보가 모두 리스트로 출력
git config --list or -l

diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager-core
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.clean=git-lfs clean -- %f
user.name=seonggon do
user.email=62453668+mooh2jj@users.noreply.github.com

✳️ git config user.email 형식

62453668+mooh2jj@users.noreply.github.com

이는 GitHub의 기본적인 이메일 주소 형식입니다. GitHub은 사용자의 이메일 주소를 실제 이메일 주소 대신 "noreply" 도메인을 사용하는 것으로 알려져 있습니다.
이러한 형식은 GitHub에서 사용자의 개인 정보를 보호하기 위한 방법입니다. 사용자의 실제 이메일 주소를 노출시키지 않고, GitHub에서 고유한 식별자를 생성하여 이메일 주소를 대체합니다.

계정 설정

# --global를 사용하여 전역으로 설정
git config --global user.name "USER_NAME"
git config --global user.email "USER_EMAIL"

# Repository마다 다른 사용자(계정) 정보 사용
git config --local user.name "USER_NAME"
git config --local user.email "USER_EMAIL"

계정 삭제

# global
git config --unset --global user.name
git config --unset --global user.email

# local
git config --unset user.name
git config --unset user.email

window vs mac

carrige line 차이 문제 충돌 발생될 수 있어!

윈도우
text\r\n
carrige-return & line feed

맥, 리눅스
text\n
only line feed

줄바꿈 문자열이 서로 달라 문제 생길 수 있어!

해결)
core.autocrlf
treu로 설정해야 window에서는
드림코딩 깃허브 참고
https://www.youtube.com/watch?v=Z9dvM7qgN9s&t=199s

.gitignore

이 .gitignore파일에 있는 파일들은 working 디렉토리에 있어도 git이 tracking이 되지 않는다! (staging 디렉토리 뿐만 아니라 git status에서도 보이지 않게 된다!)

💡 intelliJ Plugins -> ignore를 설치
간단히 만들 수 있다!

예시)
gradle일 때, intellij일때
처음 아래사진의 gradle 파일들은 github에 보관할 필요가 없다.
어차피 프로젝트는 가져올 때 받아오기 때문이다.

# 특정 파일 지정
dev.env

# 확장자로 지정
.env

# build 내 모든 파일
build/

# build 내 log 파일만 지정
build/.log

💥 rm --cached

그리고 git cache에 있어더 그대로 노출될 수 있다. 그렇 땐 다음 명령어를 입력, 그다음 push 해주자!

git rm --cached ./src/main/resources/application-prod.yml

clone

• 기존 방식

# .git 생성
git init 

# 로컬과 원격 git repository 연결
git remote add origin https://github.com/조장아이디/레포지토리명.git
# master 원격 레포지토리에서 code를 pull 받아옴
git pull origin main

위에걸 한방에 하는 것이 clone!!

• clone 방식

git clone <저장소 url>

💥 주의) git clone or fork 하면 default 브랜치 하나만 복사되는 것!
자동으로 로컬의 default 브랜치가 리모트 저장소의 default 브랜치를 추적하도록 한다>

✨ fork vs clone

1) fork (fork-workflow)

: 남의 원격 저장소를 내 원격 저장소로 가져오는 것

다른 사람의 원본 저장소를 개발자가 자신의 GitHub 계정으로 복제하여, 해당 저장소에 대한 완전한 권한을 얻는 것입니다. Fork한 저장소는 개발자의 GitHub 계정으로 관리되며, 다른 사람의 저장소에 대한 직접적인 수정 권한을 가지지 않습니다. 따라서, 개발자가 원본 저장소에 기여하고자 할 때는 Pull Request를 통해 이를 요청하게 됩니다. 주로 오픈소스 소프트웨어에서 진행합니다.

2) clone (branch-workflow)

: 어떤 원격 저장소를 내 지역 저장소로 가져오는 것

원본 저장소의 코드를 개발자가 로컬 환경으로 복제하는 것입니다. 원본 저장소와 개발자의 로컬 저장소는 같은 저장소를 가리키며, 개발자는 해당 저장소에 대한 모든 권한을 가집니다.

내가 clone 하기 전의 commit 이력 등의 로그는 보지 못한다

• 그림으로 비교

remote

## Remote Repository와 연결
git remote add origin https://github.com/조장아이디/레포지토리명.git

## 연결삭제
git remote remove origin 

## remote 확인
git remote -v 

## 레포지토리 정보
git remote show origin 

🔍 git init을 지우기

rm -rf .git

그 이후 다시 remote add해서 so 레포지토리에 설정할 수 있다!

기본 사용 명령어

# add
git add <파일>

# 커밋
git commit -m “<메시지>”

## 커밋되지 않고 스테이징된 변경 사항 재설정하기
git reset HEAD <파일> [<파일>]

add

## 파일의 일부를 스테이징하기
git add -p [<파일> [<파일> [기타 파일들…]]]
## add 명령에서 Git 대화 모드를 사용하여 파일 추가하기
git add -i
## 수정되고 추적되는 파일의 변경 사항 스테이징하기
git add -u [<경로> [<경로>]]

commit

## 작업 트리의 변경 사항 돌려놓기
git checkout HEAD <파일> [<파일>]
## 수정되고 추적되는 모든 파일의 변경 사항 커밋하기
git commit -m “<메시지>” -a
## 마지막 커밋 고치기
git commit -m “<메시지>” - -amend
## 이전 커밋을 수정하고 커밋 메시지를 재사용하기
git commit -C HEAD - -amend

stash

새로운 stash를 스택에 만들어 하던 작업을 임시로 저장

## 하던 작업 임시로 저장과 동시에, 이 과정을 통해 working directory에 stash한 거는 없어짐
git stash 

## stash한 목록 보기
git stash list

## stash 적용하기
git stash apply

## stash 제거하기 list보면 제거되어 있음.
git stash drop

commit

## 메시지 없이 커밋하기
git commit --allow-empty-message -m ""


## 직전 commit한 부분 수정 커밋 추가
git commit --amend 

인텔리제이를 쓸 경우,

간단하게 처리할 수 있다!

log

## git commit한 이력 나옴
git log

🥵 주의! git log에서 나가기
커밋한 로그를 확인하기 위해서 git log를 사용했는데 다른 키를 누르면 그 다음 로그 메시지를 모두 출력한다.
이때는 확인할 로그가 지났다면 Q키를 눌러 로그 화면을 나갈 수 있다.

merge

## main으로 이동
git checkout main

## 무조건 덮어쓰기 
## 타겟 브랜치 -> main 브랜치에 합치기(merge)
git merge <타겟 브랜치>

## 커밋하지 않고 합치기
git merge - -no-commit <브랜치>

cherry-pick : 선택하여 합치기

## 선택하여 합치기
git cherry-pick <커밋명>

## 커밋하지 않고 선택하여 합치기
git cherry-pick -n <커밋명>

## 브랜치의 이력을 다른 브랜치에 합치기
git merge - -squash <브랜치>

rebase

merge vs rebase
rebase 는 base를 새롭게 설정한다는 의미로 이해하면 좋다.

$ git rebase [newbase]

💥 Confilct 해결방법

서로 다른 branch들이 merge하면서 생기는 문제가 있을 수 있다.
하나의 파일에 각 branch들이 서로다르게 코딩해서 생겨 git이 모르니 충돌이라고 알리는 것!

merge 취소

merge -abort

참고) https://minny27.tistory.com/44

💡 해결법

1) git checkout main : main에 들어감, 즉, merge를 시도했을 때 주체 브랜치에 들어가라는 뜻!

2) 충돌난 파일 (>>>> <<<<) 요런 것들 확인

싹 다지우고 제대로 만듬 // 여기서 엄청 오래걸릴수 가 있을 것 같음... -- 그러니 애초에 그사람이 맡은 부분은 그 사람만 담당해서 confilct가 최소화해야 한다!

• 인텔리제이
  

• Resolve -> merge할 대상 선택

• 인텔리제이 가운데가 Apply할 대상 left(yours) or right(theirs) 둘 중에 적용하면 된다.
  

3) git add .
git commit -m "confilict 해결" && git push 하고 끝내면 됨!

revert vs reset

• git revert: 취소 커밋, 되돌린 버전 이후의 버전들은 모두 유지되고, revert되었다는 사실을 담은 commit만 새로 추가(추천!)

• git reset : 복귀, 되돌린 버전 이후의 버전(commit이력)들이 모두 사라지게 된다. (💥 위험! 비추...)

• 결론

  revert를 사용하면 중간에 무슨 문제가 있었는지, 왜 돌아갔는지 등의 기록이 가능하다는 장점이 있다. 또한 다른 사람과 같은 브랜치에서 함께 작업할 때 코드 충돌을 최소화할 수 있다.
  💥 reset 너무 위험한 것!
  reset 을 사용하면 커밋 히스토리를 깔끔하게 유지할 수 있고, 혼자 작업할 때 편하게 되돌아갈 수 있다는 장점이 있다. 그러나 타인과 같은 브랜치에서 함께 작업할 때 커밋이 뒤섞여버릴 수 있다는 위험한 단점이 있다.

• 사용법

1) revert

# git log에서 commit번호 확인 
git revert <빼버리고 싶은 commit번호> 

# revert 시에는 commit이 동시에 되는데 commit 없이 revert 하고 싶을 때 
git revert de6d5c1148981e15617999c7ecaa6ec2ea21ff29 --no-commit


git revert de6d5c1148981e15617999c7ecaa6ec2ea21ff29 --no-edit

그리고 충돌 안할려면 역순으로! revert 해줘야 한다. 한번에 그 커밋으로 되돌리려고 하면 충돌 난다!

✳️ git push 한거 원복 단계
1) git revert de6d5c1148981e15617999c7ecaa6ec2ea21ff29 --no-edit

2) git stash

3) git push origin dev -f

2) reset

## <되돌릴 싶은 commit번호> // revert랑 다른 점! 
## hard: 커밋되지 않은 것들을 지우고 현재 커밋 상태로 초기화하고 싶을 때
git reset --hard 

## hard/mixed/soft 협업할 때 reset하기 정말 까다롭다...

그다음 강제 push를 해줘야 된다!

git push -f origin master

• reset 옵션

• ^ : 가장 최근 커밋으로부터 하나 되돌리는 것

ex.

---

참고

• https://dev-yakuza.posstree.com/ko/git/branch-merge/
• https://www.youtube.com/watch?v=Z9dvM7qgN9s&t=199s