버전관리 시스템 (VCS)

Version Control System
제품으로는 SVN(Subversion. 중앙집중형), GIT(분산형), BitKeeper, CVS(Subversion에 밀려서 멸망) 등이 있다.
버전을 관리한다는 것은 시간과 차원을 관리한다는 것
쉽게 말하면 데이터의 과거와 현재 상태를 관리하는 것
더 쉽게 말하면 싱글 RPG게임할때 세이브포인트를 지정하는것과 같다. 세이브포인트의 용량을 본적있나? 몇KB 정도밖에 안한다. 문자열 데이터일 뿐.

VCS의 주요 종류

CVS (Concurrent Versions System)

서버에 프로젝트의 원본이 있고 클라이언트 각각은 서버에서 파일을 가져다가 로컬저장소에서 변경한 뒤 변경된 내역을 서버에게 보낸다.
파일의 이름변경이나 이동을 자동으로 추적하지 못하고 완전한 버전은 오직 서버에만 존재한다.

Subversion (SVN)

CVS의 여러 단점을 개선한 아파치의 최상위 프로젝트
CVS와 완전하게 호환되는 동시에 더 나은 기능을 제공하는 것을 목표
commit이 곧 원격 저장소 반영이다. Git과 달리 push 단계가 없다.

SVN의 파일 상태:

Incoming Mode(파란색 ← 모양): 서버에는 올라와있는데 로컬에는 수정이 안된 파일
Outgoing Mode(검정색 → 모양): Local에서 수정하고 있는 파일. 수정 끝나면 commit하면 됨
Conflict Mode(빨간색 ↔ 모양): Local과 서버에서 같은 부분을 서로 다르게 수정한 파일

Mercurial (머큐리얼)

2005년 매트 맥컬이 개발한 분산모델의 버전관리시스템
Git과 기본 개념은 크게 다르지 않으나, Git은 필요한 기능을 골라서 사용하지만 Mercurial은 버전관리시스템에 필요한 모든 기능을 한번에 통합하여 제공
배우고 사용하기 더 쉽다는 평가를 받음

Git

Git의 탄생 배경

2005년, 리누스 토발즈(Linus Torvalds)가 리눅스 커널 개발을 위해 Git을 만들었다.

배경 스토리:

리눅스 커널 프로젝트는 1991년부터 패치와 압축 파일로 관리되다가 2002년부터 상용 DVCS인 BitKeeper를 무료로 사용하기 시작했다.
2005년, BitKeeper의 저작권 소유자인 BitMover사와 리눅스 커널 커뮤니티의 관계가 틀어지면서 무료 사용이 불가능해졌다.
구체적으로는 앤드류 트리젤(Andrew Tridgell)이 BitKeeper의 프로토콜을 리버스 엔지니어링하려 시도했고, 이로 인해 BitMover는 무료 라이선스를 철회했다.
리누스 토발즈는 기존 VCS들(CVS, Subversion 등)이 리눅스 커널같은 대규모 분산 프로젝트에 적합하지 않다고 판단했다.
결국 리누스는 직접 새로운 시스템을 만들기로 결심하고, 2005년 4월 3일 개발을 시작해 4월 7일(단 4일 만에) 첫 버전을 완성했다. 같은 해 6월 16일에는 리눅스 커널 2.6.12를 Git으로 관리하기 시작했다.

Git의 설계 목표:

속도 – 대규모 프로젝트에서도 빠른 성능
단순한 설계
비선형적 개발(수천 개의 동시 브랜치) 지원
완전한 분산 시스템
리눅스 커널같은 대규모 프로젝트를 효과적으로 관리

참고 자료:

Git의 기본 개념

작동 원리

로컬환경의 파일을 추적하고 있다가 사용자가 소스를 수정하면 그 변경사항을 감지한다.
이후 사용자는 리모트 서버에 변경사항을 반영하고싶은 파일을 고른뒤 업로드한다.
물론 리모트 서버에 있는 파일을 내 컴퓨터로 복제할 수도 있다.

왜 사용하는가?

시간여행이 가능한 평행우주를 만들 수 있다:

“최종버전.pptx”, “최최종버전.pptx”, “진짜최종버전.pptx”… 이런 식의 파일 관리에서 벗어날 수 있다.
파일은 하나로 유지되면서 그 파일의 역사를 거슬러 올라갈 수 있다.
실험적인 기능을 별도 브랜치에서 개발하고, 성공하면 메인 브랜치로 병합할 수 있다.
숙련도에 따라 Git 활용도가 달라지지만, 기본만 사용해도 엄청난 생산성 향상을 얻을 수 있다.

Git의 핵심 특징

1. 스냅샷 방식의 버전 관리

다른 VCS들은 파일별로 변경된 델타(차이점)만 관리한다.
Git은 프로젝트 전체를 스냅샷(사진처럼 찰칵) 형태로 관리한다.
변경되지 않은 파일은 다시 저장하지 않고 이전 버전의 파일에 링크만 걸어준다.

2. 분산 버전 관리 시스템 (DVCS)

데이터가 중앙 서버에만 있는 것이 아니라 모든 개발자의 컴퓨터에 전체 저장소가 복제된다.
인터넷 없이도 대부분의 작업(커밋, 브랜치, 이력 조회 등)을 할 수 있다.
나중에 인터넷 연결 후 git pull 또는 git fetch로 동기화하면 된다.

3. 데이터 무결성

Git의 거의 모든 작업은 데이터베이스에 내용을 추가하는 작업이다.
일단 커밋을 한 이후라면 데이터를 잃어버리기 매우 어렵다.
실험적인 작업을 안전하게 시도할 수 있다.

Git 사용 Best Practices

.gitignore 파일을 먼저 세팅해놓는 것이 좋다.
커밋과 푸쉬는 자주 하는 것이 좋다.
커밋의 단위는 논리적인 일관성이 유지되는 한 최대한 작게 쪼개는 것이 좋다.
- 예) ❌ “로그인 수정” → ✅ “로그인 화면 스타일 수정”
작업하기 전에 fetch하는 것을 습관화해야 한다.
Git은 실시간으로 인식하는 것이 아니라 파일이 저장되는 시점을 기준으로 파악한다.

공식 자료 한글판 꼭 읽기

pro-git
repository관계도

공부

얄코 깃-깃헙
https://www.youtube.com/watch?v=1I3hMwQU6GU&t=3639s&ab_channel=%EC%96%84%ED%8C%8D%ED%95%9C%EC%BD%94%EB%94%A9%EC%82%AC%EC%A0%84
https://www.yalco.kr/lectures/git-github/
거의가 원래알고있던거고 1:25부터 충돌해결

사용하는 방법

깃설치
2가지중 하나 사용
GUI (소스트리)
CLI (커맨드)

준비

GIT, IDE, SOURCETREE
간혹 윈도우에서 아이콘이 안뜨면 C:Users(내사용자명)AppDataLocalSourceTree 에 있다.
공부는 CLI로 하고 현장에서는 CLI와 GUI를 섞어쓰는것을 추천한다.

Git의 파일 상태 관리

Git에서 파일은 크게 두 가지 상태로 나뉜다:

Tracked (추적되는 파일)

이미 Git이 관리하고 있는 파일들. 세부적으로 다음과 같이 나뉜다:

