Portfolio

참고 링크

안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합니다. '배달의민족 안드로이드 모바일 파트에서 이렇게 브랜치를 관리하고 있구나' 정도로 봐주시면 좋을 것 같습니다. 2016년 1월, Github로 소스코드를 이전하면서 Github-flow를 사용하기 시작했습니다. 그러다 2017년 6월부터 Git-flow로 브랜치 전략을 바꾸게 되었습니다.

https://techblog.woowahan.com/2553/

6. Github으로 협업하는 법

Pull Request 와 Code Review | 지난 글에서 Github Organization을 만들고 원격 저장소에 Commit History를 Push하기까지 했다. 공동 작업할 수 있는 환경이 갖춰졌다. 이제 동료들과 '너도나도 여기저기에서' commit하면서 프로젝트를 진행 해보자. 0. 되돌아보기 로컬 저장소에서 브랜치를 만들어서 작업한 commit을 master에 Merge 했었다.

https://brunch.co.kr/@anonymdevoo/9

Github로 프로젝트 관리하기 Part1 - Yun Blog | 기술 블로그

Github를 이용해서 Project Management 하는 방법 및 전체적인 프로세스에 대해서 정리했습니다. issue 관리, 일정 관리, 코드리뷰, 버그 리포트 등 다양한 일들을 Github 하나에서 다 관리할 수 있고 어느 하나 부족하다고 생각하지 않습니다. 이미 Remote Repository로 Github를 사용 중 이리 사면 적극 추천해 드립니다. 프로젝트는 지속해서 추가될 예정이라 상단의 전체 사용법은 Github 에서 확인하실 수 있습니다.

https://cheese10yun.github.io/github-proejct/

Git 100% 활용하기: 협업을 위한 브랜치 전략, 팁과 노하우

2016년 360|AnDev 에서 git의 고급 활용법을 주제로 발표한 강연입니다. 팀 구조에 맞게 빠른 워크플로를 달성하기 위해 활용할 수 있는 다양한 브랜치 전략과 Shazam 안드로이드 팀에서의 브랜치 활용 전략 시연, 작업 방식을 최적화하고 다른 사람들과 공유할 수 있는 방법을 배울 수 있습니다. 저는 Savvas Dalkitsis 이며, Shazam의 수석 소프트웨어 엔지니어로 일하다 ASOS.com의 리드 안드로이드 개발자로 이직했습니다.

https://academy.realm.io/kr/posts/360andev-savvas-dalkitsis-using-git-like-a-pro/

[GitHub] - IntelliJ Task로 GitHub Issues의 브랜치 간단하게 생성하기

안녕하세요, 이번에는 인텔리제이에서 깃허브 레포지토리의 Issues를 기반으로 브랜치를 간단하게 생성하는 방법 에 대해 알아보겠습니다. 저는 그동안 개발을 하면서 ( 멍청하게) 브랜치는 CLI를 통해 생성하고 관리를 했었습니다. 😂 하지만 인텔리제이에서는 깃허브의 레포지토리에 존재하는 이슈를 토대로 브랜치를 생성하는 기능을 제공하고 있습니다. 👍 IntelliJ, GitHub Repository, Repository의 Issues, GitHub Token 만 있으면 됩니다.

https://zzang9ha.tistory.com/377

헤이딜러 개발팀 모두가 행복한 개발/PR관리 방법 7가지

개발자마다 코딩하는 방식은 제각각입니다. 똑같은 if/else문을 작성하더라도 각자의 방식대로 코딩합니다.😱 vs name을 표시하는 TextView라는 UI의 id를 정할때도 등으로 자기가 맘에드는것으로 선택해서 정합니다. 혼자 개발할때는 문제가 없지만 여러명이 하나의 프로젝트를 개발할때는 각자 다른 방식으로 코딩하는것이 문제가 됩니다. 그래서 코딩 컨벤션📝이 필요합니다.코딩 컨벤션을 만들고 이를 모두가 지켜서 코딩한다면 아래와 같은 점이 좋습니다.

