Git, Github 정리

 

참고한 자료

제대로 파는 Git & GitHub (무료 파트)

제대로 파는 Git & GitHub (무료 파트)

개요

우선 Git이란 소스코드 관리를 위한 관리 도구이며 개발자들끼리 수정 , 복구 , 기록 , 저장 뿐만 아니라 협업을 위한 여러 기능들을 제공하고 이를 통해 효율적으로 협업할 수 있게 해주는 하나의 도구(시스템)입니다. Git 뿐만 아니라 관리 도구는 여러가지 다양한 것들이 있지만 굳이 git이 아니어도 되지만 (https://na27.tistory.com/211 SVN(Subversion) 사용하는 이유) 그럼에도 Git을 사용하는 이유는 분산 관리를 통해서 서버에 문제가 생겨도 클라이언트 쪽에서 쉽게 복구할 수 있게 되면서 많은 수의 개발자들이 참여할 수 있고 이렇게 됨으로써 작업하는데 매우 쉬워졌기 때문입니다. 뿐만 아니라 웹에서도 만들어놓은 소스들과 히스토리등을 확인하면서 작업할 수 있기 때문에 GIt을 사용하고 있습니다.

https://github.com/DefinitelyTyped/DefinitelyTyped

GitHub - DefinitelyTyped/DefinitelyTyped: The repository for high quality TypeScript type definitions.

(범용성을 위해 JS로 작성된 코드이지만 사람들이 TS에서도 사용하기 위해 여러 개발자들이 타입을 추가하고 그것을 올려놓은 저장공간)

 

이를 통해 우리는 효율적인 협업을 할 수 있습니다만 단점은 처음 사용하기엔 조금 어려워 헤멜 수 있기 때문에 이후 또 보기위해 추가로 수정하고 조금 더 명확하게 정리할 예정입니다.

• 기본적인 명령어들
  • commit
  • add
    • status
  • push
  • reset
  • revert
  • pull
  • clone
• 협업을 위해서
  • Branch
    • 기본적인 명령어
    • merge
    • rebase

 

1. commit

 

commit은 게임의 세이브에 해당하는 명령어라고 할 수 있습니다. 그렇기 때문에 우리가 commit을 해놓으면 언제든지 commit한 지점으로 되돌아갈 수 있게 됩니다.

굳이 복구하기 위해서가 아니더라도 코딩한 것들을 기록해두기 위해 commit은 필수적이고 이를 통해 복구와 서로 작업한 것들을 확인할 수 있다고 생각할 수 있습니다

Git Commit Message 규칙

Git Commit Message 규칙

 

https://jason-api.tistory.com/89

Git Commit Message 규칙

 

요약해보면 어떠한 작업을 수행했는지 확인하기 위해서 변경되고 추가된 모든 코드를 살펴보는 것은 매우 귀찮고 어려운 일이기 때문에 commitlint를 준수하여 로그를 확인하게 된다면 굳이 로그를 하나하나 확인해보지 않더라도 쉽게 이해할 수 있게 됩니다.

• build
• chore
• ci
• docs
• feat
• fix
• perf
• refactor
• revert
• style
• test

 

2. add

 

commit을 하기 전 파일을 먼저 하나의 commit 단위로 묶어야 하는데 Git 자체가 똑똑해서 수정되거나 추가된 파일들을 감지하게 됩니다. 여기서 git이 관리할 수 있게 add를 한다면 그 파일들을 하나의 commit 단위로 묶어주게 됩니다.

이 작업을 스테이지에 올린다라고 표현하기도 합니다

 

git add . → 변화가 있는 모든 파일들을 commit하기 위해 하나로 묶음

 

git status → git이 관리하고 있는 폴더 안에서 변경사항이 있는 것들을 보여줌( 새로 추가 되었거나(untracked..) , 수정되었거나 , 삭제되었거나 등등.. 나중에 add해서 파일을 올리면 다른 색깔로 보여주기 때문에 커밋단위를 확인하기 쉽습니다.

git commit -am “add와 동시에 commit" → 새로 추가한 파일이 없고 수정한 파일들만 있을 때

 

git log → 내가 지금까지 commit한 메시지들을 확인할 수 있습니다.

 

(참고) Vim

나중에 commit 메시지를 잘못 올렸을 때나 수정이 필요할 때 Vi입력모드로 진행되게 되는데 마우스가 안먹습니다. 따라서 나중을 위해 vi명령어를 인식하고 있을 필요가 있습니다.

 

보관 및 종료 명령어를 확인하면 됩니다.

 

vi /vim 편집기 명령어 정리 (단축키 모음 / 목록)

vi /vim 편집기 명령어 정리 (단축키 모음 / 목록)

 

push

 

 

원격저장소인 github(github 뿐만 아니라 gitlab 등등이 있음)에 업로드하는 것으로 이렇게 업로드를 하게 되면 다른 사람들과 공유할 수 도 있고 로컬에서 파일이 날라가도 복구할 수 있게 됩니다.

 

 

 

다시 복구하는 명령어

commit 단위로 작성된 파일들을 그때 commit 한 시점의 파일로 되돌리는 것으로 reset과 revert가 있습니다.

 

 

reset

 

원하는 시점으로 돌아간 뒤 이후 내역들을 지움

해당 시점으로 되돌리고 그 시점 이후에 commit 되었던 것들을 전부 삭제함(기록이 안남는다)

git reset --hard (돌아갈 커밋 해시)

돌아갈 커밋 해시는 git log 를 찍어보면 해시(문자열)가 있습니다

 

revert

 

되돌리기 원하는 시점의 커밋을 거꾸로 실행합니다.

 

revert를 통해서 뒤로 되돌리는 것처럼 보이지만 사실은 앞에 그 당시 파일을 커밋과 함께 추가함(기록이 남는다)

주로 revert를 사용함

 

git revert (되돌릴 커밋 해시)

이후 :wq로 커밋 메시지를 저장해야 원래대로 되돌아가면서 앞에는 커밋을 통해 하나의 커밋을 추가

 

git revert --no-commit (되돌릴 커밋 해시)

커밋없이 저장

 

 

pull

 

push가 원격저장소인 깃허브에 업로드하는 것이라면 pull은 반대의 동작을 합니다.

pull은 협업, 하나의 프로젝트를 진행하면서 원격저장소에 남들이 commit한 코드들을 가져와 변경사항들을 적용시키는 명령어입니다

pull 명령어는 원격 저장소의 소스를 가져오고 해당 소스가 현재 내 소스보다 더 최신 버전이라고 하면 지금의 버전을 해당 소스에 맞춰 올립니다. merge 명령어를 사용하는 것이지요. 하지만 fetch의 경우 단지 소스를 가져올 뿐 merge 하지는 않습니다.

git pull

pull 명령어는 원격저장소에서 fetch명령어로 가져온 후 merge까지 한번에 해 실제 파일의 내용이 변경되는 명령어입니다. 명령어는 git pull <원격 저장소 명> <branch 명>입니다.

[git] git을 이용한 버전관리 - 기본편 (remote, push, pull, fetch, clone) with github

[git] git을 이용한 버전관리 - 기본편 (remote, push, pull, fetch, clone) with github

나중에 push하려고 할 때 원격저장소에 이미 최신의 commit이 있다면 git에서 그것을 감지하여 pull을 먼저 해서 최신의 버전으로 push해야 한다는 에러메시지를 보여주게 됩니다.

 

이렇게 하는 이유는 단순히 push만 한다고 할 때 충돌 등 여러가지 문제들이 발생하기 때문이고 깃에서는 그러한 문제들이 발생했을 때 해결하는 기능들까지 제공하고 있습니다.

 

기본적인 git pull말고도 push할 것이 있을 때 pull하는 명령어는 두가지가 있는데

merge처럼 원격과 로컬이 합쳐지는 것을 확인할 수 있습니다

 

git pull --no-rebase

git pull --rebase

 

여기서의 rebase는 push와 다르기때문에 사용해도 상관없습니다.

 

Git branch

자주 사용할 거 같아서 따로 분리하여 정리하였습니다.

기본적인 명령어

branch 

• 프로젝트를 하나 이상의 모습으로 관리해야할 때 ( 실배포용 , 테스트 서버용)
• 여러 작업들이 각각 독립되어 진행될 때 ( 신기능 1, 신기능 2, 코드개선 , 긴급수정)

각각의 branch에서 작업한 뒤 확정된 부분을 메인 brach에 통합..

이러한 것들을 branch를 사용한다면 처음에 만들어둔 하나의 프로젝트 폴더 내에서 진행할 수 있게 해줍니다

 

git branch 브랜치명 → 브랜치 생성

git branch → 현재 만들어진 브랜치 확인

git switch 브랜치명 → 해당 브랜치로 이동

github에서도 브랜치 확인 가능

 

 

 

merge, rebase

브랜치를 합치는 두가지 방법

 Merge

• 두개의 브랜치를 하나의 커밋을 통해 합침

main 브랜치로 이동해서 합치려하는 브랜치를 입력하면 됩니다.  git merge 브랜치명

이후 합쳐진 브랜치는 삭제하는게 좋습니다. git branch -d 브랜치명

 

rebase

 

브랜치 그대로 잘라서 이어붙이며 브랜치 기록이 남지 않습니다

 

merge때와는 반대로 rebase하려는 브랜치로 이동해서 main을 rebase를 시켜준다

 

git rebase main

 

이렇게 쓰면 메인에서 해당 브랜치로 이어붙는다.

rebase는 거의 안쓰인다고 합니다

이후 충돌이 발생할 수 있는데

git status 를 통해 충돌을 확인할 수 있습니다.

 

지금 바로 해결할 수 없다면

git rebase --abort git merge --abort 를 통해 rebase , merge를 중단하고

 

해결할 수 있다면 충돌난 부분을 수정하고 git add . 한 뒤 git merge --continue 하면 된다고 합니다.