Unmodified: 수정하지 않음 (최근 커밋 이후 변경사항 없음)
Modified: 수정함 (변경되었지만 아직 Staging Area에 추가되지 않음)
Staged: 커밋하면 저장소에 기록할 준비가 된 상태

Untracked (추적되지 않는 파일)

Git의 관리에 들어간 적 없는 파일. git add로 Staging Area에 추가해야 추적이 시작된다.

실습 예제

깃의 기본 개념
깃 설치
소스트리 설치
1. 1절.txt 파일을 만들고 애국가 1절, 2절.txt만들고 내용은 비워주세요.
  동해물과 백두산이 마르고 닳도록
  하느님이 보우하사 우리나라만세
  무궁화 삼천리 화려강산
  대한사람 대한으로 길이보전하세
2. 2절.txt내용에 애국가 2절 채워넣기
  남산 위에 저 소나무 철갑을 두른 듯
  바람 서리 불변함은 우리 기상일세
  무궁화 삼천리 화려 강산
  대한 사람 대한으로 길이 보전하세
3. 1절.txt내용 변경
  동해물 -> 서해물
  백두산 -> 한라산
  하느님 -> 부처님
4. 새폴더 라는 폴더 만들고 간단.py 넣기
```
print('Hello, world!')
print('안녕') #문자열
print(123) #정수형
print(123.123) #실수형
```
5. 브런치생성

용어

Git 디렉토리 : Git의 핵심. 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳. clone하면 이것이 만들어짐.
Repository : 저장소. 프로젝트가 저장된 공간
commit : 가장 중요한 기능. local repository(내 컴퓨터 저장소)에 저장하는 것이다. 게임으로 치면 세이브시점을 만드는것.
push : remote repository( 원격 저장소) 에 저장하는 것.
대표적으로 GitHub이 있다. 개발자스러운 아이디를 잘지어야된다. 많이 노출되기 때문에
Origin : 리모트 서버로 사용하는 관례적인 이름.
보통 한개의 리모트 서버만 운영하는 경우가 대다수 이기 때문에 많은 사람들이 Remote와 Origin을 섞어쓰곤 한다.
Stage : 이번에 저장할 캡슐
Staging Area(Index) : 워킹트리에서 작업한 내용이 커밋되기 전에 거치는 공간. Git디렉토리 안에 있다. 이 공간이 있기 때문에 필요없는 파일들은 커밋에 포함하지 않고 일부만 커밋할 수 있다.
stash : 책갈피.
- 커밋할수는 없는 코드인데 그렇다고 코드를 날려버리긴 아까울때 백업 및 책갈피 개념으로 쓰는 명령어. 하던일을 놔두고 급하게 다른일을 해야할때 사용.
- stash기능이 없더라면 별도의 브런치를 만들어서 checkout해야하는데 그러기위해서는 반드시 커밋을 해야한다. 마무리되지 않은 작업을 커밋해야된다는 문제가 생긴다.
- “git stash”를 하게 되면 Staged 영역에 있는 파일, 또는 추적하는파일중 수정된것을 보관 스택에 보관한다. 스택에 쌓이기 때문에 stash를 할수록 더 아래의 순번으로 가며 더 큰 index숫자를 갖게된다.
- 그리고 working directory는 깨끗해지고 HEAD로 이동한다.
- 백업했던거 가져오려면 git stash apply –index
  //–index 옵션은 Staged상태까지 적용하여 원래작업하던 상태로 돌리는것
  또는 “git stash pop” //Stash를 적용하고 스택에서 제거. 로그에서도 지워지므로 이것이 좋다.
- 백업한거 지울려면 git stash drop
- 리스트 볼려면 git stash list
Staged : 파일을 수정후 git add를 통해 Staging Area에 추가한 상태.
즉 수정한 파일을 이번 커밋에 포함할거라고 표시한 상태
커밋을 하면 staging area에 있는 모든 파일들을 저장소에 올린다.
branch : 가지. 다른 평행우주. 회사소스는 그대로 두고 나만 별도의 우주
main브랜치는 기존기능을 유지/보수만 하면서 새로운 기능을 추가하려고 한다면 새로운 브랜치를 하나 따서 개발하는것이 정석.
소스트리에서 브런치 갈라진게 바로안보이는것은 각가지마다 변경사항이 없기 때문.
가지마다 새로운 변경사항이 있으면 브런치 갈라진거 보이게된다.
브런치확인 : gir branch -a //all 옵션없으면 로컬만 보인다.
브랜치이동 : git switch 브랜치명
브랜치삭제 : git branch -d 브랜치명
로컬과 리모트 브랜치연결 : 로컬브런치 선택한상태에서 git switch -t origin/브런치명
conflict : 깃이 스스로 판단하지 못하는것은 어떤 똑똑한 사람도 자동으로 판단할수 없고 수동으로 판단해야 한다는 것이다. 그렇게 같은곳을 변경했을때 양쪽의 소스를 보고 수동으로 양자택일 해야한다.
master
head: 해당 브랜치의 제일 앞쪽 끝의 커밋. 각 브랜치는 자신의 head를 가진다.
HEAD: 현재 체크아웃된 커밋을 가리키는 포인터. 대부분의 경우 현재 브랜치의 최신 커밋을 가리킨다.
- origin/HEAD: 원격 저장소의 기본 브랜치
- HEAD: 로컬 저장소의 현재 작업 위치
- HEAD와 브랜치 이름이 다른 위치를 가리키면 “detached HEAD” 상태 (이전 커밋을 체크아웃한 경우)
- Git은 한 번에 하나의 브랜치에서만 작업 가능하며, 이를 HEAD 브랜치라고 한다.
forward : 브랜치 헤드가 이동하는 방향
fast forward : 현재작업중인 브랜치가 있고 다른 브랜치의 내용을 머지하는경우 발생하는 특별한 머지
내가 작업한것을 마스터에 머지하려고 하는데, 마스터에는 내가작업한 내용보다 최근에 수정한 내용이 있어서 앞쪽에 속할때 mergecommit대신에 fast-foward(마스터의 내용을 내브랜치에 업데이트)한다.
fast-forward(빨리감기)
특정 브랜치를 다른 브랜치가 가르키는 커밋으로 갱신할 때 사용. 병합 시나리오 중의 하나인데 복잡한 병합과정 없이 브랜치의 포인터만을 최신 커밋으로 이동시키는 간단한 방법
분기한 브랜치의 커밋 히스토리가 기존 브랜치의 커밋 히스토리를 포함한다.
이상태에서 병합하게 되면 새로운 Merge commit이 만들어지는게 아니라 HEAD(참조위치)만 변하게 된다.
working tree(워킹트리) : Git디렉터리에서 특정버전을 checkout해온 것.
여기에서 작업을 진행하게 된다.
checkout: 워킹트리의 일부 혹은 전체를 업데이트하는 것. 브랜치를 전환하거나 특정 커밋으로 이동한다.
- 호텔에서 체크아웃하듯이 현재 브랜치에서 목표 브랜치로 이동
- 명령어: git checkout 브랜치명
- 소스트리에서는 더블클릭
- 직접 HEAD를 바꾸는 것. 특정 커밋을 직접 가리키는 이유는 거기서 새로운 브랜치를 만들거나 내용 되돌리기 등을 위해
- 현재의 아직 커밋하지 않은 파일과 Checkout할 버전이 충돌이 나면 브랜치 변경이 안되므로 작업하던 것을 모두 커밋하거나 stash해야 한다.
- git checkout . : 모든 변경사항을 취소 (⚠️ 주의: 복구 불가능)
- 중요: Git 2.23 버전(2019년 8월)부터 checkout이 switch와 restore로 분리되었다.
  - git switch 브랜치명: 브랜치 전환 전용
  - git restore 파일명: 파일 복구 전용
  - git restore --staged 파일명: Staging Area의 파일을 Working Directory로 이동
