GIT

◉ branch
⦁ 독립적으로 어떤 작업을 진행하기 위한 개념, 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행 가능

⦁ 이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모으고
여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듬
각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용, 이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됨

⦁ 저장소를 처음 만들면, Git은 'master'라는 이름의 브랜치를 만듬, 이 저장소에 파일을 추가, 변경하여 그 내용을 저장(Commit)하는 것은 모두 'master' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 됨
'master'가 아닌 새로운 브랜치를 만들어서 선언(checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어 짐

◉ merge
⦁ 특정 브랜치에서 작업한 내용을 또 다른 브랜치에 적용 또는 병합 하는 것

◉ 파일 상태
⦁ 파일들의 상태는 크게 Tracked와 Untracked로 나뉨, Tracked의 Unmodified 상태의 파일들을 수정하게 되면 Modified 상태가 됨
이후 다시 git add 명령어를 이용하여 Staged 상태로 올려준 후 커밋을 하는 과정을 반복함

⦁ Untracked : Git에 의해 파일의 상태가 추적되고 있지 않은 상태를 의미, Untracked 상태인 파일들은 파일의 내용을 변경하여도 Git이 파일의 내용 변경을 감지하지 못함
Commit 하면 Tracked 상태로 바뀝

⦁ Tracked : Git에 의해 파일의 상태가 추적되고 있음을 의미, Tracked 상태인 파일들은 수정되었을 때 Git이 파일의 변경 내용을 감지함
Unmodified : 파일의 수정이 Git에 의해 감지되지 않은 상태
Modified : 파일의 수정이 Git에 의해 감지된 상태
Staged : 파일이 Staging area에 존재하는 상태, staging area에 있는 파일들을 커밋하게 되면 해당 파일들은 하나의 커밋으로 저장된 후, 파일의 상태는 Unmodified로 변경됨
만일 Staged상태의 파일을 수정할 경우 파일이 staged이면서 modified인 상태가 되기에 수정한 파일을 커밋하려면 다시 git add 명령어를 사용해야함

⦁ 3가지 상태
Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.
Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다.
Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.

◉ Git 영역
온라인
⦁ Remote repository(원격 저장소)

로컬
⦁ Work space(작업 공간)
눈으로 볼 수 있는 디렉토리 자체를 의미, Git은 Work space를 자동으로 스캔 하다가 변경된 사항을 발견하면 사용자에게 해당 사항을 알려주고, 어떤 행위를 취해야 하는지 적절한 명령어 및 동작을 알려줌
git init을 입력한 직후, 다른 어떠한 Git 명령어도 입력하지 않은 상태의 파일들이 존재하는 영역

⦁ Staging area(스테이징 영역)
Local repository에 저장할 파일들이 임시적으로 대기하는 영역을 의미
일반적으로 Git을 활용하여 작업을 할 때에는 Work space에서 작업을 마친 파일을 Staging area로 옮겨서 모아두고 어느 정도의 단위 작업이 끝나면 Staging area에 모인 파일들을 한 번에 Local repository로 저장
git add 명령어를 사용하여 Staging area로 이동시킴

⦁ Local repository(지역 저장소)

명령어
◉ git init : 새로운 Git 저장소(repository)를 생성, 디렉토리 내에 .git 디렉토리가 생성

◉ git status : 작업 디렉토리(working directory)와 스테이징 영역(staging area)의 상태를 확인
Changes to be committed : 변화가 감지되었으며, 아래의 파일들을 Commit할 수 있음을 의미, 즉 출력되는 파일들은 Staged 상태를 의미
Changes not staged for commit : Local Repository의 최신 버전과 Work space의 파일 간의 변화가 감지되었으나 아직 스테이징되지 않았음을 알려줌, 즉 출력되는 파일들은 Modified 상태를 의미
Untracked files : 워킹 디렉토리에 있는 파일중 한번도 Git 저장소가 관리한 적이 없는 새로운 파일 즉 Untracked 상태의 파일들을 보여줌

◉ git add : 작업 디렉토리(working directory) 상의 변경 내용을 스테이징 영역(staging area)에 추가하기 위해서 사용
git add 파일명 또는 디렉토리 경로 : 작업 디렉토리의 변경 내용의 일부만 스테이징 영역에 넘기고 싶을 때는 수정한 파일이나 디렉토리의 경로를 인자로 넘김
git add . : 현재 디렉토리 이하에서 발생한 모든 변경 내용을 스테이징 영역으로 넘김, 상위 디렉토리의 변경 내용을 포함하지 않음
git add -A : 작업 디렉토리 상에 어디에 위치하든 항상 동일하게 모든 변경 내용을 스테이징으로 넘김
git add -p : 각 변경 사항을 터미널에서 직접 눈으로 하나씩 확인하면서 스테이징 영역으로 넘기거나 또는 제외할 수가 있음

⦁ git config : 각종 설정값들을 설정함
git config --local : 범위 옵션의 기본값, 다른 범위는 --global, --system
git config --global --unset : 특정 설정을 삭제
git config --global init.defaultBranch 변경할 브랜치 명 : 앞으로 git init을 입력했을 때 생성되는 기본 브랜치의 이름이 변경할 브랜치 명 으로 설정됨

⦁ git rm
git rm 파일명 :
git rm --cached 파일명 : 스테이징한 파일을 다시 Work space로 되돌림

⦁ git commit : Local repository에 파일을 저장하고 버전을 기록함
git commit -m "커밋 메시지" :
git commit --amend -m "변경할 메시지" : --amend 옵션은 직전의 커밋에 대해 메시지나 파일을 변경할 수 있도록 하는 옵션, 예) git add <누락된 파일> git commit --amend
git commit -am : 한번이라도 커밋된 파일을 수정했을 때 add와 커밋을 동시에 실행해줌

