옆히

얄코의 TOO MUCH 친절한 깃&깃허브 본문

개인공부용1/etc

얄코의 TOO MUCH 친절한 깃&깃허브

옆집히드라 2024. 6. 14. 05:40
얄코의 TOO MUCH 친절한 깃&깃허브 - 10점
고현민 지음/리코멘드

Learn Git Branching

 

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

  • commit
  • branch
  • checkout
  • cherry-pick
  • reset
  • revert
  • rebase
  • merge

chapter 01 깃 시작하기

#깃은 VCS(Version Control System)라는 프로그램의 한 종류

 

#깃을 사용하는 두 가지 방법

CLI(Command Line Interface) -> git bash(리눅스 커맨드 가능), GUI(Graphical User Interface) -> sourcetree

 

#.gitignore 파일 형식

*.c    # c 확장자 모든 파일들

logs/*.c    # logs 폴더 안의 .c 파일들

logs/**/*.c    # logs 폴더 하위에 있는 모든 폴더의 .c 확장자 파일들

 

#깃 최초 설정하기

깃 버전 확인하기     git --version

줄바꿈 오류 방지(윈도우)    git config --global core.autocrlf true #mac은 true -> input

사용자 이름 등록하기    git config --global user.name "본인 이름"

사용자 이메일 확인하기    git config --global user.email "본인 이메일"

기본 브랜치 이름을 main으로 변경하기    git config --global init.defaultBranch main

 

#깃 관리 시작하기

깃 관리 시작하기    git init

깃 상태 확인하기    git status

chapter 02 시간 여행하기

프로젝트를 과거로 되돌리는 방법은 크게 두 가지 reset, revert가 있다. 리셋은 이전 상태로 되돌아가거나 특정 커밋을 삭제할 때 사용됩니다. 리버트는 이전 상태로 되돌아가면서 새로운 커밋을 생성하여 삭제된 내용을 되돌리는 데 사용됨 리셋은 과거로 돌아간 다음 이후 행적은 작업 내역에서 지워버림

 

리버트는 작업 내역을 되돌린 내역까지도 하나하나 기록으로 남길 필요가 있을 때 사용함. (리셋 방식은 이후 시점의 기록을 그냥 지워버림); 결정적으로 한 가지 내역만 취소해야 하는 경우 리버트 사용 ++ 공유된 커밋은 리버트를 사용

 

- git reset 브랜치를 지정한 커밋으로 이동한다.

- git revert 는 입력한 버전의 이전 버전으로 되돌리는 명령어다.

옵션

- hard : 돌아가려는 커밋 이후의 모든 내용들이 사라진다.

- soft : 돌아가려는 커밋으로 돌아가고 이후의 모든 내용들이 stage 상태로 남아있다. (git add 된 상태) 커밋을 다시 할 수 있는 상태

- mixed : 돌아가려는 커밋으로 돌아가고 이후의 모든 내용들이 unstage 상태로 남아있다. (git add 이전 상태) (default)

 

#프로젝트의 변경사항을 버전에 담기

특정 파일 담기    git add (파일 이름)

모든 파일 담기     git add .

 

#변경 사항 커밋하기

커밋하기    git commit

커밋 메시지와 함께 커밋하기    git commit -m "커밋 메시지"

add와 커밋을 한꺼번에 하기    git commit -am "커밋 메시지"

깃 커밋 내역 확인하기 git log

 

#리셋과 리버트

리셋하기    git reset --hard (되돌릴 커밋 해시값)

리버트해서 과거 커밋으로 되돌리기    git revert (되돌릴 커밋 해시값)

커밋하지 않고 리버트 하기    git revert --no-commit (되돌릴 커밋 해시값)

#VIM 명령어

입력 시작 및 입력 종료    i, esc

저장 없이 종료 및 강제 종료, 저장하고 종료    :q, :q!, :wq

위로 스크롤 및 아래로 스크롤    k, j

 

VIM 명령어 참고

chapter 03 차원 넘나들기

브랜치를 여러개 만드는 경우

첫째, 하나의 프로젝트를 여러 형태로 사용해야 될 때(테스트 브랜치 여러 개)

