개발공부 기록지

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

참고 자료

Git Flow

복잡한 프로젝트 관리를 위해 여러브랜치를 사용하는 전략이다.

장점 : 뚜렷한 브랜치 구조는 대규모 팀이나 프로젝트에 적합하고, 버전 관리와 출시가 용이하다.

단점 : 복잡하고 브랜치 관리가 어려울 수 있으며, 작은 프로젝트나 빠른 개발 사이클에는 비효율적일 수 있다.

GItHub Flow

단순화된 방식으로, main 브랜치 하나와 기능 브랜치들로 구성된다. 모든 변경사항은 main 으로 병합되기 전에 리뷰된다.

장점 : 단순하고 이해하기 쉬우며, 지속적인 배포와 통합에 적합하다.

단점 : 매우 크고 복잡한 시스템에서는 충분한 구조를 제공하지 않을 수 있다.

GitLab-flow

위의 두 전략의 장점을 결합하여 환경에 따라 코드를 배포하는 유연한 전략이다.

장점 : 유연하며 다양한 배포 환경에 적응할 수 있다. 코드 관리와 릴리스가 분리되어 있어 안정성을 높일 수 있다.

단점 : 설정과 관리가 복잡할 수 있으며, 전략을 완전히 이해하고 적용하기 위해서는 경험이 필요할 수 있다.

요약 및 정리

참고자료

1. https://wiki.yowu.dev/ko/dev/Git/about-git-github-gitlab-flow
2. https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5
3. https://blog.hwahae.co.kr/all/tech/9507

가장 최근에 Push 한 것을 취소

git reset HEAD^

원하는 워킹디렉토리로 돌아가기

// 커밋 아이디 확인
git relog

//돌아가고 싶은 커밋아이디 입력
git reset [commit id]