◉ git branch
git branch : 생성한 브랜치 목록과 현재 어떤 브랜치 인지 확인
git branch 생성할 브랜치 명 : 로컬에 설정한 이름의 브랜치를 생성
git branch -m 기존 브랜치명a 변경할 브랜치명b : a브랜치를 b브랜치로 이름을 변경함
git branch -d 브랜치명 : 설정한 브랜치를 삭제, merge하지 않은 커밋을 담고 있는 경우 삭제되지 않음, 강제종료 옵션 -D으로만 삭제 가능
git branch -r : remote (원격) 브랜치 목록을 보여줍니다.
git branch -a : all(모든) 브랜치 목록을 보여줍니다.

◉ git checkout
⦁ git checkout <브랜치명> : 특정 브랜치로 이동
⦁ git checkout -b <생성할 브랜치명> : 특정 브랜치를 생성하여 이동
⦁ git checkout -b <생성할 브랜치명> <베이스 브랜치명> : 베이스 브랜치 데이터를 복사하여 새로운 브랜치를 생성하여 붙여넣은 뒤 이동

⦁ git log :

◉ git fetch
⦁ git fetch 원격 저장소 별칭 : 원격 저장소의 커밋들을 로컬 저장소로 가져온다. 자동으로 병합(Merge)를 해주지 않기 때문에 본인이 직접 확인을 한 후에 병합(Merge)하는 과정을 거쳐야한다.
가져온 커밋 내역은 git branch -r 실행시키면 특정 브랜치가 생성되는 것으로 보이는데 해당 브랜치로 이동하면 확인할 수 있다.

⦁ git remote
git remote : 현재 프로젝트에 등록된 리모트 저장소명을 출력함
git remote -v : 현재 프로젝트에 등록된 리모트 저장소 단축 이름과 URL을 함께 출력함
git remote add 원격 저장소 별칭 원격 저장소 URL : 리모트 저장소 추가
git remote rm 원격 저장소 별칭 : 지정한 리모트 경로를 제거함
git remote prune 원격 저장소 별칭 : 원격 리포지토리에 존재하지 않는 브랜치들이 local 에 존재할 경우 삭제한다. git fetch --prune 과 같은 기능

⦁ git restore :
git restore 파일명 : 파일의 내용을 수정 전으로 복구
git restore --staged 파일명 : git add 명령으로 Staging Area에 올라간 파일들을 다시 Working Directory로 되돌림

⦁ git reset : remote repository에 적용된 commit 이 아닌 경우 삭제 시킴
git reset HEAD^ : 가장 최신의 commit 을 삭제 하고 이전 커밋으로 돌아감
git reset --hard 돌아갈 커밋 해쉬 : 해쉬에 입력한 커밋으로 돌아가고 그 이후에 실행했던 커밋은 전부 삭제됨
git reset --soft [commit ID] : commit된 파일들을 commit 하기 전 상태 즉 staging area로 돌려놓음
git reset --mixed [commit ID] : commit된 파일들을 add 하기 전 상태 즉 working directory로 돌려놓음