fetch : 리모트에서 로컬로 가져오기(다운받기)만 하고 합치지는 마.
리모트 서버에 새로 업데이트한 모든 내역을 받는다.
pull : 리모트리파지토리의 최신소스를 가져와(fetch) 병합(merge)하는것
즉, 가져와서 합친다. 다른 브런치끼리도 가능
merge : 병합. 병합하지 않고 한쪽으로 덮어쓰게 되면 다른한쪽의 업데이트 내역이 사라지기 때문에 이력 관리가 안된다. 병합을 잘해야 충돌이 안나고, 그래서 충돌이 일어나면 수동으로 병합을 해줘야한다.
병합을 하면 HEAD브런치가 아닌 브랜치의 내용이 HEAD브런치로 합쳐지게 된다.
- CLI사용법 : 주브런치로 이동한 상태에서 git merge 합칠브런치명
rebase: 브랜치의 base를 다시 설정하여 커밋을 재배치하는 것
- merge vs rebase 차이점:
  - merge: 두 브랜치를 합쳐서 새로운 merge commit을 만듦 (브랜치 흔적 남음)
  - rebase: 한쪽 브랜치의 커밋들을 다른 브랜치 위에 재배치 (히스토리가 한 줄로 깔끔하게 정리됨)
- 사용 시 주의사항:
  - ⚠️ 이미 팀원들과 공유된 커밋에는 rebase를 사용하지 말 것 (히스토리 꼬임 발생)
  - pull 받는 상황에서는 rebase 사용 가능: git pull --rebase
- rebase 후 충돌 해결:
  1. git pull --rebase 실행
  2. 충돌 발생 시 파일 수정
  3. git add .
  4. git rebase --continue (별도 커밋 불필요)
- CLI 사용법:
```
# feature 브랜치를 main 브랜치에 rebase
git checkout feature
git rebase main
# 충돌 해결 후
git add .
git rebase --continue
# main 브랜치를 fast-forward
git checkout main
git merge feature
git branch -d feature
```
- rebase 옵션:
  - git rebase --continue: 충돌 해결 후 rebase 계속 진행
  - git rebase --skip: 현재 커밋을 건너뛰고 계속 진행
  - git rebase --abort: rebase 취소하고 원래 상태로 복구
  - git rebase -i: interactive 모드로 커밋을 선택적으로 rebase
- 소스트리: 복잡하고 버전마다 차이가 있어 CLI 사용 권장
ogigin : clone했을때 원격저장소의 디폴트 이름 (git remote add 이름 주소)
master : 브랜치 중 가장 중심이 되는 branch (옛날버전의 공식 이름이였으나 노예제도가 떠오른다고 최신버전은 main으로 대체됨.)
소스트리 기본브런치를 master에서 main으로 변경하려면 우측위 Settings – Repository Settings의 Edit Config File 설정파일에서 main으로 변경
pull request : 내가 작업한 브랜치를 가져가서 합쳐줘
이름이 Merge Request가 아닌이유는 합치는 행위를 하는 주체가 요청을 받은 사람이기 때문에

커밋 메시지 작성 가이드

기본 원칙

미래의 나와 다른 개발자들을 위해 명확하고 의미 있는 메시지를 작성해야 한다.

작성 형식

첫 줄: 간단하지만 명확한 요약 (50자 이내 권장)

(빈 줄)

상세 설명: 변경 이유, 변경 내용, 관련 이슈 번호 등

좋은 커밋 메시지 예시

✅ 로그인 화면 스타일 수정

사용자 피드백을 반영하여 로그인 버튼 크기를 확대하고
색상 대비를 개선하여 접근성을 높임

관련 이슈: #123

나쁜 커밋 메시지 예시

❌ 수정
❌ asdf
❌ 로그인 기능 추가, 버그 수정, 스타일 변경 (여러 작업을 한 커밋에)

따라해보기

C드라이브에 GitTest폴더생성
숨김파일 표시 하고 .git폴더가 만들어진것 확인
1.txt파일에 애국가, 2.txt파일은 비워놓기
스테이지에 올리고 최초의 commit
2.txt만들고 애국가2절넣고 빈 3.txt만들고 두번째 커밋
남산을 북한산으로 바꾸고, 동해물을 남해물로 바꾸고, 하느님이를 부처님이로 변경 하고 단어세개 변경 세번째커밋

명령어와 순서 링크

git init
이 폴더를 깃의 명령하에 두겠다. 저장소생성
git config –global user.name “내이름”
git config –global user.email “내 메일주소”
//깃은 여러개발자들이 함께 사용하기 때문에 연락처를 남겨두는것
//–global은 프로젝트마다가 아니라 이 컴퓨터에 전반적으로 적용하겠다는 말
//값부분 빼고 명령어 치면 현재의 값을 확인해볼 수 있다.
//숨김파일 보면 .git폴더가 생긴걸 확인할수있다.
//.git 폴더가 모든 역사(변경내역)을 담고있다.
git config –global init.defaultBranch main //기본 브런치를 main으로 변경
git status
현재 폴더의 상태를 깃의 관점으로 살피기
밑에는 아직 담기지 않은것.
- git status -sb // sb옵션은 short , branch. 현재 브랜치 정보와 함게 파일의 상태를 간략하게
git ignore //깃이 관리 안할 파일들 처리
git add 파일명
해당 파일을 GIT이 추적할 수 있게 저장소에 추가 (타임캡슐에 담기)
다시 git status 확인하면 묻을것들 색깔 바껴서 보임
왜 각각의 파일을 담는게 있냐? 한버전에 모두 담지않고 버전별로 나눠서 타임캡슐에 담고싶을수 있으니.

git add -A //전체 파일 담기 (All의 약어. 작업디렉토리에 있는 변경내역을 한번에 추가)
git add . //현재폴더의 모든파일 담기
git commit -m “메세지”
변경된 파일을 저장소에 제출. message와 함께 로컬 리파지터리에 저장
이전 커밋상태부터 현재상태까지의 변경이록이 기롯된 커밋을 추가한다.
무슨캡슐인지 설명해줘야됨
- git commit –amend -m “메세지” 마지막 커밋 메세지를 수정
  - vscod
