[Git] Github-Flow

in Git

어제 Git-Flow를 공부해보았는데, 헷갈리는 부분이 너무 많다. 그래서 Github-Flow 방법에 대해서도 헷갈리는 부분이 많아 잘 정리된 블로그를 보고 공부했다.

"사전 과제 Repository를 fork 떠서 수정하고 PR 날려주세요."라는 메일을 받았다. 나는 Github을 사용하고 이런 비슷한 방식으로 프로젝트를 진행해왔지만 이게 이 방식이 맞는지도 모르고 있었다.

Pull Request

협업을 하다보면 Pull Request를 보내서 코드 리뷰를 거쳐 원격 저장소에 merge가 된다. 분명 중요하다. Pull Request를 위해서 아래와 같은 절차를 거쳤다.

  • Fork
  • clone, remote 설정
  • branch 생성(안할 수도 있음)
  • 수정 작업 후 add, commit, push
  • Pull Reqeust 생성
  • 코드 리뷰, Merge Pull Request
  • Merge 이후 branch 삭제 및 동기화

Fork

  • 타켓 프로젝트의 저장소를 자신의 저장소로 Fork 한다.

Clone, remote 설정

  • fork로 생성한 본인 계정의 저장소에서 clone or download 버튼을 누르고 표시되는 url을 복사한다.
  • Mac 기준에서 터미널을 켠다.
  • 자신의 컴퓨터에서 작업을 하기 위해서 지정한 디렉토리로 가서 Fork한 저장소를 로컬에 Clone하기 위해서 아래의 명령어를 실행한다.
1
git clone https://github.com/wayhome25/blog.github.io.git
  • 이제, 로컬 저장소에 원격 저장소를 추가한다. 위 작업과 동일하게 github 저장소에서 clone or download 메뉴를 통해서 확인한 url을 사용한다.
    • 원본 프로젝트 저장소 (직접 추가 필요)
    • fork한 로컬 프로젝트 (origin이라는 별명으로 기본으로 추가되어 있다. 따로 추가할 필요 없음)
1
2
3
4
5
6
# 원본 프로젝트 저장소를 원격 저장소로 추가
# 보통 upstream 사용
$ git remote add real-blog(별명) https://github.com/원본계정/blog.github.io.git

# 원격 저장소 설정 현황 확인방법
$ git remote -v

branch 생성

  • 자신의 로컬 컴퓨터에서 코드를 추가하는 작업은 branch를 만들어서 진행한다.

개발을 하다보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다.

1
2
3
4
5
6
7
8
9
10
git branch develop master
git checkout develop

# 하나의 명령어로 축약 가능
git checkout -b develop

# 이제 2개의 브랜치가 존재한다.
git branch
* master
develop

수정 작업 후 add, commit, push

  • 자신이 사용하는 코드 편집 툴을 활용하여 수정 작업을 진행한다.
  • 작업이 완료되면 add, commit, push를 통해서 자신의 github repository(origin)에 수정사항을 반영한다.
1
2
3
4
5
# add, commit 같이 수행
git commit -a -m "Modify code"

# push
git push origin develop
  • push 진행 시에 branch 이름을 명시해주어야 한다.
  • 위의 명령어는 develop 브랜치의 수정 내역을 origin으로 푸시한다는 것이다.

Pull Request 생성

  • push 완료 후 본인 계정의 github 저장소에 들어오면 Compare & pull request 버튼이 활성화 되어 있다.
  • 해당 버튼을 선택하여 메시지를 작성하고 PR을 생성한다.(날린다.)

코드 리뷰, Merge Pull Request

  • PR을 받은 원본 저장소 관리자는 코드 변경 내역을 확인하고 Merge 여부를 결정하기 전에 Review를 남긴다.
  • 팀의 정책에 따라 Review가 1개 이상이면 Merge를 하는 등의 조건이 있을 수 있다.

Merge 이후 동기화 및 branch 삭제

  • 원본 저장소에 Merge가 완료되면 로컬 코드와 원본 저장소의 코드를 동기화 한다.
  • 작업하던 로컬의 branch를 삭제한다.
1
2
3
4
5
6
7
8
# 코드 동기화
git pull real-blog(remote 별명)

## ex
git pull upstream

# 브랜치 삭제(develop 브랜치 삭제)
git branch -d develop(브랜치 별명)
  • 나중에 추가로 작업할 일이 있으면 git pull real-blog명령을 통해 원본 저장소와 동기화를 먼저 진행하고, 세번째부터 일곱번째 작업을 반복한다.

느낀 점

지금까지 내가 했던 방식이 Github-Flow 방법이라는 것을 알게 되었다. 원격 저장소를 자신의 개인 저장소로 fork 하는 방식으로 간단하게 사용할 수 있는 방법이다. 어제 공부했던 브랜치 전략은 Git-Flow로 브랜치를 나누어서 작업을 진행하는 것인데, 조금 더 복잡하다.

참고

Comment and share

[Git] Git-Flow

in Git

Git-Flow 전략에 대해서 알아볼 예정이다. 기존에 사용하던 방법은 이름을 몰랐고 그냥 프로젝트 팀원한테 배웠던 방식을 사용했다. 이름은 나중에 찾아보니 Github-Flow였다. Git-Flow를 알아보기 전에 Github-Flow가 무엇인지 알고 넘어가보자.

Continue reading

Repository

Repository 정의는 Memory cache를 할 수 있으며, Remote/Local 데이터를 불러오게 된다. SQLite 사용 시에는 Loaders 사용으로 비동기식 데이터를 쉽게 로드할 수 있는 방법을 사용하고, RxJava 등의 방법을 사용할 수 있다. [이 경우는 이번 글에서 다루지 않는다.]

Continue reading

다음을 정리

이전 영상을 보면서 배웠던 내용은 View -> Presenter -> Model -> Presenter -> View -> Adapter을 정의하였다. 오늘은 아래 그림과 같이 View -> Presenter -> Model -> Presenter -> Adapter View/Model을 바로 갱신하게 된다. 그래서 Activity/Fragment의 View를 한 단계 더 분리하고, 이를 좀 더 편하게 관리하기 위함이다.

Continue reading

이번에는 Adapter에 대한 Contract 정의하는 방법을 살펴보려 한다. 여기서는 Adapter에 대한 Contract를 정의하고 이를 상속받아서 사용하는 방법을 정리해보겠다.

Continue reading

이번에는 MVP 따라하기 4번째 시간이다. 저번 글에서 Android MVP 적용하는 방법 중 구글에서 추천하는 Presenter / View 인터페이스를 Contract 인터페이스에 선언해서 사용하는 방법을 다루었다.

Continue reading
Author's picture

VictoryWoo

기록을 통해 사람들과 공유하는 것을 좋아합니다.


Android Developer