https://medium.com/prnd/%ED%97%A4%EC%9D%B4%EB%94%9C%EB%9F%AC-%EA%B0%9C%EB%B0%9C%ED%8C%80-%EB%AA%A8%EB%91%90%EA%B0%80-%ED%96%89%EB%B3%B5%ED%95%9C-%EA%B0%9C%EB%B0%9C-pr%EA%B4%80%EB%A6%AC-%EB%B0%A9%EB%B2%95-7%EA%B0%80%EC%A7%80-1d4cd5d091f0

Git! 브랜치 관리 전략 및 버전 관리 환경 개선 사례

1년 동안 앓은 고질병

https://moonsupport.oopy.io/post/1

git으로 함께 일하기 | merge 전략, PR, 커밋 컨벤션

내가 속한 팀은 신생 팀이고 팀 단위의 git 전략은 딱히 존재하지 않았다. release log를 남기기 위해 커밋 컨벤션을 만들어놓은 정도였다. 사내 다른 개발자들의 브랜치 머지 전략, 커밋 로그 컨벤션 등을 보고 팀원들에게 제안해 적용해보았다. 🧚‍♀️참고: https://moonsupport.oopy.io/f8a56d78-1425-4987-9a34-30ed30885d2c 군데군데 merge commit이 섞여 있어서 히스토리를 매끄럽게 알기 어렵다.

https://another-light.tistory.com/71

[Git] Gitflow로 branch를 관리하자!!

https://k39335.tistory.com/82

[Git] PR 후 merge된 branch 자동 삭제하기

branch를 나누어 개발을 하다보면, Issue close되어 branch를 삭제해야 하는 경우가 자주 생깁니다. 이때, 매번 삭제하는 것이 귀찮을 경우 아래와 같이 Github이 제공하는 기능을 통해 PR 후 merge된 branch를 삭제할 수 있습니다. 먼저, Settings에 들어간 후 Options의 Merge button을 찾습니다. 그 후, Automatically delete head branches를 클릭합니다.

https://earth-95.tistory.com/101

GITHUB protected branch를 설정 해 보자

프로젝트/N poem 가든리 가든리 2020. 4. 25. 00:57 GITHUB 에서 어떤 브랜치를 어떤 행위에 대해서 보호하기 위한 조치이다. 예를 들어 우리의 소중한 마스터 브랜치는 언제나 잘 작동하는 올바른 코드가 올라가야 할 것이다. 이 원칙을 지키기 위해 마스터 브랜치에는 항상 올바른 커밋 혹은 머지가 되어야 할 것이다.

https://gardeny.tistory.com/19

[GitHub] PR 템플릿, 이슈 템플릿 등록하기 (Pull Request Template, Issue Template)

GitHub을 이용해서 소스 코드를 관리할 때 PR(Pull Request)라는 과정을 거치게 된다. PR 등록을 하면 소스코드를 관리하는 개발자나 다른 팀원이 PR에 대한 코드 리뷰를 진행하게 된다. PR을 등록할 때 소스코드 이외에 어떤 작업이었고 어떤 내용을 고쳤는지 설명도 같이 써주면 좋다. 단순히 커밋 로그와 소스코드만으로는 작업에 대한 완벽한 이해가 어렵기 때문이다.

https://soft.plusblog.co.kr/66

gitmoji

Gitmoji is an emoji guide for your commit messages. Aims to be a standarization cheatshee /t for using emojis on GitHub's commit messages.

https://gitmoji.dev/

Gitmoji 사용하기

gitmoji란? Gitmoji = git + emoji 입니다. 글을 쓸 때 이모지를 이용하면, 나중에 글을 읽을때 명확합니다. 👍 커밋할 때도 이모지를 이용한다면, 내용을 한 눈에 알아보기 더 쉽겠죠. 그래서 나온 것이 gitmoji 입니다. github.com/carloscuesta/gitmoji Gitmoji is an initiative to standardize and explain the use of emojis on GitHub commit messages.

https://treasurebear.tistory.com/70

✏️

극락이들의 GitHub 협업 가이드 문서입니다. ⇒ 궁금한 점이 있으면 주디()에게 질문해주세요!

[ 목차 ]

