git 간단명료 사용법/ 브랜치 설명/git branch/git merge/git rebase/git init/ git error/ git branch삭제/git 커밋삭제/git revert/ git reset/ HEAD개념/git 파일 삭제/collaborator

먼저 맨 처음 repository생성 후

주의:readme.md를 만들었다면 git init할 수 없다.
이미 커밋이 되어 버린상태라 병합 수 없기에
git clone을 해야한다.

git init

git remote add origin 주소

여기서 origin은 컨벤션에 따라 이름이 지정된것이지
이름을 따로 지정해줄 수는 있다. 그냥 이 git원격저장소의 별명이다.

git에 다른 작업이 있거나 할때

git clone 주소 => 폴더 전체로 클론
git clone 주소 . => 파일들만 따로 뽑아 클론

원격에 올릴때

git add .

현재폴더의 모든 것 더해주는것
원칙적으로는 git add file file file.... 하나하나 더해주는게 좋다.

git reset 파일명

add해준거 stage에서 뺴기

git status

git에 잘 올라가졌는지 파일의 현상태를 알려준다.
초록이면 올라갔고, 빨강이면 add안됌.

git commit -m "무엇을 누가 추가했다 이정도 내용"

커밋도 마찬가지로 새로 추가한 내용이 있을때 마다 커밋해주는 것이 좋고

이렇게 커밋을 하고나면 히스토리가 남는데 그것을 확인할 수있는것

git log

커밋 히스토리
=> git log -n 10 하면 10번쨰전까지만 보여준다.

그 log를 이용해서 HEAD나 커밋해쉬를 알아내 그 단계로 넘어가거나 삭제 할 수 있다

git commit 삭제하기

HEAD

일단 HEAD가 뭐냐면 현재 체크아웃된 커밋을 가리키는 포인터이다.
HEAD는 일반적으로 현재작업중인 브랜치의 최신 커밋
HEAD~1(HEAD^) 한 커밋전, HEAD~2 두커밋전을 가리킨다.

A -> B -> C 순으로 커밋이 있고 현재 HEAD는 C를 가리킨다고 가정

git reset

최근 커밋을 되돌릴 수 있다 => 커밋 히스토리를 변경시킨다. 주의필요

git reset HEAD는 아무런 일을 하지 않는다. 왜냐? reset은 포인터를 움직이는 방식으로 동작하는데 포인터가 현재를 가르키고 있기 때문에.
반면에 git revert HEAD는 가능한데 그 이유는 그 HEAD커밋에 반대되는 다른 커밋을 새로 생성하기 때문이다. 그렇기에 그 직전으로 되돌아가는것이기때문에 되돌아가는것이 가능하다. 히스토리도 지워지지않고.

1. soft reset:
git reset --soft HEAD~1
=> 최근의 커밋을 되돌린다. 변경된 파일들은 스테이징 영역에 그대로 남음.

git status를 확인하면 해당 파일들이 여전히 "staged" 상태로 나타나는 것을 볼 수 있다는 것

2.Mixed Reset (기본):
git reset --mixed HEAD~1 # or git reset HEAD~1
=> 최근의 커밋을 되돌리고, 변경된 파일들은 스테이징 영역에서 제거된다 (하지만 작업 디렉토리에는 그대로 남아있다).

3.Hard Reset:
git reset --hard HEAD~1
=> 최근의 커밋을 되돌리고, 스테이징 영역과 작업 디렉토리의 변경사항까지 모두 제거한다. 이 방법은 변경사항을 완전히 삭제하므로 주의가 필요.

git revert

git revert HEAD
git revert [커밋해시]

=> git revert는 새로운 커밋을 생성하여 이전 커밋의 변경사항을 취소하여, 커밋 히스토리를 변경하지 않으므로 다른 사람들과 함께 작업하는 저장소에서 안전하게 사용할 수 있다.

헷갈리기 때문에 좀 더 설명하자면::
먼저 기본 개념:

스테이징 영역은 커밋될 준비가 된 변경사항들의 집합입니다.
git revert는 특정 커밋의 변경을 되돌리는 새로운 커밋을 생성하는 명령입니다.

사용할 수 있는 두가지 방법을 풀이::

기본 git revert 사용:

git revert HEAD/[커밋해시]를 실행하면
=> 해당 커밋을 되돌리는 변경사항을 바로 생성하고 커밋합니다.
이렇게 하면 스테이징 영역에는 아무런 변경사항도 남아있지x.
WHY? 모든 변경사항이 즉시 새로운 커밋으로 저장되기 때문.

