Github 정복하기

LeeWlWL·2024년 4월 15일
공부

기타

목록 보기
1/3

Github

깃헙 : 자신의 코드를 남기고 싶을 때 혹은 여러명이서 협력을 할 때

깃 처음 까면 git config user.email "io0818@postech.ac.kr", git config user.name "wiwlee"

기본적인 관리 흐름 = master

image-20240131163521164

보통은 git add .으로 스테이지에 전부 올리고 stage에 올리고 싶지 않은 것은 gitignore에 넣는식임. (구글링 하셈)

커밋으로 그 상태를 스냅샷으로 남김 => git commit -m "한줄" or git commit 해서 insert해서 긴 줄 넣어서 저장할 수 있음

git log로 뭘뭘 커밋했는지 볼 수 있고, git log --oneline으로 커밋 내용들을 다 한줄씩으로 볼 수 있음

image-20240131172644131

git branch -M main : 원래 master 였던 원격 브랜치가 main으로 바뀜 => git push origin main (origin-main 원격의 main branch에 푸쉬하겠다.)

origin : 원격 레포지토리 이름

git remote add origin 주소 : 이 레포지토리를 Origin으로 부를꺼고 원격 저장소로 관리할 것이다

(git push -u origin master 명령어는 origin이라는 원격 저장소(설정한 주소)에 master 브랜치를 푸시하면서 동시에 추적(tracking) 브랜치로 설정하는 것입니다. -u 옵션은 --set-upstream의 축약형이며, 이 옵션을 사용하면 해당 브랜치에 대한 추적 정보가 저장되어 이후에 git push 또는 git pull 명령을 실행할 때 브랜치 이름을 명시하지 않아도 됩니다.)

git clone = 그냥 통째로 가져오기, git pull : 내꺼 + 남의꺼, 수정된거 가져오기, 누가 수정했으면 ~~modified 쭉 뜸

브랜치 : 코드의 여러 갈래 (보통 master(최종), release(버전), develop(개발), feature(기능))

  • master 브랜치는 매우 안정된, 언제든 배포 가능한, 브랜치입니다. 이 브랜치로 직접 작업(커밋)하지 않고 다른 브랜치(develop, release 등)에서 작업하고 머지하는 형태로 됩니다. 실무에서도 오픈소스에서도 master 브랜치는 그렇게 관리됩니다.
  • 즉, feature에서 기능을 만들어! feature/wing 이렇게 => 그다음 그것들을 합쳐서 develop/bird 이렇게 합치고 => 이것들을 합쳐서 release/1.2.0 이렇게 1.2.0 배포 버전에 필요한 내용들만 합침 => 그다음 master 브랜치에 합치게 됩니다. master에 머지된 이후에는 release/1.2.0 브랜치는 삭제합니다.
  • 요약하자면 release 브랜치는 develop에서 따져서 master로 합쳐지고, 특정 버전의 배포를 위한 임시 작업 브랜치로 보시면 됩니다.
image-20240131173738664

git merge branch B : 지금 내가 있는 브랜치 A에서 B 브랜치를 병합한다.

fast-forward 뜨면 conflict 없이 잘 된거

보통은 git이 잘 머지해줌. 근데 같은 코드의 다른 부분을 수정한 경우에는 conflict 발생함. => 수동밖에 방법이 없음

conflict 예시

  • image-20240131174731759
  • head branch (지금 보고 있는 브랜치)꺼 <<<~====랑 new branch(병합한거랑) Conflict가 났다
  • image-20240131174901564
  • 예를 들어 두개 다 남기고싶은거면 그냥 <<< === 다 없애고 깃 애드 커밋 해주면 된다
  • 이렇게 해결해주고 커밋하면 걍 git commit 만 해주면 알아서 로그 만들어주니까 :wq해주면댐

git tag, git diff, git reset, git statsh, git cherry-pick

  • checkout 시에 이렇게 commit ID로 이동도 가능함 (시간이동)

    • ** git log --oneline을 애용하자. 시간이동에 좋은 기능인듯
    image-20240131175137818

  • git tag "ver0.1" 이렇게 하고 git tag 하면 어느 시점의 브랜치에 태그가 붙어있는지 알 수 있음 => git checkout ver0.1 이렇게 가능

  • git diff (브랜치이름, 태그이름, 커밋아이디 등) => 현재 브랜치와 차이점을 알려줘

