비전공자 개발자로 취업하기

개발/github

[github] 쌩 초보자를 위한 팀 프로젝트 github 사용법

pizzaYami 2024. 4. 18.

이 글에서는 완전한 초보 개발자를 대상으로 Git과 GitHub이 왜 중요한지, 사용하는 주된 이유들을 쉽게 설명하고자 합니다.

 

0. Git과 GitHub을 사용하는 이유

  1. 버전 관리: Git을 사용하면 코드의 이전 버전으로 쉽게 돌아갈 수 있으며, 어떤 변경사항이 언제, 누구에 의해 만들어졌는지 정확하게 알 수 있습니다.
  2. 협업: 여러 개발자가 동시에 하나의 프로젝트에 참여할 수 있습니다. 각 개발자는 자신의 로컬에서 작업을 하고, 완료된 작업을 공유하여 다른 사람들과 통합할 수 있습니다.
  3. 백업과 보안: GitHub은 클라우드에 코드를 저장하기 때문에 컴퓨터의 문제로 데이터가 손실되는 일이 없습니다. 또한, 중요한 프로젝트를 비공개로 설정하여 보안을 유지할 수 있습니다.
  4. 오픈 소스 프로젝트: GitHub은 전 세계 수백만 개발자와 그들의 프로젝트를 연결하는 중심지입니다. 여러분도 오픈 소스 프로젝트에 기여할 수 있으며, 다른 사람의 코드를 보고 배울 수 있습니다.
  5. 문서화와 이슈 트래킹: 프로젝트 관련 문제를 기록하고 해결 방법을 논의할 수 있는 이슈 트래킹 시스템을 제공합니다. 이는 팀 내 커뮤니케이션을 원활하게 하고, 프로젝트의 진행 상황을 명확하게 파악할 수 있게 해줍니다.

 

1. Git으로 작업하기

 

1) git과 연동하기 (git init)

자신이 git, github을 사용하지 않고 로컬에서 작업하고 있는데  git, github을 사용하고 싶다면 git init을 해야합니다.

git init

 

git init을 함으로써 폴더안에 .git폴더가 생성되고 이후부터는 git과 로컬폴더가 연동이 되어서 git을 사용할 수 있게 됩니다.

 

2) 스테이징하기 (git add .)

프로젝트에 새 파일을 추가하거나 기존 파일을 수정한 후, 이 변경사항을 저장소에 기록하고 싶다면 먼저 Git에게 이 파일을 "스테이지"하도록 명령해야 합니다.

 

스테이징이란?
commit하기전에 잠깐 저장하는 창고입니다.

 

git add <파일명> // 특정 파일 스테이징
git add . // 모든 파일 스테이징

 

또는 vscode에서 "+" 버튼을 눌러서 스테이징을 시킬 수 있습니다.

 

3) 커밋 (git commit -m "커밋 메시지")

파일을 스테이지한 후, 이제 이 변경사항들을 커밋(commit)해야 합니다. 커밋은 변경사항을 저장소에 안전하게 저장하는 행위입니다.

 

git commit -m "커밋메시지"

 

또는 vscode에서 "커밋" 버튼을 눌러서 커밋을 시킬 수 있습니다.

 

커밋 컨벤션 - 커밋 메시지를 작성하는 룰
팀 프로젝트를 하면 커밋을 다시 되돌아보는 경우가 많은데 이때 필요한 커밋을 빠르게 찾기위해서 커밋메시지의 룰을 설정합니다.
이러한 커밋메시지 룰을 "커밋 컨벤션"이라고 합니다.
팀마다 다르게 커밋 메시지 룰을 설정하는데 제가 사용하는 커밋 컨벤션은 

Type들
Feat: 새로운 기능 추가
Bug: 버그 발견
Fix: 버그 수정
Init: branch 추가시 초기 설정
Refactor: 리팩토링
Style: 디자인관련 수정
Docs: 구성원 추가 (리드미)
HOTFIX: 치명적 버그 수정
Rename: 이름변경
Remove: 삭제
Comment: 주석
Chore: 빌드 관련 수정 (번들러)
Test: 테스트 코드 작성