0. 극락이들의 협업 규칙 1. 협업을 위한 사전 준비 2. 브랜치 전략 3. 이슈 기반 브랜치 생성 4. Branch에서 작업 후 PR

0. 극락이들의 협업 규칙

브랜치는 main, develop, feature 브랜치만 사용

feature 브랜치는 이슈 기반으로 인텔리제이를 활용해 생성

브랜치간 merge 전략은 다음 규칙을 따름

develop → main : create a merge commit 옵션 사용

feature → develop: squash and merge 옵션 사용

develop → feature: rebase and merge 옵션 사용

브랜치 형식 → feature/domain-이슈번호

feature/diary-1

커밋 형식 → Gitmoji 구현한 내용

✨ 일기 엔티티 생성

이슈 형식 → [Domain] 구현할 내용

ex) [Diary] 일기 생성 기능 구현

PR 형식 → Gitmoji [Feature/domain-이슈번호]구현한 내용

ex) ✨ [Feature/diary-1] 일기 생성 기능 구현
fix(hotfix)에서 develop으로 merge 할 경우

Gitmoji [Fix/domain-이슈번호]구현한 내용

develop에서 main으로 merge 할 경우

Gitmoji [Develop]구현한 내용

이슈에 Assignees, Label, Project, Milestone 필수로 추가

PR에 Reviewers, Assignees, Label, Project 필수로 추가

이슈와 PR은 템플릿을 활용

이슈 템플릿


<!-- 
    Issue 제목은 다음과 같은 형식으로 작성합니다.

    [domain] title
    ex) [Diary] 일기 작성 기능 구현
-->


## 📑 작업 사항 
<!-- 진행할 작업 목록을 작성해주세요. -->

PR 템플릿


<!-- 
    PR 제목은 다음과 같은 형식으로 작성합니다.

    gitmoji [Feature/domain-issue number] title
    ex) :sparkles: [Feature/diary-1] 일기 작성 기능 구현
    
    PR에 사용되는 Gitmoji 가이드입니다.
    
    feat(✨) - Introduce new features
    fix(🐛) - Fix a bug
    docs(📝) - Add or update documentation
    style(🎨) - Improve structure / format of the code
    refactor(♻️) - Refactor code
    perf(⚡️) - Improve performance
    test(✅) - Add or update tests
    build(👷) - Add or update CI build system
    ci(💚) - Fix CI Build
    chore(⚙️) - Other changes 
    revert(⏪️) - Revert changes
    hotfix(🚑️) - Critical hotfix
-->


## 💡 개요 
<!-- PR에 대한 설명을 간략하게 작성해주세요. -->
- resolved #0


## 📑 작업 사항 
<!-- 진행한 작업에 관한 내용을 작성해주세요. (스크린 샷이 있다면 첨부해주세요) -->



## ✒️ 코드 리뷰 요청 사항
<!-- 리뷰어가 집중해서 봐야 하는 포인트나 궁금한 점을 작성해주세요. -->


## ✔️ 코드 리뷰 반영 사항
<!-- 코드 리뷰에 대한 반영사항을 작성해주세요. (재 PR 시에만 작성합니다) -->

1. 협업을 위한 사전 준비

IntelliJ - Git Tool Box 플러그인 설치 (필수)

인텔리제이에서 Git Tool Box 플러그인을 설치합니다.

깃허브를 사용하실 때 유용한 플러그인이니 설치하시는 것을 추천드려요!

설치하시면 다음과 같이 프로젝트 옆에 뜨는 것을 볼 수 있습니다.

깃 프로젝트에 대한 정보를 데코레이션을 볼 수 있는 기능입니다.

데코레이션은 Settings > Version Control > GitToolBox 에서 커스텀 가능합니다.

IntelliJ - Gitmoji Plus 플러그인 설치 (옵션)

인텔리제이에서 Gitmoji Plus 플러그인을 설치합니다.

깃모지가 익숙하지 않은 사용자를 위해 쉽게 쓸 수 있도록 도와주는 플러그인입니다.
플러그인 설치가 싫으신 분들은 Gitmoji 홈페이지를 참고하셔도 됩니다.

