현재 오즈코딩스쿨 강의를 통해 프론트엔드를 학습하고 있습니다.
본 포스트는 해당 강의에 대한 내용 정리를 목적으로 합니다.

1. Github에 Repository생성하고 push해 보기

2. Github push와 pull

Git에서 push와 pull은 원격 저장소(GitHub 등)와 로컬 저장소(내 컴퓨터) 간의 데이터를 동기화하는 명령어다.

명령어	역할
git push	로컬의 변경 사항을 원격 저장소에 업로드
git pull	원격 저장소의 변경 사항을 로컬로 가져오기

1) git push (원격으로 올리기)

a. 원격 저장소(GitHub)에 푸시하는 기본 방법

git push origin main  # main 브랜치에 푸시

✅ main 브랜치의 변경 사항을 origin(GitHub)으로 올림

b. 새로운 브랜치를 원격에 푸시

git push -u origin feature-branch

✅ feature-branch 브랜치를 원격 저장소에 처음 푸시할 때 사용

c. 강제 푸시 (--force)

git push --force

✅ 주의! 강제 푸시는 원격 저장소의 내용을 덮어쓰므로, 협업 시 주의해야 함

2) git pull (원격에서 가져오기)

a. 원격 저장소의 최신 변경 사항을 가져오기

git pull origin main

✅ main 브랜치의 최신 변경 사항을 가져와 자동 병합

b. pull 시 충돌 발생하면?

1️⃣ git pull 실행 후 충돌 발생
2️⃣ git status로 충돌 파일 확인
3️⃣ 수동으로 충돌 해결 후 git add 충돌난파일
4️⃣ git commit -m "충돌 해결" 후 푸시

3) git push vs git pull 흐름

1️⃣ 로컬에서 작업 (수정, 추가)
2️⃣ git add .
3️⃣ git commit -m "작업 내용"
4️⃣ git push origin main # GitHub로 올리기
5️⃣ 다른 사람이 작업 후 push
6️⃣ git pull origin main # 최신 코드 받아오기

📌 팀 프로젝트에서는 pull → merge → push 순서로 진행

3. Github를 이용한 협업 프로세스

GitHub로 협업을 진행하다 보면 규모에 따라 다르겠지만 참여하는 개발자가 많은 프로젝트의 경우 무분별한 Branch 생성으로 협무의 효율을 떨어뜨릴 수 있다.

그 외 수많은 Git branch 전략이 있다.

그래서, 효율적인 버전 관리를 위해 만들어진 다양한 GitHub-Flow 전략 중 One of the Git Flow 전략을 우리가 진행할 프로젝트에 적용시켜 볼 수 있으면 좋겠다는 생각을 했다

출처:One of the Git Flow © Sammy Baek

프로젝트 Git & GitHub 활용 도식화

진행 순서↓

1. 팀장이 GitHub에 생성한 프로젝트 원격 저장소(Remote Repositoty)를 본인의 GitHub에
   Fork해 오기

2. Fork해온 프로젝트를 본인의 로컬 저장소(Local Repository)로 Clone해 오기

   #로컬 저장소 = 본인 pc

3. 프로젝트를 Forked해온 원격 저장소(Remote Repositoty) https 주소를 로컬 저장소(Local Repository)에 등록하기

   #clone 받아오면 remote에 clone 받아온 원격 저장소의 https 주소와 별칭(origin)이 자동으로 생성됨, 그렇기 때문에 프로젝트로 원격 저장소의 주소는 직접 입력해 줘야함

4. 로컬 저장소(Local Repository)에서 작업하기 전 새로운 Branch를 생성해서 작업하기

   #main 저장소에는 pull 이용해 항상 최신의 정보가 유지되도록 만들고 생성한 branch에서
   작업을 진행해야 로컬 환경에서 merge를 통해 충돌을 사전에 처리할 수 있고 정상적으로
   작동하는지 확인 가능함