git commit -m "{Type}: {기능}"
// HomePage 제작시
git commit -m "Feat: HomePage 제작"

// 에러 고쳤을 시
git commit -m "Fix: Home와인 api에러 고침"

 

4) 푸쉬 (git push origin {보내야하는 브랜치})

변경사항을 저장소에 저장한 커밋을 로컬에만 두면 안되고 github으로 보내는 작업을 해야합니다. 이 작업을 "push"라고 합니다.

무작정 main 또는 dev로 보내는게 아니라 어디로 보내야할 지 정확하게 인지하고 있어야합니다.

보통은 자신이 작업한 브랜치로 커밋을 push합니다.

git push origin {보내야하는 브랜치}

// 자신이 현재 Feat/Home 브랜치에서 작업중이라면
git push origin Feat/card

//이러면 자신의 커밋이 원격저장소인 github의 Feat/card로 보내집니다.

 

또는 vscode에서 "푸시" 버튼을 눌러서 커밋을 시킬 수 있습니다.

"변경 내용 동기화"버튼은 "푸시"와 "풀"을 동시에해서 로컬과 원격저장소를 동기화하는 작업입니다.

 

 

5) 커밋확인

 

터미널에서 확인하기

이제 제대로 커밋이 되었는지 확인해봅시다.

가장 상단의 방금했던 커밋이 있다면 제대로 커밋이 된겁니다. -> git log후에는 q를 누르면 나올 수 있습니다.

// 간단하게 보기
git log --oneline
// 자세히 보기
git log

 

git log --oneline
git log

 

 

GitHub에서 확인하기

자신의 github 레파지토리의 브랜치에 가서 커밋이 되었는지 확인하면 됩니다.

아래의 예시는 어제가 마지막으로 커밋이 되어있네요.

 

 

로컬에서 변경된 파일이 GitHub까지 가는 경로
로컬 -> (git add .) ->  스테이징 -> (git commit -m "")-> 커밋 -> (git push origin {브랜치}) -> GitHub

 

 

2. 브랜치(Branch)작업하기

Git에서 브랜치는 프로젝트의 독립적인 개발선을 의미하며, 다양한 기능 개발이나 버그 수정 작업을 분리하여 진행할 수 있게 해줍니다. 이는 여러 개발자가 동시에 다른 작업을 할 수 있도록 하며, 작업이 완료되면 이를 주 브랜치에 병합(merge)하여 통합합니다.

 

예를들어 Home을 만든다면 Feat/Home 브랜치를 만들고 중간에 갑자기 navbar를 제작할 일이 생기면 Feat/Navbar를 만들어서 독립적으로 작업하다가 완성이 된다면 기준이 되는 main 또는 dev 브랜치에 merge(합치기)를 하면됩니다.

 

브랜치 네이밍 설정
브랜치도 커밋과 동일하게 이름을 정하는데 룰이 필요합니다.
어떤 브랜치에서 어떤 작업이 이루어지는지 딱 이름으로 보고 알아야 자신과 팀원이 브랜치를 쉽게 찾을 수 있습니다.

Type들
Feat: 새로운 기능 추가
Bug: 버그 발견
Fix: 버그 수정
Init: branch 추가시 초기 설정
Refactor: 리팩토링
Style: 디자인관련 수정
Docs: 구성원 추가 (리드미)
HOTFIX: 치명적 버그 수정
Rename: 이름변경
Remove: 삭제
Comment: 주석
Chore: 빌드 관련 수정 (번들러)
Test: 테스트 코드 작성

{Type}/{기능 or 대표적 컴포넌트}

//예시
Feat/RefreshToken
Feat/HomePage
Feat/zustandSetting​

 

1) 새로운 브랜치 생성 

 

터미널에서 아래와 같은 코드를 입력하면 브랜치가 생성됩니다.

git branch <브랜치명>

 

 

또는 깃헙에서 dev -> View all branches -> New branch로 들어가서 브랜치를 만들어도 됩니다.

