-
git clone 시, 뒤에 .을 붙이면 별도로 레포 명의 폴더가 생성되지 않고 지정 경로에 클론 가능
-
보통 폴더 구조는 static=> css/javascript/image 로 분류
-
협업 방법에는 포크(협업자와 권한 공유X)와 일반적인 깃 클론(협업자 모두 권한 가지고 있음)이 있음
-
협업 시에는 pull을(원격 저장소와 싱크 맞추기) 생활화하자
커밋 컨벤션 - 커밋 양식에 관한 링크
https://www.conventionalcommits.org/ko/v1.0.0/
깃플로우
되도록 메인 브랜치로 보내지 않는다 (깃 브랜치 전략)
브랜치는 크게 5개로 분류되는데,
hot fixes -> 메인에서 오류남(급하게 고쳐야 하는 에러 수정용)
release -> 출시 전 (메인으로 병합 전) 테스트용 브랜치
feature -> 기능별로 세세하게 나누는 브랜치 (ex-회원 가입 ,회원탈퇴, 회원 검색 ...)
develop -> feature을 한데 모아 큰 기능 하나를 모은 브랜치 (ex-회원 관리)
하지만 이 전략은 대규모 프로젝트에는 적합하지만, 소규모로는 branch가 너무 많고 관리 인원이 적어 어렵다..
깃허브 플로우
각 기능별 프로그래밍이 끝나면 메인으로 합쳐주는 방식
중간에 release, hotfix 등은 그냥 feature branch 안에서 해결한다.
깃플로우와 달리 소규모 프로젝트에서 유용하다.
pull VS fetch
이 둘의 차이는 'merge'의 유무
pull은 변경사항을 확인함과 동시에 merge를 시켜버림.
하지만 fetch의 경우 변경사항을 확인만 함
checkout VS reset
둘 다 이전 시점의 브랜치로 이동이 가능하다. 다만 checkout은 헤드가 분리가 된다.
또, reset(hard)는 원래 있던 커밋 내역을 변경할 수 있기 때문에 조심해서 사용해야한다.
- push 후 reset은 지양하자...
checkout, reset 모두 브랜치가 변경된다
checkout - head가 분리됨
reset - 브랜치가 head를 바라봄
revert VS reset
revert 새로운 commit 내역을 만들면서 이전 상태로 돌아감
반면 reset은 그런거 없이 이전으로 돌아감
revert는 한 단계씩으로만 이전으로 돌아갈 수 있다.
즉, 이전으로 돌아가야 할 커밋이 많다면 revert보다는 reset --soft가 더 낫다
