깃 동작원리2

장우솔·2022년 3월 5일

git github

git

목록 보기

3/3

며칠전 학교 특강으로 깃 동작원리에 대해 설명해주는 것을 듣고 내용 요약 및 정리를 해보았다.
자신의 history를 남기는 것도 중요하지만 깃을 사용하는 이유는 협업하기 위해 익혀야한다는 말을 새겨 들으며..~~

협업과정 순서

참여할 프로젝트 fork 복사
fork 한 프로젝트 다운로드 (clone)
프로젝트 분석(경향 파악)
config 설정(저자(author)정보 설정) git config --global core.deitor 이름
commit (소스코드 수정) 생성
fork 한 프로젝트에 commit 업로드 (push)
pull

fork : 깃허브안에서만 복사하는 것

CLI(command line inter): 명령어 기반 인터페이스
세부기능활용, 자동화(스크립트)
GUI: 그래픽 유저 인터페이스
세부기능활용어렵다, 자동화 어렵다.

명령어

pwd : 현재 폴더경로 출력
ls : 현재 폴더내부 존재하는 파일들 출력
cd : 현재 폴더경로 변경 상위폴더로 이동 : cd ..
mv : 파일명 변경 /mv 원래꺼 바꿀꺼
rm : 파일삭제 폴더 삭제 : rm –r 폴더명
touch : 빈파일 생성 /touch 빈파일명.확장자
clear : 터미널 화면 정리

브랜치

같은 폴더인데 다른 세상
<명령어>

생성(처음) --> git checkout –b 새이름
지우기 --> git branch –D 이름
바꾸기 --> git checkout 이름

수정해서 커밋 제출하기

순서
1. 새로운 브랜치 생성
2. author 이름으로 파일 열기 : author이름 파일이름.확장자
3. 파일 내용 수정하고 나서
ctrl o->enter-> ctrl x
4. git status, git diff로 수정됐나 확인
5. add로 확인하고 추가하기 : git add 파일
6. commit 하기 : git commit –m “ ”

내가 작성한 commit 확인하기 : git show 후에 git log --oneline -l
commit 정보 삭제하기 : git reset --hard HEAD~1 (1은 가장위에서 첫 번째 내용 삭제한다는 의미)
자신이 설정했던 config 확인 : git config –l
지금까지 commit 수 확인 명령어 : git log --oneline | wc

git push origin branch이름

수정 파일

매번 커밋할 수도 없고 임시로 수정하고 다시 원상복구 하고 싶을 수도 있잖아! 그때 사용하자!

수정파일 확인 : git status
내용 잠시 저장하기 :git stash(add는 됐는데 commit 하기는 애매해 잠시 keeping 해두는 것, 근데 status에는 안뜬다.)
잠시 저장해둔 내용 복구(불러오기): git stash pop
복구된 수정한 파일 다시 확인하기 git status
수정 내용 완전히 삭제하기 : git checkout -- 파일.확장명 (띄어쓰기 잘해야한다......!)
최신역사 기준으로 파일내용 원상복구 후 내용 확인: git diff
add 취소 : git reset
라이센스 서명 넣어서 commit message 적기(라이센스이해했고 동의하고 한 것이 맞다 서명하는 것)
add까지 한 상태에서, git commit –s –m “”
commit 궁금할 때 확인해보기! : git show

이미 만들어져있는 commit 내용 수정하기

순서

최신 수정 이전 commit 확인
git log --oneline -1
git add 하고.
git commit --amend (가장 위에있는 것만 수정할 수 있다.)
최신 수정 이후 commit 확인
git log --oneline -1

git remote –v
remote 추가 : git remote add upstream fork한 http
remote 지우기 : git remote remove upstream

수정내역 과거시점으로 되감기

순서

일단, 처음에 어떤지 확인하기 : git log --oneline
git rebase –i --root -->고치고 나간다.
되감은 내용풀기: git rebase --continue
*수정 여러개 됐으면 여러번 되돌려야한다.

rebase 취소 : git rebase --abort *단 git rebase --continue 했으면 불가.
이럴땐, git reset --hard origin/master commit 로 히스토리 복구 해야한다.

오래된 커밋에 파일 추가해서 수정하기

git log --oneline
git rebase –i --root -->고치고 나간다. 이때 위에서부터가 오래된거야. 만약 2번째로 오래된 커밋을 변경하고 싶다면 위에서 두 번째 것을 edit으로 바꾼다.
파일 touch로 만들고 commit –m “” 까지 진행한다.
되감은 내용풀기: git rebase --continue
수정결과 확인 : git log --oneline

<soft/hard의 차이>
git reset --soft HEAD~1 : commit은 없는데 변경본은 살아있다파일은 남아
git reset --hard HEAD~1 : 내용도 삭제

예를 들어, 두 번째로 오래된 commit 이후에 세 개의 커밋 하나로 합치기

순서
1. git log --oneline
2. git rebase –i --root -->고치고 나간다. 세 개의 커밋 중 최근꺼부터 합치려면 위에서 세 번째에 edit을 해야한다.
3. git reset --soft Head~2 -->최근에 두 개를 파일은 남기고 커밋만 지우는 방법
4. 커밋 메시지 수정하기 : git commit --amend
5. 되감은 내용풀기: git rebase --continue
6. 수정결과 확인 : git log --oneline

간단하게-->두 번째로 오래된 commit 이후에 새로운 커밋 세 개 넣으려면 두 번째에다가 edit 걸어줘야한다. **
최근 commit 두 개 먼저 합치고 나머지 하나 합치려면??
최근꺼(3)에 edit를 해야한다. 그럼 2커밋에 3이 흡수된다.

합친 것을 다시 풀려면?

합친 것에 되감기 걸어서 edit 해주고 git reset --soft Head~1 해주고 아직 add 되어있는 상태니까 git reset 으로 add 풀어주고 파일은 있으니까 touch 안해도 되고 다시 git add, commit 순으로 파일 넣어준다.(3개의 파일 전부!) 그 후 되감은 continue로 내용풀면 끝!

가장 오래된 두 번째 커밋 삭제하기

git rebase –i —root (위에서 두 번째 edit으로 바꾸기)
git reset —hard Head~1
git rebase —continue
git log —oneline

blame 기능
소스코드 기준으로 라인(코드내용)마다 커밋을 확인할 수 있다.

commit 나오기 전 과거로 되돌려보기
git reset —hard 1a126ed11c(: 예시코드이다.)~1
다시 돌아오기 : git reset --hard origin/master

버그를 수정했을 때 commit message를 어떻게 작성할까? (예를 들어 문제b가 발생했는데 if 문에 a라는 조건이 없어서)

제목에 들어가야할 내용

카테고리-어느파트에서 만들었는지 [test], ooo:fix b problem 이런식으로!
첫단어
fix : 잘못된 것 고친 것
improve : 개선한 것
add : 없던기능/옵션 추가할 때(함수, 클래스 등 무엇을 추가한 것은 코드보면 알 수 있다. why를 적는 것이 더 중요)
support : 원도우에서만 되는 것을 리눅스에서 되게 한다던가!
remove, refactor 등이 있다.
설명 한줄 --> 요약해서 이유가 들어나게 적는다.

본문에 들어가야할 내용

why(80%), how: 어ᄄᅠᇂ게 구현했는지, 방법(20%)
when ~, the b error can occur
the reason is that~, so fix it.

commit 한 개의 적당한 크기는? : review하기 좋은 단위

장우솔

공부한 것들을 정리하는 블로그

이전 포스트