repository 를 생성해서 이름을 정할때 마다 고민이 되어서 통일성 있게 하기 위해 정리

 

학습 용

prefix-[기술이름]-[옵션:추가 디테일 사항]

    • learn-   <ex> learn-typescript
      • 단순히 처음 배워보는 용도   
    • practice-    <ex> practice-nestjs-auth
      • 이미 배운 것을 실습해보는 용도
      • 이미 알고 있는 기술을 연습하거나 반복 적용
      • 개념을 학습한 후, 익히고 숙련하기 위해
  • explore-  <ex> explore-graphql 
    • 문서/공식 가이드를 따라가며 써보는 단계
    • 이거 뭔지는 아직 잘 모르는데 한번 써보는 중

프로젝트 용

개인 프로젝트

[프로젝트명] - [backend/ frontend] - [기술 프레임(express, nestjs,...)]

(ex) gymlog-backend-nestjs,  gymlog-be-nestjs 

 

학습 기반 구현 프로젝트 -  실무 예제를 따라 하거나 튜토리얼 기반으로 만든 것

 

clone-[대상 서비스 명] -[be/ fe/ full]

 

[강의 업체] - [프로젝트 명] - [기술]-[be/ fe/ full]

 

 

현재 브랜치에서

git fetch origin  # 최신 원격 정보 가져오기
git show origin/develop:README.md > README.md # 특정 파일만 가져오기

git pull # 전체 변경사항을 로컬 브랜치에 병합

1. 레포지토리 clone

git clone "레포지토리 주소"

 

2. 원격에 있는 모든 브랜치 확인하기

git branch -r

 

3. 모든 브랜치 가져오기 (로컬에 생성)

git fetch --all

 

- 특정 브랜치만 가져오기

git fetch origin 가져올-브랜치명

 

4. 각 브랜치를 로컬에 체크아웃하기

git checkout -b 브랜치명 origin/브랜치명

 

 

(예시)

$ git checkout -b develope origin/develope                                      
branch 'develope' set up to track 'origin/develope'.
Switched to a new branch 'develope'

 

이제 로컬 브랜치 develope가 원격 브랜치 origin/develope와 연결되었다

 

이젠 main 에서 develope 브랜치로 이동하려면 아래만 입력하면된다.

git checkout develope

 

1. Github 에 로그인 한다.

2. 수정이 필요한 repository에 들어간다

3. Pull Requests 메뉴에 들어가서 잘못된 PR의  github의 주소를 확인

    예시) https://github.com/계정이름/레포지토리-이름/pull/8

4.  깃허브에 문의를 한다. 

    https://support.github.com/request

5. Remove data from a repository I own or control( https://support.github.com/request/remove-data )로 접속

6. Remove pull requests 클릭

7. 3 번에서 복사한 삭제할 pull request 주소를 입력하여 티켓을 생성

 

완전히 삭제되면 메일로 알람이 온다.

 

다음으로 할일은 잘 못 합쳐진 내용을 복구하기

만약에 develope 에 pr 해야할 것을 main 으로 하였다면

1. 로컬에서 main 으로 이동 git pull origin main 으로 동기화

2. git log 를 입력하여 커밋된 내용을 확인해서 PR 되기 바로 이전의 commit id 를 확인

3. git reset --hard  <commit id> 를 이용하여 바로 이전으로 되돌리기

4. git push origin main -f 를 이용하여 강제로 이전의 내용으로 덮어씌우기

 

너무 복잡해진다. pull request 를 할때 대상을 잘 지정하였는지 꼭 확인하자.

  • feat :  새로운 기능(feature) 추가
  • fix : 버그 수정
  • perf :  성능향상을 위한 코드 변경
  • refactor :  버그를 수정하지도 않고 새로운 기능을 추가하지도 않은 코드 변경  혹은 파일의 위치 변경/ 리팩토링
  • style :  코드 변경없이 여백, 들여쓰기 철자등을 수정,
  • test : test를 하기 위한 코드를 수정밑 추가
  • docs : 문서만 수정
  • chore :  코드 변경없이 설정을 변경(package.json, tsconfig.ts, 빌드 스크립트 수정 등등) 

Entity 관계를 수정했을 때?

- refactor: 엔티티 관계의 수정이 기존 기능에 영향을 주지 않으면서 코드의 설계나 내부 구조를 개선하기 위한 목적인 경우

- feat : 엔티티의 관계를 수정하는 것이 새로운 기능을 추가하거나 기존 기능의 동작 방식을 변경하는 경우

 

참고 자료

 

Conventional Commits

A specification for adding human and machine readable meaning to commit messages

www.conventionalcommits.org

 

 

angular/CONTRIBUTING.md at 22b96b96902e1a42ee8c5e807720424abad3082a · angular/angular

Deliver web apps with confidence 🚀. Contribute to angular/angular development by creating an account on GitHub.

github.com

 

 

[Git/Github] Commit Convention이란?

커밋 컨벤션에 대해 알아보자

kdjun97.github.io

 

+ Recent posts