⦁ git revert : 현재 커밋에서 설정한 커밋에 해당하는 파일만 제거하고 새로운 커밋을 생성함
git revert --no-commit 커밋 해쉬 : revert한 결과를 commit 하지 않고 stage 상태로 만듬

push

• push 실패상황
  원격 브랜치에 로컬 브랜치에는 없는 새 커밋이 있을 경우, git push는 "non-fast-forward" 오류를 발생시키며 실패한다. 이는 로컬 브랜치가 원격 브랜치보다 뒤쳐져 있을 때 발생하며 이 경우 먼저 git pull 명령으로 원격의 변경 사항을 가져와 병합해야 한다.

• 명령어 사용법
  git push : Remote repository에 업로드
  git push <원격 저장소 별칭> <로컬 브랜치명> : 로컬 브랜치를 리모트 브랜치에 업로드한다. 즉 로컬 브랜치와 동일한 브랜치를 생성하여 주입한다.
  git push <원격 저장소 별칭> <로컬 브랜치명>:<리모트 브랜치명> : 로컬 브랜치명과 다른 브랜치명을 가진 리모트 브랜치를 생성하여 주입한다.

◉ pull
⦁ git pull : 원격저장소에 있는 프로젝트의 변경사항을 그대로 로컬저장소에 옮겨와 자동으로 병합
git pull 원격 저장소 별칭 브랜치명

⦁ git clone : Remote repository의 코드를 로컬로 복사해오면서 해당 Remote repository와 자동으로 연결을 맺어주는 명령어
저장되는 디렉토리의 이름은 Remote repository의 이름으로 설정됨, Remote repository를 로컬로 복제하면 .git이 자동으로 만들어지므로 별도로 git init을 입력할 필요가 없음
Clone을 진행하면 별도로 git remote add 불필요
git clone remote repository url

⦁ git switch : 브랜치 이동
git switch -c 브랜치명 : 브랜치를 생성하고 해당 브랜치로 이동함

git merge

예) main 브랜치에 practice 브랜치를 병합하려면 main 브랜치로 이동하고 git merge practice 명령어를 실행함

• git merge --ff 병합할 브랜치명 : 옵션 기본값이 --ff 이며, 현 브랜치와 병합할 브랜치가 Fast-Forward 관계일 경우 병합할 브랜치(커밋)을 따라감. without Merge 커밋
  Fast-Forward 관계가 아닐 경우 병합할 브랜치와 병합됨. with Merge 커밋

• git merge --no-ff 브랜치명 : 현재 브랜치와 병합 대상의 관계가 Fast-Forward이던 아니던 무조건 Merge 커밋과 같이 병합되는 옵션이다.

• git merge --ff-only 브랜치명 : 현재 브랜치와 병합 대상의 관계가 Fast-Forward인 경우에만 병합 진행. Merge 커밋 생성되지 않음

• git merge --squash 브랜치명 : 현재 브랜치에 병합 대상을 바로 커밋하지 않고 Staging area 에 만 올려둔다.(add한 상태) 커밋을 하더라도 병합대상에 있던 커밋들은 합쳐지지 않는다.

• git merge --abort : 머지를 중단시킴

• merge시 두가지 발생 상황
  1. 서로 다른 파일을 수정했을 때 : 충돌 없이 git이 자동으로 소스코드를 합쳐줌

  2. 서로 같은 파일을 수정했을 때 : 다시 이와 같은 상황으로 나뉨 2-1) 서로 같은 이름의 파일을 수정했지만 수정한 부분이 다를 때, 2-2) 서로 같은 이름의 파일을 수정하고 수정한 부분이 겹칠 때
     2-1의 상황은 1번 상황과 마찬가지로 충돌없이 git이 자동으로 소스코드를 합쳐줌
     2-2 상황은 git은 자동으로 merge를 해줄 수 없는 상황이라고 사용자에게 알리고 수정을 사용자에게 위임함, 이런 상황을 'conflict 충돌' 이라고 부름

