git hub 명령어

떡ol·2022년 11월 30일

내가 쓸려고 만든거

git bash 윈도우에서 리눅스 명령어 사용가능한 shell창
git remote -v // 현재 리모트되어있는 리포지터리 사이트 확인하기
git remote set-url origin "reactBeginer" // 해당 프로젝트를 리포지터리로 설정하기
git remote add origin "https://github.com/아이디/프로젝트명" // 해당 프로젝트를 원격 저장소에 연결하기
git remote remove origin // 리모트 삭제하고 위에과정 다시 해서 재연결
git clone https://github.com/아이디/프로젝트명 //해당 서버에 소스를 내컴퓨터 git 연동된 폴더에 clone한다. (폴더 오른쪽 버튼 git bash here를 클릭하고 입력하면 됨)

git --version // 깃버전 확인하기
git config --global user.name '아이디' //문서에 표시될 아이디
git config --global user.email '이메일' //문서에 표시될 이메일
git config --global init.defaultBranch main //init 할때마다 main으로 브런치 만들기 gitHub이 main써서 미리 작업치는듯

git add "파일이름" // 커밋을 할 대상을 정한다. stage area(작업공간)에 먼저 넣어서 대기상태를 만든다.
git add -A // 현재 디렉로리 전부 (쓰지말자)
git add . // 프로젝트 전부
git status // add 한 파일을 확인가능하다 stage area를 확인가능하다.
git log // commit정보를 전체 확인가능 (해시코드도 확인가능)
git commit -m "commit Test ver.2" // 커밋하고 설명을 작성한다. -m은 현재 add로 commit 대기 상태에 있는 자료만 넣는 의미이다 -a는 add까지 작업해주는거
git commit --amend -m '메시지' // 바로전 커밋에 추가로 파일집어 넣거나 메시지 바꿀 수있음
Add .gitignore // .gitignore이란 파일이 있는데 여기에 작성한 파일들은 저장소로 업로드 안된다. 보통 보안상의 문제나 불필요한 파일을 선언해준다.

add, commit 각각 하기 (hunk)

commit은 한번할때 뭉탱이로 하는것보다, 기능별로, 단계별로 나중에 되돌릴때도 문제 없게 나눠가며 하면 좋다.
그래서 한개의 파일에 다수의 커밋요청이 필요할때는 다음의 명령어를 쳐서 사용하면 된다.
git add -p // 명령어 입력하라고 나오는데 ?는 설명 보통 y,n쓰면 됨 읽어가며 commit에 포함하고 싶은 줄은 y아니면 n하면 됨
git commit -v // 명령어를 실행해서 커밋하면 됨

git stash

stash는 작업중인 파일들을 미뤄두는 역할을한다. 갑자기 다른 작업을 해야하는데 지금까지 작업한걸 삭제할 수도, commit할 수도 없으니, 다른 곳에다가 저장해두는거 stage area에 존재하는 대상이어야 가능하다.
git stash // 현 작업들 치워두기
git stash pop // 치워둔거 저장소에서 없애고 현 브런치에 덮어쓰기 apply+drop
git stash apply // 치워둔고 덮어만쓰기 git stash apply stash@{1} 또는 메시지
git stash drop // 치워둔거 그냥 지워버리기
git stash branch 브런치명 // 새로 브런치를 만들어서 거기다가 넣기 충돌방지
git stash clear // stash 저장소 다 지우기
git stash -p // 위에서 설명한 각각하기 처럼 각각 저장소에 넣을 수 있음
git stash -m 'Add Stash3' // commit 처럼 저장소에 메시지를 남길 수 있음
git stash list // stash 저장소 보기

stash를 나눠서 여러개로 만들어둔경우, 한파일에 변경점이 많으면 pop을 하더라도 하나씩만 된다. 할때마다 add를 해서 변경점을 stage에 넣어주고 불러와야한다.

