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

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

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

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

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

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/

누구나 쉽게 이해할 수 있는 Git 입문

https://backlog.com/git-tutorial/kr/