Git 버전관리 기초 사용 방법 & 에러 대응 방법

 

 

오늘은 Git의 '버전관리'에 대한 실습을 진행해 보며

기초적인 사용법에 대해 포스팅을 해보겠습니다:-)

 

 

< 목 차 >

1. 터미널 작업
   • 버전 변경
2. 깃허브에 올리기
3. Error 대응 방법

---

[ 1. 터미널 작업 ]

 

1. 소스 코드를 관리할 폴더를 만든다.

 

 

2. 폴더 내에 코드 파일을 만들고 소스코드 작업(코딩)을 진행한다.

 

 

3. 먼저 ' git config--global init.defaultBranch main '명령어를 통해 '깃 설정을 변경'한다.

 

• 이는 기본적으로 브랜치가 'master'로 설정되어 있기 때문에 'main'으로 변경해 주기 위함이다.
• ('Black Lives Matter' 운동으로 master/slave 등의 IT에서 사용되는 용어에도 정화가 필요하다는 의식이 생기고 있을 때 Github에서 2020년에 레파지토리의 기본 브랜치명을 master에서 >  main으로 변경했기 때문)

 

 

4. 이후 ' git init ' 명령어를 통해 깃을 '초기화(생성)'한다.(이제 이 위치에 '버전 정보'들이 저장된다.)

 

 

5. ' git config --global user.email 이메일 '

    ' git config --global user.name 이름 '

     을 입력하여 깃허브의 '이메일'과 '이름'을 입력한다.

 

3 ~ 5번 진행

 

 

6. ' git add 파일이름.html '(지정된 파일을 하나씩 staging area로 넣음)

    ' git add * '(변경 사항이 있는 모든 파일들을 staging area로 넣음)

    을 입력하여 '커밋할 파일들'을 'staging area'로 넣어야 한다.

    (원하는 파일들을 'staging area'에 넣어두고 '커밋'을 진행하면 하나의 버전이 생성된다.)

 

 

7.  ' git status '명령어를 통해 현재 'staging area'에 담겨있는 파일들을 확인할 수 있다.

 

• 만약 'staging area'에 파일을 잘못 올렸다면 ' git restore --staged 제외할 파일명 '명령어를 통해 원하는 파일을 제외할 수 있다.(단, 해당 명령어는 커밋이 하나라도 있어야 사용이 가능하다.)

 

6 ~ 7번 진행

 

 

8. 파일이 정상적으로 담겨있다면 ' git commit -m "이름" '명령어를 통해 'staging area'에 존재하는 파일들로 새로운 '버전'을 만들 수 있다.

 

8번 진행

 

 

9. ' git log '명령어를 통해 커밋된 정보들을 확인할 수 있다.

 

 

 

[ (Plus) 버전 변경(수정된 코드 버전 관리) ]

 

1. 소스코드의 내용을 변경하고 두 번째 버전을 생성한다.

 

• 소스코드 변경 > ' git add * '로 변경된 코드 모두 추가 > ' git commit -m "이름" '을 통해 버전 생성 및 이름 지정

 

 

2. ' git log '를 통해 커밋된 정보들(저장된 버전들 및 사용자 아이디)을 확인

 

기존에 존재하던 '베타 버전1.0'과 코드가 수정되어 새로 만들어진 '베타 버전 1.1'이 존재하는 것을 확인

 

 

3. 내가 작업할 커밋을 선택할 때 ' git checkout 식별자 '를 통해 내가 보고 있는 버전을 변경할 수 있다.

 

 

4. ' git check HEAD^ '(현재 작업 디렉토리를 직전 커밋 상태로 변경하지만, 변경사항은 그대로 유지)

    ' git reset --hard HEAD^ '(현재 커밋을 직전 커밋으로 리셋하고 모든 변경사항을 삭제)

    명령어를 통해 바로 직전의 커밋으로 돌아갈 수 있다.

 

 

 

[ 2. 깃허브에 올리기 ]

 