둘째, 현업에서 여러 개발자가 역할을 분담해서 프로그래밍을 해야할 때(특정한 기능을 추가하는 브랜치, 오류를 개선하는 브랜치, 긴급한 수정 사항을 다루는 브랜치) 서로 각자 다른 차원에서 작업한 뒤 적용이 확정된 것만 메인 작업에 통합해서 사용자에게 배포하면 됨

 

-i =  --interactive

-m = --message

-c = --config

-b = --branch

-u 옵션은 --set-upstream 또는 --set-upstream-to

 

git 2.23 버전부터 checkout 명령어가 switch, restore로 분리

 

merge

 

rebase

진행하는 프로젝트의 성격에 따라 브랜치의 사용 내역을 남겨 둘 필요가 있다면 머지를 쓰는 것이 좋고, 작업 내역을 깔끔하게 만드는 게 중요하다면 리베이스가 더 적절한 선택 ++ 이미 팀원들 간에 공유도니 커밋에 대해서는 리베이스를 사용하지 않는 게 좋다

 

#충돌 상황

한쪽 브랜치와 다른 쪽 브랜치에서 같은 파일의 같은 줄에 서로 다른 내용을 입력하고 병합하면 컴퓨터는 서로 다른 변경 사항 중에서 어떤 걸 채택해야 될지 모르기 때문에 충돌이 발생함.

 

#브랜치 생성, 이동, 삭제하기

새 브랜치 생성하기     git branch (새 브랜치 이름)

브랜치로 이동하기    git switch (브랜치 이름)

브랜치 생성과 동시에 이동하기    git switch -c (새 브랜치 이름)

브랜치 삭제하기    git branch -d (삭제할 브랜치 이름) //-D면 강제 삭제

 

#머지와 리베이스

브랜치 병합하기    git merge (브랜치 이름)

브랜치 리베이스하기    git rebase (브랜치 이름)

머지 중단하기    git merge --abort

리베이스 중단하기    git rebase --abort

충돌 해결 후 리베이스 하기    --continue

 

add + 주석 git commit -am '...'

chapter 04 깃허브사용하기

커밋에서 충돌 사항이 있다면 본인 컴퓨터에서 병합하든 해결한 뒤에 비로소 자신이 작업한 커밋을 공유 공간에 올릴 수 있다. 구성원이 각자 동시에 작업하되 각자의 작업을 공유 공간에 올릴 때는 깃허브가 중간에서 교통 정리를 함

 

download zip은 프로젝트 파일만 다운로드 가능 관리 내역이 담긴 .git 폴더는 미포함

 

git push --force :서로 합의가 된 상태에서 한쪽 로컬 컴퓨터에 있는 작업 내역대로 원격 저장소의 작업을 맞출 때 진행

-t: track 해당 원격 브랜치와 연결되어 이를 추적하고 전담하는 브랜치를 로컬에 만든다는 의미

 

#깃허브 시작하기

원격 저장소 목록 보기    git remote

원격 저장소 연결 삭제하기    git remote remove (origin 등 원격 이름)