설치하시면 커밋 창에서 깃모지 아이콘이 생긴 것을 볼 수 있습니다.

클릭 후 커밋 상황에 맞는 깃모지를 선택 해주시면 됩니다.

검색도 가능해요!!

2. 브랜치 전략

Gitflow 관련 추가 설명 (참고 링크)

💡

Gitflow를 축소시켜 main, develop, feature 브랜치만 사용할 예정입니다. 각 브랜치는 Github의 Issue기반으로 IntelliJ의 Task를 활용하여 생성할 것이고, Issue는 PR과 1대 1로 매칭합니다.

main 릴리즈를 위한 브랜치입니다.

develop 릴리즈 전 릴리즈를 위한 준비가 된 가장 안정적인 브랜치입니다.

즉, main에 merge 전 모든 feature가 develop에 merge 되어야 합니다.

feature 새로운 기능이 추가되어야 할 때 사용되는 브랜치입니다.

develop으로부터 브랜치를 생성 해서 작업 후, 작업이 완료되면 develop에 merge 합니다.

Merge 방식 이해하기 (Merge, Squash, Rebase)

Merge 방식을 이해해야 깃 크라켄 같은 도구에서 커밋 내역을 볼 때 이해가 쉽고 협업할 때 도움이 될테니까 꼭 이해해주세요!

[Git] Merge 이해하기 (Merge / Squash and Merge / Rebase and Merge)

회사에서 Git을 사용해서 형상 관리를 하고 있다. 그 동안 내가 개인 repository branch에 commit, push등을 해본 적은 많지만 다른 사람과 협업을 하면서 branch를 생성하고 master에 merge를 해본 적은 없어서 처음에 매우 당황했었다. 그래서 오늘은 많이 비교가 되는 merge와 rebase에 대해서 알아보려고 한다! 먼저 Merge와 Rebase는 다음과 같은 상황에서 사용된다.

https://im-developer.tistory.com/182

Github Merge 방식 이해하기(merge, squash, rebase)

Github에서 지원되는 Merge 방식에는 Merge, Squash and Merge, Rebase Merge 로 총 3가지가 있습니다. 각각의 Merge 방식에 대해서 이해하려면 우선 브랜치(Branch)라는 개념을 아는 것이 선행되어야 하는데, 브랜치에 대해서 간략하게 먼저 정리해보도록 하겠습니다. 브랜치는 그 뜻 그대로 나무의 가지라고 생각하면 좋습니다. 나무의 굵직한 기둥이 마스터가 되고 각각의 브랜치들이 여러 갈래로 뻗어나가면서 다양한 버전들을 가지고 있는 것이죠.

https://datalibrary.tistory.com/194

Branch Merge 전략

develop → main : create a merge commit 옵션 사용

머지 커밋이 남습니다. main 브랜치에는 머지 시점이 필요하니 해당 전략을 사용합니다.

feature → develop: squash and merge 옵션 사용

PR의 커밋 로그를 하나로 묶을 수 있습니다. 원자적인 커밋 또는 PR 기능과 전혀 상관 없는 커밋 로그(ex. 콘솔 로그 제거)를 하나로 합쳐서 의미 있는 커밋 로그만 남기는 방식입니다. PR 제목이 커밋 로그가 됩니다!!

다만 PR에 커밋이 하나 뿐일 경우에는 커밋이 커밋 로그가 되기 때문에 꼭 PR 제목 형식에 맞게 수정 후 머지해주세요~

develop → feature: rebase and merge 옵션 사용

머지 커밋이 남지 않기 때문에 develop 브랜치를 내 브랜치로 pull할 때 사용해 쓸데 없는 머지 커밋을 남기지 않을 수 있어요!

3. 이슈 기반 브랜치 생성

Github 이슈 생성

이슈 기반으로 브랜치를 생성하기 위해서 깃허브에서 이슈를 생성합니다.

새로 추가해야 하는 기능, 개선해야 하는 기능, 버그 등 모든 것을 이슈라고 합니다.
프로젝트에서 생성할 경우 템플릿 적용이 되지 않으니 이슈에서 생성 후 프로젝트를 연결해주세요!