git reset --hard 이동할 해시코드 // 히스토리 시점의 커밋으로 돌아간다.(브런치 이후로 진행한거 다 날라감)
해시코드는 전부 안쓰고 git reset --hard djklfn34 요렇게 대충 앞에꺼 몇자만 써도됨
git revert 취소할 해시코드 // 딱 하나의 히스토리만 취소 (브런치에서 하나 뽑아서 취소가능)
git revert --no-commit 해시태그 // 돌아가되 status에 add는 안된상태, 좀 더 수정하고 내가 commit 다시하겠다 라는 뜻
git reset --hard // 해시태그없이 실행하면 그냥 최신 commit 시점으로 돌아가짐.

git reflog // git 작업내역을 확인가능하다. 앞서, reset 명령어를 잘못써서 날라가버린것을 reset --hard + (reflog에 나온 되살릴 해시값)으로 다시 복구가능하다.

git branch // 현재 repository branch를 모두 표시한다.
git branch -a // 원격까지 전부 보기
git branch 브런치이름 // 새로운 branch를 만들어 관리한다.
git checkout --orphan 브런치이름 // 위의 명령어는 현재브런치기준 부모의 commit이 전부들어간다. 부모없이 처음부터 관리하고 싶다면 이 명령어
git switch 존재하는 브런치 이름 // 해당 branch로 작업한다는 의미 스위치 바꿔줌
git switch -c 브런치이름 // 만들고 작업 스위치까지 함
git branch -d 삭제할 브랜치명 // branch 삭제함
git branch -D 삭제할 브랜치명 // 강제 삭제
git push (원격 이름) --delete (원격의 브랜치명) // 원격에 브런치 지우기
git branch -m (현 브런치) (새 브랜치명) // 이름 바꾸기
git log --all --decorate --oneline --graph // 각 브런치에 commit 메시지를 UI화

git merge 병합할 브런치명 // 여러브런치에서 메인이 되는 브런치와 병합할 브런치를 이어 붙인다. (병합,합병)
git merge --no-ff 브런치 // 브런치가 메인 가장 위에서 뻗아나갈때가 있다. 이때 병합을하게 되면 '한가지'로 바뀌게 된다.(구성상 한가지가 맞으니깐...) 그래서 후에 어느 가지에서 파생된건지 알 수 없다. 이때 noff를 이용하면 다른가지에서 병합했다는 git tree가 적용되어 히스토리를 확인가능하다.
git rebase main // 메인브런치에 해당 브런치를 잘라 붙힌다. (재배치)
주의 사용할때 조심하자.
merge :: 현재 브런치가 main이면 ->> merge newBranch :: main(현 브런치)에 newBranch 데이터가 병합된다.
rebase :: 현재 브런치가 main이면 ->> rebase newBranch :: newBranch(옮길 브런치)에 main의 데이터가 붙어진다.
만약 충돌 난다면
git merge --abort
git rebase --abort
사용하면 작업 중단 원소스로 돌아감
merge의 경우 충돌 진행하고 소스 정리 후 add -> commit 하던데로 하고 완료
rebase의 경우 브런치의 commit된 히스토리가 여러개로 되어있으면
1. Commit 히스토리 서로 비교
2. 사용자가 파일 정리 후 git rebase --continue
3. 반복
4. 마지막에 main에서 point 마다 rebase해서 정리된 최상단 point를 merge진행

git cherry-pick 해시코드 // 대상이되는 커밋 시점만 찍어서 가져온다. 딱 특정부분만 main브런치에 복사하고 싶을때 사용하면 된다. 해당 히스토리는 남아있으므로 삭제하던 남기던 맘대로.
git rebase --onto (도착 브랜치) (출발 브랜치) (이동할 브랜치) // 이동할 브런치에 내용만 가져와서 붙혀넣고 싶을때 사용한다. 이동할 브런치에 있는 스타트 커밋,한개(출발 브랜치에 속해있는거)는 가져오지 않는다.
git merge --squash (대상 브랜치) // 브런치의 히스토리가 엄청 많지만, 그냥 하나로 커밋하고 싶을때 사용한다. 이때 merge가 완료된게아니라, stageing 상태에 들어가져있는 상태까지만 진행되므로 commit따로 해줘야한다. 브런치는 남아있으므로 삭제하던 맘대로.

git blame (파일명) // 누가 작성했는지 알아보기 사실 이걸 사용하기보단 확장프로그램에서 gitLens를 사용하는게 낫다.