5. 작업이 완료되었다면 git fetch를 활용해 원본(Upstream) 프로젝트에 변경 이력이 있는 확인해보기
   #git fetch 후 받아 온 정보를 git diff ..upstream/main 코드를 이용해 상세 확인

6. 원격 저장소의 변경 이력이 없거나 내 작업물과의 충돌이 발생하지 않을것 같다면, 우선 main
   브랜치로 이동 후 git pull upstream을 이용해 최신 버전으로 만들기

7. main브랜치에서 작업을 진행한 브랜치 merge 진행, 이 과정에서 충돌이 일어난 경우
   충돌 해결 후 merge 계속하기

8. merge가 완료되면 본인의 원격 저장소로 git push

9. GitHub 사이트에서 본인의 원격 저장소(Forked Remote Repository) 이동 후 Push된 이력을 원본 프로젝트가 있는 저장소에 pull request 요청 보내기
   #팀원을 프로젝트 원격 저장소에 초대했다면 pull request 요청 시 승인 과정없이 자동으로 merge 됨

4. Git의 tag

git tag는 특정 커밋을 표시(태그)하는 기능이다.
주로 버전 관리(v1.0, v2.0 등)나 릴리스(release) 작업에 사용된다.

1) git tag 기본 사용법

a. 태그 목록 확인

git tag

✅ 현재 저장소의 모든 태그 목록을 출력

b. 특정 태그 정보 확인

git show v1.0

✅ v1.0 태그가 가리키는 커밋 정보 출력

c. 태그 생성 (Lightweight Tag)

git tag v1.0

✅ 현재 커밋을 v1.0으로 태그
✅ Lightweight 태그는 메타데이터 없이 커밋만 가리킴

d. 주석이 포함된 태그 (Annotated Tag)

git tag -a v1.0 -m "첫 번째 릴리스"

✅ -a 옵션으로 주석을 포함한 태그 생성
✅ 주석 태그는 메타데이터(작성자, 날짜 등)를 포함함

e. 특정 커밋에 태그 추가

git tag v1.1 abc1234

✅ abc1234 커밋에 v1.1 태그를 추가

f. 태그 삭제

git tag -d v1.0

✅ v1.0 태그를 삭제 (로컬에서만 삭제됨)

g. 원격 저장소(GitHub)로 태그 푸시

git push origin v1.0

✅ v1.0 태그를 GitHub로 푸시

h. 모든 태그를 원격 저장소로 푸시

git push origin --tags

✅ 로컬의 모든 태그를 GitHub에 푸시

i. 원격 저장소에서 태그 삭제

git push origin --delete v1.0

✅ GitHub에서 v1.0 태그 삭제

5. 원격 브랜치 관리하기

1) 로컬에서 브랜치 만들어 원격에 push 해보기

1. from-local 브랜치 만들기
2. 아래 명령어로 원격에 push

아래와 같이 하면 대상을 명시하라는 메시지 나타남

git push

아래 명령어로 원격의 브랜치 명시 및 기본설정

git push -u origin from-local

1. 브랜치 목록 살펴보기
   • GitHub에서 목록 보기
   • 아래 명령어로 로컬과 원격의 브랜치들 확인 git branch --all
     

2) 원격의 브랜치 로컬에 받아오기

1. GitHub에서 from-remote 브랜치 만들기

   • git branch -a에서 현재는 보이지 않음

2. 아래 명령어로 원격의 변경사항 확인

   git fetch

   • git branch -a로 확인

3. 아래 명령어로 로컬에 같은 이름의 브랜치를 생성하여 연결하고 switch

   git switch -t origin/from-remote

3) 원격의 브랜치 삭제

git push (원격 이름) --delete (원격의 브랜치명)

6. Git Hooks 활용해보기

Git Hooks은 Git상의 이벤트마다 자동으로 실행될 스크립트를 지정하는데 사용됩니다.

