Git

Git Workflow

1 . 새 프로젝트의 경우, 로컬 컴퓨터에서 작업하기 위해 clone 해줌

git clone <project url>

2 . 모든 기능 분기는 프로젝트의 최신 코드 상태에서 생성

git checkout main

git fetch origin

git reset --hard origin/main

혹은

git pull origin main

3 . 새 기능을 개발하기에 앞서 격리된 작업 브랜치를 만들고, 해당 브랜치로 체크아웃 한다.

git checkout -b <branchname>

혹은

git branch <branchname>

git checkout <branchname>

4 . issue 확인 및 해당 작업 진행

git add <file1> <file2> ...

git commit -m "commit message"

5 . 원격 branch에 푸시

git push -u origin <branchname>

6 . Github 저장소에서 Compare & Pull Request 버튼을 통해 Pull Request 생성

7 . PR 요청은 검토자가 코드 변경내역을 확인하고 Merge 여부를 결정

8 . Merge 이후 동기화 및 branch를 제거

✨ reference

• https://github.com/elsewhencode/project-guidelines#git-workflow

• https://wayhome25.github.io/git/2017/07/08/git-first-pull-request-story/

• Github에서 Pull request 날려보자

Github Project Management

Github를 이용해서 Project Management 하는 방법 및 전체적인 프로세스. (issue 관리, 일정 관리, 코드리뷰, 버그 리포트 등)

✨ 1 . 전체 플로우

1. Issue 발급

2. Issue 작업

3. Pull Request Code Review 진행

4. Issue 반영

✨ 2 . Issue

• Issue 발행

모든 활동 내역을 의미한다. 이를 테면 새로 추가될 기능, 개선 해야할 기능, 버그 등이 있다

• Issue template

Issue를 등록할 템플릿을 설정할 수 있다

https://github.com/cheese10yun/github-project-management#issue-template

• Issue 작업

• Assignees : 해달 작업의 담당자

• Labels : 해당 작업의 성격

• Milestone : 해당 작업이 속한 파트

• Milestone :

Sprint를 관리해주는 도구로, Due Date를 설정한 후 해당 기간 동한 수행할 Issue들을 등록해 놓고 진행 상황을 확인할 수 있다

✨ 3 . Pull Request

• PUll Request 생성

Github 탭에서 New Pull Request 버튼을 클릭s

• PR 작업

• resolved #이슈넘버 (https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)

• 리뷰어 지정

✨ 4 . Code Review

✨ 5 . Wiki

프로젝트의 문서를 관리

✨ 6 . Project

발급된 많은 이슈들을 한눈에 보기 위한 UI를 제공

✨ reference

• https://github.com/cheese10yun/github-project-management

• https://docs.github.com/en/issues

• https://terry-some.tistory.com/93

Git Style Guide

✨ 1. Branches

Perform work in a feature branch.

• main

• feature/\*

1.1 main

> 제품으로 출시될 수 있는 브랜치

> 버전관리가 필요되는 경우 master/1.0.0 이러한 형식으로 브랜치를 생성합니다.

1.2 feature/\*

> 기능을 개발하는 브랜치

1.3 상세 규칙

• main 브랜치는 feature/\* 브랜치에 의해 merge 되어 수정되야 합니다.

• feature 브랜치에서 main 브랜치에 merge 할 때,

반드시 main 브랜치에 있는 내용을 pull 해야 합니다.

(충돌시 로컬에서 수정하기 위해서)

✨ 2. Commits

Writing good commit messages

2.1 구조

`issue(옵션 ex MP-3) type(옵션): subject(필수)

body(옵션)`

• issue: 관련된 이슈 번호를 작성합니다.

• type: 어떤 의도로 커밋했는지를 type에 명시합니다.

• subject: 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않습니다.

영문으로 표기하는 경우 동사(원형)을 가장 앞에 두고 첫글자는 대문자로 표기합니다.

• body: 긴 설명이 필요한 경우에 작성합니다.

한줄에 최대 75글자를 넘기지 않도록 합니다.

어떻게 했는지가 아니라, 무엇을 왜 했는지 작성합니다.

2.2 Type

Type은 항상 영문 소문자로 작성합니다.

• feat : 새로운 기능 추가

• fix : 버그 수정

• docs : 문서의 수정

• style : UI를 추가/변경 하거나 스타일 관련 수정

• refactor : 코드를 리펙토링

• test : Test 관련한 코드의 추가, 수정

• chore : 기능/테스트, 문서, 스타일, 리팩토링 외에 배포, 빌드와 같이 프로젝트의 기타 작업들에 대해 추가/수정

✨ 3. Pull Request (Merge)

3.1 규칙

• main 브랜치로의 merge는 feature/\* 브랜치에 의해서만 가능합니다.

