#코멘토 #코멘토실무PT #실무PT후기 #실무강의 #리액트강의 #웹프로그래밍 #react #웹개발실무
필수 링크
https://bit.ly/3D9XCOz
1. Git이란?
- 로컬에서 관리되는 버전 관리 시스템(VCS: Version Control System)
- 소스코드 수정에 따른 버전을 관리해주는 시스템
1-1. 그럼 Github은?
- 클라우드 방식으로 관리되는 버전 관리 시스템(VCS)
- 클라우드 서버를 사용해서 로컬에서 버전 관리한 소스코드를 업로드하여 공유가능
- 분산 버전 제어, 액세스 제어, 소스 코드 관리, 버그 추적, 기능 요청 및 작업 관리를 제공
2. Git 커밋
다들 한번씩 경험해 봤을지는 모르겠지만 보통 커밋 메세지를 뭐라고 쓰지? 또는 브랜치명을 어떻게 써야 잘만들었다고 하지? 생각 해봤을 것 같다. 그래서 만들어진 것이 유다시티 커밋 메시지 스타일 가이드가 있고 대표적이다!!
유다시티 커밋 메시지 스타일 가이드
- 메시지 구조 : 커밋 메시지는 제목, 선택적인 본문 및 선택적인 바닥글의 세 부분으로 구분되어 빈 줄로 구분된다
- type : 제목에 포함되며 다음 유형 중 하나일 수 있다!
- Subject : 제목은 50자 이하여야 하며 대문자로 시작하고 마침표로 끝나지 않아야 한다
- body(선택사항) : 어떻게가 아니라 무엇을, 왜 커밋 했는지 설명하기 위해 본문을 사용해야한다
- footer(선택사항) : 문제 추적기 ID를 참조하는 데 사용된다
- 참조: https://udacity.github.io/git-styleguide/
3. Git 명령어
Git 기초
git init
$ git init
git add
- 작업 디렉토리의 변경 내용의 일부만 스테이징 영역에 넘기고 싶을 때
$ git add <파일/디렉토리 경로>
- 현재 디렉토리의 모든 변경 내용을 스테이징 영역으로 넘기고 싶을 때
$ git add .
- 작업 디렉토리 내의 모든 변경 내용을 모두 스테이지 영역으로 넘기고 싶을 때
$ git add -A
git commit
- 커밋 메시지을 붙여 커밋
$ git commit -m '[메시지]'
- 메시지을 붙여서 스테이징과 커밋을 동시에 진행
$ git commit -a -m '[메시지]'
git push
- 지역 저장소의 커밋을 맨 처음 원격 저장소에 올리는 경우
$ git push -u <저장소명> <브랜치명>
- 1번을 한 후에 지역 저장소의 커밋을 원격 저장소에 올리는 경우(업로드) 또는 저장소명과 브랜치명 생략 가능
$ git push <저장소명> <브랜치명>
$ git push
브랜치 활용
git branch
- 로컬 저장소의 브랜치 목록
$ git branch
- 원격 저장소의 브랜치 목록 / 로컬 + 원격 모든 브랜치 목록
$ git branch -r
$ git branch -a
- git branch 브랜치 이름 (브랜치 생성)
$ git branch <브랜치이름>
- 해당 브랜치를 로컬 저장소에서 삭제(필요하면 원격 브랜치에서 가져올 수 있다)
$ git branch -D <브랜치이름>
git checkout
- 해당 브랜치로 이동. HEAD 포인터가 해당 브랜치로 옮겨지게 된다
$ git checkout -b <브랜치이름>
- 브랜치를 생성함과 동시에 이동
$ git checkout -b <브랜치이름>
Git 심화
- 특정 커밋을 참조하는 이름 붙이기
$ git tag
- 마지막 커밋 수정하기
$ git commit -amend
- 공개된 커밋의 변경 내역을 되돌리기
$ git revert
- 이전 작업 결과를 저장한 상태로 되돌리기
$ git reset
- 특정 파일을 최종 커밋 시점으로 되돌리기
$ git checkout HEAD --filename
- 브랜치 이력을 확인하면서 병합하기
$ git rebase
- 커밋 내역 합치기
$ git rebase -i
<참고>
https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html
4. 이제 협업을 위한 브랜치 - Gitflow
- 대표적인 브랜칭 전략중 하나이다
- 브랜치를 크게 4가지로 나누어 개발하는 전략이다
- master 와 develop 이라는 항상 존재하는 메인 브랜치
- feature, hotfix, release 라는 필요에 따라 생성하는 브랜치 => 필요에 따라 추가 / 삭제하여 사용
master
develop
- 개발 브랜치. 개발자들은 이 브랜치를 기준으로 각자 작업하는 기능들을 병합
feature
- 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치로 병합
release
- 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질 검사)를 하기위한 브랜치
hotfix
- master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치
<참고>