-n 또는 --no-commit 옵션을 사용하여 git revert 실행:

이 옵션을 사용하여 git revert -n HEAD/[커밋해시]를 실행하면, 해당 커밋을 되돌리는 변경사항만 준비한다.
이 변경사항은 스테이징 영역에 추가됩니다, 하지만 아직 커밋되지는 않게 되는것.

이 시점에서 git status를 확인하면 스테이징 영역에 변경사항이 존재.

이후에 git commit -m "Revert some commit"와 같은 명령으로 수동으로 커밋을 생성가능.

간단히 말하면, -n 또는 --no-commit 옵션을 사용하면 git revert는 그전 단계로 되돌아가면서 사용자는 스스로 커밋을 생성할 수 있는 기회를 갖게된다.

그렇기에 원격저장소에 푸시한 커밋을 되돌리려면 git revert를 사용하는게 훨씬 권장되는 사용법이다.

git push origin(다른별칭으로 remote add했으면 그것) 브랜치 이름

여기서 푸시하고 난 후에 나오는 에러들이 있는데 그것들은 여길 참조:https://velog.io/@stella_k/git-errors-%EB%AA%A8%EC%9D%8C

여기서 잠시!
git push -u origin main에서 -u 옵션은 "upstream"의 약자로서

-u를 쓰면 좋은 장점:
git push 또는 git pull만 입력하면 된다.

이 뜻은 현재 로컬브랜치에서 원격 origin/main브랜치를 upstream으로 연결해 서로의 status를 확인할 수 있게해주며 git push 또는 git pull만 입력하면되서 간결성이 있다.

로컬브랜치란 그냥 기본main이의 내가 따로 브랜치를 만들어서 push 하기이전의 것을 로컬 브랜치라한다.

그래서 일반적인 워크플로에서는 같은 이름을 가진 로컬 브랜치와 원격 브랜치를 추적하도록 설정하는 것이 일반적인데(즉 처음으로 push 하게되면 원격저장소가 생성되고 추적되겠지), 특수한 사항에서 바꿔야 되는 상황이면 밑의 코드에 따라 추적위치를 다른곳으로 바꿔 줄 수 있다.

git branch --set-upstream-to=origin/dev-featureB featureA

이 명령은 featureA 브랜치가 origin/dev-featureB를 추적하도록 설정한다.

git branch

브랜피의 현상태:: 나는 지금 어디에있는지 어떤 브랜치들이 있는지

git brach 새로만들브랜치이름

그 이름으로 브랜치 생성

git branch -m 바꿀이름

브랜치이름을 바꾸고 싶을때는 현 위치에 그 브랜치를 두고 이 명령어 실행

브랜치 삭제

1. 삭제할 해당 브랜치에서 벗어나야하기 떄문에

git checkout main

2. 로컬브랜치 삭제

git branch -d [브랜치명]

3. 브랜치 변경 사항이 아직 병합이 안되어있으면 -d로 삭제 불가 -> -D강제로 삭제

git branch -D [브랜치명]

4. 원격 브랜치 삭제

git push origin --delete [브랜치명]

*. 브랜치 삭제 전 해당 브랜치 커밋이 중요하고 나중에 참조해야하면 삭제전 백업해주기
1. 새로운 브랜치 만들기
git checkout <branch_to_backup>
git branch <backup_name>

삭제하려는 브랜치와 동일한 위치에 새로운 브랜치를 만들어 주면 커밋 히스토리 들을 다 가지게 된다. 공유하는것
2.태그 사용하기
git checkout <branch_to_backup>
git tag <backup_tag_name>

태그는 좀더 필요하면 나중에 더 알아가면 좋겠고,

일단 여기서는 branch와는 다르게 tag는 한번 지정해주면 움직일수 없다.
북마크처럼 사용된다고 생각하면되는데, 특정 커밋을 참조하는것이다.
삭제될 브랜치라 더이상의 커밋이 없다는 가정하에 태그를 사용하는 것.

이러한 백업 방법 을 사용하면 원래의 브랜치를 안전하게 삭제하고,
필요할 때 백업한 브랜치나 태그를 참조하여
커밋 히스토리를 복구하거나 조회할 수 있다.

브랜치관련설명

여기서 브랜치를 가지치라고 생각하게되면 무언가 하나의 공간이라고 생각할 수있는데 그게아니다.