image-20240131175650922
  • git reset 0.1 이런식으로 망한 코드 버리고 돌아갈 수 있음 (이 사이에 --hard, --soft, --mixed 있는데)
    • hard = 아예 그 코드를 작성한 기억 조차 없어짐. 로그에도 없음. 위험하기도 함
    • soft = 커밋 만 없어짐. 스테이징은 되어 있음
    • mixed = add 직전으로 돌아감. 스테이징도 안되어있음
  • 근데 협업할 때에는 reset 해버릴 수 없음. 즉, 서버에 올라간걸 push된걸 reset 할 수가 없음
    • git revert가 필요함. 특히 협업시에 (push 안했을 시에는 reset 쓰자)
    • 왜냐면 정상적인 것들 사이에 오류가 있는데, 오류 뒤에 있는게 다 날라가는거니까. 정상적인 것도 날라가는거지 (내작업어디갔어)
    • git revert (지우고싶은커밋)
      • image-20240131222857487
      • 하면 이렇게 표시가 뜨고, 우리는 판단을 못하겠으니까 뭘 지우고 싶은지 니가 골라라 뜸!
      • 마찬가지로 수정해주고 "solve" 커밋해주면 됨
      • 단, 이 Revert도 log에 남음. 로그 자체를 지울 수는 없음. 과거를 인정하고 변화시키는것
  • git 커밋 안하고 체크아웃 하면 수정 저장하라고 안되는데, 이걸 git stash를 통해서 임시 저장 가능함 (푸는 것도 있는데 알아서 ㄱ)
  • git log 정리하고 싶을 때 => git cherry-pick (알아서 공부)
  • image-20240131175951959
  • 커밋은 노드고 브랜치이름은 포인터임
  • HEAD도 포인터임 = 현재 유저가 보고 있는 포인터. checkout을 하면 이 HEAD포인터가 이동하는거
  • tag도 포인터임
  • 그래서 checkout ( ) 뭘 해도 상관없는거 다 포인터라서
  • reachable 하지 못하는 노드도 생길 수가 있는데, 이건 아라서 garbage collecting 깃이 해준다고함
image-20240131180254136

git workflow

  • git으로 프로젝트하는법
  • image-20240131223117309
  • 각각의 줄은 브랜치. 이 회사에서 사용하는 브랜치명
    • tag를 붙여놧음
    • main = release
    • hotfix = 긴급수정 브랜치 -> 메인으로 머지함.
    • 개발은 devleop에서 진행함. 이 develop에 feature를 만들고 머지하는 역할만함!! feature에서 따로 개발하지 않음
      • ex) feature = 맞춤법 검사 등
    • Develop 에서 머지한거를 적절히 배포할 상태이면 main에 머지함
    • 이렇게 워크플로우 쭉 가져감
  • source tree를 통해서 워크 플로우 볼 수 있음
    • git log를 분석해서 그래프 그려주는 프로그램 있음
    • repository 추가, add, 탐색해서 불러오면댐
    • image-20240131224445307
    • 그래프도 정확하지 않을 순 있음. 예를 들어 병합된 develop, banana가 같은 라인인것처럼 나오지 여긴.
    • 이 깃 그래프를 통해서 워크플로우를 잘 알 수 있음
    • 이런 그래프를 깔끔하게 해서 진행하는게 개발에 더 좋음. 팀원끼리 브랜치 상의해서 룰 정하면 됨

깃을 사용하면서 마주하는 두려운 상황들

image-20240131224628210
  • (1) git commit --amend 를 통해서 커밋 메세지만 변경할 수 있다 **단, 푸쉬한건 건들이지 않는게 좋음
  • (2) git reflog 를 통해서 자신이 사용한 git 기록들을 볼 수 있음. => reference log => 삭제한 커밋도 볼 수 있음
  • (3) git branch test를 master기반으로 만들어서 거기에 develop 머지하면서 테스트해보자. 이후똑같이 마스터에 적용
  • (4) commit은 유의미할때만 하자!! 고 약속. 그래서 stash를 대신 사용하자
    • stash를 해놓으면 마지막으로 커밋한 상태로 돌아가고, 그 전 수정내용은 stash list의 어느 한 스태시에 저장되어있음
    • 다른 브랜치 갓다와서 다시 git stash apply stats@{} 해놓으면 됨!
    • image-20240131230339787
  • image-20240131230334594

  • 깃 엎어버리고 싶을 땐 그냥 지워버리고 git clone 다시 받자 마스터든 베이스든 뭐든

    • image-20240131230527868
  • 이외에도 기억하면 좋은 것들
  • <깃 사용법>
    Git clone url //이거 하면 폴더로 복사가 되는데,
    Git branch -r //원격 브랜치 볼 수 있고
    Git checkout 브랜치명 //원격에 있는 이름은 그거 불러오고, 없는 이름은 로컬 브랜치로서 불러와짐.
    GIt branch //여기서 불러온 원격 브랜치 or 로컬 브랜치 볼 수 있음
    단, 여기서 로컬 브랜치 생성했을 때 git push origin 로컬브랜치 하면 새로운 원격 브랜치가 생성되어서 반영됨!
    Git remote -v //연결된 원격 저장소 볼 수 있는데, 클론 하면 이미 주소 연결되있는거 볼 수 있음
    Git push origin 브랜치명 //원격 저장소의 한 브랜치에 푸쉬를 함
    다 알다시피 git add . / git commit -m “” / git push origin 브랜치명 으로 조작할 수 있음
    Git remote update //새로 원격 브랜치 만든걸 이미 만든 git 저장소에서 확인하고 싶을 때 업데이트
    Git branch -d (이름) //로컬 저장소 없애고 업데이트하면 업데이트된 브랜치 가져옴
    (clone은 병합 없이 그냥 폴더 외부에 씌워서 가져오는거고, pull은 병합하는거임. 가져오는 건 그냥 clone이 나을듯)
    —
profile
LeeWlWL
진화중이에요
다음 포스트

Node.js - MongoDB 연동 [] 해결법

0개의 댓글