(위의 9번에서 이어집니다.)

10. 깃허브에 올리기 위해 소스코드들을 관리할 레파지토리를 생성하고, 해당 레파지토리의 '주소'를 복사한다.

      (주소는 레파지토리 생성 후 초록색의 " <> Code "버튼을 통해 확인할 수 있다.)

 

 

11. 로컬 환경의 터미널에서 ' git remote add origin 저장소 주소 '를 입력하게 되면 외부의 레파지토리(저장소)와 연결한다.

 

 

12. ' git remote -v '명령어를 통해 현재 연결된 레파지토리(저장소)의 정보를 확인할 수 있다.

 

 

13. 마지막으로 ' git push origin main '명령어를 사용하게 되면 깃허브의 메인 브랜치에 커밋들이 들어가게 된다.

 

+ ' git pull origin main ' 명령어를 통해 브랜치에 추가된 커밋들을 받아오는 것도 가능하다.

 

 

 

[ Error 대응 방법 ]

 

1. 간혹 깃허브의 메인 브랜치에 커밋을 넣을 때 오류가 발생하는 경우가 생기는데 이때는

 

• 원격 저장소의 초기 커밋이 존재하는 경우
• 로컬 저장소와 원격 저장소의 이력이 일치하지 않는 경우
• 기존의 레파지토리를 복제 후 초기화 하지 않은 경우

등의 이유가 있을 수 있다.

 

이때는 로컬에서 이력을 '병합' 혹은 '리베이스' 할 필요가 있으며 명령어는 아래와 같다.

 

• git fetch origin main : 원격 저장소의 내용을 로컬로 가져오기
• git merge origin/main : 원격의 이력을 병합
• git rebase origin/main : 리베이스
• git push origin main :  변경 사항을 push

 

만약 원격 저장소의 내용을 덮어쓰고자 한다면 강제로 push가 가능한 ' git push -f origin main '명령어를 사용하면 된다.

 

 

2. 깃허브 push 중 에러가 발생한 경우

 

• 이는 ' git init '단계 후에 git에 ' add/commit '을 하지 않고 바로 push를 해서 생기는 오류이다.

 

>>> 고로 ' add > commit > push '의 순서를 꼭 지키도록 하자.

 

 

3. 비밀번호 에러가 발생한 경우

 

• 이는 ' user password 입력 후'에 발생하는 에러이다.
• ' git push '명령어를 사용하면 git의 ' username '과 ' password '를 요청받게 되는데, 모든 git작업에는 비밀번호 대신 토큰(혹은, SSH키)이 필요하도록 변경되어 password입력란에 깃허브에서 발급받은 '토큰 값'을 입력하면 해결된다.

 

 

4. ![reject]에러가 발생한 경우

 

• 이는 ' git push origin main '입력 후 발생되는 에러이다.
• 쉽게 말해 충돌이 일어났다고 볼 수 있는데, "원격 저장소 커밋보다 로컬 저장소의 커밋이 더 오래되었을 때 발생하는 오류"이다.
• 해결 방법은 아래와 같다.
  • ' git push origin + main ' : 강제로 덮어쓰는 명령어(다른 사람이 커밋한 내용에 영향을 줄 수 있는 위험이 있다.)
  • 원격 저장소 커밋을 먼저 로컬 저장소로 pull 한 다음 수정 내용을 동기화하고 그다음 push를 진행하자.
• 즉, '깃허브에서 직접 수정'은 지양할 것 / pull을 할 때 적절한 단계에 진행할 것

 

 

 

 

 

( 참 고 )

- https://growth-coder.tistory.com/129

[Git & GitHub] 깃 버전 관리 기초 사용법

- https://velog.io/@neighborkim/git-push-%EB%A5%BC-%ED%95%B4%EB%B3%B4%EB%A9%B0-%EA%B2%AA%EC%9D%80-3%EA%B0%80%EC%A7%80-%EC%97%90%EB%9F%AC

git push 를 해보며 겪은 3가지 에러