2023.04.14 TIL(Git 사용법)

 

👀Today...

---

오늘은 첫 페어프로그래밍을 진행했다...! 겨우 삼일동안 온라인으로 수업듣고 만나는 페어라니... 솔찍히 문제 해결보다는 걱정이 앞섰던거같다. 외부에서 사람들을 만나고 이야기하는것을 딱히 어렵다고 생각하지 않는데, 오히려 온라인에서 만나서 얼굴을 보고 대화해야된다는것이 생각보다 부담으로 다가온것같았다. 근데 생각보다 이거 괜찮은데? 싶었다. 페어분과 첫 대화여서 어색어색한 상태로 과제를 하나씩 풀어나가는게 재미있었다ㅋㅋㅋ 쨋든 Git에 대해서 배웠는데 혼자 사이트를 참고해가면서 열심히 따라했던게 나름 도움이 됐던것같다. 오늘의 잡담은 여기까지...!

 

 

☕오늘의 TIL(Today I Learn)

---

Git이란?

#Git

Git은 리누스 토발즈가 만든 프로그램으로 파일을 관리해 주는 프로그램이다. 여기서 관리라는 것은

• 버전 관리
• 백업
• 협업

정도로 생각해볼수있는데 그럼 의문이 생긴다. 웹에 조금만 관심을 가지면 자주듣게되는 깃허브는 과연 무엇인가?

깃허브는 로컬에서 관리되는 Git을 사용하는 프로젝트를 클라우드를 통해 관리하고 운영하는 방식이다. 즉 협업이나 백업의 관점에서 로컬로만 사용하는 방법보다 더 효율적이라고 생각된다. 

출처 : designless.net

 

 

 

Git 기초

# Git의 영역

Git의 영역은 이렇게 3가지로 구분된다.

(1) Work space : 파일이 임시로 대기하는 영역

(2) Staging area

(3) Local repository : 

git init

을 하게되면 해당디렉토리의 모든파일들이 Git의 관리를 받게된다. 이때의 상태가 Work space이다. 

Work space에 올라가있는상태는 Git의 관리를 받게된 Tracked(추적 되고있음) 라고 할수있다. 그리고 git초기화가 되지않은 상태를 Untracked(추적되고있지않음) 상태라고 할수있다. 

추적이 되고있다는 이야기는 파일의 수정이나 변경이 있을때 Git이 파일의 변경 내용을 감지가능한 상태라고 볼수있다.

그리고 Tracked의 경우 다시 3가지 상태로 나눠진다.

 

Unmodified : 파일의 수정이 Git에 의해 감지되지 않은 상태

Modified : 파일의 수정이 Git에 의해 감지된 상태

Staged : 파일이 Staging area에 존재하는 상태

 

즉 위의 그림에서 Work space -> Staging area로 이동을 하게된 상태를 Staged라고 하며 이를 위해서는

git add .

명령어가 필요하다. (이때는 아무런 메세지도 출력안됨), 성공적인 수행을 확인하고싶으면

git status

를 통해서 확인이 가능하다.

 

그리고 Stage에 올린 파일을 다시 Staging are -> Work space로 돌리고 싶으면 아래와 같은 명령어를 입력하면된다.

git rm --cached [file name]

 

자이제 Staging are에 있는 파일을 Local repository로 옮겨보자. 이를 commit 이라고 하며 Local repository에 파일을 저장하며 동시에 파일의 버전까지 기록을 한다.

git commit -m "[short message]"

commit이 완료된 상태에서

git log

를 입력하면 터미널 내에 별도의 창이 열리면서 commit 내역을 확인하는것이 가능하다.

이때 로그메세지중에 HEAD는 브랜치들중에 현재 작업중인 브랜치를 말하고 숫자영어 조합의 해시값이 버전마다 부여되는데 이를 커밋 해시라고 부르며, 이를 통해 버전을 식별할수있다.

 

지금까지의 작업은 로컬에서 진행된것이고 이제 Github를 통해 Remote repository로 이를 옮겨보자. 순서는 다음과 같다.

1. 온라인에 Remote repository 생성

2. Remote repository 와 Local repository 연결 ( git remote )

3. 업로드

 

1번작업은 기본적으로 알고있으니 생략하고 다음은 2번 git remote를 통해 연결을 할차례이다.

git remote add [별칭] [원격저장소 URL]

//ex
git remote add origin https://github.com/example/example.git

이렇게 연결을 진행한뒤에 만약 Remote repository를 다시 연결해제하려면

git remote rm [해제할 별칭]

을 통해서 해제가 가능하다. 그리고 정상적으로 연결되었는지 확인하려면

git remote --v

이런 메세지가 출력되는데 이때

fetch는 파일을 내려받을때 사용하는 별칭과 URL을 나타내고

push는 Remote repository로 업로드할때 사용하는 별칭과 URL을 나타낸다.

 

자이제 연결이 끝났으니 마지막으로 작업물을 Remote repository에 업로드 해보자. 이를 push라고 부른다.

git push [remote시 입력했던 별칭] [브랜치 이름]

//ex
git push origin main

이를 그림으로 정리하면 다음과 같다..!

 

Git 실습

요거 그림 써도 되는지 모르겠는데... 일단 너무 잘정리되어있어서 올려놓고 만약 문제가 생기면 삭제해야겠다..!

 

# 협업

위의 그림과 같이 타인의 Repo와 연결하여 협업할일이 발생하면 일단 타인의 repo와 다음과 같은 방법으로 연결한다.

git remote add [repo 별칭] [repo URL]

//ex
git remote add pair <연결할주소>

그리고 이상태에서 서로 수정이 진행되고 작업물을 받아오려면 

git pull [repo 별칭] [브랜치이름]

//ex
git pull pair main

이런식으로 해서 상대방의 remote repository의 작업물을 받아올수있다. 그리고 이때 받아오는 내용은 자동으로 병합(merge)된다.

 

 

Git 명령어 모음

git clone [URL] 	//remote repository 로컬로 복제

 

 

---

👊혼자서 해결하기

---

1. 협업 진행시에 충돌이 발생하면?

협업중 동일한 라인을 수정한뒤 서로 pull을 하게되면 merge 실패가 발생한다. 이때는 git status 명령으로 확인이 가능하고 파일을 열어보면 충돌이 발생한 부분을 볼수있다. 충돌이 일어난 부분을 수정한뒤에 다시 staging area로 파일을 추가하고 commit을 진행하면된다. 

 

2. 리눅스환경에서 Github SSH인증과정에서 장애발생

2023.04.18 - [Tip!✨] - 우분투 환경에서 Github ssh인증시 장애

 

3.git pull 과 git clone의 차이점은 무엇인가?

- git clone을 사용하면 로컬 저장소의 내용이 원격 저장소의 내용과 일치해진다. 

- git pull을 사용하면 원격저장소의 내용을 가져와 현재 브랜치와 병합(merge)까지 실행해준다. 즉 기존 작업 내용을 유지하면서 최신코드로 업데이트가 가능하다.

* 다시말해서 git clone은 초기 다운로드에 사용하고 git pull은 업데이트 사항 등을 다운로드 할때 사용한다.