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/*hotfixdevelopfeature
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)