Git
1. Centralized Workflow
1.1. 작동 원리
- 저장소 하나에 여러명이 작업하는 것
- 모든 변경 내용은
master
브랜치 하나에 커밋
1.2. 충돌 처리
두 가지 방법이 있다.
rebase
(prefer)merge
철이
$ mkdir git
$ cd git
$ mkdir centralized-workflow
$ cd centralized-workflow
$ git init
$ git remote add origin https://github.com/pinstinct/git-test.git
$ vi README.md
$ git add -A
$ git commit -m "First commit"
$ git push -u origin master
# origin이라는 별칭이 자동 생성
$ git remote -v
origin https://github.com/pinstinct/git-test.git (fetch)
origin https://github.com/pinstinct/git-test.git (push)
# 작업
$ vi abc.txt
$ git add abc.txt
$ vi test.txt
$ git st
$ git add test.txt
# 스테이징 영역에 있는 파일을 변경
$ vi test.txt
$ git st
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: test.txt
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: test.txt
# 푸시 후에는 사용하면 안된다.
$ git commit --amend
# origin의 master 브랜치에 로컬 master 브랜치를 푸시
$ git push -u origin master
미애
# 작업
$ vi xyz.txt
$ git add -A
$ git commit -m "xyz.txt"
# 작업완료 후 푸시를 하려고 하면,
$ git push
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
# 두가지 방법
# rebase : 미애의 커밋 앞에 변경사항을 끼어놓은 다음 푸시
# rebase 옵션을 사용해 불필요한 커밋을 안남기는게 좋다.
$ git pull --rebase orgin master
# 충돌이 발생할 경우, rebase를 할 수 없다.
# merge : 앞에것과 내것을 병합한 다음 푸시
2. Feature Branch Workflow
2.1. 작동원리
- 브랜치를 만들어 작업
- 기능을 만든 후
master
브랜치에 합침 master
브랜치는 손대지 않는 게 핵심
2.2. 풀 리퀘스트
master
를 관리하는 관리자가 있어, 리퀘스트를 확인하고 이상이 없으면 리퀘스트를 받는다.
미애
$ git branch new-branch
$ git branch -v
$ git checkout new-branch
# 작업
$ git push -u origin new-branch
# 깃헙에서 풀리퀘스트 작성
# 풀리스퀘트 수용
# 작업완료 후 브랜치는 삭제한다.
# 리모트 브랜치 삭제
$ git push origin --delete new-branch
# 로컬 브랜치 삭제
$ git branch -d new-branch
3. Gitflow Workflow
3.1. 작동 원리
다른 워크플로우와 마찬가지로 로컬 브랜치에서 작업하고 중앙 저장소에 푸시한다. 단지 브랜치의 구조만 다를 뿐이다.
master
: 릴리즈 태그release/*
hotfix
develop
feature
4. Forking Workflow (프로젝트에 사용할 방식)
하나의 중앙 저장소를 이용하는 것이 아니라, 개개인마다 서로 다른 원격 저장소를 운영하는 방식이다. 특히, 오픈 소스 프로젝트에서 많이 사용하는 방식이다.
4.1. 작동 원리
- 프로젝트 참가자
- 공식 저장소 >
Fork
(주의: Clone하는 것이 아님)Fork
한 것은 푸시권한이 없다.
Fork
한 저장소(공식 저장소 복제본)를git clone
명령으로 로컬 저장소 생성- 브랜치를 나눠서 작업한다.
- 작업 후 커밋이력을 ‘공식 저장소 복제본’에
push
한다. - 그 후, pull request를 던진다. (브랜치 단위)
- 공식 저장소 >
- 프로젝트 관리자
- 참가자의 리퀘스를 병합할 때, 참가자의 변경사항을 자신의 로컬에 저장
- 로컬
master
에 병합 후 공식 저장소master
브랜치에 반영
팀 프로젝트 발표
API 문서 작성 및 테스트는 개발을 시작하면서 해야 한다.
- DB 모델 : 지금 기능은 외래키 관계만으로 충분
- 외부 API 사용 : 검색 후 DB에 저장하고 보여주는 방식이 일반적 (구글에 쿼리를 가장 적게 날리도록 설계하는게 가장 좋음)
- 속도문제를 해결하려면 백그라운드 작업을 해줘야함, 배우지 않았지만 원하면 도움을 주실 예정 > 수업예정
- 강사님 추천 : 데이터 최신 상태 유지, 외부 API와 데이터베이스를 비교해서 유지하기 (서버가 놀고 있는시간에 동작, 새벽)
- 강사님 추천 : 추천 기능, 사용자가 저장한 책을 기반으로 추천 알고리즘 제작
- 강사님 추천 : 푸시 서비스
- 강사님 추천 : 이메일 인증 (3rd 파티 툴이 있으나, 직접 구현해보는 것을 추천)
추가 수업 일정 (각 2시간)
- 백그라운드 테스크
- 서버 모니터링
- CI (Travis)