시간의 포인터라고 보면된다.

만약 A세계가있다.
A는 따로 시간이 흐를 B시간대를 주고싶어.
그래서 그 만들어주고 싶은 시간대에 포인터를 가리켜 B를 동시간대를 가질 수있게해. 하지만 그 이전의 A의 히스토리를 다 공유는 하고 있고, 그 이후의 벌어지는 사건들은 공유가 안되는거지. 왜냐? 동시간대라 A도 자기만의 사건이 벌어질테니까.

예)

A세계 :: #A-B-C-R-T
B세계 :: A-B-C-D-&E-K-O
&C세계 :: A-B-C-D-E-P-U
#D세계 :: A-P-J

A의 A커밋에 포인터D를 넣어주고 계속 알아서 자시 시간을 가져가지만 그 이전 히스토리 A는 가지고 있지
B도 마찬가지로 A의 C단계까진 히스토리 공유하지만 그때 branch를 해주어서 자기만의 시간이 나가는거고
C는 B의 E타임라인에서 부터 다른 자기만의 동시간대를 형성한것.

여기서 brach니까 계속 커밋이 생성하면서 최근 커밋으로 움직이게되지만
tag를 사용하면 그 지점에 계속 움직이지 않고 있게된다고 생각하면돼. 더이상의 커밋저장은 하지않는거지.

그렇기때문에 실제로 커밋이나 데이터가 중복되어 복사되는게 아니라, 해당 커밋을 가리키는 포인터가 생성 => 저장소의 크기가 급격히 커지지 않게된다.

서브모듈

Git 서브모듈은 하나의 Git 저장소 내에 다른 Git 저장소를 포함시키는 기능.

예를 들어, 여러 프로젝트에서 공통으로 사용되는 라이브러리를 별도의 Git 저장소로 관리하고, 이 라이브러리를 메인 프로젝트의 서브모듈로 포함시키는 경우.

git switch/checkout 브랜치이름

그 브랜치 이름으로 브랜치가 이동되는데.
switch는 새로생긴 언어다
checkout이 4가지 기능을 하는데 하나는 이전커밋이동, 브랜치 이동인데 헷갈리다는 평이 많아 switch를 새로 만들었다.

한번에 생성하고 위치를 변경해는 옵션을 추가해주면 한번에 할 수있다.
git switch -c 이름
git checkout -b 이름

git checkout 4가지 기능

1. 다른브랜치로 전환: git checkout 브랜치명
   git 2.23버전 업데이트이후:
   git switch 브랜치명

2. 새로운 브랜치 생성->그 브랜치 전환:git checkout -b 브랜치명
   git switch -c 브랜치명

3. 이전 커밋으로 이동:git checkout [커밋해시]
   커밋해시는 Git에서 각 커밋을 고유하게 식별하기 위한 SHA-1 해시:: git log 에서의 커밋번호 앞에서 7자리까지만 처도 식별가능
   이렇게하면 detachedHEAD상태로 전환=> 필요한 작업완료 후 새로운 브랜치 생성하거나 기존 브랜치로 돌아가.
   why? detachedhead상태에서 커밋하면 브랜치에 연결이 되지않은 커밋이 생성되서 추후 접급하기 어려움.

4. 특정 파일을 이전버전으로 되돌리기:git checkout [커밋해시] -- [파일명]
   만약 한 커밋에서 여러 파일의 변경사항이 있었고, 그 후에 다른 커밋을 수행하여 여러 파일을 수정했는데, 그 중 한 파일만 특정 커밋 시점의 상태로 되돌리고 싶을 때 사용하는 것.
   git restore --source=[커밋해시][파일명]

여기서 잠깐! 브랜치가 원격 저장소에만 존재하는 경우: 로컬 저장소에는 없지만 원격 저장소에는 있는 브랜치인 경우
1.git fetch - 최신정보 불러와서
2.git branch -a 명령을 사용하여 모든 브랜치(로컬 및 원격)를 확인
3.git checkout -b 가져올브랜치이름 origin/가져올브랜치이름 : 즉 따로 리모트에 있는 브랜치를 로컬에 만들어줘야해

브랜치위치는 가져올곳 : git pull origin(별칭) (가져올내용이담긴브랜치)

이것은 git fetch origin 브랜치 + git merge origin 브랜치 합친것 인데, 새로운 브랜치에서 정보를 받아온다거나 할때는 git pull 하는게 빠르지만

