In수

Music GIF

Github - 002 - 2024년12월16일


Merge Conflict 해결방법

  1. Solve Merge Conflict [ 일반적인 상황에서 사용 ] -> Merge 상황에서 해결
  2. Solve Merge Conflict [ 특수한 상황에서 사용 ] -> rebase 방법으로 해결

Branch Models

  • git flow

    가장 전통적이고 많이쓰이는 모델
    각 단계가 명확히 구분되어 배포주기가 주기적인 서비스에 유리. 하지만 복잡

  • github flow

    브랜치 모델의 단순화.
    CI 의존성이 높고, pull request가 없으면 실수에 대처가 힘듬

$ git branch feature/{새로운 branch 이름}
$ git switch feature/{새로운 branch 이름}
$ vi {파일명.확장자} # 여기서 main branch 와 다르게 수정
$ git add {파일명.확장자}
$ git commit
$ git push -u origin feature/refactor-fb # u : 새로운 branch에서 push 할 때 한번만 사용하면 OK

# 깃허브 리퍼지스토리에 들어가기
# Pull requests에 접속 -> Create pull request
# feature/{새로운 branch 이름} 선택
# Create pull request 선택 후 title, description 잘 짓기 (+ Assignees(담당자) 선택) -> Create pull request
# Merge pull request 선택 -> Confirm merge

# 작업이 다 끝났으므로
# 왼쪽 위 main 클릭 -> View all branches 클릭 -> feature/{새로운 branch 이름} 삭제

# git bash에 돌아와서
# feature/{새로운 branch 이름} 삭제
$ git branch -D feature/{새로운 branch 이름}

# github cloud에 있는 최종 데이터를 로컬에 받기
$ git pull origin main
  • gitlab flow

    deploy, issue에 대응을 하기 쉽도록 한 모델

stash

작업중인 변경사항 잠시 미뤄두기 [ 새로운 branch 에서 사용 ]

$ git stash
$ git stash list     # stash 목록 보기
$ git stash pop {번호} # stash 다시 불러오기 {번호}는 특정한 stash 불러올 때만

undo

변경사항 취소하기

$ git restore {파일명.파일확장자}

Unstaging

Stage의 변경사항(blob) Working Directory로 내리기

$ git add {파일명.파일확장자}
$ git reset HEAD {파일명.파일확장자}    # HEAD : 마지막의, 최신의

Edit commit message

직전 commit message 수정하기 git add -> commit ->

$ git commit --amend

Revert commit

잘못을 인정하고 특정시점으로 되돌리기 git add -> commit 인 상황에서

$ git revert --no-commit HEAD~{되돌리고 싶은 commit 숫자}..
$ git status   # 삭제 이력 나와있음
$ git commit    # 왜 사용했는지 이유를 적어야 함

Issue

github 프로젝트의 다양한 이슈를 관리하기 위한 기능
할 일, 버그, 질문 등을 관리하기 위함
Label, 상태 관리 등의 업데이트가 잘 이루어져야 원할한 작업 가능
template 존재[ 깃허브 repotory -> settings -> issue template ]
Issue Labels

Issue의 상태와 종류, 긴급도 등을 표시하기 위함
Milestone : 작성된 Issue가 프로젝트의 어떤 주기에서 해결되어야 하는지를 표기
Milestone 작성을 통해 해당 Sprint의 달성률과 남은 Issue 파악이 쉬워짐

Projects

github에서 repo issue 기반의 task management
Scrum board와 table의 방식 존재.
팀의 Admin만 관리 가능(관리자가 관리하는 것이 맞음!!)
commit, pull request 등을 통해 자동으로 움직이도록 관리할 수 있음

Wiki

repository에서 README.md 에서 더 자세히 설명할 부분이 있을 경우 작성
따로 사이트를 만들지 않더라도 해당 프로젝트에 대한 FAQ, Docs 처리 가능
프로젝트 중 문서화가 필요한 모든 것들을 담아놓는 공간
Daily Scrum, Sprint Retrospection(Liked, Learned, Lacked), Code Convention, Technical Issues

pull request [깃허브 상에서]

명령어 지원
close, resolve, fix(복수형, 과거형) ex. resolve #1

팀 Project REMOTE 과정[main branch 에서 실행]

$ git remote -v    # remote 확인보기
$ git remote add upstream {팀 repository 주소}   # 관습적으로 팀 이름은 upstream 이라고 부름
$ git fetch upstream main   # FETCH_HEAD 라는 공간에 쌓임
$ git merge FETCH_HEAD
$ git push origin main

해야할 것!

직접 프로젝트를 생성하고 협업하는 과정을 처음부터 끝까지 해보기!