코딩공부

깃&깃허브 특강2

정해인3 2023. 5. 29. 20:12

소스트리를 이용해 버전관리를 하는 것은 비추 - 소스트리 자체의 신뢰성이 낮음

실무 - 명령어가 더 많이 쓰임

 

빨리감기 병합: 브랜치에서 만든 것을 마스터에 병합만

빨리감기 병합이 아닌 경우: 두 브랜치를 병합한 새로운 커밋이 생성된다.

 

충돌: 빈번, 같은 부분을 다르게 수정했을 때 

 

충돌한 경우의 파일 내용

HEAD와 === 사이의 내용: 현재 브랜치 내용

===와 foo 사이의 내용: foo 브랜치 내용 

 

충돌했을 경우: 

  1. 내가 남기고 싶은 내용만 남기고 지운다.
  2. 새로 커밋한다.

 

작업 되돌리기

만들어진 버전을 되돌리는 두 가지 방법 

  • revert: 버전을 되돌린 새로운 버전 만들기(지금까지 만든 버전들은 유지 / 메모리 사용량 늘어남)
  • reset: 버전을 완전히 되돌리기
    • soft
    • mixed
    • hard

하나의 버전이 만들어지는 과정 

  1. 작업디렉터리에서 변경사항 생성하기 (hard reset) - 작업을 했던 것도 삭제 
  2. 스테이지로 추가하기 (mixed reset) - git diff로 작업내용 볼 수 있음
  3. 저장소로 커밋하기 (soft reset) - git diff --staged로 작업내용을 볼 수 있음

 

- 작업 되돌리기 명령어 정리 - 

  • git reset
    • git reset --soft <되돌아갈 커밋> : <되돌아갈 커밋>으로 소프트 리셋하기
    • git reset --mixed <되돌아갈 커밋> / git reset <되돌아갈 커밋>: <되돌아갈 커밋> 으로 믹스드 리셋하기
    • git reset --hard <되돌아갈 커밋>: <되돌아갈 커밋>으로 하드 리셋하기 
  • git revert <취소할 커밋>: <취소할 커밋>이 취소된 새로운 커밋 만들기 

커밋 해시를 쓸 때 주의

revert를 하면서 충돌이 발생할 가능성이 있음, 충돌해결 방법은 모두 같음 

 

깃허브

  • 개발자의 sns: 포트폴리오 작성, 만든 코드에 대해 별을 달 수 있음, 코드리뷰 주고받음
  • 주소
    • https://github.com/계정명 
    • https://github.com/계정명/저장소이름: 소유한 원격저장소 
  • 원격 저장소 호스팅 서비스: 컴퓨터 속에만 있는 저장소(로컬 저장소)가 아닌 인터넷 세상 어딘가(원격)에 있는 다른 컴퓨터 속의 저장소 -> 백업과 협업을 위해 사용 
    • 깃허브 vs 구글 드라이브(네이버 마이박스/드롭박스): 업로드 대상이 다름 (깃헙-커밋, 버전 / 구글 드라이브등 - 완성본)

 

원격 저장소 만들기 - 깃헙 홈페이지 - +버튼 - new repogitory

원격 저장소와의 네가지 상호작용 

  • 클론(clone): 원격 저장소를 (로컬환경으로) 복제하기 - .git 숨김 폴더를 포함해 모든 폴더가 컴퓨터로 복제 됨 -> git init을 할 필요 없음 (모든 원격 저장소에는 .git 숨김 폴더가 숨겨져 있음) 
    • 방법: 깃허브 원격저장소 페이지에서 <>code 초록색 버튼 -> ssh -> 경로 복사 -> git bash의 원하는 위치(폴더)에 git clone <복사한 경로> 입력 
    • 원격 저장소 브랜치 이름
      • main 브랜치 == master 브랜치
      • origin == 원격저장소에 붙은 일종의 별명
      • origin/HEAD == 원격저장소 origin의 HEAD
      • origin/main == 원격저장소 origin의 main 
        • 로컬저장소의 HEAD/main과 원격저장소의 HEAD/main이 다를 수 있기 때문에 별도로 지칭 
  • 푸시(push): 원격 저장소에 로컬저장소의 변경사항을 밀어넣기
    • 원격저장소 페이지 -> ssh 선택 -> push 명령어 복사/붙여넣기 
      • 첫번째 명령어:  로컬 저장소가 원격 저장소의 주소를 알아야 서로 상호작용할 수 있음 -> git remote (-v)로 확인 (origin) 
      • 두번째 명령어: 현재 브랜치 이름을 main으로 변경 
      • 세번째 명령어: 실질적으로 푸시하는 명령어 
  • 패치(fetch): 원격 저장소의 변경 사항을 일단 가져만 오기 (변경사항을 가져오되 병합하진 않는 방식) 
    • git fetch origin main: origin에 있는 내용을 main 브랜치로 패치해 올 것
    • git checkout FETCH_HEAD: 여기서 패치한 내용을 볼 수 있음
    • git merge FETCH_HEAD: FETCH_HEAD의 내용을 병합 
  • 풀(pull): 원격 저장소를 가져와서 합치기(패치와 병합을 동시에 하는 방식) (충돌할 가능성 있음)
    • git pull origin main: origin의 변경사항을 main에 가져와서 병합  

 

푸시 첫번째 명령어

git remote add origin <레포지토리 주소>

푸시 두번째 명령어

git branch -M main

푸시 세번째 명령어

git push -u origin main

 

git remote -v: 원격저장소의 이름과 경로를 함께 확인 

 

레포지토리: 버전이 관리되고 저장되는 공간, 프로젝트를 레포지토리에 업로드

 

 

깃허브를 통한 실무에서의 협업 - 풀 리퀘스트 실습하기 

내가 소유하지 않은 원격 저장소에 푸시하는 것 - 일반적으로는 불가능 (소유자가 collaborator로 추가하면 가능)

누구에게나 권한을 주면 - 수정, 삭제 과정에서 혼란이 발생할 수 있음

-> 풀 리퀘스트 사용 - 원격 저장소가 내 변경사항을 풀 하도록 요청사항을 보내는 것

풀리퀘스트를 보내면 권한이 있는 사람이 검토하고 반영할 지 결정

실무에서 풀 리퀘스트 자체가 코드 논의의 장이 됨 

풀 리퀘스트를 이용하면 기록이 남음 -> 포트폴리오에 유용(코드 논의가 깃허브 상에서 이루어졌는가)

<과정>

  1. 기여하려는 저장소를 본인 계정으로 포크(특정 원격 저장소를 내 계정으로 복제)하기
  2. 포크한 저장소를 클론하기(포크한 저장소만 푸시할 수 있기 때문) (포크한 저장소는 몇 커밋이 뒤쳐져 있을 수 있음 -> sync fork 사용해서 맞춰줌) 
  3. 브랜치 생성 후 생성한 브랜치에서 작업하기
  4. 작업한 브랜치 푸시하기 (foo브랜치에서 작업했다면 git push origin foo입력)
  5. 풀 리퀘스트 보내기 

mian/master 브랜치 - 기준점, 기둥 같은 역할 -> 무언가를 바꾸고 싶다면 브랜치를 생성해서 바꾸는 것이 좋음