• commit 후 자동으로 이모지 등록
• commit 후 Push하면 테스트 코드 자동실행 후 검증
• Git Action과 같은 CI/CD에 사용

1) Git Hooks 폴더 보기

프로젝트 폴더 내 .git > hooks 폴더안에 스크립트 예시 파일들이 있습니다.

• 파일 끝에 .sample을 없애면 hook 실행 파일이 됩니다.
• 파일명 앞쪽에 적힌 내용에 따라 작동 시기가 다릅니다.

  • pre-commit : commit 명령 직후에 작동

  • pre-push : push 명령어 입력 직후 작동

    
    

2) gitmoji-cli로 활용 예 보기

gitmoji-cli GitHub 페이지

a. gitmoji-cli 설치

b. 윈도우

• 먼저 Node.js 설치
• 터미널에서 설치: npm i -g gitmoji-cli

c. 맥

• brew로 설치 : brew install gitmoji

d. 프로젝트의 훅에 적용

e. 프로젝트 폴더에서 아래 명령어 실행

gitmoji -i

• hooks 폴더에 추가된 파일 확인하기
• 프로젝트에 수정 뒤 git add ., git commit하여 진행
• commit 추가 뒤 push하여 GitHub에서 확인

  <br>

  
  

7. Git Submodule

git submodule은 Git 저장소 안에 또 다른 Git 저장소를 포함시키는 기능이다.
보통 다른 프로젝트의 코드를 의존성으로 포함해야 할 때 사용한다.

1) Git Submodule을 사용하는 이유

• 공유 코드 재사용: 공통 라이브러리를 여러 프로젝트에서 공유할 수 있음

• 독립적인 버전 관리: 메인 프로젝트와 별개로 서브모듈의 버전을 관리할 수 있음

• 협업 용이: 다른 팀이 관리하는 저장소를 직접 포함할 수 있음

2) Git Submodule 기본 사용법

a. 서브모듈 추가

git submodule add <저장소 URL> <폴더명>

✅ 예시:

git submodule add https://github.com/example/library.git libs/library

📌 libs/library 폴더에 library 저장소를 서브모듈로 추가

b. 서브모듈 클론하기

git clone --recursive <저장소 URL>

✅ 서브모듈이 포함된 프로젝트를 처음 클론할 때 사용

✅ 만약 --recursive 옵션 없이 클론했다면:

git submodule update --init --recursive

📌 서브모듈을 초기화하고 최신 상태로 업데이트

c. 서브모듈 업데이트

git submodule update --remote

✅ 원격 저장소의 최신 커밋을 가져옴

d. 서브모듈 내부에서 작업 후 커밋

cd libs/library
git checkout main  # 서브모듈 브랜치 이동
git pull origin main  # 최신 코드 가져오기
git add .
git commit -m "서브모듈 업데이트"
git push origin main  # 서브모듈 푸시
cd ../  # 메인 프로젝트로 돌아가기
git add libs/library  # 서브모듈 변경 사항 반영
git commit -m "서브모듈 최신 버전 반영"

✅ 서브모듈 변경 사항을 반영하려면 메인 저장소에서도 커밋 필요

e. 서브모듈 삭제

1️⃣ .gitmodules 파일에서 해당 서브모듈 항목 삭제
2️⃣ .git/config에서도 관련 항목 삭제
3️⃣ 다음 명령어 실행

git rm --cached <서브모듈 폴더명>
rm -rf <서브모듈 폴더명>
git commit -m "서브모듈 삭제"

✅ 서브모듈을 제거하고 커밋

f. git submodule 사용 시 주의할 점

• 서브모듈은 독립적인 저장소이므로 별도로 업데이트해야 함

• git clone 시 --recursive 옵션을 사용해야 서브모듈까지 클론됨

• 협업 시 서브모듈 업데이트(git submodule update --init --recursive)를 잊지 말아야 함

끝맺음.

주말에 github 꾸미고, github vs코드 10k 오류 정리해서 올려야지!!