깃허브에서 pull request(PR) 를 실행하면 merge 옵션을 선택하는데 아래와 같다.
Create a merge commit -> git merge --no-ff
Squash and merge -> git merge --squash
Rebase and merge -> git rebase

⦁ main 브랜치에서 hotfix 브랜치를 생성하고 몇개의 커밋을 한 뒤 main 브랜치로 이동 후 hotfix 브랜치를 merge 할 경우 Fast-Forward Merge 가 가능하기 때문에
hotfix 에서 생성한 커밋만 main 브랜치에 합처지고 Merge 에 대한 커밋은 발생하지 않는다.

⦁ main 브랜치에서 hotfix 브랜치를 생성하고 몇개의 커밋을 하고 main 브랜치에서도 몇개의 커밋을 한 상황에서 hotfix 브랜치를 merge 할 경우
main 브랜치에 hotfix 에서 생성한 커밋외에 Merge 했다는 커밋이 생성되고 head 가 해당 커밋에 위치한다. head란 해당 해당 브랜치에 마지막 커밋을 뜻하는 포인터 이다.

⦁ 깃 병합 방법
fast-forward : A 브랜치에서 다른 B 브랜치를 Merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동 시킴
branch간의 병합을 진행할 때 커밋이 생기지 않고 merge 명령어를 실행하는 브랜치의 Head Commit이 병합 되는 branch의 Head commit으로 이동되는 방식

git rebase

• 말 그대로 base를 재설정한다는 의미로 하나의 브랜치가 다른 브랜치에서 파생되서 나온 경우, 다른 브랜치에서 진행된 커밋을 다시 가져와서 base를 재설정하는 것이다.

  예를들어 B브랜치가 A브랜치에서 파생된 경우, A브랜치와 B브랜치는 각각 계속해서 커밋이 이루어진 상태에서 B브랜치에서 A브랜치를 rebase 할 경우 A브랜치의 모든 커밋 기록이 B 브랜치의 커밋 기록 이전에 꼬리잡기 처럼 따라 붙는다 즉 base가 재설정 된 것이다.
  쉽게 말해서 마치 지금 처음으로 A브랜치 에서 B 브랜치가 파생된 것처럼 변한 것이다.

  이 점이 Merge와 다른데 merge의 경우 새로운 커밋이 발생하면서 합쳐진다.

◉ git diff : modified 상태 파일들의 수정 내역을 보여줌

◉ git stash
⦁ 파일 수정중 다른 branch로 이동해야하는 상황이 생기거나, 브랜치를 착각해서 다른 브랜치에 작업했을때 stash로 저장하고 본래 작업해야할 브랜치로 이동하고 임시로 저장된 작업내용을 적용할 때 사용한다.
⦁ git stash : 현재 작업 수정 내역을 임시저장소에 저장한다.
⦁ git stash save "설명할 내용" : 임시저장소에 저장시 설명을 덧붙일 수 있다.
⦁ git stash list : 임시저장소에 저장된 stash 목록을 출력한다.
⦁ git stash apply : 가장 최근의 stash를 가져와 적용한다. staged된 파일을 자동으로 스테이칭 처리 해주지 않는다.
⦁ git stash apply stash명 : stash명에 해당하는 stash를 적용한다.
⦁ git stash apply --index : 가장 최근의 stash를 가져와 적용하면서 staged된 파일을 자동으로 스테이칭 처리까지 해준다,
⦁ git stash drop : 가장 최근의 stash를 삭제한다.
⦁ git stash drop stash명 : stash명에 해당하는 stash를 제거한다.
⦁ git stash clear : stash를 전체 삭제한다.
⦁ git stash pop : 가장 최근의 stash를 적용하고 바로 삭제한다. apply + drop의 형태

키워드
HEAD : 현재 작업 중인 브랜치를 가리킴

◉ git tag
⦁
⦁
⦁

◉ 에러 내역
⦁ error:failed to push some refs to : github 원격 저장소에는 내 Local 에 없는 파일이 있는 상태에서 로컬을 push 할 때 발생하는 오류, update 가 필요하여 git pull 실행하고 git push 하면 해결
⦁ fatal: refusing to merge unrelated histories : 관련 기록이 없는 두 프로젝트를 병합할 때 git이 거부를 한다. 즉 git pull 할 때 발생함 해결법 git pull origin main --allow-unrelated-histories