시작하기에 앞서
Git 은 학문적으로 어렵다기보다, 도구일 뿐인데 처음에는 낯설어서 어렵게 느껴질 수 있습니다. 습관이 가장 중요하기 때문에 손에 익을 정도로 자주 쓰는 것이 좋습니다. TIL Repo를 만들고 매일 학습하거나 얻은 지식을 정리하고, Github 정적 블로그를 만들어 정리하는 습관을 만들며 markdown 과 친해집시다!
Git 과 Github 의 차이
Git은 버전관리를 위한 소프트웨어 이고, Github는 Git으로 저장/원격전송된 내역들이 저장되는 공간을 제공하는 웹 서비스.
git objects
Blob: 파일 하나의 내용에 대한 정보
Tree: Blob이나 subtree의 메타데이터(디렉토리 위치, 속성, 이름 등)
Commit: 커밋 순간의 스냅샷
Git 환경설정
git config --global user.name+ 사용자 이름git config --global user.email+ 사용자 메일주소git config --global core.editor "vim"git config --global core.pager "cat"git config --list: 정상 설정 확인vi ~/.gitconfig: 수정 가능 명령어
이미지 출처: champlintechnologiesllc.com
- Working Directory: 개인 코드 작성
- Staging Area:
git add를 통해 수정된 코드를 올리는 영역 - Local Repository:
git commit을 통해 최종 수정본을 등록
git init
"initialize" 의 약자로, 초기화를 뜻하며 새로운 Git 저장소(repository)를 생성할 때 사용하는 명령어 입니다.
디렉터리 생성 후 git init 명령어를 통해 초기화를 시키면 해당 디렉토리를 기준으로 git 저장소가 생깁니다.
이후 git 명령어를 사용할 수 있습니다. 얼핏보면 차이가 없으나 ls -a 명령어를 통해 .git 파일이 생성된 것을 확인할 수 있습니다.
git status
지정된 저장소의 현재 상태를 확인할 수 있는 명령어 입니다. 상태 변경이 필요한 파일들을 알려주기도 합니다.
git add
git add {파일이름} 명령어를 실행하면 working directory에서 staging area로 파일이 등록됩니다.
git add --all 혹은 git add . 을 사용하면 git status에서 확인한 모든 변경사항을 staging area에 등록할 수 있습니다.
또한 git rm --cached {파일이름} 명령어 사용 시 stagin area에 등록한 파일을 내릴 수도 있습니다.
git commit
Local 저장소의 마지막 local repo 에 파일을 등록하기 위해서 git commit 명령어를 사용합니다. 현재 commit 대상이 된 파일은 모두 등록됩니다. commit 은 동작 가능한 최소 단위로 자주하는 것이 좋고, 모두가 이해할 수 있는 log를 작성하는 것이 좋습니다.
이때, 버전 관리를 위해 commit message를 작성해야 합니다. commit message는 50자 이내로 요약하여 작성하는 것이 좋으며, 제목과 내용의 사이에는 한 칸(<br>)의 공란이 있어야 합니다.
prefix를 사용하면 커밋의 용도를 이해하는 것이 쉽습니다.
- feat: features
- docs: documentations
- conf: configurations
- test: test
- fix: bug-fix
- refactor: refactoring
- ci: Continuous Integration
- build: Build
- perf: Performance
예시)
feat: Add server.py
fix: Fix Typo server.py
docs: Add README.md, LICENSE
conf: Create .env, .gitignore, dockerfile
BREAKING CHANGE: Drop Support /api/v1
refactor: Refactor user classes예시 2)
feat: Create index.html
I created index.html to serve this wijoonwu.github.io
NEXT_STEP:
-install hexo
-create blog with hexo혹은 git commit -m {commit message} 명령어로 쉽게 등록하는 방법도 있습니다.
git push
git push {저장소 이름} {브랜치 이름} 명령어를 사용하면, 최종적으로 로컬 저장소에 있던 파일이 원격 저장소로 등록됩니다.
git remote
원격 저장소의 연결을 해제하거나 등록하는 명령어입니다.
git remote add {저장소 이름} {저장소 주소}: 위 이미지의 [Code] 아래 url을 복사하여 위 명령어의 {저장소 주소}에 입력하면 해당 저장소를 원격으로 연결할 수 있습니다.git remote -v: 현재 git에 등록된 원격 저장소 리스트를 보여줍니다.git remote remove {저장소 이름}: 원격 저장소를 git의 설정에서 삭제합니다.
git branch
git branch {branch이름}명령어로 브랜치를 생성합니다.git switch {branch이름}명령어로 브랜치를 전환합니다.브랜치 전환 명령어는 원래
git checkout이었으나chekcout은 기존에 가진 기능이 많아git switch,git restore로 대체되어 사용되고 있다.
기존에 생성한 Repository의 Default branch 를 변경하려면?
kyeoneee님의 티스토리 블로그 -> https://kyeoneee.tistory.com/72
git flow
git flow init 명령어를 실행하고 나면 자동으로 mian 외에 develop branch가 생성됩니다. 기본적으로 develop branch에서 개발하고, main branch로 release 하는 방식입니다. > git flow 사용법 : 링크
git flow를 이용해 만들 수 있는 branch는 모두 6종류입니다.
- main: 최종 release에 사용되는 안정된 버전
- develop: 다음 release를 위해 개발 중인 최신 버전
- feature: 특정 기능 개발을 위한 branch
- release: release 점검을 위한 branch
- hotfix: 긴급 버그 픽스를 위한 branch
- support: 버전 호환성 문제를 처리하기 위한 branch
git flow init명령어를 사용하면 프로세스 별로 사용할 branch 이름을 입력하라는 메시지가 나오는데,-d옵션을 주어git flow init -d명령어로 실행하면 이 과정을 생략할 수 있습니다.
git flow feature
특정 기능을 개발하기 위한 branch가 필요한 경우 사용합니다.
git flow feature start {branch 이름}: 새로운 기능 개발을 위한 branch가 "feature/branch 이름" 이라는 이름으로 생성되고, 자동으로 해당 branch로 checkout 됩니다.git flow feature finish {branch 이름}: 작업이 완료된 후 사용하면 git flow는 develop branch로 checkout 한 뒤, feature branch의 변경 내용을 자동으로 develop branch에 merge하며 작업이 끝난 feature branch를 삭제합니다.git flow feature publish {branch 이름}: 여러 개발자와 공동 개발을 하고 싶다면 원격 서버에 게시할 수 있습니다.git flow feature pull origin {branch 이름}: 다른 사용자가 게시한 기능을 가져올 수 있습니다.git branch -D {branch name}: 브랜치를 merge하지 않고 삭제할 때 사용합니다.
git flow release
-
git flow release start {version}: develop branch의 내용을 기반으로 release/branch name 의 이름을 갖는 새로운 branch를 생성해 checkout 합니다. (ex.git flow release start v0.0.1)release branch는 보통 릴리즈 점검을위해 간단한 버그를 수정하는 작업등을 목적으로 합니다.
-
git flow release finish {version}: release 완료 후 사용합니다. 이후 release branch 코드를 main branch에 merge 하고 release 이름으로 태그 등록 후, release develop branch로 재병합(back-merge)한 뒤 release branch를 삭제합니다.