코드 에러지점찾기

이미 버그가 난 파일이 언제부터 에러가 난건지 커밋 시점을 찾을때 사용
git bisect start // 에러찾기를 시작한다.
git checkout (해당 커밋 해시) // 일단 어디서 날거같다는 짐작가는 부분을 직접 찍어준다.
git bisect good/bad // git이 이진탐색으로 검색을 해가며 파일을 바꿔줄꺼다. 테스트를 해보며 에러가 나면 bad /없으면 good을 입력, 계속 반복적으로 검색 -> 질의 답해주면 최종적으로 어느 커밋에서 문제가 있었는지 알려준다.

push:원격에 넘기기 pull:원격에서 받아오기

git push origin master // 소스를 마스터라는 브런치로 넣는다.
git push -f origin master // f 하면 타 사용자 변경이력 무시하고 강제 덮어씌우기 실무에서는 트롤 됨
git push -u origin master // 한번 사용하고 부터는 git push만하면 브런치 경로 잡아줌.
git push -u origin from-local // 원격에 없는 브런치면 hub에도 자동으로 만들어짐
git push (원격 이름) --delete (원격의 브랜치명) // 원격에 브런치 지우기
git switch -t origin/from-remote // 이건 반대로 원격에 있는 브런치를 로컬에도 만들어주면서 스위치
git pull // 원격에서 가져오기 이게 기본옵션 사실 이게 merge임 --no-rebase랑 같음
git pull --no-rebase // merge라고 생각하면됨 브랜치를 두개 관리하며 그걸 붙힌거임
git pull --rebase // rebase 잘라 붙힌거라 히스토리가 한줄임
git rebase --continue

git fetch // 원격에 있는 브런치 현황을 가지고 올 수 있음 git pull 이 브런치 현황을 업데이트하고 가져오기까지 하는것이라면, fetch는 그냥 최신인지 아닌지 정도 체크가 됨

git pull origin (이름) // 현재 브런치에서 origin(웹 저장소)에 (이름)에 해당하는 브런치 자료 불러온다
예:: switch main -> git pull origin dev // 이렇게 하면 main브런치에 dev브런치 내용이 있게 되는거임.

git의 공간에 대한 설명

git에는 3가지 공간이 존재합니다.
working directory-> stage area ->repository

git mv tigers.yaml zzamtigers.yaml //파일이름 변경할때 합니다. F2+이름바꾸기, add 랑 같음
git rm tigers.yaml // 파일을 삭제합니다. delete + add랑 같음
git restore --staged (파일명) // 파일을 stage area 대상에서 제외합니다.
git restore (파일명) or . // working directory에 있는 파일을 작성 전 상태로 되돌립니다.
git restore --source=(헤드 또는 커밋 해시) 파일명 // 해당시점으로 파일을 돌려보냄
git reset --hard // working directory 시점으로 commit한 히스토리를 이동 (그냥 작업전)
git reset --mixed (default) // stage area 시점으로 이동 (add까진 된상태)
git reset --soft // repository 시점으로 이동 (commit만 안된상태)

HEAD란 각브런치의 최신 지점,
git checkout HEAD^ // 브런치의 한 단계 아래 히스토리로 이동
git checkout HEAD~ // 마찬가지로 동일함 뒤에 갯수를 입력할 수 있음 ~~ : 2번이동, ~2 :두번이동
git checkout HEAD- // 이전작업 히스토리로 돌아감 CTRL+Z임 한단계 앞이아니라 이전작업
git checkout origin/main // main저장소에 있는 내용을 먼저 확인만하고 싶을때 이 후 fetch 명령어를 한번 써주면 저장소에 최신상태를 '확인'만 가능하다.
git checkout -t origin/main //위에꺼는 확인만 가능한 임시 브런치가 생기는 것이지만(commit, push 안됨), 이건 branch를 로컬로 복사하는거라고 생각하면됨. clone할때 못가져온거는 이렇게 가져올 수 있다.
git reset HEAD(원하는 단계) (옵션) // 기존에 reset에서 해시태그를 이용하는것에서 HEAD값으로도 가능