만약 데이터가 달라져있는게 로컬에 있다면 git fetch 하고 merge하는게 좋은상황일때도 있다.

허나 pull을 하는 것이 대부분인것이 애초에 다른 값이 들어있다면(로컬과 원격브랜치가 divergent발산) 병합이 되지않기에 그것을 확인해주는 작업을 하게된다.

발산이란?

로컬 브랜치와 원격 브랜치가 서로 다른 지점에서 변경이 발생하여 각각 다른 방향으로 진행되었다는 것으로 ::
처음에는 로컬과 원격브랜치 모두 같은 커밋A에서 시작,
로컬에서 작업을 진행해서 새로운 커밋 B를 생성
근데 동시에 다른 개발자가 작업을 진행해서 새로운 커밋 C를 생성하고 푸시

이렇게 되면 로컬브랜치와 원격브랜치는 서로 다른지점에서 변경이 발생
이것을 발산이라합니다.

발산되지 않은 상태라 하면 단순진행(fast-foward)인 상황이라 할 수 있다.
원격브랜치가 로컬 브랜치보다 앞선 커밋을 가지고 있지만, 로컬 브랜치는 추가적인 커밋이 없는 상태를 말한다. 즉, 최신 커밋으로 직진하는 형태에는 발산이라 칭하지 않고 merge를 하더라도 커밋이 생성되지 않는다.

추가적으로 단순진행(fast-foward) 더 예를 들자면:

1. 다른사람의 작업 가져올때:
   내 로컬에는 새로운 커밋이 없는 상태(일정기간 작업이 없는 등등)에서 최신 변경사항을 가져올때

2. 원격저장소에서 직접 작업한 내용 가져올때 :
   Git-Hub같은 웹 인터페이스를 통해 직접 파일을 수정하거나, readme갱신, 또는 머지된 pull-request의 내용을 로컬로 가져올때그렇기에 git pull --ff-only로 명시적으로 지정 하여 단순진행 머지를 실행하면, 벼롣의 병합커밋없이 히스토리가 깔끔히 유지된 상태에서 원격 브랜치의 상태로 갱신이 가능합니다. 히스토리 추적이나 이해하기가 더 쉽다는 장점이 있다.

git fetch origin 브랜치명

원격 저장소의 최신 변경사항(커밋, 브랜치, 태그 등)을 로컬에 가져오지만, 로컬의 작업 디렉토리에는 아무런 변경이 보이지 않는다.

허나 머지전 내용을 확인하거나 충돌을 예방을 위해 사용하고 그 이후 git rebase를 활용해 커밋없이 머지 시키고 싶을때 사용할 수 있다.

git merge origin/[원격브랜치명] :현재 브랜치에 원격의 변경사항을 병합
git rebase origin/[원격브랜치명] :현재 브랜치의 커밋들을 원격 브랜치 위로 재배치 => 커밋히스토리가 달라짐.

이 차이점을 보려하면

1. log로 차이점 보기
main 브랜치에는 없고 origin/main 브랜치에만 있는 커밋들을 보여줍

git log main..origin/main

반대로,
origin/main 브랜치에는 없고 main 브랜치에만 있는 커밋들을 보여줌

git log origin/main..main

2. git diff로 차이점 보기
이건 코드를 직접 보여주기때문에 : 달라진점 초록색글씨에 빨간색커서

git diff main..origin/main > diff_output.txt

이렇게 파일로 아웃풋 시켜 원본과 비교해줄 수 있다.

3. vscode Extention 사용하기
Source Control 패널 => 변경사항 섹션에서 파일을 클릭하여 변경 내용을 확인확인.
특정 브랜치 간의 차이점을 보려면, VSCode의 터미널에서 git checkout을 사용하여 원하는 브랜치로 전환한 후 위의 절차를 따르면 된다.

git fetch -p/git fetch --prune
(-p 옵션은 원격에서 삭제된 브랜치를 로컬에서도 정리)

로컬과 다르게 원격에서 삭제된 브랜치가 있을때, 일반 git fetch 만 사용하면
로컬의 원격 추적 브랜치 목록과 실제 원격 저장소의 브랜치 목록이 동기화되지 않을 수 있다.

로컬의 원격 추적 브랜치:
로컬에서 원격을 추척하고 비교하기위한 참조 역할인데,
origin/branch-name 형태로 표현하고 fetch실행시 업데이트되는데
제대로 동기화 안되면 활용하기 힘들다.
git diff main..origin/main 과 같은 문구 활용할때 문제 생길 수 있다. 메인이라 그렇진 않겠지만 다른 삭제된 브랜치라면.

