[SISS/C언어 스터디] 겨울학기 2주차 스터디 - Git + GitHub(2)

겨울학기 2주차 스터디 - Git + GitHub(2)

: 2주차 (1/13~1/19) [Git&GitHub강의] 섹션1. branch / fork와 pull request / 그 외 명령어

 

branch

---

• 관련된 기능 단위로 작업할 수 있도록 작업 공간을 나눔 → merge를 통해 완성된 후 통합
• 기본 브랜치
  • main(깃에서는 master로 표기)
• 기능
  • 브랜치 생성 및 이동
    • checkout → switch, restore(기능 분리)
      • switch → 브랜치 이동
      • restore → 파일 수정 내용 복원, add로 스테이지에 올린 파일 내리기
  • 브랜치 복구
    • reflog → 모든 참조 목록 확인
  • 브랜치 병합
    • merge
      • push 필요
  • 충돌 시
    • 수정 필요

 

• 브랜치 실습

// 현재 브랜치 확인
$ git branch

// 원격 저장소의 내용을 클론
$ git clone 원격저장소주소 .

// 새 브랜치 만들기
$ git branch 브랜치명

// 브랜치 이동
$ git checkout 이동할브랜치명

// 브랜치 삭제
$ git branch -d 삭제할브랜치명

// 참고 명령
// git clone 전 디렉토리가 비어있어야 하므로 기존 git 정보(ls로 보이지 않음) 삭제를 위해 rm -rf .git을 입력했음
$ rm -rf ./*
$ rm -rf ./.git

// 깃 재연결, 연결 확인
$ git remote add origin 원격저장소주소
$ git remote -v

브랜치 확인

새 레포지토리(branchtest) 생성 후 클론

세 번의 리드미 수정(1차)

세 번의 리드미 수정(2차)

세 번의 리드미 수정(3차)

리드미 수정 후 깃허브 확인

첫 번째 브랜치(newtest) 생성

두 번째 브랜치(newtest2) 생성

깃허브에서 브랜치 확인

 

• restore 실습

// 수정 이전으로 복구
$ git restore 복구할파일명

// 스테이지에서 내리기 (reset을 이용해서도 가능)
$ git restore --staged 내릴파일명

새 파일(restoreTest.txt) 저장 후 add, commit까지 완료

파일 수정과 restore 결과

 

• merge 실습

// main에 브랜치를 merge
$ git merge 병합할브랜치명

// 적용을 위해 push 필요
$ git push origin main

newtest2를 main에 병합

newtest를 main에 병합

 

• merge 충돌 실습
  • 새 레포지토리(conflicttest) 생성 후 각각의 브랜치에서 동일한 영역(README.md)을 작업

브랜치 1(sion)

브랜치 2(yushi)

브랜치 2를 main에 병합

브랜치 1을 main에 병합(README.md에서 충돌 발생 → yushi를 남김)

 

• 삭제한 브랜치 복구

// 모든 참조 목록 확인 (커밋 해시값 확인을 위해)
$ git reflog

// 복구
$ git checkout -b 삭제브랜치명 커밋해시값

 

fork와 pull request

---

• fork
  • 특징
    • 제 3자가 저장소를 복사하여 사용
    • 추후 원본 저장소에 pull request를 통해 merge 가능
    • fork 이후의 원본 저장소 수정 사항은 반영되지 않음 → git remote add로 원본 저장소의 주소를 추가해야함
  • 방법 → 페이지의 Fork 버튼 누르기(나의 프로젝트처럼 수정 가능)

fork 버튼 확인

 

• pull request(PR)
  • 특징
    • fork한 내용의 원본 저장소 merge를 소유자에게 요청
    • 상대가 수정 내용 확인 및 코드 리뷰를 할 수 있다는 장점
      • 수정 필요 시 change request를 보낼 수 있음
    • 취소는 가능하지만 취소 내역이 남음(직접 삭제 불가)
  • 방법
    • fork한 문서 > contribute > open pull request > create pull request를 통해 실행 가능
    • pull request에서 close pull request를 통해 취소할 수 있음
    • 전체 확인은 pull requests에서 할 수 있음

contribute 버튼 확인

 

그 외 명령어

---

•  amend
  • 기존 커밋에 파일 추가
    • 커밋이 기능 단위이므로 유용
  • ammend 후 커밋 메시지 수정 창(vi)이 생성됨

  // 커밋에 파일 추가
  $ git add .
  $ git commit --ammend
  

 

•  stash
  • 현 브랜치의 작업을 마무리하지 못한 상태로 다른 브랜치로 이동할 경우 현 브랜치 임시 저장
  • 여러 모드가 있음 → save, list, apply(--index), drop, …
  • 추적 가능 여부
    • tracked 파일을 stash → 수행 중 작업을 임시 저장한 후 가장 최근 커밋 상태로 돌아옴

      // 임시 저장
      $ git stash
      
      // 임시 저장 파일 복원하기
      $ git stash pop
      

    • untracked 파일을 stash → git이 관리하는 파일만 임시 저장하므로 --all 옵션을 붙여줘야 모두 저장 가능

      // git이 관리하지 않는 파일까지 임시 저장
      $ git stash --all
      

 

• reset
  • 이전 커밋으로 브랜치를 되돌림
  • 공동 작업 시 사용하지 말 것 → revert 사용
    • 돌아간 커밋 이후의 히스토리가 전부 사라짐 → 로컬의 커밋 히스토리와 원격의 커밋 히스토리가 달라 오류 발생
    • 로컬에만 커밋한 경우 사용
  • 자주 사용하는 모드
    • hard → 지정 커밋 이후 변경 사항을 전부 삭제
    • mixed → 지정 커밋 이후 변경 사항을 로컬에 unstaged 상태로 유지
    • soft → 지정 커밋 이후 변경 사항을 로컬에 staged 상태로 유지

  // 이전 커밋으로 되돌림
  // 커밋 아이디는 git log를 통해 확인 가능
  $ git reset 모드 커밋아이디
  

 

•  revert
  • reset과 비슷하나 push된 커밋 이력을 되돌릴 수 있음(또 하나의 커밋 히스토리)
  • 충돌이 발생하므로 선택해서 저장한 후 add, push

  // 커밋을 되돌리는 새로운 커밋 생성
  $ git revert 커밋아이디
  

 

•  cherry-pick
  • 원하는 커밋만 선택해 현재 브랜치로 가져오기
    • 브랜치 버그가 생긴 경우 → 수정 후 main에 merge
    • main에 당장 merge가 어려운 경우 → 버그 수정 커밋을 선택해 릴리즈 브랜치에 가져옴

  // main 브랜치에 원하는 커밋 가져오기
  $ git cherry-pick 커밋아이디