웹 풀사이클 데브코스 TIL 1주차 DAY 4

프로그래머스 데브코스, 국비지원교육, 코딩부트캠프

🚩 프로그래머스 데브코스 웹 풀사이클 과정 1주차 DAY 4

---

오늘도 어제와 마찬가지로 Git에 대해 공부하였고,뿐만아니라 Github와 나의 프로젝트를 연동하는 방법도 배울 수 있었다. 중요하다고 생각하는 부분을 집중적으로 정리해보았다.

💡Git에 대하여

---

저번 시간과 마찬가지로 오늘도 Git 명령어에 대해 공부하였다. 저번에는 Git을 직접적으로 활용하는 명령어보다는 리눅스 상에서 사용하는 명령어를 위주로 공부하였는데, 이번에는 대망의 add, commit, push에 대해서 공부하게 되었다.
먼저 add, commit, push 명령어를 실습하기 전에 Git의 영역과 라이프사이클에 대한 이해가 필요하다.

✔️ Git의 영역

1. Working Directory
   : 우리가 현재 프로젝트를 작업하는 공간이다.

2. Staging Area
   : Working Directory에서 수정한 작업물을 Repository로 commit을 하기 전에 머무르는 공간이라고 할 수 있다.
   즉, add가 이루어진다면 Staging Area에 머무르게 된다.

3. Git Repository
   : commit된 작업물이 모여있는 공간이다.
   add가 되고 commit까지 완료된 후에야 작업물은 Repository에 저장될 수 있다.

✔️ Git 파일의 상태

위는 File Status Lifecycle 사진이다.
Workign Directory 내의 파일은 Untracked와 Tracked로 구분이 된다. Untracked는 아직 add가 되지 않은 파일이다. 여기서 git add 등과 같은 add 명령을 하게 된다면 Tracked 상태가 되는데, 이 Tracked 내에서도 Unmodified, Modified, Staged 이 세 상태로 나뉘어진다.

1. Untracked
   : Working Directory에 있는, 파일을 생성한 이후로 한 번도 add 되지 않은 상태의 파일이다.

2. Unmodified (Tracked)
   : 최신 commit과 비교했을 때 바뀐 부분이 없는 상태를 뜻한다. commit을 한 직후에는 working directory 내의 모든 파일이 unmodified 상태가 된다.

3. Modified (Tracked)
   : 최신의 commit과 비교했을 때 변경된 부분이 있는 파일을 뜻한다.

4. Staged (Tracked)
   : 최종적으로 Git의 Staging Area에 올라간 상태를 뜻한다.

무작정 add, commit, push를 진행하는 것보다 Git 내부에서 어떻게 동작하는지 이해하고 수행한다면 더 효과적으로 실습을 진행할 수 있을 거라고 생각한다!

💡 자주 사용하는 Git 명령어

---

이제 드디어 실습을 하며 직접 Git을 사용해볼 시간이다!

1. git add (파일 이름) / git add .
   : 파일을 Staging Area로 올리기 위해 add를 하는 과정이다. 한 파일만 add하고 싶다면 git add 파일명을 사용해도 되지만 보통은 git add .를 사용한다. 작업한 모든 내용을 add 할 수 있는 명령어다.

나는 파일 하나만 add를 할 것이기 때문에 위처럼 명령어를 입력하였다. 저렇게 입력한다면 아무것도 뜨지 않을 텐데 그게 정상이다! 여기서 git status를 입력한다면 해당 파일은 정상적으로 Staging Area에 올라갔으니 커밋이 필요하다! 라는 안내가 뜰 것이다. 나는 vscode에서 작업하였기 때문에, 사이드메뉴의 Git 아이콘을 클릭하면 아래와 같이 뜨게 된다. vscode의 장점은 Git을 GUI로 이용할 수 있다는 점이다.

위처럼 스테이징된 변경사항이라고 뜬다. Staged Area로 무사히 올라갔다는 뜻이다.

2. git commit / git commit -m '커밋메시지'
   : 이제 add를 했으니 commit을 할 차례다. 만약 그냥 commit을 한다면 터미널에 commit 메시지를 입력할 수 있는 vim 창이 뜨게 될 텐데, 굳이 vim 창에서 또 메시지를 입력하는 것보다는 commit -m 명령어를 사용하는 것을 개인적으로 추천한다.
   명령어 입력 후 아래처럼 파일이 변경되었다고 뜬다면 정상적으로 커밋이 완료된 것이다!