git merge

원격 저장소의 변경사항을 현재 체크아웃된 로컬 브랜치와 병합

git fetch로 가져온 변경사항들을 merge로 병합하려면
git fetch로 가져온 최신커밋을 가르키는 특별한 포인터인 FETCH-HEAD를 사용해야한다.

git merge FETCH_HEAD

Fast-forward 병합: 로컬 브랜치가 원격 브랜치의 직접적인 이전 상태일 때, Git은 단순히 로컬 브랜치의 포인터를 원격 브랜치의 최신 커밋으로 이동시킵니다. 이 경우 새로운 커밋은 생성되지 않습니다.

3-way 병합: 로컬과 원격 브랜치가 발산(diverged)한 경우, Git은 마지막 공통 조상(커밋)과 이 두 브랜치의 최신 커밋을 사용하여 병합을 수행하는 방식으로두 브랜치의 변경사항을 병합하여 새로운 "Merge commit"을 생성합니다.

a-b-c(branch 1)
a-d-e(branch 2)

즉, 마지막 공통 조상 커밋 a 확인 -> 브랜치들 커밋확인 -> 병합시도
3단계를 거친다는 의미.

git rebase 브랜치 명.

git rebase전단계로 취소해서 돌아가기
git reset --hard HEAD@{1}

리베이스를 사용하려면 일단
당연히 합쳐질 브랜치에 fetch를 해야한다
그 이후에 rebase를 사용하는데,
그다음에 push

git rebase를 사용하면, 현재 브랜치의 커밋들이 일시적으로 제거되고, 대상 브랜치의 모든 커밋이 먼저 적용되면서 커밋히스토리가 선형화된다.

예를 들면::

A-B-C (m branch)
\
D-E (y branch)
현재 y브랜치에서 git rebase m 하면
일시적으로 y브랜치의 변경사하인 D E를 제거하고,
m브랜치의 A- B -C가 적용되고
순차적으로 y브랜치의 D - E가 적용

그후엔

A-B-C (m branch)
\
D-E (y branch)

이렇게 변경.

비선형::merge할 경우 커밋이 두개의 부모커밋을 가지게되면서 복잡해지거나, 동시에 여러 사용자가 다른브랜치에 작업하면 커밋히스토리가 나뉘어져 매우 복잡해진다.

선형:: 근데 리베이스를 사용하면 병합커밋없이 연속적인 일련의 변경사항으로 재배치해 => 단순하고 가독성있게 유지하면서 동인한 변경내용을 포함.

rebase 충돌

리베이스를 하다 충돌이 발생할 수있는데 충돌이 발생하면 충돌을 해결 한 후
:: git rebase --continue를 하여 rebase과정을 계속 진행해준다.

그리고 나서 push를 하게되는데 이때 문제가 발생할 확률이 높다.

push 충돌

git rebase를 사용하면 커밋의 내용이나 순서가 바뀌면 해당 커밋의 해시값도 변경되기때문에, 리베이스된 로컬 브랜치의 커밋 히스토리와 원격 저장소의 브랜치의 커밋 히스토리가 서로 다르게 될 수 있다.

그렇게되면 push는 변경사항을 원격에 반영할 수 없게되는데
이상황에서 원격에 반영하려면
=> git push --force
=> git push --force-with-lease
이건 단지 하나의 브레이크를 더 주는것 뿐인데,
원격 브랜치의 상태가 로컬의 마지막 알려진 상태와 일치하는지 확인.
=> 다시 말해, 그 사이에 다른 변경사항이 푸시되지 않았는지 확인해주는것.

그렇다고 해서 다른 팀원이 이전 커밋을 pull해서 push 할 계획이 있는지에 대한 정보가 없기에 최소한의 브레이크이다.

이렇게 강제로 push 하면 추후에 팀원들의 최신 변경사항을 가져올때 문제가 발생할 확률이 높아 팀프로젝트를 할때는 권장되는 방법은 아니다.

pull충돌

이것은 git pull할때도 마찬가지인데,
git fetch + merge이니까 merge작업을 할때
merge , rebase, fast-forward 할 것인지 정하라 하는데
그 중
git config pull.rebase False(merge)/
git config pull.rebase True(rebase)/
git pull --ff-only(fast-forward)
리베이스를 선택하게 되면, 원격저장소의 변경사항을 가져와서 현재 브랜치 커밋들을 그위로 재배치하게되면 이것도 커밋히스토리가 재구성되어 권장되지 않는다.