Source를 설정하는게 있는데 이건 브랜치를 만들때 어떤 브랜치를 복사해서 가져와 만들거냐라는 뜻입니다.

dev로 설정하면 dev브랜치를 그대로가져서와서 새로운 브랜치를 만들어줍니다.

 

2) 브랜치 전환 

이제 자신이 생성한 브랜치로 이동을 해야합니다.

저는 주로 checkout 대신 switch를 사용하는데 이 블로그를 참고했습니다.

아래의 코드처럼 브랜치 생성과 동시에 이동하는 방법도 있습니다.

// 브랜치 이동
git checkout <브랜치명>
// 브랜치 생성과 동시에 이동
git checkout -b <브랜치명>

 

또는 vscode에서 좌측하단에 버튼을 누르고 브랜치를 변경해도 됩니다.

리스트를 보면 파란글씨로 "분기"와 "원격분기"가 있는데 "분기"는 로컬에 있는 브랜치이고 "원격 분기"는 GitHub에 있는 브랜치들입니다.

 

 

자신이 만든 브랜치가 위 사진 브랜치리스트에 안 보인다면 원격에 있는 브랜치가 아직 vscode에서 인식을 못 한 겁니다.

아래의 코드를 입력하면 뜹니다.

 // 로컬과 원격 동일화하기
 git fetch --prune origin

 

 

3) 브랜치 병합하기

혼자 작업시

특정 브랜치의 작업이 완료되어 주 브랜치(main 또는 dev)에 병합하려면, 먼저 주 브랜치로 이동합니다.

git checkout dev

 

그리고 병합하고자 하는 브랜치를 다음과 같이 병합니다.

git merge <브랜치명>

 

충돌이 나면 스테이징과 커밋을 하고 푸쉬를 하면됩니다.

git add <수정된 파일>
git commit

 

팀 프로젝트에서 PR을 통해서 작업시  ⭐️⭐️⭐️⭐️⭐️

팀 프로젝트를 한다면 PR을 통해서 merge를 해야합니다.

왜냐하면 자신이 만든 코드들을 그냥 merge를 하면 갑자기 코드가 업데이트되고 이에 대한 설명이 전혀 없어서 팀원은 혼란스러워집니다.

그래서 팀원들에게 PR을 통해서 내가 이러한 코드를 만들었고 이러한 기능을 한다. 코드를 보면서 이상한 점이 있다면 알려주고 승인을 받으면 merge를 하겠다 라고 허락 맡는겁니다.

 

완성된 자신의 브랜치를 PR하기전에 PR을 하고 싶은 브랜치(main or dev)를 가져와 합칩니다.

PR을 보내고 싶은 브랜치에서 git pull origin dev를 하면 dev파일을 가져와서 자신의 브랜치와 합칩니다.

충돌이 난다면 해결하고 자신의 브랜치에 푸시를 합니다.

// dev와 자신의 브랜치 합치기
git pull origin dev

// 충동해결 후에 커밋을 하고 자신의 브랜치에 푸시르 합니다.
git push origin {자신의 브랜치}


// 저는 rebase를 사용합니다. 자세한건 구글에 검색해보세요
git pull origin dev --rebase

 

PR(Pull requests)이란
즉 Pull 요청입니다.
자신이 A브랜치와 B브랜치를 합치고 싶은데 확인받고 싶을 때 사용합니다.
팀원은 PR을 확인하고 승인을 하면 합칩니다.(merge)

 

pull과 merge의 차이점

pull은 fetch와 merge를 합친 것
즉 원격저장소에서 로컬로 파일을 가져와 합치는 것입니다.

merge는 파일끼리 합치는 겁니다.

 

"New pull request"를 눌러서 PR을 생성해줍니다.

 

 

어떤 브랜치를(compare) 기본이 되는 브랜치(base)에 합칠지 선택합니다.

PR title과 description을 작성해주는 팀원들이 이 브랜치를 보고 이해가 되도록 최대한 가독성있게 작성해주면 됩니다.