- git commit –amend 커밋하자마자 바로 버그를 발견한 경우같을때 이전 커밋에 포함시키기
git push : 로컬의 수정내용을 리모트 리포지토리에 저장한다.
git pull : 브랜치의 내용을 fetch한후 merge.
git log : 이때까지 묻은 캡슐들을 본다. 모든 커밋마다 고유한 문자열이 있다.
git log –graph –all –decorate
git log –oneline
git diff git add를 하기전의 파일만 가능하다.
git diff –cached 스테이지 영역으로들어온 파일의 비교
git branch 브랜치명: 브랜치 생성 (소스트리에서는 브랜치 버튼)
git branch: 현재 생성된 브랜치들의 목록 확인
git branch -a: 원격 브랜치 포함 모든 브랜치 목록
git branch -d 브랜치명: 브랜치 삭제 (병합된 브랜치만 삭제)
git branch -D 브랜치명: 브랜치 강제 삭제 (병합 여부 무관)
git switch 브랜치명: 브랜치 전환 (Git 2.23 이상 권장)
git checkout 브랜치명: 브랜치 전환 (구버전 명령어)
- 소스트리에서는 브랜치 더블클릭
- 소스트리에서 원격 브랜치가 안보이면: 저장소 → 체크아웃 → 새 브랜치 체크아웃
git merge 합칠브랜치명: 현재 브랜치에 다른 브랜치를 병합
- 체크아웃한 곳이 기준이 되고, merge 뒤의 브랜치 변경사항을 가져온다.
- 소스트리: 주 가지를 checkout → 합칠 브랜치 우클릭 → “주 가지에 병합” 선택 → 푸쉬
git clean -fd: 추적되지 않는 파일과 디렉토리 삭제
git remote show 원격저장소이름

소스트리 ## sourcetree

초보는 명령어보다 소스트리같은 GUI를 쓰는것이 좋다.
JIRA의 개발사로 유명한 Atlassian에서 만든 gui 툴
<★★★ 중요 ★★★>

(매우중요)소스트리에서 reset은 local을 바꾸는거지 remote를 바꾸는 것이 아니다.
그렇기 때문에 reset한것을 원격에 반영하기 위해서는 로컬을 원하는상태의 커밋으로 맞춘다음
원격도 동일한 상태로 만들기 위해서 git push -f origin 브런치명 으로 강제 푸쉬해줘야 한다.
(중요) fetch를 해야지만 원격 히스토리가 최신화되지 자동으로 최신화되지 않는다.
파란선은 일반적으로 현재 체크아웃된 브랜치의 히스토리
빨간선은 일반적으로 원격 저장소의 브랜치의 히스토리 또는 로컬브랜치에 분기된 다른 커밋

충돌(★★중요★★)

fetch다음 pull을 하면 병합 경고창이 뜬다. (중요)로컬리파지터리의 내용은 이 순간 <<< === >>> 가 생긴 상태로 변경된다.(중요)
git staging에 위치한 파일 우클릭해서 어떤식으로 병합할건지 선택하고
‘반드시’ ‘커밋'(저장) 후에 push해야지 안그러면 충돌때문에 push를 못한다.
pull도 마찬가지다. 반드시 커밋 먼저 하고.
커밋하고 pull 하면 병합충돌 해결 창뜨고 stage되지 않은 파일에 해결해야될 파일들 뜬다.
충돌이 안나게 하기 위해서는 역할적, 시간적, 공간적 분리가 필요

<<<<<에서 =====위까지 현재 로컬브랜치의 코드
======아래에서 >>>>>>까지 병합할 원격브랜치의 코드
이니까 <<<< ==== >>>> 안의 코드들을 수정하고싶은대로 수정해주고
Unstaged files에 충돌된 파일 우클릭해서 Resolve Conflicts > Mark Resolved
Ok한다음 커밋
- 충돌한게 너무많아서 당장 어찌하지 못하겠다 싶으면
  git merge –abort //merge중단하고 평온한 상태로 되돌아간다.
- 병합이 깔끔하게 되면 commit까지 된거지만 이렇게 충돌나서 수동으로 병합해준경우 스테이지에 넣고 커밋해야한다.
  git add . 이후 git commit
- rebase의 충돌해결은 더 어렵다. 잔가지를 순서대로 메인가지에 커밋하는 원리기 때문에

소스트리에서 충돌해결

옵션 – 비교 – 외부비교도구 툴 선택
충돌난 파일 우클릭 – 외부병합툴 시작

STS에서 충돌 해결

크게 2가지 방법이 있다.
Perspective를 Team Synchronizing으로 변경. 양방향 빨간화살표 Conflicts Mode 선택

내소스를 commit안하고 pull해야할 경우 : Mark as Merged 사용
충돌한 파일 우클릭 -> Mark as Merged선택 -> Overwrite(원격을 로컬에다 덮어쓰기) -> Pull
내소스를 commit해야할 경우 : Metge Tool 사용
충돌한 파일 우클릭 – Merge Tool선택 또는 충돌한파일 더블클릭
수작업으로 선택해서 수정병합
commit 또는 Add to Index
이후에 pull받고 push

소스트리에서 내꺼 버리고 원격으로 덮어씌우기

파일상태 – 해당파일 클리후 Discard file – pull

<설치>
Bitbucket : Atlassian에서 만든 웹기반 버전관리저장소 호스팅서비스.
Mercurial : 크로스플랫폼 분산 버전관리도구. git과 거의비슷한 철학을 가지고있다.
Git은 태생부터 수많은 병렬 브랜치를 전제로 설계되었다.
Mercurial은 그런장점이 없는대신 배우고 사용하기 쉽도록 더 많은 노력을 들였다.
위의 2개 체크안함. 아이디, 이메일 입력, ssh없음.

create – 플러스버튼 – 위치 선택 =
네모안에 + 버튼으로 캡슐에 담는다.
생활코딩 소스트리

버전관리
Uncommited changes 는 아직 커밋되지 않은 변경사항이있다는것을 알려주는것이다.
Working Copy 탭으로가서 Staged Files로 올리고(캡슐 파묻고) 커밋하면된다.
하나의 버전에 여러개의 파일 관리 = 한캡슐에 파묻으면된다.(staged)

되돌아가는 방법

reset: 커밋 히스토리를 되돌리기

⚠️ 주의사항:

혼자 작업하는 브랜치에서는 사용해도 괜찮다. 팀원과 공유된 브랜치에서 reset을 사용하면 큰 문제가 발생할 수 있다.
사용 방법:

소스트리: 돌아갈 커밋 선택 → 우클릭 → “이 커밋까지 현재 브랜치를 초기화” (Reset current branch to this commit)

CLI: git reset --옵션 커밋해시

reset 후에는 강제 푸쉬가 필요: git push -f origin 브랜치명 (소스트리에서는 CLI로 강제 푸쉬 필요)

reset 옵션:

--soft: 가장 안전한 방법
- HEAD만 이동 (커밋 히스토리만 되돌림)
- Staging Area와 Working Directory는 그대로 유지
- 커밋만 취소하고 변경사항은 Staged 상태로 남음
--mixed (기본값)
- HEAD와 Staging Area 모두 되돌림
- Working Directory는 그대로 유지
- 변경사항은 Unstaged 상태로 남음 (add 전 상태)
--hard: 가장 과감한 방법
- HEAD, Staging Area, Working Directory 모두 되돌림
- ⚠️ 작업 내용이 완전히 삭제됨 (복구 불가능)

예시:

# 최근 1개 커밋 취소 (변경사항은 Staged 상태로)
git reset --soft HEAD~1

# 최근 1개 커밋 취소 (변경사항은 Unstaged 상태로)
git reset HEAD~1

