* Fast-Forward(빨리 감기) 병합

1. 목적지(병합하려는) 브랜치로 이동한다. (B를 A에 합치고 싶다면 A로 이동)
2. git merge B 실행
3. A의 브랜치가 B의 브랜치를 따라잡게 된다.

병합을 하더라도 병합 대상의 내용들이 브랜치에 추가되는 것은 한 순간이고 동기화가 계속 이뤄지는것은 아니다. 여전히 별개의 브랜치로 존재한다.

그리고 모든 병합이 빨리 감기 병합은 아니다.

예를 들어 main에서 브랜치를 새로 만들어서 작업 후 main 브랜치에 병합하려고 하는데 그 사이 다른 팀원들에 의해 main 브랜치에서 커밋이 이뤄졌다면 현재 나의 브랜치에는 없는 새로운 정보들이 main 브랜치에 존재하게 된다.

이 때 병합을 하게되면 빨리 감기 병합이 아닌 merge commit(병합 커밋)이 이뤄지고 해당 커밋은 2개의 부모를 가지게 된다.

위와 같은 병합 커밋은 서로 다른 파일로 작업을 진행했기 때문에 충돌 없이 자동으로 병합이 이뤄진다.

병합하려는 브랜치의 파일이 삭제되거나 동일한 파일을 수정해서 충돌이 발생하는 경우 깃은 충돌이 발생한 파일을 알려주게 된다.

이 때 충돌이 발생한 파일을 열어서 직접 해결하면 된다.

대부분의 경우 병합 커밋이 완료되면 병합 대상의 브랜치는 더 이상 필요 없으므로 삭제하는 편이다.

* 병합 충돌이 발생한 경우

1. 충돌이 발생한 파일 열기
2. 파일 수정
3. 충돌 표시 제거
4. 커밋

VS Code를 이용하면 병합 커밋을 조금 더 편하게 할 수 있다.

상단의 Accept 메뉴를 클릭하면 한쪽 내용만을 적용하거나 양쪽 다 적용하는 등 단순 작업을 더 편하게 할 수 있다.

브랜치도 커밋처럼 매일 또는 자주 다루게 될 것이다.

커밋은 고유의 해시를 가지고 부모 커밋 하나를 참조하고 있다.

어떤 팀에서 각각 진행하는 작업의 내용이 진척도가 서로 다르고 작업 내용이 추후 적용된다고 했을 때, 순차적인 커밋은 불가능하다고 볼 수 있다.

이 때, 브랜치로 작업을 분기시켜서 별도로 진행하다가 추후 합칠 수 있다.

작업은 항상 브랜치 위에 존재한다.

master(main) 브랜치는 실제로 특별한것은 없지만 많은 팀과 사람들이 프로젝트 코드 베이스의 원본처럼 취급한다.

어떤 브랜치에서 작업한 내용은 다른 브랜치에 영향을 미치지 않는다.

# 둘은 서로 동일하다
git switch -c main
git checkout -b main

* 스테이징 되지 않은 변경사항으로 브랜치 전환

커밋되지 않은 내용이 있는 상태에서 브랜치 변경시 내용이 사라진다. 그렇기 때문에 변경 시도시 커밋하거나 임시로 백업(스태시) 하라고 알려준다.

가급적 변경사항을 만들 때마다 브랜치 이동 전에 항상 커밋할 것을 권장한다.

깃의 문서는 https://git-scm.com 에서 볼 수 있다. 명령어의 기능이 궁금할 때 레퍼런스를 참조하면 된다.

* Atomic commits (커밋의 원자적 유지)?

가능하다면 커밋은 단일 기능이나 단일 변화, 수정만을 포함시켜야 한다.

한 커밋에 모든 변경사항들을 통합한다면 커밋을 롤백할 때 많은 작업들을 취소해야 할 수도 있다.

* 커밋 메시지 작성

현재 시제의 명령형 커밋 메시지를 사용할 것을 공식적으로 권장하고 있다.

예를들어 'x를 만들다', 'x를 변경하다' 등의 동사(영어 기준)로 표현해야 한다.

커밋 메시지를 넣지 않고 커밋을 하면 vim으로 진입하게 된다.

이 때 i를 입력하면 입력 모드로 바뀌고 메시지를 작성 후 esc입력, :wq를 입력하면 커밋 메시지가 추가되고 다시 터미널로 돌아온다.

-m 플래그를 통한 커밋은 보통 짧은 메시지를 쓸 때 사용되고 길게 쓸 필요가 있을 때 사용하면 될 것으로 보인다.

터미널이나 GUI나 작동 방식은 동일하지만 GUI는 시각적으로 다이어그램을 볼 수 있으므로 흐름을 파악하는데 도움이 된다.

* Amending commits

직전의 커밋을 수정한다. 커밋에 파일을 포함시키는 것을 잊거나 메시지 오타 발생 등 커밋에 빼먹은 내용이 발생했을 때 수정할 수 있다. 반드시 "직전 커밋" 에만 사용할 수 있다.

git commit -m "something"
# 여기서 누락된 걸 확인했을 때
git add something.txt
git commit --amend

* git ignore

보통은 저장소의 최상위 폴더에 넣는다. 깃이 추적하길 원하지 않는 컨텐츠를 .gitignore에 작성 해놓으면 추적하지 않는다.

https://gitignore.io 에서 작업중인 프로젝트의 환경을 검색하면(ex: python) gitignore에 추가할 권장 내용들을 보여준다.

깃 저장소는 작업공간이다.

.git 폴더를 삭제하면 저장소의 이력까지 모조리 사라진다.

저장소 안에 또 다른 저장소를 넣지 말아야 한다. (초기화된 저장소 안에서 또 초기화를 하지 말라는 뜻)

깃이 깃을 추적하기 때문에 혼란스러워진다.

* 커밋이란?

프로젝트의 변경 사항이 있는 일종의 체크포인트.

git commit -m "change something"

깃은 이름과 이메일을 설정해주어야 누가 작업했는지 알 수 있다.

주로 깃허브 로그인 이메일 주소와 같게 사용하는 편이다.

git config user.name : 등록된 유저의 이름 확인
git config user.email : 등록된 유저의 메일 확인

git config --global user.name : 유저 이름 등록
git config --global user.email : 유저 메일 등록

rm playlist.txt
rm -rf Songs/