다 작성하면 "Create pull request"를 눌러서 PR을 보내면 됩니다.

 

 

Reviewer로 어떤 팀원이 이 PR을 리뷰했으면 좋은지 선택합니다.

Assignees로 이 브랜치를 만든 사람들을 넣으면됩니다.

 

 

리뷰를 다 받으면 "Merge pull request" -> "Confirm merge"를 통해 머지하면 됩니다.

 

 

그 뒤에 브랜치를 삭제하겠냐고 뜨는데 PR은 자신 작업이 완전히 완성된 뒤에 올리고 merge를 해야됩니다.

그렇게 된다면 해당 브랜치는 더 이상 쓸일이 없기때문에 삭제하는게 맞습니다.

하지만 그 브랜치를 불안전해서 수정할 여지가 있거나 후에 디자인 작업을 해야된다면 브랜치를 삭제하지 말고 내버려뒀다가 작업 완료후에 삭제하면됩니다.


브랜치를 삭제하지 않으면 브랜치 목록에 너무 많은 브랜치가 남아서 찾고싶은 브랜치를 찾기 힘들어지기 때문에 왠만하면 사용후에 꼭 삭제 해주세요

 

 

3. 자주 사용하는 GIt 명령어 모음

 

  1. git init
    • 용도: 새로운 Git 저장소를 초기화합니다.
    • 사용 예: 프로젝트 디렉토리에서 git init을 실행하여 Git 저장소를 시작합니다.
  2. git clone [url]
    • 용도: 원격 저장소의 내용을 로컬로 복제합니다.
    • 사용 예: GitHub에 있는 프로젝트를 로컬 시스템으로 가져오기 위해 git clone https://github.com/user/project.git을 사용합니다.
  3. git add [file]
    • 용도: 변경된 파일을 스테이징 영역에 추가합니다.
    • 사용 예: 변경된 모든 파일을 추가하려면 git add .을 사용합니다.
  4. git status
    • 용도: 현재 작업 트리의 상태를 확인합니다.
    • 사용 예: 어떤 파일이 변경되었는지 또는 스테이징 되었는지 확인하기 위해 git status를 사용합니다.
  5. git commit -m "message"
    • 용도: 스테이징된 변경사항을 저장소에 기록합니다.
    • 사용 예: 변경 사항을 커밋하면서 "Initial commit"이라는 메시지를 남기려면 git commit -m "Initial commit"을 사용합니다.
  6. git push [remote] [branch]
    • 용도: 로컬의 변경사항을 원격 저장소로 보냅니다.
    • 사용 예: master 브랜치의 변경사항을 기본 원격 저장소로 푸시하려면 git push origin master를 사용합니다.
  7. git pull [remote]
    • 용도: 원격 저장소에서 최신 변경사항을 로컬로 가져옵니다.
    • 사용 예: 원격 저장소의 최신 변경사항을 로컬 master 브랜치로 가져오려면 git pull origin master를 사용합니다.
  8. git branch [branch-name]
    • 용도: 새로운 브랜치를 생성합니다.
    • 사용 예: "feature-x"라는 새 브랜치를 생성하려면 git branch feature-x를 사용합니다.
  9. git checkout [branch-name]
    • 용도: 다른 브랜치로 전환합니다.
    • 사용 예: "feature-x" 브랜치로 전환하려면 git checkout feature-x를 사용합니다.
  10. git merge [branch]
    • 용도: 다른 브랜치의 변경사항을 현재 브랜치로 병합합니다.
    • 사용 예: "feature-x" 브랜치를 현재 브랜치와 병합하려면 git merge feature-x를 사용합니다.
저작자표시 (새창열림)

'개발 > github' 카테고리의 다른 글

[github] 브랜치 룰 설정하기  (0) 2024.04.16
[github] github 대소문자 가릴줄 알게 만들기  (0) 2024.04.03
git pull --rebase 하는법  (0) 2024.03.19
git pull와 git pull --rebase의 차이점  (0) 2024.02.23
깃헙 프로필 꾸미기  (1) 2023.12.28

댓글

티스토리툴바