# 최근 1개 커밋과 변경사항 모두 삭제
git reset --hard HEAD~1

# 특정 커밋으로 되돌리기
git reset --hard abc1234

# 원격 저장소에 강제 반영
git push -f origin 브랜치명

유의사항:

브랜치 모양이 이상한 상태에서 push하면 에러 발생 → 강제 푸쉬 필요
--hard로 했는데도 소스가 안 지워지면, 임시로 commit 한 다음 다시 reset 시도
최초 커밋으로 돌아가려면 최신 HEAD에서 최초 커밋으로 reset

revert: 새로운 커밋으로 변경사항 되돌리기

특징:

협업 환경에서 권장되는 정석적인 되돌리기 방법이다. 히스토리를 지우지 않고 새로운 revert 커밋을 추가한다.

reset vs revert 차이:

reset: 히스토리를 지움 (팀 작업 시 위험)
revert: 히스토리를 유지하고 역방향 커밋 추가 (팀 작업 시 안전)

사용 방법:

소스트리: 되돌릴 커밋 우클릭 → “커밋 되돌리기” (Reverse commit)
CLI: git revert 커밋해시
자동 커밋 없이 revert: git revert --no-commit 커밋해시

사용 시나리오:

특정 커밋 하나만 되돌리기:
```
git revert abc1234
```
주의: 충돌 가능성이 있음
여러 커밋을 되돌리기:
- 소스트리: 최신부터 순서대로 revert 반복 적용
- CLI: 범위로 한 번에 revert
```
git revert HEAD~3..HEAD  # 최근 3개 커밋 되돌리기
```

연속된 커밋들을 한 번에 revert:

git revert --no-commit HEAD~3..HEAD
git commit -m "Revert 최근 3개 커밋"

특정 파일만 되돌리기

특정 커밋에서 특정 파일만 추출하여 현재 디렉토리로 복사:

# 구버전 명령어
git checkout a1b2c3d -- script.js

# 신버전 명령어 (Git 2.23 이상)
git restore --source=a1b2c3d script.js

# 변경사항을 커밋
git add script.js
git commit -m "script.js를 이전 버전으로 되돌림"

참고: 각 커밋은 고유한 SHA 해시 ID를 가진다. 긴 해시 중 앞 7자리만 사용해도 된다.

비교
빨간색은 없어진것. 초록색은 생긴것.
이미지나 .hwp나 이런건 어떻게 비교할수있는가?
보고싶은 버전 파일 우클릭 – Open Current Version 하고, 비교하고싶은 버전의 파일 우클릭 – Open Selected Version 하면 각기다른 버전 2개열린다.
또는 비교전용 프로그램 사용
브런치 병합(merge)
메인이 될 브런치를 체크아웃해서 선택하고, (메인 브런치에 병합하려고 하면 현재 브런치가 메인이여야 한다.)
가져올 브런치를 history에서 보이게한다음 우클릭 병합하기(merge).

원격 사용
1. github에 리모트 리파지토리 만들기
2. 소스트리에서 clone해서 리모트 리파지토리 주소넣으면 로컬주소 자동으로 만들어진다. 바꾸고싶으면 수정하면된다.
3. 클론버튼
4. 작업하고 commit
5. push

소스트리 계정정보 수정,삭제

도구-옵션-일반-기본사용자정보 에서 계정정보 변경
계속 다른 계정정보가 남아있으면 window 자격증명 제거 또는 수정
예전버전은 변경이 잘안돼서 아래처럼 삭제했음
소스트리경로 (디폴트 c:Users계정AppDataLocal|AtlassianSourceTree)
에있는 password, userhosts 파일 지우고 소스트리 재시작

에러

소스트리에서 인식못하거나 찌꺼끼 파일 있으면
git clean -fd
origin이 깨졌다고 하면
cd .git/refs/remotes/origin
rm -f main HEAD
cd ..
rmdir origin
git status 에러코드 128로 실패함.
=> git config –global –add safe.directory “풀경로”
나는 H:/programming/개발공부_엑기스
//디렉토리를 이 아니라 /로 넣도록
git status했을때 fatal: detected dubious ownership in repository at 경로
=> git config –global –add safe.directory ‘D:/programming/개발공부_엑기스’
따옴표를 넣어야함

하고나서 또 git status하면

You are in a sparse checkout with 100% of tracked files present.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    '
        deleted:    .vscode/extensions.json
        deleted:    .vscode/settings.json
        modified:   "353260261354227224353223234/354236220353260224352263265353266200.md"
        deleted:    "354231270354243274,354202254354227205/353247210354274200355214205.md"
        modified:   "355224204353241240355212270354227224353223234/css354240225353246254.md"

커밋하고 pull하니까

Your branch is ahead of 'origin/main' by 123 commits.
  (use "git push" to publish your local commits)

You are in a sparse checkout with 100% of tracked files present.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    '

no changes added to commit (use "git add" and/or "git commit -a")

이상태에서 pull하면

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks fetch --no-tags origin
error: object file .git/objects/b2/603e6921f59447f9f0a3dac97aeee2d5aed53e is empty
fatal: loose object b2603e6921f59447f9f0a3dac97aeee2d5aed53e (stored in .git/objects/b2/603e6921f59447f9f0a3dac97aeee2d5aed53e) is corrupt
error: https://github.com/ggoomter/StudyAboutDevelop.git did not send all necessary objects