• merge시 merge가 되는 브랜치에서 pull을 먼저하고 충돌이 있다면 해결한 뒤 merge를 해야 합니다.

• merge는 github pull request에서 진행합니다.

✨ reference

• 좋은 git 커밋 메시지를 작성하기 위한 7가지 약

• ​Git Commit Message Style Guide

• https://github.com/ikaruce/git-style-guide/blob/master/README.md

• https://git-scm.com/book/ko/v2

• 연습 예제 : https://hankkuu.tistory.com/87

Git rebase & merge

Git - Rebase 하기git-scm.com

Git delete branch

✨ local

✨ remote

git push origin --delete {branch-name}

Git에 잘못 올라간 파일 삭제

✨ 원격 저장소에서 파일 삭제

git rm [File Name]
git rm --cached [File Name]

예시

git rm --cached .DS_Store
git rm --cached -r .idea/

✨ .gitignore 설정

gitignore.iotoptal

위 사이트를 참고하여 gitignore 설정

✨ 원격 저장소에 적용

git commit -m "chore : Delete .idea/"
git push origin main

✨ reference

• github에 잘못 올라간 파일 삭

Git add, git commit, git push 되돌리기

✨ git add 취소

파일 상태를 Unstage로 변경

git add *
git status
git reset HEAD [File Name]
git status

✨ git commit 취소

git log

// 방법 1 : 
// commit을 취소
// 해당 파일들은 staged 상태로 워킹 디렉터리에 보존
git reset --soft HEAD^

// 방법 2 : 
// commit을 취소
// 해당 파일들은 unstaged 상태로 워킹 디렉터리에 보존
git reset mixed HEAD^
git reset HEAD^
git reset HEAD~2 // 마지막 2개의 commit을 취소

// 방법 3
// commit을 취소
// 해당 파일들은 unstaged 상태로 워킹 디렉터리에서 삭제
git reset --hard HEAD^

✨ git commit message 변경

git commit --amend

✨ reset 옵션

• soft : index 보존(add한 상태, staged 상태), 워킹 디렉터리의 파일 보존. 즉 모두 보존.

• mixed : index 취소(add하기 전 상태, unstaged 상태), 워킹 디렉터리의 파일 보존 (기본 옵션)

• hard : index 취소(add하기 전 상태, unstaged 상태), 워킹 디렉터리의 파일 삭제. 즉 모두 취소.

워킹 디렉터리를 원격 저장소의 마지막 commit 상태로 되돌리고 싶은 경우

git reset --hard HEAD

✨ git push 취소

이 명령을 사용하면 자신의 local의 내용을 remote에 강제로 덮어쓰기를 하는 것이기 때문에 주의해야 함.

되돌아간 commit 이후의 모든 commit 정보가 사라지기 때문에 주의.

특히, 협업 프로젝트에서는 동기화 문제가 발생할 수 있으므로 팀원과 상의 후 진행하는 것이 좋음

1. 워킹 디렉터리에서 commit을 되돌림

// 1.1 : 
// 가장 최근의 commit을 취소하고 워킹 디렉터리 되돌림
git reset HEAD^

// 1.2 : 
// 원하는 시점으로 워킹 디렉터리 되돌림

// 1.2.1
git reflog 
// or
git log -g

//1.2.2
git reset HEAD@{number} 
// or
git reset [commit id]

1. 되돌려진 상태에서 다시 commmit

git commit -m "chore : Revert commit"

1. 원격 저장소에 강제로 push

git push origin [Branch Name] -f
// or
git push origin +[Branch Name]

✨ reference

• https://gmlwjd9405.github.io/2018/05/25/git-add-cancle.html

• https://ninano1109.tistory.com/3

Git commit 되돌리

[GitHub] git add, commit, push 취소/변경/덮어쓰기(reset, revert, --amend)velog.io

Git sub module

Git stash

Git remote repository 변경

Git fork and PR

Git 관계 없는 커밋 병합 거부

[Git/GitHub] fatal: 관계 없는 커밋 내역의 병합을 거부합니다

Git rebase

• https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-Rebase-%ED%95%98%EA%B8%B0

Git branch 전략

• https://tecoble.techcourse.co.kr/post/2021-07-15-git-branch/

Github repo 관리

• sub module

• sub tree

• 루트 프로젝트 내부에서 각각 git clone git clone

ref

• 서브모듈(Submodule)

• https://tecoble.techcourse.co.kr/post/2021-07-31-git-submodule/

Etc

✨ command line에서 메세지와 설명 같이 쓰기

git commit -m "Title" -m "Description ..........";

✨ github submodule 사용

✨ reference

• How to commit a change with both "message" and "description" from the command line? [duplicate]