Git

1. Centralized Workflow

1.1. 작동 원리

  • 저장소 하나에 여러명이 작업하는 것
  • 모든 변경 내용은 master 브랜치 하나에 커밋

1.2. 충돌 처리

두 가지 방법이 있다.

  1. rebase (prefer)
  2. 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 문서 작성 및 테스트는 개발을 시작하면서 해야 한다.

  1. DB 모델 : 지금 기능은 외래키 관계만으로 충분
  2. 외부 API 사용 : 검색 후 DB에 저장하고 보여주는 방식이 일반적 (구글에 쿼리를 가장 적게 날리도록 설계하는게 가장 좋음)
    1. 속도문제를 해결하려면 백그라운드 작업을 해줘야함, 배우지 않았지만 원하면 도움을 주실 예정 > 수업예정
    2. 강사님 추천 : 데이터 최신 상태 유지, 외부 API와 데이터베이스를 비교해서 유지하기 (서버가 놀고 있는시간에 동작, 새벽)
    3. 강사님 추천 : 추천 기능, 사용자가 저장한 책을 기반으로 추천 알고리즘 제작
  3. 강사님 추천 : 푸시 서비스
  4. 강사님 추천 : 이메일 인증 (3rd 파티 툴이 있으나, 직접 구현해보는 것을 추천)

추가 수업 일정 (각 2시간)

  1. 백그라운드 테스크
  2. 서버 모니터링
  3. CI (Travis)