git config --global alias.(단축키) "명령어" // 단축키 예 : git config --global alias.cam "commit -am"

rebase 응용하기 (commit 수정, 삭제, 합병 등)

-i 명령어를 사용하면 해당 히스토리기점으로 분기 브런치(임시)가 생기는거 같습니다.
최종적으로 명령이 종료되면 그 작업들이 합쳐져서 메인 브런치에 rebase됩니다.
수정 삭제 합병 이렇게 이야기는 했지만, 새로 생성된 분기점을 붙히는 거라고 생각하면 될 거같습니다.
git rebase -i (대상 바로 이전 커밋)
p, pick 커밋 그대로 두기
r, reword 커밋 메시지 변경
e, edit 수정을 위해 정지
d, drop 커밋 삭제
s, squash 이전 커밋에 합치기(앞에꺼에 선언하면 됨)

태그달기 feat. 시멘틱 버전

hub에 태그다는 방법은 두가지가 있다.
lightweight : 그냥 태그만 달기 거의안씀
annotated : 설명까지 다는것
git tag v2.0.0 // lightweight 방법 그냥 최신 commit에 v2.0.0이라는 태그만 달기
git tag v2.0.0 -m '자진모리 버전' // annotated 방법 설명까지 달기
git show v2.0.0 // v2.0.0라는 태그 내용 보기
git tag -d v2.0.0 // 태그 삭제
git tag -l 'v2.*' // 원하는 태그 검색해서 보기
git push origin 태그명 // 태그를 origin이라는 원격에 올리기
git push --delete origin 태그명 // 삭제
git push --tags // 태그 전체 올리기
hub에 들어가서 저장소 메인에 오른쪽에 releases가 보임 여기 클릭해서 진행하면 다운로드 사이트처럼 파일 배포가능

Semantic Versioning 2.0.0
버전을 주.부.수 숫자로 하고:
기존 버전과 호환되지 않게 API가 바뀌면 “주(主) 버전”을 올리고,
기존 버전과 호환되면서 새로운 기능을 추가할 때는 “부(部) 버전”을 올리고,
기존 버전과 호환되면서 버그를 수정한 것이라면 “수(修) 버전”을 올린다.
주.부.수 형식에 정식배포 전 버전이나 빌드 메타데이터를 위한 라벨을 덧붙이는 방법도 있다.

서브모듈 사용하기

서브모듈이란 한개의 프로젝트안에 다른 프로젝트(lib framework)가 들어가있는경우 git에서 관리하는 방식입니다.
1. main 프로젝트로 cd경로를 설정해두고 실행 defalut
2. git submodule add (submodule의 GitHub 레포지토리 주소) (하위폴더명, 없을 시 생략)
3. main 프로젝트에 submodule 이라는 폴더와 .gitmodules 파일이 만들어짐
4. 변경사항 add 후 commit
만약 submodule 변경사항 있으면...
5. submodule 프로젝트로 cd경로를 설정해두고 실행 -> 변경사항 add 후 commit
4. main 프로젝트로 cd경로를 설정해두고 실행 -> 변경사항 add 후 commit

clone해서 가져왔다면...
1. git submodule init (특정 서브모듈 지정시 해당 이름)
2. git submodule update

만약 submodule 변경사항 있으면... main프로젝트의 push같은거
git submodule update --remote

PR Pull Request, issue 사용하기

브런치를 새로만들어서 코딩한다. (내만 자유롭게 작업할 수 있는 공간을 만들어둠)
commit하고 push까지 진행한다.
GitHub에서 브런치를 클릭하거나 노란색 알림뜨는것을 클릭
new pull request 클릭하고 입력할거 하고 create pull request 클릭
관리자가 해당 request클릭해서 메시지도 남겨주고 승인하면 끝

1.GitHub 레포지토리 페이지에서 Issues 탭 클릭
2.필요시 label 또는 milestone 생성 (milestone: 이슈의 주제 묶음 (특정 목표 등))
3.이슈 작성, 필요시 label, milestone, asignee 지정
4.이슈 확인 후 처리
5.코멘트 달기 (관련 개발 착수 (브랜치명이나 커밋 footer에 이슈 번호 반영))
6.Close issue