새로만든 파일이 untracked files임
-> 파일을 새로 만들면 untracked이며 add해줘야 추적대상으로 관리된다.
-> 즉, 너도 관리대상이야 라고 지정해줘야한다. 관리대상인 애들만 다룬다.
git status로 확인하면된다.
오류가 나면서 완료됨.
git -c diff.mnemonicprefix=false -c core.quotepath=false –no-optional-locks push -v –tags origin main:main
remote: Invalid username or password.
fatal: Authentication failed for ‘https://github.com/ggoomter/StudyAboutDevelop.git/‘
Pushing to https://github.com/ggoomter/StudyAboutDevelop.git
-> 인증문제.
옛날 버전의 소스트리일 경우 :
소스트리 인증 수정. C:Users자기유저명AppDataLocalAtlassianSourceTree 폴더
userhosts 파일 지우면 로그인 입력창 뜨는데 그때 제대로넣으면됨.
단, 비번은 토큰값 (만료안되었는지 확인). 혹시 모른다면 또만들면됨.
브라우저에 깃헙 로그인이 된상태라면 브라우저를 통해서도됨.
최근 버전의 소스트리일 경우:
설정 – 원격 – origin 더블클릭
URL/경로 에 원래꺼앞에 토큰@넣기
“https://토큰@깃허브 리포지토리 주소”
unsafe repository is owned by someone else
=> git config –global –add safe.directory ‘*’
ERROR [2022-12-06 22:36:02,044] [1] [SourceTree.Notifications.NotificationsManager] [Log] – Unable to set owner as parent is not visible or non-existen
ERROR [2022-12-06 22:48:56,137] [15] [SourceTree.Diagnostics.FailureHandler] [Log] – ‘diff-tree in GetCommitFileChanges’ 에러 코드 128로 실패함: fatal: unable to read 83754ab06b568e5ee3f3a98fc2b98853329bc5c4
(H:programming개발공부_엑기스)
=> 로컬리파지터리에 쓰기 권한이 없고, 그 이유는 로그인 계정이 풀린것 같은데
설정보면 잘 되어있음.
rejected-non-fast-forward 에러
=>
공부 : https://otzslayer.github.io/git/2021/12/05/git-merge-fast-forward.html
이 에러가 뜨는 이유 : 현재 브랜치의 최신 상태가 리모트 저장소의 최신 상태보다 뒤처져(push하려는 브랜치가 리모트 저장소의 브랜치보다 이전 커밋을 가지고 있는 경우) 발생
조건 : 한 브랜치의 끝이 다른 브랜치의 직계 조상일때 가능
장점 : 병합과정이 간단하고 병합 히스토리가 깔끔함
단점 : 병합히스토리가 단순화되어 특정 시점의 브랜치의 상태를 명확하게 파악하기 어려움
역사를 명확하게 보존하고 싶을때는 –no-ff 옵션을 사용하여 병합
해결 : 3가지
- 풀부터 git pull origin main
- 강제푸쉬 git push -f origin main
- 리베이스 git pull –rebase origin main
warning : LF will be replaced by CRLF the next time Git touches it
error: open(“외부api/자바스크립트외부라이브러리.md”): Invalid argument
error: unable to index file ‘외부api/자바스크립트외부라이브러리.md’
=> 탐색기에서 직접 지워도 안지워짐. 외장하드 그냥 빼서 에러난듯.
update conflict
The file ‘~~’ has been changed on the file system. Do you want to overwrite the changes made on the file system?
=>
(중요)git untracked working tree files would be overwritten
원인 : 하위폴더를 확인해보면 .git폴더가 또 생성되어 있을 가능성이 높음.
하위 .git폴더를 삭제하고 cache삭제
git rm -rf –cached 폴더명
=>
해결방법1
git clean -d -f -f
이후에 다시 pull

해결방법2

git add -A // 옵션 -A, 모든 변경내용을 Staging Area으로 넘긴다.
git stash // 현재 상태를 임시 저장
git pull // github 저장소의 변경사항을 pull
git push // Staging Area에 있는 내용을 github저장소로 push
하라는데 3번에서 똑같은 에러남.

알고보니 이미 충돌병합된 파일이 내 로컬파일로 덮어씌워져있었음.
로컬파일 제거하거나 수동으로 수정후 재작업해줌

해결방법3

현재 Staging영역에 있는 파일의 변경사항을 스택에 백업
git stash
원격의것을 내것에 적용
git pull 원격저장소명 브런치명
변경사항 적용하고 스택에서 제거
git stash pop
pull 또는 push

failed to push some refs to ‘원격주소’
=> local저장소와 remote저장소가 일치하지 않을때 발생
먼저 브런치 확인해보자.
git status로 문제분석해보고 못찾겠으면 강제 진행

내컴퓨터의 상태로 강제로 원격에 올리기. 잘못올린거 있으면 제거됨

git push -f origin
error: bad signature fatal: index file corrupt 에러
=> (해결)
$ rm -f .git/index
$ git reset

