git & github
텍스트 파일 하나 있는데 여러 사람이 수정하거나 추가하거나 삭제하면 여러 파일 추가 되거나 삭제됩니다. 시간이 지나면 엄청 많은 파일이 생기거나 삭제 되면서 관리하기가 힘들어지고 많은 파일과 폴더로 인해 생각하기도 싫은 일이 벌어집니다.
이를 위해 필요한 것이 Git 입니다.
git
git install
텍스트 파일이 하나 존재하는데 이 텍스트 파일에서 수정하거나 추가를 한 후 저장을 하면 저장을 할 때마다 기록 해야 하는가?
이를 위해 규칙이 존재합니다.
규칙 1
"수정"의 단계는 "의미"를 기준으로
commit
이 파일의 수정이 끝났다
"이 파일의 의미있는 수준의 수정 작업이 끝났음"이라고 git에게 알려주는 일
위 이미지처럼 텍스트의 내용을 수정하고 커밋을 한후에 커밋에 대한 내용을 간단히 기록할 수 있습니다.
규칙 2
하나의 커밋은 여러개의 파일이 포함될 수 있다.
"수정의 의미"를 확장하자
하나의 파일을 수정하는 것,
하나의 수정 작업이 여러 파일에 영향을 줄 수 있는 것. 의미라는 관점에선 하나의 수정이라고 할 수 있다.
커밋은 수정의 단위. 수정은 여러 파일에 걸친 변경 내역의 묶음일 수 있다.
규칙 3
파일을 수정하지 않고 새로운 파일 내용을 만들고 싶을 때는?
상태를 저장하는 공간 branch
상태란 모든것이다. 파일, 파일의 내용, 커밋 정보등을 관리하는 모든 것을 의미한다.
git을 시작!
git init추적하고자 하는 내용을 위한 준비
선택된 폴더의 내용을 추적하기 위해 git 저장소를 만든다. 저장소가 만들어지면 git은 지정한 폴더를 포함하여 하위 폴더의 모든 변경 내용을 커밋 단위로 추적한다.
git init 이라는 명령어를 통해 .git 파일을 생성
git bash를 통해 git init 명령어를 하기 전과 후의 차이는
main이라는 브런치가 생성
git의 시작
지정한 폴더의 변경 내용을 추적하기 위한 준비
init 명령으로 저장소가 만들어질 때 git은 main이라는 이름의 브랜치를 기본으로 생성하고 이후 커밋 내용을 브랜치 기준으로 저장한다.
지금 현재 브런치는 MAIN이다
github 원격 저장소 연결하기
원격 저장소를 생성하여 이미지처럼 원격 저장소를 복사하여 아래 명령어를 통해 원격 저장소에 연결해주자
git remote add origin 원격 저장소 주소원격 저장소로 로컬 저장소에 있는 내용 보내기
git add . //수정된 전체 파일에 대한 내용을 commit 하기전 상태로 만들겠다.
git commit -m "커밋 내용 "
git push origin main
위 명령어들을 통해 원격 저장소에 수정한 내용을 push 한다.
이제 여기서 새로운 브런치를 생성하고 브런치로 가보자
git checkout -b test
test 브런치에서 console.log(45);로 수정하고 다시 main 브런치로 돌아가보자.
다른 브런치로 넘어가기 위해서는 커밋을 한후 넘어 가야한다.
git add.
git commit -m " 메시지"위 명령어를 통해 커밋 메시지를 작성하고 main으로 다시 넘어가보자
브런치마다 파일에 대한 값이 다른걸 알 수 있다. 그렇다면 다른 브런치에 있는 내용을 합칠려면 어떻게 해야 하는가?
git merge main이 아닌 새로 만들어진 브런치합쳐져야 할 기준이 되는 브런치에서 합쳐야할 브런치의 명령어를 사용하여 합칠 수 있다.
git merge test나의 경우에는 main브런치에 test 브런치의 값을 합칠 것이기 때문에 main 브런치에서 test 브런치의 값을 가져오자.
❗중요
merge 하는 과정에서 병합 출동이 일어날 수 있다. 이 경우에는 git에서 충돌난 부분을 해결하여 merge 계속 이어나가도록 하고 있다. 충돌의 경우 여러 파일들을 수정하고 중간에서 충돌이 나면 그 이후에 단계에는 진행되지 않고 멈추기 때문에 충돌을 해결한 후에는 git merge --continue
명령어를 통해 이 다음 병합을 진행할 수 있다.
위와 같은 이미지로 병합 충돌이 일어나는데 코드 수가 적으면 한눈에 고치기 쉬울 수 있지만 코드가 몇백줄이 된다면 병합 충돌을 해결하기에는 많은 시간이 필요 할것이다.
vsc에서는 이러한 병합 충돌에 대해 비교적 쉽게 해결할 수 있도록 제공하는 것이 있는데
resolve merge edtior를 통해 비교적 쉽게 해결 할 수 있도록 도와준다.
위 이미지처럼 나오는데 아래 쪽에 위치한 문단이 최종 병합 충돌을 해결하는 곳으로 생각하고 병합 충돌을 해결하고 complete merge 버튼을 통해 최종 수정을 할 수 있다.
Accept All Changes from Left를 클릭하면 왼쪽에 존재하는 내용이 아래쪽 문단으로 그대로 복사되어 넘어가는 것을 확인할 수 있다.
그리고 브런치 삭제 명령어는
git branch -d 삭제할브런치명❗ 원격 저장소와 로컬 저장소에 상태가 다르다면 원격 저장소에 내용을 로컬 저장소로 무조건 가져온 후에 작업을 하는 것이 좋습니다. 저의 경우에는 무조건 수정하기전에 git pull origin 루트 브런치 에 대한 명령어를 시작한 후에 브런치를 새로 생성하거나 작업을 시작합니다.
예를 들어 main 브런치에서 원격 저장소와 로컬 저장소에 상태가 다르다고 가정한다면 git pull origin main 명령어를 시작한 후에 git chekcout -b 생성할 브런치명 으로 시작하는 편입니다.
마지막 git rebase
git rebase의 경우에는 merge와 반대로 병합해야할 기준이 아닌 병합을 할 브런치에서 rebase 명령어를 사용해야 합니다.
예를 들어 test 브런치에서 main에 rebase 해야할 경우 test 브런치에서
git rebase main위 명령어처럼 사용하여 rebase를 진행해야합니다.
fast-Forward
병합 방식 중 하나로, 브랜치 간에 공통 커밋이 있을 때 발생합니다. Fast-Forward 병합은 별도의 추가 커밋을 생성하지 않고, 브랜치의 HEAD를 병합 대상 브랜치로 단순히 이동시키는 방식입니다
Fast-Forward 병합은 두 브랜치 간에 변경 내용이 충돌하지 않을 때 사용됩니다.
커밋 히스토리를 직선형으로 유지하면서 병합 커밋 없이 간단하게 진행됩니다.
히스토리 보존을 위해 --no-ff 옵션을 사용할 수 있습니다.
후기
Git과 GitHub은 다양한 협업 프로젝트에서 필수적인 도구로, 프로젝트를 성공적으로 협업하기 위해 반드시 알아야 한다고 생각합니다. 이번 수업을 통해 Git과 GitHub에 대해 다시 복습할 기회를 가졌고, 특히 협업 사이드 프로젝트에서 주로 merge를 사용해 작업을 진행했었습니다. 이번에 rebase를 새롭게 배우면서, 왜 rebase가 필요한지, 그리고 어떤 상황에서 사용하는 것이 적절한지 알게 되어 매우 유익한 경험이었습니다.