이슈 생성하기

이슈 제목 형식은 아래와 같이 작성하려고 합니다.

[domain] 구현할 내용

ex) [Diary] 일기 추가 기능 구현

본문은 이슈 템플릿을 활용해 작성해주시면 됩니다.

이슈에 배정, 라벨, 마일 스톤 추가하기

이슈에는 Assignees, Label, Milestone, Project는 필수로 추가합니다.

IntelliJ Task Server 설정

Settings > Tools > Tasks > Servers 에 들어가서 깃허브 레포를 등록합니다.

아래 더하기 버튼을 클릭 후 Github를 선택해주세요.

Repository 에 깃허브 유저명 / 레포지토리명을 입력합니다.

Craete API Token 을 클릭 후 토큰을 발생합니다.

TEST 를 눌러 확인 후 이상이 없으면 OK 를 누릅니다.

IntelliJ 이슈 기반 브랜치 생성

위에서 생성한 이슈에 대한 브랜치를 인텔리제이에서 생성합니다.

feature 브랜치를 생성한다고 이해해주시면 됩니다.
브랜치 생성 형식은 다음과 같습니다.

feature/domain-이슈번호

ex) feature/diary-1

shift를 두 번 클릭 후 open task를 검색합니다. (윈도우 기준 단축키 alt + shift + n)

깃허브와 연관된 이슈 목록 중에서 원하는 이슈를 선택합니다.

from 이후를 develop으로 선택 후 브랜치 명을 형식에 맞게 작성 후 OK 를 클릭합니다.

develop origin/develop 다 가능합니다!!

다만 develop 으로 할 경우 최신으로 업데이트 됐는지 확인 후 해주세요~

혹시 브랜치명 실수했을 경우는 rename 하셔셔 변경하시면 됩니다.

4. Branch에서 작업 후 PR

IntelliJ Commit & PR

브랜치명에 어떤 팀인지에 대한 정보가 있으니 앞으로 커밋 형식은 다음과 같습니다. (커밋 내용은 자유롭게 작성하시면 될 것 같아요)

깃모지 구현한 내용

ex) ✨ 일기 엔티티 생성

작업 완료된 브랜치는 develop 에 PR을 날려서 squash merge 해주세요!

깃모지 [Feature/domain-이슈번호] 구현한 내용

ex) ✨ [Feature/diary-1] 일기 생성 기능 구현

Rwviewers, Assignees, Label, Project 도 추가합니다.

PR 본문에는 키워드와 함께 이슈 넘버(#이슈 번호)를 기재합니다.

본문은 PR 템플릿을 활용해 작성해주시면 됩니다.
merge 시 자동으로 이슈가 close 됩니다.

이슈 종료 키워드


- close
- closes
- closed
- fix
- fixes
- fixed
- resolve
- resolves
- resolved

스쿼시 머지 시 커밋이 1개일 경우 제목이 PR 제목으로 반영 안되니 확인해주신 후 merge 해주세요!!

성공적으로 PR이 merge되고 이슈가 닫혔습니다.

머지된 브랜치는 리모트에서는 자동 삭제됩니다.

작업 중 develop 내용 가져오기

develop에서 새 브랜치를 만들어서 작업 중 다른 브랜치에서 작업 내용이 develop에 merge 된 상황

현재 브랜치 - c/user-4

이때 인텔리제이에서는 이렇게 보입니다.

develop 의 내용을 c/user-4 로 가져오려면 아래 그림처럼 develop 을 우클릭 후 rebase를 선택합니다.

충돌이 없을 경우 바로 rebase가 적용되서 합쳐지는 것을 볼 수 있어요!

충돌이 있는 경우 충돌을 해결하라는 안내가 뜨는데 충돌을 해결하면 됩니다.

이렇게 하고 나서 PR을 날리면 깔끔하게 커밋을 유지하면서 develop 의 최신 내용을 반영할 수 있습니다!!

[BE] GitHub 협업 가이드

0. 극락이들의 협업 규칙

1. 협업을 위한 사전 준비

2. 브랜치 전략

3. 이슈 기반 브랜치 생성

4. Branch에서 작업 후 PR