깃허브 ( # github.com)

//깃헙써놓고 깃 쓸줄안다고 잘못알려주는곳 많다. 특히 국비학원들.
//깃헙은 기본적으로 remote repository를 제공해주는 호스팅 사이트. 많은 오픈소스들을 볼 수 있다. git소스파일도 오픈소스로 깃허브에서 관리된다.
//단순히 원격 저장소만을 제공하는 것이 아니라, 여러가지 프로젝트 진행을 원할하게 하는 도구를 함께 제공한다.
//최신이 아닌 파일을 올리거나 받으면 충돌이 발생하기 때문에 최신상태임을 보장해준다.
//최초에는 README.md파일 생성하지 않고 완전 빈껍데기 공간을 만들도록 하는것에 유의하자.

사용방법
1. 깃헙 계정가입
2. repository 생성 : 초록색 create repository 버튼
  1. Public은 누구나 이소스를 볼수있다. 수정은 만든사람이 권한을 줘야되지만.
  2. Private은 주소를 알아도 소스 볼 수 없다. 팀원한테 접근권한 줄려면
    프로젝트 – Setting – Collabaroatos 에서 깃헙아이디로 추가
    그럼 이메일로 초대메일 간다.
    아이디 검색했는데 만약 안나온다면 새로고침
  3. 밑에껀 건들지말고 create repository
3. 소스 올리기
  1. 빈 리모트리파지토리에 처음에 코드 보이는게 이 소스 올리는 설명이다.
  2. HTTPS선택된 상태로 주소 복사
  3. 빈 폴더를 올리는법
    - 명령어로 하는법
      git init
      git add 올릴파일
      git commit -m “올릴메세지”
      git branch -M main // 기본브런치명을 main으로
      git remote add origin 리모트주소 // 로컬 저장소에 원격저장소 연결. 이름은 보통 origin으로
      git push -u origin main // 로컬 저장소의 커밋내역들을 원격으로 업로드 //-u는 그것을 기본으로 세팅해주라는말. 한프로젝트에 원격 저장소를 여러개 둘수도있기때문
    - 소스트리로 하는법
      new tab(+버튼) – Create버튼 – 폴더선택
  4. 이미 프로젝트가 있을때 업로드하는법
    - 명령어로 하는법
      git remote add origin 리모트주소
      git branch -M main
      git push -u origin main
  - 소스트리로 하는법
    저장소 – 원격저장소 추가
    원격이름 origin, url에 복사한것
    사용자명에 깃헙유저명
    왼쪽 원격탭에 origin클릭하고 위의 push버튼
4. 소스 확인
  git remote
5. git ignore 추가
  올릴필요가 없거나 올려서는 안되는 파일
  프로젝트 최상위공간에 .gitignore 파일 생성
6. 깃헙 소스를 내컴퓨터에 다운받기
  - 클론
  - 명령어로 하는법
    : 다운받고싶은 폴더에서 우클릭 – git bash here클릭 – git clone 리모트주소
  - 소스트리로 하는법
    : 탭 – 클론버튼 – 제일위에 리모트주소 붙여넣기 – 2번째에 로컬리파지토리 주소 설정 – 클론버튼
  - 그냥 다운로드zip : 깃의 관리내역은 없다. 즉 git폴더는 없다. 현재의 완성본만 가져옴.
7. 작업 주고받기
  git fetch
  git status 로 뒤쳐진게 있는지 확인
  push 할것이 있으면 pull부터.
  //깃헙에서 파일명 선택해서 직접 수정 할 수도 있다.
  (중요) pull을 하는 두가지 방식이 있다. 너무 나중에야 알았다.
  git pull –no-reabse // 리베이스가 아닌방식이니 merge방식. (중요)로컬의 main브런치와 리모트의 main브런치를 다르게 보고 합치는 방식
  git pull –rebase // 리베이스방식. 선안나뉘고 한줄에 합쳐준다.
8. 브런치 주고받기
9. 충돌 해결하기
  - merge방식 :
    git pull –no-reabse 하면 <<< === >>> 있는 코드 띄워준다.
    수정해준다음
    git add .
    git commit
    git push
  - rebase방식 : 어떤걸 선택하느냐에 따라 추가되는 커밋의 수가 달라질수있다.
    git pull –rebase 하면 <<< === >>> 있는 코드 띄워준다.
    상대방걸 먼저 붙이기 때문에 accept current change를 하냐 accept incoming change 를 하냐에 따라 다르다.
    git add .
    git rebase –continue
10. 강제푸쉬
  로컬에서 충돌전으로 reset 한 다음
  git push –force //원격이 더 최신이라도 강제로 밀어넣는다. 협업상황이라면 반드시 합의되어야 한다.
- 포크(Fork)
  - 깃헙안에서 다른사람의 계정에서 내 계정으로 원격 저장소를 복제하는 것
  - 포크를 안하면 내것이 아닌 저장소(쓰기 권한이 없는 원격저장소)를 사용하는 것
  - 포크를 한 리포지토리는 포크를 꽂아넣은 아이콘이 표시되며 원본 저장소의 출처를 표시해준다.
- 깃헙 메뉴
  - Code
    - 저장소의 루트디렉토리로 이동
  - Issues
    - 주요 이슈사항을 관리. 댓글이 있는 게시판형태
  - Pull Requests
    - 풀리퀘스트 전체 목록. 왼쪽의 숫자는 현재 요청이 온 리퀘스트를 받아들일 것인지에 대한 논의가 몇개인지
  - Wiki
    - 말 그대로 이 프로젝트와 관계된 위키. 마크다운과 위키위키 문법 사용
  - Pulse
    - 저장소의 최근 변경내역 확인. 최대 한달까지
  - Graphs
    - 공헌자의 공헌내역, 커밋 수 등 해당 저장소의 활동 내역을 그래프로 보여줌
  - Settings
    - 해당 원격 저장소의 관리자라면 보이고 각종 설정 변경
  - HTTPS clone URL
    - 원격저장소를 클론할때 사용하는 주소 정보. 클릭해서 HTTPS, SSH, SVN에 맞는 주소 변경 가능
  - Clone Desktop
    - GitHub전용 클라이언트 프로그램을 사용해 클론할때
  - Download Zip
    - 저장소의 전체파일을 압축파일형태로 다운
      
      깃헙 토큰 생성
      
      비밀번호로 리모트 리파지토리에 접근하는것이 아니라 토큰으로 인증받는 방식으로 바꼈다.
      프로필 우클릭 setting – developer setting – Personal access tokens – Generate Psersonal access token
      (이름은 마음대로. Expiration(만료기간) No expiration(하고싶은대로)으로. 체크는 전부다.(최소는 repo)
      값 까먹으면 복구할수없다. 복사해서 자기만의 장소에 저장. 만약 까먹으면 다시 새로만들어서 사용하면됨)

뭐 할때마다 토큰값 넣기 귀찮으면 컴퓨터에 저장할수있다.
윈도우라면 자격 증명 관리자 – Windows자격증명관리자 – git:https://@github.com
있으면 편집, 없으면 자격정보생성 – 사용자명과 토큰번호 넣기
소스트리에서도 도구 – 옵션 – 인증 – github.com 편집

리파지터리에서 탈퇴하는법

settings – repository – 해당리파지토리 leave

Remote – +계정추가 버튼 – 호스팅서비스를 Github로 변경하고 하단의 OAuth토큰 새로고침

초록색버튼 누르고 깃비밀번호 입력
Clone : 리모트를 로컬로 다운받는다.
풀 리퀘스트 : 마스터 브랜치에 병합하기전에 다른사람의 리뷰를 받고싶을때
merge를 누르면 마스터브랜치에 병합된다.

STS와 깃헙 연동

깃헙에서 STS로 받기

바로 워크스페이스에 클론하지말것
워킹디렉토리와 로컬리포지토리를 분리하여 의도치 않은 사고를 방지하고 여러 장점을 취하자.

https://all-record.tistory.com/163

깃헙 = 호스팅 서버.
remote repository만들기
clone 기능을써서
내 컴퓨터(local repositry)에 깃헙의 소스를 받기
내 로컬 리파지터리를 sts의 git perspective로 load하기
workspace 로 가져오기
spring프로젝트는 git perspective에 받은걸로 그냥 import 하면되는데
srpingboot프로젝트는 Project Explorer 가서 import를 gradle로 해야된다.

STS에서 깃헙에 프로젝트 올리기

https://devbirdfeet.tistory.com/42

이미 개발되어있는 코드를 깃헙에 올리는 방법
1. (중요)git perspective열어서 remote받아놓기
2. 프로젝트 우클릭 team- share project 에서 위에 받은 깃폴더 선택.
3. 반면에 .git의 부모폴더를 local Repository 설정해주면 commit까지만 가능
4. push를 시도하거나 설정에 가면 remote repository 경로 설정해줘야함
5. 거기에 깃헙주소 넣어주고 push하면 끝
깃헙에서 새프로젝트 만들고 로컬에서 연동해서 시작하는 방법
처음부터 clone해서 remote 소스를 local로 받는다.
그다음 소스 개발한다음
올릴 프로젝트로 가서 우클릭 – team – share 해서 local repository를 연결해준다.
local 은 remote와 연결되어있기 때문에 commit하면 local로, push 하면 remote로 올라갈 수 있다.
403에러 뜰때 :

여러계정을 쓸때 발생한다.
- 에러 본문
  remote: Permission to Kimsia0717/teamC_campYo.git denied to ggoomter.
  fatal: unable to access ‘https://github.com/Kimsia0717/teamC_campYo.git/‘: The requested URL returned error: 403
- 확인사항
  1. 가장먼저확인할건 : 초대했고 초대 ‘승낙’ 했는지
  2. 사용자이름(이메일 아님)
  3. 올바른암호(토큰)
  4. 레포형식
Updates were rejected because the tip of your current branch is behind its remote counterpart 에러

푸쉬하기전에 풀을 안해서 발생.
늦게 풀을 해도 안된다면 이미 꼬여버렸다.
git push -u origin main
git -c diff.mnemonicprefix=false -c core.quotepath=false –no-optional-locks fetch –no-tags origin

remote: Repository not found.
fatal: repository ‘https://github.com/Kimsia0717/teamC_campYo.git/‘ not found
오류가 나면서 완료됨.
=> 여러가지 이유가 있다.
이중계정을 사용하고 있었기 때문인데 유저네임과 함께 클론하면 된다.
git clone https://gitid@github.com/gitusername/portfolio.git

Permission to ggoomter/StudyAboutDevelop.git denied to lepelaka.
같이 remote 리파지토리에 권한을 주지않은 로그인유저로 푸쉬한 경우:

cherry pick
- 정의 : 특정한 커밋 하나만 되돌릴때 사용
- cherrypick 과 rebase 는 목적은 반대지만 방법은 같다.
STS에서 깃 연동후 the original file has been deleted 에러
=> (해결)STS재시작하면 됨

git ignore

포함할 필요가 없는 파일들(자동으로 만들어지거나 다운받아지는 파일들)과 포함하지 말아야 하는 파일들(보안상 민감한 정보) 을 등록하여 깃의 관리에서 해당 파일들을 배제한다.
.gitignore 파일을 깃폴더와 같은 레벨에 두어 그 역할을 수행한다.
제대로 설정했다면 git status에 파일목록이 보이지 않아야 한다.
스프링부트, 장고 등으로 프로젝트를 생성하면 자동으로 .gitignore파일이 그 프레임워크에서 무시해야될 파일들을 등록한 상태로 생성된다.

www.gitignore.io 에 접속해서 운영체제, IDE, 언어, 프레임워크 등을 넣고 Generate 해서 템플릿화된 깃이그노어 사용하는것이 좋다.

문법

주석은 #

파일이름.확장자 = 그 파일을 직접 제외

그냥 이름 = 해당이름의 파일이나 폴더

맨앞에 쓰인 / 는 해당프로젝트의 최상위폴더를 말함

은 모든을 말함 예) .class

