Git 저장소는 4개를 기억해주면 된다!
1) working 저장소
: (내 작업 폴더) = working Directory
Git으로 버전 관리하는 내 컴퓨터 안의 폴더를 의미.
2) staging 저장소
: git add 명령을 실행한 경우 담아지는 저장소
3) .git local 저장소
: 로컬에 있는 git 저장소, commit해서 들어가는 저장소
4) .git remote 저장소
: 원격 git 저장소 orign
이라고도 표현된다. push해서 들어가는 저장소
git --version
github에 가서 Repository를 생성 후,
## .git
git init
## 커밋
git commit -m "첫번째 프로젝트 구현"
## master -> main 브랜치로 바꿈
git branch -M main
## .git이 있는 폴더와 원격 Repository에 연결
git remote add origin https://github.com/{github 계정}/{git repository 이름}.git
## git main 브랜치에 push
## -u : -set--upstream
git push -u origin main
## 브랜치 만들어짐
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 : main으로 이동
git merge <브랜치 이름> : main or dev 브랜치로 이동해와 <브랜치> 합병
origin/master는 첫 원격저장소에 있는
master 브랜치
라는 뜻.
즉, origin은 첫 원격저장소을 뜻함!
사연...
기본 브랜치명을 바꾸게 된 이유는 몇 달 전 큰 이슈가 되었던 '조지 플로이드 사건'을 계기로 인종차별적 요소나 주종 관계의 의미를 업계 전반에 이런 부분을 제거하자는 움직임이 일어났고, 깃헙도 이러한 운동에 발맞추기 위해서이다. (참고 기사)
깃헙은 10월 1일부터 기본 브랜치를 master에서 main으로 적용하였고, 이제 저장소를 생성할 때 초기화 옵션을 선택하면 main 브랜치가 기본 브랜치로 생성됨을 알 수 있다.
이전에는 git이 알아서 기본으로 master를 사용하였지만 main은 그렇지 않기 때문에 명시적으로 git branch -M main으로 브랜치를 생성하는 명령어가 추가해 주어야 한다.
git branch -M main
git staging 저장소에 add / reset
git add .
## 특정 파일 저장
git add {특정파일}
git reset
## 특정 파일 취소
git reset {특정파일}
git pull
명령어는 로컬에서 remote 리포지토리에 작업한 내용을 가져와 update 하는 명령어다.
IntelliJ에서는 Remote에서 가져올려면 빨간색 박스(Remote)의 branch를 오른쪽 클릭
하고 Pull into {브랜치 명} Using Merge
하면 Remote의 origin/{헤딩 브랜치} 의 소스를 pull 한 것이다.
단순 git pull
명령어로는 로컬에서 가져오는 것 같다.
--set-upstream
: 로컬 브랜치와 원격 브랜치 동기화 작업
git push --set-upstream origin main
이렇게 처음에 해주면 나중에 git push로!
git push
git Repository 만든 후
git Repository 만든 후 gitHub 페이지내 명령어대로 기입하면 됩니다!
💥 그럼에도 git push 오류!
해결법)
git push -u origin +main
참고) https://doozi316.github.io/errorlog/2019/09/30/error1/
## 여러 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
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
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
파일에 있는 파일들은 working 디렉토리에 있어도 git이 tracking이 되지 않는다! (staging 디렉토리 뿐만 아니라 git status에서도 보이지 않게 된다!)
ignore
를 설치간단히 만들 수 있다!
=> 안나옹ㅁ... ㅡㅡㅡ 왜그러지?? => cached 삭제해야!
gradle
일 때, intellij
일때
처음 아래사진의 gradle 파일들은 github에 보관할 필요가 없다.
어차피 프로젝트는 가져올 때 받아오기 때문이다.
# 특정 파일 지정
dev.env
# 확장자로 지정
.env
# build 내 모든 파일
build/
# build 내 log 파일만 지정
build/.log
1) .idea
- IntelliJ의 IDE 옵션 저장
2) iml(IntelliJ IDEA Module)
- 자바 응용 프로그램을 생성 시 IDE가 모듈 구성을 xml 형태로 기술한 것
### IntelliJ IDEA ###
out/
!**/src/main/**/out/
!**/src/test/**/out/
*.idea/
*.iml
### Eclipse ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
bin/
!**/src/main/**/bin/
!**/src/test/**/bin/
☑️ Mac
### Mac OS ###
.DS_Store
.gitignore
가 작동하지 않을때 대처법 => rm --cached
위의 내용 적용 후에 .gitignore 가 제대로 작동되지 않아 ignore처리된 파일이 커밋대상에 포함되어 나오는 문제가 발생하여 이 내용을 추가로 작성하였다.
git의 캐시가 문제가 되는거라 아래 명령어로 캐시 내용을 전부 삭제후 다시 add All한다.
한번에 처리가 안되서 한번더 반복해서 입력하니 정상적으로 적용되었다.
# 전체 캐시 삭제
git rm -r --cached .
# 다시 add 하면 gitignore처리한 파일들이 git에 올라오지 않게 된다.
git add .
# 원격저장소 일단 갖고만 오기
git fetch
# origin을 로컬 repository에 merge하지 말고 일단 가지고 온다.
git fetch (origin main)
# origin/main 임시 브랜치로 바꾼다. -> origin의 변경된 사항을 확인할 수 있다.
git checkout origin/main
fetch 는 거의 안쓴다 -> 바로 clone을 사용!
# .git 생성
git init
# 로컬과 원격 git repository 연결
git remote add origin https://github.com/조장아이디/레포지토리명.git
# master 원격 레포지토리에서 code를 pull 받아옴
git pull origin main
위에걸 한방에 하는 것이 clone!!
git clone <저장소 url>
💥 주의) git clone or fork 하면 default 브랜치 하나만 복사되는 것!
자동으로 로컬의 default 브랜치가 remote 원격 저장소의 default 브랜치를 추적하도록 되어 있다.
: 남의 원격 저장소를 내 원격 저장소로 가져오는 것
다른 사람의 원본 저장소를 개발자가 자신의 GitHub 계정으로 복제하여, 해당 저장소에 대한 완전한 권한을 얻는 것입니다.
Fork한 저장소는 개발자의 GitHub 계정으로 관리되며, 다른 사람의 저장소에 대한 직접적인 수정 권한을 가지지 않습니다.
따라서, 개발자가 원본 저장소에 기여하고자 할 때는 Pull Request
를 통해 이를 요청하게 됩니다. 주로 오픈소스 소프트웨어에서 진행합니다.
💡fork vs pull request 사용법 참고 블로그
https://velog.io/@mooh2jj/github에서-fork-pull-Request까지
: 어떤 원격 저장소를 내 지역 저장소로 가져오는 것
원본 저장소의 코드를 개발자가 로컬 환경으로 복제하는 것입니다. 원본 저장소와 개발자의 로컬 저장소는 같은 저장소를 가리키며,
개발자는 해당 저장소에 대한 모든 권한을 가집니다.
내가 clone 하기 전의 commit 이력 등의 로그는 보지 못한다
## Remote Repository와 연결
git remote add origin https://github.com/조장아이디/레포지토리명.git
## 연결삭제
git remote remove origin
## remote 확인
git remote -v
## 레포지토리 정보
git remote show origin
rm -rf .git
그 이후 다시 remote add해서 so 레포지토리에 설정할 수 있다!
# add
git add .
git add <파일>
# 커밋
git commit -m “<메시지>”
## 커밋되지 않고 스테이징된 변경 사항 재설정하기
git reset HEAD <파일> [<파일>]
## 파일의 일부를 스테이징하기
git add -p [<파일> [<파일> [기타 파일들…]]]
## add 명령에서 Git 대화 모드를 사용하여 파일 추가하기
git add -i
## 수정되고 추적되는 파일의 변경 사항 스테이징하기
git add -u [<경로> [<경로>]]
## 작업 트리의 변경 사항 돌려놓기
git checkout HEAD <파일> [<파일>]
## 수정되고 추적되는 모든 파일의 변경 사항 커밋하기
git commit -m “<메시지>” -a
## 마지막 커밋 고치기
git commit -m “<메시지>” - -amend
## 이전 커밋을 수정하고 커밋 메시지를 재사용하기
git commit -C HEAD - -amend
새로운 stash를 스택에 만들어 하던 작업을 임시로 저장
## 하던 작업 임시로 저장과 동시에, 이 과정을 통해 working directory에 stash한 거는 없어짐
git stash
## stash한 목록 보기
git stash list
## stash 적용하기
git stash apply
## stash 제거하기 list보면 제거되어 있음.
git stash drop
## 메시지 없이 커밋하기
git commit --allow-empty-message -m ""
## 직전 commit한 부분 수정 커밋 추가
git commit --amend
인텔리제이를 쓸 경우,
간단하게 처리할 수 있다!
## git commit한 이력 나옴
git log
## 빠져 나올 땐 q
🥵 주의!
git log에서 나가기
커밋한 로그를 확인하기 위해서 git log를 사용했는데 다른 키를 누르면 그 다음 로그 메시지를 모두 출력한다.
이때는 확인할 로그가 지났다면Q키
를 눌러 로그 화면을 나갈 수 있다.
## main으로 이동
git checkout main
## 무조건 덮어쓰기
## 타겟 브랜치 -> main 브랜치에 합치기(merge)
git merge <타겟 브랜치>
## 커밋하지 않고 합치기
git merge - -no-commit <브랜치>
## 선택하여 합치기
git cherry-pick <커밋명>
## 커밋하지 않고 선택하여 합치기
git cherry-pick -n <커밋명>
## 브랜치의 이력을 다른 브랜치에 합치기
git merge - -squash <브랜치>
merge vs rebase
rebase 는 base를 새롭게 설정한다
는 의미로 이해하면 좋다.
$ git rebase [newbase]
서로 다른 branch들이 merge하면서 생기는 문제가 있을 수 있다.
하나의 파일에 각 branch들이 서로다르게 코딩해서 생겨 git이 모르니 충돌이라고 알리는 것!
merge -abort
참고) https://minny27.tistory.com/44
1) git checkout main : main에 들어감, 즉, merge를 시도했을 때 주체 브랜치에 들어가라는 뜻!
2) 충돌난 파일 (>>>> <<<<) 요런 것들 확인
싹 다지우고 제대로 만듬 // 여기서 엄청 오래걸릴수 가 있을 것 같음... -- 그러니 애초에 그사람이 맡은 부분은 그 사람만 담당해서 confilct를 최소화해야 한다!
인텔리제이
Resolve -> merge할 대상 선택
3) 다시 git add . -> git commit & push
git commit -m "confilict 해결" && git push 하고 끝내면 됨!
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: 커밋되지 않은 것들을 지우고 현재 커밋 상태로 초기화하고 싶을 때
## HEAD~1 하나만 되돌림
git reset --hard HEAD~1
## hard/mixed/soft 협업할 때 reset하기 정말 까다롭다...
## hard - reset하기 전까지 했던 staging area, working directory의 작업까지 모두 reset!
## mixed(default) - staging area은 reset, reset하기 전까지 했던 working directory의 작업은 남겨둠.
## soft - reset하기 전까지 했던 staging area, working directory의 작업은 남겨둠.
강제 push
를 해줘야 된다!git push -f origin master
❗ 사용 상 주의 요망 : 과거 커밋으로 이동하면서 그 이후 커밋은 삭제되어 되돌릴 수 없으므로 주의가 필요하다.
특히, push 후에는 다른 사람의 코드에 문제를 일으킬 소지가 있으므로 금지한다!
그냥, HEAD~n 으로 기억하자!
git reset --hard HEAD~2
✳️직전 commit한 거 취소하기!
git reset --hard ORIG_HEAD
ex.