그렇기에 위에서 언급했다 시피 팀 프로젝트보다는 혼자 개인프로젝트를 할때나 혼자 작업하는 브랜치에서는 리베이스를 사용하여 커밋 히스토리를 깔끔하게 유지하는것이 좋을 수 있다.

이것 왜에도 pull이 당겨지지 않을 때가 있는데,
이 이유는 이미 현재 상태에서 수정이 되어있고 그 것과 다른 또 수정된 무언가를 pull로 땡겨오려하면 충돌이 생겨 풀이 안될때가 있다. 그럴땐 =>
현재 수정하고 있는 브랜치에 먼저 커밋을 해주고 난 다음에 주로 master에서 가져오니 가져와야할 브랜치에서 pull해주면 내것과 pull된 자료의 차이점을 fetch처럼 보여주고 그것을 보며 수정해준다음에 push해주면 된다.

문제들의 예:

먄약 커밋을 원격에 했던 상태 (다른사람이 올렸든,내가 이전에 올렸든)
이미 원격과 달라지게된다 rebase를 해서 push하면

내가 rebase해서 커밋히스토리를 변경해 push한 후에 다른 팀원이 이전커밋의 히스토리를 가지고 있는 변경사항을 push하려할때 커밋히스토리가 다르기에 push에 문제가 생기게된다.(git push --force-with-lease 체크해서 푸시해도)

git rebase -i / git rebase --interactive라는 대화형 리베이스도 있는데 커밋히스토리를 텍스트 에디터에서 직접 수정할 수있다.
예)
커밋 순서 변경
커밋 메시지 수정
커밋 합치기 (squash)
커밋 분리 (split) 등등

파일삭제

먼저 로컬에서 파일삭제
git rm <파일명>

커밋
git commit -m "파일 삭제: <파일명>"

그리고 변경사항 원격저장소 푸시
git push origin <브랜치명>

헷갈려 하는 부분들이 있는데:

git rm --cached <파일명>

git rm --cached <파일명>만을 사용하면 해당 파일은 로컬 Git의 추적 목록에서만 제거하는 것이지 원격저장소에 있는 파일을 삭제시키는 것이 아니다.

git 추적 목록에서 제거되고 untracked상태가 되지만 아직 이 변경을 커밋도지않아서 git status 하면 changes to be committed 영역에 나열된다.
즉, 커밋을 하지않으면 로컬이력에는 아무 변화가 반영되지 않는다
=> 변경사항을 stage영역에 추가했다하더라고 커밋히스토리에는 추가하지않아 영구적으로 기록하지 않아 현재 변경이 된 상태는 아닌것이라 할 수 있다.

사용법::

잘못 추적하고 있는 파일 제거: 예를 들어, 기본설정파일 등등 .gitignore에 포함되어야 하는데 잘못해서 Git에 추가된 파일을 추적에서 제거하고 싶을 때 사용한다.

그냥 .gitignore에 추가하면 되는거 아냐? 하겠지만

기본적으로 새로운 파일은 untracked 상태로 존재.
아직 그 파일의 변경사항을 추적하고 있지 않다는 것을 의미한다.
git add실행시 git의 추적은 시작되고 해당 파일은 staged 상태로 변경된다. 커밋을 하면 staged상태의 모든 변경사항이 커밋에 포함되고, 커밋 후 해당 파일 git에 의해 tracked상태로 관리.

그렇기에 그이후에
.gitignore에 추가하는 것만으로는 이미 추적 중인 파일이 Git의 추적에서 제거되지는 않기때문에 그 파일의 변경사항은 계속해서 Git에 감지될것이기 때문.

git rm --cached 파일명: 파일을 Git의 추적 목록에서 제거

.gitignore에 파일 추가 : 변경사항

git commit -m "변경사항 커밋": 로컬 저장소의 git히스토리에는 해당파일이 삭제 (git push 안하고 멈추면 원격저장소에 반영 안되 해당파일 존재)

git push : 원격저장소 해당 파일 삭제

하는 순으로 해줘야 원격에 올라간 파일도 삭제되고 ignore상태가 된다.

collaborator

팀 레포지토리 만들기.

먼저 레포지토리 만들어 => 설정들어가 => collaborator들어가서 팀원들 깃헙 유저네임이나 이메일로 invitation보내주고 팀원들이 허락하면 끝