디렉터리 뒤에쓰인 /는 파일이 아니라 해당폴더와 그안의 내용들 예) logs/*.c logs폴더안에 있는 .c확장자

은 하위디렉토리 예) logs//debug.log log폴더와 그하위폴더 안의 debug.log파일

!는 다른 필터에서 걸리더라도 이건 무시하지 마라는 설정

gitignore 수정했는데 바로 반영안되는 문제

이미 추적하고 있는 파일을 .gitignore에 추가하여 추적을 멈추려고 한다면
이그노어 파일에 필요한 패턴 추가
캐시된 파일 제거 git rm -r –cached .
전체를 스태이징 영역에 추가 git add .
커밋

1> .gitignore 파일에 application.properties 있는데 푸쉬되는 상황
2> 저파일있는 경로에서 cmd열고 git rm –cached application.properties
3> 소스트리에서 보면 스테이지에 올라간파일 영역에서 파일삭제됐다고 알려줌. 실제로 워크스페이스에는 파일 정상적임.
4> 스테이지에서 내리고 수정하면 다시 add commit push가능하게됨… (내리기 올리기를 서로 왔다 갔다 할수없고 내려버리면 파일상태에서 아예 없어져버리네)
5> 다시 git rm -r –cached application.properties 하고 스테이지 올라간파일 영역에서 파일삭제 확인하고 워크스페이스의 파일 열어서 파일 바꿨지만 파일상태에서 바꼈음을 인식못하고있네.
그렇게 빨간색 -표시뜬 상태로 커밋. 이제될것같다.
6> ok 로컬에서 파일 변경하니까 정상적으로 ignore됨.

즉 쉽게 정리하자면 원격에서 이제까지의 역사의 기록은 어쩔수 없고 마지막으로 변한만큼을 지움. git rm -r –cached 파일
로컬의 상태 그대로 세이브 파일 만듦. git add 파일
커밋, 푸쉬 하면 없어진 상태로 원격의 역사 만들어짐. 그리고 ignore에 등록되어있기 때문에 앞으로는 인식안함

설명

//원격 저장소와 로컬 저장소에 있는 파일 모두 삭제
$ git rm 삭제할 파일 이름
$ git rm -r 삭제할 파일 디렉토리

//원격저장소의 파일만 삭제
$ git rm –cached 삭제할 파일 이름
$ git rm –cached -r 삭제할 파일 디렉토리

그러나 원격 저장소의 파일을 삭제한다고 해서 이미 커밋 내역으로 history로 등록되어버린 내역까지는 삭제해줄수 없는데 그럴때는 커밋 내역에서 삭제하고자 하는 파일, 폴더내역을 아래와같은 방법으로 지울 수 있다.
// // 파일 삭제
$git filter-branch –index-filter ‘git rm –cached –ignore-unmatch 파일이름’ –prune-empty –force — –all

// // 디렉토리 삭제
//커밋내역 삭제
$ git filter-branch –tree-filter ‘rm -rf 해당폴더위치와이름(ex)frontend/src)` HEAD
//존재하는 빈 commit 삭제
$git filter-branch –prune-empty -f HEAD

//잘 삭제되었다면 해당내역을 강제로 푸쉬
$ git push origin +master

<좋은 참조>
https://velog.io/@psk84/.gitignore-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0

원격 기준 브런치 로컬로 가져오기 (중요)

git fetch –all // 원격 브런치 최신 상태로 업데이트
git branch -a // 원격과 로컬 브런치 목록 확인’
(로컬에 dev가 없는 상태라면 ) git checkout -b 로컬브랜치이름 -t origin/원격브랜치이름 // -t 옵션은 원격 브런치를 추적하는 로컬 브런치를 새로 만들어서 체크아웃
git checkout -b 로컬브랜치이름 까지만 하면 그냥 로컬브런치를 만들면서 거기로 체크아웃
(로컬에 dev가 있는 상태라면 연결만 ) git branch -u origin/원격브런치명 로컬브랜치명 하라는데 안됨
git branch –set-upstream-to=origin/dev dev 또는 git push –set-upstream origin 새브런치명

git reset –hard origin/브런치명 //로컬 무시하고 완전히 원격으로 덮어씌울 때

원격 저장소에 커밋한 내용 수정하는 법

파일별로 수정내용 돌려놓기

unstage된 상태에서 체크아웃 명령어 : git checkout 파일명
스테이지 된 상태라면 git reset 파일명 먼저 해서 unstage시킨후에 체크아웃
이미 push가 된 상태라면 reset하면 안되고 revert

노하우

git status 잘 활용하자.
git stash잘활용하자. 백업
소스트리 새로고침 따로없다. 반영이 안된거같으면 새탭 괜히 열었다 끄면 새로고침처럼 작동된다.

커밋내역 삭제

git log 로 커밋내역 확인
q눌러서 확인 끝
git reset HEAD~숫자 //최신이1
git push -f origin 브랜치명

깃 브런치 전략

Git Flow
- Main, Develop, Supporting(Feature, Release, Hotfix)
- 커밋을 최대한 자주 한다.
- 푸쉬는 항상 동작되는 코드여야 한다.
- 머지할때 주의점은 Fast-Forward로 머지 하지 않고, Merge Commit을 생성하여 머지를 해주어야 한다. 이렇게 해야 히스토리가 특정 기능 단위로 묶이게 된다.
- ‘웹’어플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하기 때문에, 여러버전을 병렬적으로 지원할 필요가 없기 때문에 하루에 몇번이고 릴리즈될 수 있다.
- Main브런치는 항상 Stable한 상태여야 한다. 언제 배포하든 문제가 없어야 하고, 언제든 브랜치를 새로 만들어도 문제가 없어야 한다. Main브랜치의 모든 커밋은 빌드가 되고 테스트를 통과해야한다.
Github Flow
GitLab Flow

윈도우 리눅스 차이때문에 LF 관련 에러뜨면

윈도우에서 git config –global core.autocrlf true

실무해보니 많이 쓰는 명령어

로컬 브런치를 다른 원격 브런치로 푸쉬
git push origin 로컬브런치:원격브런치/원격의하위브런치가있다면
예) git push origin dev:feature/workflow-20251031
원격 브런치를 로컬 브런치로 만들면서 가져오기
- git checkout -b feature/workflow-20251031 origin/feature/workflow-20251031

깃 안전 폴더

확인
- git config –global –get-all safe.directory
등록
- git config –global –add safe.directory “경로”
- git config –global –add safe.directory ‘별’ 이렇게 하면 전역으로 완전 허용
제거
- git config –global –unset safe.directory “경로”