깃 저장소 복제하기    git clone (원격 저장소 주소

 

#푸시와 풀

로컬에서 원격 저장소로 푸시하기    git push

원격 저장소에서 로컬로 풀하기    git pull

머지 방식으로 병합하기    git pull --no--rebase

원격 저장소에 맞춰 리베이스하기   git push --rebase

로컬의 작업 내역을 강제로 푸시하기    git push --force

 

#원격 저장소의 브랜치 다루기    

로컬과 원격 저장소의 브랜치 확인하기    git branch --all

원격 저장소의 변경 사항 확인하기    git fetch

chapter 05 깃을 더 깊게 이해하기

#깃은 SVN(Subversion; 버전 관리 툴) 등에서 사용하는 델타 방식과 달리 스냅샷 방식을 사용함

  • 델타 방식: 파일이 수정되면 그 변경점들이 저장되는 방식
  • 스냅샷 방식: 새로운 버전이 만들어질 때 해당 버전의 각 파일이 최종 상태 그대로 저장되는 방식

#CVS(Concurrent Versions System), SVN 같은 VCS(Versoin Control System)과 달리 깃은 분산 버전 관리 시스템임

 

#작업 디렉토리는 tracked, untracked 두 가지 상태로 나눌 수 있음

  • tracked: 깃의 관리 대상에 정식으로 등록됨
  • untracked: 깃이 무시하는 파일 혹은 아직 관리되어 본 적이 없는 파일

작업 디렉터리에 있는 파일에 git add 명령을 적용하면 작업 디렉터에 있는 파일이 스테이지 영역으로 이동함(파일을 선택한 상태); 이 상태에서 git commit 명령을 실행하면 저장소의 커밋 상태로 옮겨짐. 이때 파일이 커밋되는 저장소를 .git directory라고 부르기도 함 이후 파일이 수정되면 다시 작업 디렉터리로 돌아간다 -> File Status Lifecycle

 

#깃에서 헤드(HEAD)는 현재 작업 중인 브랜치의 가장 최신 커밋을 나타내는 포인터

checkout 명령을 이용하면 헤드를 이동해서 이전 커밋으로 돌아가는 등의 작업을 수행할 수 있음(switch는 브랜치 바꾸기)

 

#헤드가 바뀌는 상황

  • 새로운 커밋이 작업 중인 브랜치에 추가될 때마다 헤드가 해당 커밋을 가리킵니다.
  • 새로운 브랜치를 생성할 때 헤드가 새로운 브랜치를 가리킵니다.
  • 다른 브랜치로 이동할 때 헤드가 이동한 브랜치를 가리킵니다.

#체크아웃(checkout)은 작업 내역을 그대로 두고 파일의 상태만 과거 시점으로 이동할 때 사용함(reset은 한 단계 뒤로 가면서 앞 단계를 지워 버리지만, checkout은 파일들의 상태만 한 단계 뒤 시점으로 되돌림)

git checkout HEAD^^^ //캐럿의 개수만큼 뒤 단계로 이동
git checkout HEAD~3 //위와 동일
git checkout - //뒤로 이동한 단계를 다시 한 단계 앞으로 돌리려면 하이픈을 붙임

 

#특정 명령 뒤에 어떤 옵션을 붙일 수 있는지 CLI에서 바로 찾고 싶다면 해당 명령을 입력하고 -h를 입력합니다.

 

#config에는 global 설정(해당 컴퓨터의 깃에서 사용하는 모든 저장소에 대한 설정)과 local 설정(특정 깃 저장소에 대해서만 설정)이 있다.

 

git에서 처음 푸시할 때 git push 명령 뒤에 --upstream 옵션을 붙여서 현재 로컬 브랜치를 원격의 어느 브랜치와 연결할지 처음에 설정한다.

 

alias 별칭

 

#페치와 풀의 차이

  • pull은 원격 저장소의 최신 커밋을 로컬 컴퓨터로 가져와 머지하거나 리베이스함
  • fetch는 원격 저장소의 최신 커밋을 로컬로 가져오기만 함
  • 원격 저장소에 있는 내용을 페치하고 체크아웃으로 전체 폴더의 상태를 확인할 수 있다.

 

#파일의 삭제와 이동

  • 파일 삭제하고 바로 커밋하기 git rm (파일 이름)
  • 파일 이름 변경하기 git mv (원래 파일 이름) (변경 파일 이름)
  • 파일을 작업 디렉터리로 되돌리기 git restore --staged (원래 파일 이름) (변경 파일 이름)

 

#git reset 명령으로 작업 되돌리기

  • 작업 내역 자체를 지우기 git reset --hard
  • 변경 사항을 스테이지 영역에서만 제거하기 git reset --mixed (복사한 커밋 해시값)
  • 변경 사항을 저장소에서만 제거하고 스테이지 영역에 남기기 git reset --soft (복사한 커밋 해시값)

 

#체크아웃과 페치

  • 헤드 한 단계 뒤로 이동하기 git checkout HEAD^
  • 헤드를 이용해 리셋하기 git reset (옵션) HEAD~(원하는 단계)
  • 원격 저장소의 최신 커밋을 로컬로 가져오기 git fetch
  • 원격 저장소의 새 브랜치 확인하기 git checkout origin/(브랜치 이름)
  • 원격 브랜치와 연결하는 브랜치 만들기 git switch -t origin/(브랜치 이름)

 

#도움말 확인하기 

  • 터미널에서 깃 명령어 확인하기 git help
  • 특정 명령의 옵션 확인하기 git (명령어) -h

 

#설정값 확인하기

  • 현재 모든 설정값 보기 git config (--global) --list
  • 에디터에서 설정값 보기 git config (--global) -e
  • 기본 에디터를 VS Code로 수정하기 git config --global core.editor "code --wait" //[core] editor = code --wait 지우면 원래 설정으로 돌아옴

 

#유용한 설정

  • 줄바꿈 호환 문제 해결하기(윈도우/맥) git config --global core.autocrlf true/input
  • 풀할 때 기본 설정을 rebase로 설정하기 gif config pull.rebase true //false시 merge가 기본값
  • 기본 브랜치 이름 main으로 지정하기 git config --global init.defaultBranch main
  • 푸시할 때 로컬과 동일한 브랜치 이름 지정하기 git config --global push.default current
  • 단축키 지정하기 git config --global alias.(단축키) "(명령어)"

chapter 06 더욱 세심하게 커밋하기

보통 하나의 커밋에는 한 단위 작업을 넣음; 커밋 메시지는 변경 사항의 내용과 의도를 명확하게 표현해야 함; 컨벤션(convention; 개발 팀원들끼리 일관된 방식으로 작성)에 따라 작성하느 것이 좋음

 

타입: 서브젝트

상세내용

푸터(footer): 중요한 변경 지점(breaking point)이 있을 때 적거나 특정 이슈에 대한 해결 작업일 때 이슈 번호를 적는 식으로 사용함

 

#커밋 메시지에는 적는 타입

타입  설명
feat 새로운 기능 추가
fix 버그 수정
docs 문서 수정
style 공백, 세미콜론 등 스타일 수정
refactor 코드 리팩토링
perf 성능 개선
test 테스트 추가
chore 빌드 과정 또는 보조 기능(문서 생성 기능 등) 수정

 

#코드의 변경 사항을 확인할 때는 코드를 헝크(hunk: 하나의 파일에서 수정된 코드 블록의 일부)라는 덩어리로 나눠서 살펴봄 //변경된 부분 사이에 변경되지 않은 부분이 있으면 헝크 이분됨

 

git diff --staged: 현재 스테이지 영역에 있는 파일과 이전 커밋 사이의 차이점을 보여줌

 

#커밋은 한 작업을 완전히 끝냈을 때 하는 것이 권장되는데 오류 해결 등 다른 작업을 해야 하는 일이 생겼을 때 작업하던 것은 그대로 두고 다른 작업을 커밋하기 난감함, 일단 하던 작업을 잠시 치워둘 필요가 있음(commit x) -> 스태시 기능을 사용하면 됨

 

stash를 할려면 먼저 깃의 관리 대상(tracked)이 되어야 함

 

#원하는 변경만 스태시하기

명령어 설명 비고
git stash 현 작업들 치워 두기 끝에 save 생략
git stash apply 치워 둔 마지막 항목(번호 없을 시) 적용 끝에 번호로 항목 지정 가능
git stash drop 치워 둔 마지막 항목(번호 없을 시) 삭제 끝에 번호로 항목 지정 가능
git stash pop 치워 둔 마지막 항목(번호 없을 시) 적용 및 삭제 apply + drop
git stash branch (브랜치 이름) 새 브랜치를 생성하여 pop 충돌 사항이 있는 상황에 유용
git stash clear 치워 둔 모든 항목들 비우기  

 

git stash pop vs git stash apply: 모두 치워 둔 작업을 가져오는 명령이나 pop은 stash 기록을 삭제함

 

`git stash branch 명령어는 현재 스태시된 변경 사항을 기반으로 새로운 브랜치를 생성하고, 그 브랜치에 스태시를 적용하는 유용한 방법입니다`

 

git commit --ammend 사용하면 최근 커밋 메세지와 내용 변경할 수 있음 //사소한 변경 사항인데 커밋 한 번 더 하기는 애매할 때

 

#git rebase -i //기본적으로 깃은 모든 커밋 내역이 순차적으로 저장됨 과거에 어떤 내역이 변경되면 그다음에 이루어지는 변경 사항은 이전과는 다른 커밋이 된다. 따라서 깃에서 과거에 어떤 내역을 수정하기 위해서는 그것만 수정하는게 아니라 수정한 커밋부터 이후까지 새로운 브랜치를 만든 다음에 기존 작업에 리베이스로 갖다 붙이는 방식으로 과거를 바꿈

명령어 설명
p, pick 커밋 그대로 두기
r, reword 커밋 메세지 변경
e, edit 수정을 위해 정지
d, drop 커밋 삭제
s, squash 이전 커밋에 합치기

git rebase --continue

 

#git clean 명령을 이용해 깃에서 아직 추적하지 않는 파일들을 삭제할 수 있음

옵션 설명
-n 삭제될 파일 보여 주기
-i 인터랙티브 모드 시작하기
-d 폴더 포함하기
-f 강제로 지워 버리기
-x .gitignore에 등록된 파일 삭제하기(주의)

 

#git checkout -> git switch, git restore로 분리됨

 

git restore 수정 사항 돌림; git restore --staged 스테이징 상태 되돌림

git restore --source=(해시값) (파일명) 특정 파일을 해시값 시점으로 돌림

 

#git reflog 리셋한 커밋 복원 -> 리셋한 커밋 바로 이전 해시값 복사해서 git reset --hard (이전 커밋 해시값)

 

#깃의 각 커밋에는 별명처럼 태그(tag)를 붙일 수 있습니다. 태그를 이용하면 여러 커밋 중에 기억해야 되는 중요한 커밋을 어떤 키워드로 표시해 둘 수 있고 또한 커밋에 버전 정보를 붙일 때 유용합니다.

 

#프로그램의 버전

  • 메이저(major): 프로그램의 이전 버전에서 호환되지 않을 정도로 큰 변화나 업그레이드를 나타냄
  • 마이너(minor): 새로운 기능이 추가되거나 기존 기능이 변경되는 정도를 나타냄
  • 패치(patch): 패치는 버그 등 작은 문제를 수정한 것을 나타냄

https://semver.org/lang/ko/  

 

유의적 버전 2.0.0

Semantic Versioning spec and website

semver.org

 

#태그에는 lightweight와 annotated 두 가지 종류가 있다.

  • lightweight는 특정 커밋에 붙여서 태그 이름으로 지칭하는 것
  • annotated는 작성자의 이름, 이메일, 날짜, 커밋 메시지, GPG 설명 등을 기입할 수 있다. //추천

태그 필터링을 할 때 v1.* -> 별표(*)

git push --tags

 

git tag (태그명) (해시값) -m (메시지)

 

#내용 확인하며 헝크별로 스테이지 하기

  • 헝크별로 스테이지 하기 git add -p //patch
  • 변경 사항 확인하고 커밋하기 git commit -v

#커밋하기 애매한 변화 치워 두기

  • 변경 내용 치워 두기 git stash
  • 스태시한 변경 사항 적용하고 삭제하기 git stash pop
  • 스태시한 변경 사항 적용하기 git stash apply
  • 스태시 목록 보기 git stash list

#커밋 수정하기

  • 커밋 메시지 변경하기 git commit --amend
  • 커밋 메시지 한 줄로 변경하기 git commit --amend -m

#취소와 되돌리기 깊이 앞기

  • 깃에서 추적하지 않은 파일 삭제하기 git clean
  • 작업 디렉터리의 특정 파일 복구하기 git restore (파일 이름)
  • 깃 작업 내역 확인하기 git reflog (리셋 삭제 내역까지 보임)

#커밋에 태그 달기

  • 태그 확인하기 git tag
  • 마지막 커밋에 태그 달기 git tag (태그)
  • 태그 삭제하기 git tag -d (태그)
  • 태그 메세지 입력하여 태그 달기 git tag (태그) -m '(태그 메시지)'
  • 원하는 태그 내용 확인하기 git show (태그)
  • 원하는 버전으로 체크아웃하기 git checkout (태그)
  • 원격 저장소에 특정 태그 올리기 git push (원격 저장소 이름) (태그)
  • 로컬에 있는 태그를 원격 저장소에 한 번에 올릴 때 git push --tags
  • 원격 저장소의 태그 삭제하기 git push --delete (원격 저장소 이름) (태그)

chapter 07 브랜치 더 깊게 파기

#fast forward: 변경 사항이 더 최근인 브랜치로 통합하는 방법(빨리 감기)

ff 방식이면 헤드만 제일 최근 브랜드로 옮겨져서 어떤 브랜치를 사용했고 언제 병합했는지 기록이 남지 않는다.

 

우측 fast forward

 

fast forward 하지 않고 커밋을 만들어서 병합하려면 아래와 같은 명령어를 사용

git merge -no-ff (병합할 브랜치 이름)

 

#3-way merge: 공통 조상 커밋을 기준으로 두 개의 브랜치를 자동으로 통합하는 방법 (참고)

05-03 merge의 종류 : fast-forward, 3-way merge - Visual studio 사용자를 위한 git (wikidocs.net)
https://wikidocs.net/153693

 base와 각 브랜치가 참조하는 commit을 고려하여 자동 병합

 

소스트리의 브랜치 배열은 가장 최근 커밋이 있는 브랜치를 일직선으로 보여주고 나머지를 곁가지로 표현한다. 즉, 어느 브랜치가 직선으로 나타나는지는 컴퓨터의 입장에서는 의미가 없음

 

#체리픽은 머지나 리베이스와 달리 특정 커밋을 복제해서 가져온다.

 

#rebase --onto를 되돌리기

git reflog 로 과거 시점 찾아서 git reset --hard (해시값)

 

#merge 와 merge --squash는 실행 후 코드의 상태는 같지만 세부 내역이 다릅니다. 예를 들어 A 브랜치와 B 브랜치를 머지했다면 두 브랜치를 한 곳으로 이어 붙인 것입니다. 하지만 스쿼시는 B 브랜치의 마디를 복사한 후 하나의 커밋으로 모아서 A 브랜치에 스테이지된 상태로 붙이는 것입니다. 그러므로 스쿼시를 한 뒤에 별도로 커밋을 해야 변경 사항이 온전히 반영됩니다.

 

#깃 플로우(git flow)

master -> main

 

 
브랜치 용도
main 제품 출시/배포
develop 다음 출시/배포를 위한 개발 진행
release 출시/배포 전 테스트 진행(QA)
feature 기능 개발
hotfix 긴급한 버그 수정

 

#다른 브랜치에서 원하는 부분만 가져오기

chapter 08 분석하고 디버깅하기

#git log 자세히 알아보기

//커밋에서 변경 내역까지 같이 보기
git log -p

git log -(확인할 커밋 개수)

//각 커밋의 상세 내용은 보여주지 않지만 어떤 파일이 변했는지 변경 내용 확인 가능
git log --stat

//로그 한 줄로 보기
git log --oneline
//--online은 한 줄로 보여주는 --pretty=oneline 옵션과 
//커밋 해시값을 짧게 나타내는 --abbrev-commit 옵션을 하나로 합쳐 줄인 것

//특정 커밋의 변경 사항에 있는 단어로 커밋 검색
git log -S (검색어)

//커밋 메시지를 기준으로 검색
git log --grep (검색어)

//git log 명령의 조회 범위를 제한하는 옵션
//--since, --after: 명시한 날짜 이후의 커밋만 검색
//--until, --before: 명시한 날짜 이전의 커밋만 조회
//--author: 입력한 저자(원래 작업을 수행한 원작자)의 커밋만 보여줌
//--committer: 입력한 커미터(마지막으로 이 작업을 적용한(저장소에 포함시킨)사람)의 커밋만 보여줌

//--graph: 그래프 모양
//--decorate: 브랜치나 태그 등 모든 레퍼런스를 표시
//--decorate=short (기본값); =no 출력 결과에 브랜치나 태그 등 레퍼런스X =full 레퍼런스 상세출력
git log --all --decorate --oneline --graph

 

그밖의 출력 결과 포맷 정하기

git log --graph --all --pretty=format:'%C(yellow)%h%C(reset)%C(blue)%ad%C(reset) 
%C(white)%s %C(bold green)-- %an%C(reset) %C(bold red)%d%C(reset)' --date=short

//%C - 출력텍스트의 색상
//%h - 짧은 길이 커밋 해시
//%ad - 저자 시각
//%s - 요약
//%an - 저자 이름
//%d - 브랜치 정보(태그 등)

 

#다른 브랜치에서 원하는 부분만 가져오기

  • 다른 브랜치의 커밋 가져오기: git cherry-pick (커밋 해시값)
  • 도착 브랜치에서 파생된 출발 브랜치를 이동할 브랜치로 옮겨 붙이기: git rebase --onto (도착 브랜치) (출발 브랜치) (이동할 브랜치)
  • 대상 브랜치의 마디를 하나로 묶어 main 브랜치로 가져오기: git merge --squash (대상 브랜치)

#로그 자세히 알아보기

  • 각 커밋마다 변경 사항 함께 보기: git log -p
  • 최근 n개 커밋만 보기: git log -(개수)
  • 최근 n개 커밋을 변경사항과 함께 보기: git log -p -(개수)
  • 커밋 변경 내역 보기: git log --stat
  • 커밋마다 태그와 커밋 메시지를 한 줄씩 보기: git log --oneline
  • 변경 사항에서 단어 검색하기 git log -S (검색어)
  • 커밋 메시지를 기준으로 검색하기: git log --grep (검색어)
  • 자주 사용되는 그래프로 로그 보기 git log --all --decorate --oneline --graph

#차이 살펴보기

  • 작업 디렉터리에서 변경 사항 확인하기: git diff
  • 변경된 파일 목록 확인하기: git diff --name-only
  • 스테이지 영역으로 넘어간 변경 사항 확인하기: git diff --staged
  • 커밋 간 차이 비교하기 git diff (커밋1) (커밋2)
  • 브랜치 간 차이 비교하기 git diff (브랜치1) (브랜치2)

#누가 코딩했는지 알아내기

  • 파일의 부분별로 작성자 확인하기: git blame (파일 이름)
  • 특정 부분을 지정해서 작성자 확인하기: git blame -L (시작 줄) (끝 줄 또는 +줄 수) (파일 이름)

#오류가 발생한 시점 찾아내기

  • 이진 탐색 시작/종료하기: git bisect start/reset
  • 오류 발생 지점/양호 지점 표시하기: git  bisect bad/good
  • 오류 의심 지점으로 이동하기: git checkout (해당 커밋 해시값)

chapter 09 깃허브 제대로 활용하기

READ.md; md == markdown(HTML처럼 서식을 만들 때 쓰는 마크업 언어)

``` ~ ``` 코드 블럭; |, --- 테이블 작성

 

#체계적으로 협업하는 팀에서는 한 팀원이 자기 브랜치에 변경 사항을 푸시하면 다른 팀원이 미리 코드를 리뷰해서 몇 명 이상 동의하면 develop이나 main 브랜치 같은 공유 브랜치로 보낸다 -> 풀 리퀘스트(PR: Pull Request)

 

#이슈(issue)란 프로젝트에서 고쳐야 할 오류나 문제, 요청 사항을 알리기 위한 저장소의 게시판 같은 곳

 

#SSH(Secure Shell)프로토콜을 이용한 인증

SSH 키는 공개 키와 개인 키로 구성되어 있는데, 이 둘은 알고리즘으로 서로 연결되어 있다.

ssh-keygen -t ed25519 -C "이메일"

git remote -v
git remote remove origin

git remote add origin (SSH)

 

#GPG(GNU Privacy Guard)로 커밋에 사인하기

gpg --version

gpg --list-secret-keys --keyid-format=long

gpg --full-generate-key

gpg --armor --export (GPG 키)

git config --global user.signingkey (GPG키)

git tag -s

 

'개인공부용1 > etc' 카테고리의 다른 글

NULL vs nullptr  (0) 2024.09.02
this 메모  (0) 2024.08.29
이득우의 게임 수학  (1) 2024.01.31
'개인공부용1/etc' Related Articles more