자 여기서 이제 git status를 입력하면 어떻게 뜰까?

새빨간 오류가 가득했던 이전과는 다르게 깔끔하게 커밋할 것이 없다는 문구가 뜬다. 그렇다면 git log를 입력해서 확인해보자.

이런 식으로 커밋이 정상적으로 완료된 것을 로그를 통해 확인할 수 있다.

참고로 vscode의 확장 프로그램인 Git History를 설치한다면 위 사진처럼 조금 더 보기 편한 방식으로 Git의 상태를 확인할 수 있다.

3. push
   : commit까지 전부 완료되었으니 이제 남은 것은 push 뿐이다. 하지만 push를 진행하기 위해서는 github가 필요하다. 내 작업물을 웹 상으로 올리는 과정이기 때문이다.

❗Github가 나설 시간

이제 드디어 깃허브가 나설 시간이다. 당연한 말이지만, 회원가입이 필수적이다.

깃허브

회원가입은 전혀 어렵지 않으니 깃허브로 들어가 계정을 생성하고, 위 파일을 올릴 레포지토리를 생성해보자.

사실 크게 건들 부분은 없다. 팀 프로젝트라면 레포지토리 이름에도 신경을 써야겠지만 이건 개인 실습을 위한 레포이기에... 그냥 간단하게 지어봤다.

생성한다면 위와 같이 뜨게 될 거다. 깃허브는 아주 친절하게도 아직 레포지토리를 연결하지 않은 우리를 위해 상세하게 설명을 해주고 있다. 기존 레포지토리가 없는 경우와 레포지토리가 존재하는 경우를 모두 설명하는데 난 이미 레포지토리를 만들고 파일까지 생성하여 커밋도 진행하였기 때문에 후자를 진행해야 한다.
저 그대로 진행하면 내 레포지토리와 깃허브 연동은 끝이다! 중앙의 나의 깃허브 레포지토리 경로를 복사해두자.

1. git remote add origin 경로

깃허브 상의 레포지토리와 현재 위치하는 레포지토리와 연동을 하는 과정이다.

2. git remote -v

해당 명령어를 입력했을 때 내 깃허브 레포지토리 주소가 뜬다면 정상적으로 연결이 완료된 것이다!

3. git push origin main

이제 정말로 push를 해보자. 나의 메인 브랜치가 master가 아닌 main이기 때문에 git push origin master가 아닌 git push origin main을 입력해야 한다. 전자를 입력한다면 에러가 발생한다.

근데 입력하는 순간 위와 같은 팝업 창이 뜨는 사람도 있을 거다. 당황하지 않고 침착하게 로그인을 해주면 된다. 최초 연동을 할 때 한 번은 위처럼 로그인을 하는 과정이 필요하다.

로그인까지 정상적으로 완료했다면 아래와 같이 이런저런 출력문이 뜬다. 붉은 에러가 발생하지 않았다면 정상적으로 push가 된 것이다.

git log를 입력해서 로그를 확인해보면 큰 변화가 없는 것 같지만... HEAD -> main만 존재했던 이전과는 다르게 origin/main이 함께 출력된다. 이게 바로 push까지 완료되었다는 뜻이다.

push를 하기 이전 commit만 했을 때의 git history 화면이다.

그리고 이게 push를 한 이후의 git history 화면이다. origin/main이 추가된 것을 볼 수 있다.

자, 이제 아까 만들었던 레포지토리로 돌아가보자.

아까 전의 안내만 가득했던 화면과는 다르게 드디어 내가 로컬 상에서 작업했던 파일이 깃허브로 올라가있다!
우리는 이제 깃허브와 연동까지 해서 내 작업물을 깃허브 상에 올릴 수 있게 되었다.

🍀 마치며

---

사실 Git은 배우기에 꽤 복잡하고 어렵다. add, commit, push만 존재하는 게 아니라 정말 많은 명령어가 있고 커다란 프로젝트를 작업하다보면 각자 작업한 내용을 합칠 때 이런저런 충돌도 많이 일어난다.
나도 Git을 자주 썼고, 공부도 했지만 다시 Git에 대해 공부하면서 아직 개념이 명확하게 잡히지 않은 부분이 있었다는 걸 깨달았다. 이번 기회를 통해 확실하게 제대로 공부하며 차후 있을 협업 프로젝트에서 효과적으로 사용해보고 싶다.