작업을 하다보면 예상치 못한 오류가 발생했을 때 이전에 정상적으로 작동했던 코드를 불러오고 싶은 마음이 있을 것이다.
여러 버전으로 나누어 이러한 정보들을 보관해두고 불러온다면 편리하게 사용할 수 있을 것이다.
이를 도와주는 버전 관리 시스템이 깃(Git)이다.
로컬에서 혼자 버전 관리를 한다면 깃 하나만으로도 충분하지만 대부분 다른 사람들과 협업을 하게 될 것이다.
그래서 외부 저장소에 버전 정보들을 보관하여 팀원들과 공유하도록 도와주는 깃 호스팅 사이트이다.
로컬 환경에서 깃을 사용하여 버전 관리 하는 방법과 깃허브에 올리는 방법에 대해서 알아보려고 한다.
비쥬얼 스튜디오 환경에서 코드를 작성할 예정이다.
우선 나는 c 드라이브 아래에 github 폴더를 만들어서 간단한 html 파일을 만들어 보았다.
내용을 바꿔가면서 버전을 저장하고 버전을 바꿔보는 실습을 진행해보려 한다.
진행에 앞서 깃 설정을 변경해줘야 한다. 아래와 같은 명령어를 입력한다.
git config --global init.defaultBranch main이 설정은 기본 브랜치를 master가 아닌 main으로 지정하기 위함이다.
과거에는 기본 브랜치로 깃과 깃허브 모두 master를 사용했는데 깃허브는 현재 기본 브랜치로 main을 사용 중이고
우선 터미널에서 git init 명령어를 사용하여 깃을 초기화한다.
숨김 폴더로 .git 폴더가 생성되었다. 해당 폴더에서 숨김 폴더를 확인해보면 .git 폴더를 확인할 수 있다.
이곳에 버전 정보들이 담기게 된다.
이제 깃허브 계정 정보를 입력해야 한다. 다음과 같이 깃허브 이메일과 이름을 작성한다.
그리고 커밋할 파일들을 staging area에 넣어야 한다.
원하는 파일들을 staging area에 넣어두고 "커밋"을 한다면 하나의 버전이 생성된다.
staging area에 넣는 방법은 git add practice.html와 같이 하나씩 넣는 방법도 있고 git add *와 같이 변경 사항이 있는 모든 파일을 한번에 넣는 방법이 있다.
css 파일과 js 파일을 추가하고 이 3 파일을 staging area에 올려보았다.
git status 명렁어를 입력하면 현재 staging area에 담겨있는 파일들을 볼 수 있다.
3 파일이 잘 담겼다.
이제 git commit 명령어를 사용하면 staging area에 존재하는 파일들로 새로운 버전을 만들게 된다.
-m을 붙이면 버전의 이름을 명시할 수 있다.
이제 html의 내용을 살짝 바꾸고 두 번째 버전을 생성한다.
이제 git log 명령어를 사용해서 커밋된 정보들을 확인할 수 있다.
여러 커밋과 각각의 커밋을 한 사람의 이름, 이메일 정보가 나타난다.
만약 버전 1에서는 잘되던게 버전 2에서 오류가 발생한다면 버전 1로 다시 되돌아갈 수 있다.
자세히보면 커밋마다 식별자가 존재한다. 해당 식별자를 사용하면 되는데 상당히 길기 때문에 앞 7글자만 사용해도 된다.
git checkout [식별자] 명령어를 사용한다. 버전 1의 경우 git checkout bcb204b 명령어를 사용하면 된다.
버전 1로 돌아온 모습을 확인할 수 있다.
다시 버전 2로 돌아가고 싶다면 git checkout - 명령어를 사용하면 된다.
이제 이를 깃허브에 올려야 한다.
우선 깃허브에 가입을 하고 새로운 Repository를 생성해준다.
원하는 이름을 정하고 나머지는 기본 설정으로 생성한다.
이제 해당 레포지토리의 주소를 복사한다.
이제 다시 로컬 환경의 터미널로 돌아와서 git remote add origin [저장소 주소]를 입력하여 외부 레포지토리와 연결한다.
git remote -v 명령어를 입력하면 현재 연결된 레포지토리를 확인할 수 있다.
연결을 끊고 싶다면 git remote remove origin 명령어를 사용하면 된다.
이제 우리가 생성한 커밋들을 올릴 차례이다. git push origin main 명령어를 사용한다.
이제 레포지토리를 확인해보면 main 브랜치에 커밋들이 제대로 들어온 것을 확인할 수 있다.
빨간색 사각형을 누르면 커밋들의 정보를 확인할 수 있다.
만약 다른 팀원이 새로운 버전을 커밋했고 이를 받고 싶다면 git pull origin main 명령어를 사용하면 된다.
staging area에 실수로 올린 파일 제외
git add 명령어로 staging ar ea에 파일을 올릴 때 실수로 다른 파일을 올릴 때가 있다.
이 때 git restore --staged 명령어를 사용하여 제외할 수 있다.
git restore --staged [제외할 파일 이름]
참고로 이 명령어를 사용할 때는 커밋이 하나라도 있어야 한다.
만약 커밋이 하나도 없다면 다음 에러가 발생한다.
fatal: could not resolve HEAD
현재 작업중인 HEAD를 찾을 수 없다는 뜻이다.
커밋이 최소 하나가 있는 상태에서 실수로 올린 github.css 파일을 staging area에서 제외해보자.
github.css가 성공적으로 제외되었고 깃에서 github.css가 변경은 되었지만 staging area에 존재하지 않는다는 메시지를 띄워준다.
명령어 정리
git config --global init.defaultBranch main : 깃은 기본 브랜치가 master로 설정되어있어서 main으로 바꿈
git init : 깃을 사용하기 위해 초기화
git confing --global user.email "email@gmail.com" : 내 이메일 입력 (커밋한 사람 식별)
git confing --global user.name "nickname" : 내 이름 입력 (커밋한 사람 식별)
git add * : 모든 변경사항을 staging area 올림
git status : staging area에 올라온 파일 확인
git commit -m "버전1" : staging area에 올라온 파일들을 커밋함. 커밋 이름도 정함.
git log : 커밋 아이디와 정보 확인 가능.
git checkout abcd1234 : git log로 확인한 커밋 아이디를 보고 해당 커밋으로 되돌아감.
git checkout - : 이전 커밋으로 되돌아감
git remote add origin [저장소 주소] : 외부 저장소와 연결
git remote remove origin : 연결되어있는 외부 젖아소 끊기
git remote -v : 현재 연결되어있는 외부 저장소 정보
git push origin main : main 브랜치에 커밋들을 푸쉬함
git pull origin main : main 브랜치의 추가된 커밋들을 바당옴
만약 깃의 구체적인 동작 원리에 대해 알고 싶다면 아래 포스팅을 참고하자.
'공부 > Git & GitHub' 카테고리의 다른 글
| [Git] git 비슷한 명령어 제대로 이해하기 (fetch/pull, checkout/switch, merge/rebase) (0) | 2024.08.19 |
|---|---|
| [Git&GitHub] 깃허브에 실수로 올린 코드 한 줄 삭제하기 (커밋 수정하기) (0) | 2023.05.20 |
| [Git&GitHub] 서로 다른 브랜치 병합하는 방법 (충돌 해결) (0) | 2023.03.16 |
댓글