깃허브(GitHub) 정리

영민·2023년 8월 7일

git github 깃 깃허브

Git & GitHub

목록 보기

4/4

깃허브를 사용하면서 코드 작성 후 업로드만 해보고 다른 기능들을 사용 해본적이 없어서 기능들을 한번씩 적용시키며 정리 해보려고 합니다.

📌 깃허브(GitHub)란?

분산 버전 관리 소프트웨어인 Git을 기반으로 소스코드를 공유하고, 다른 프로그래머들과 함께 협업할 수 있게 도와주는 플랫폼입니다.

비공개 저장소를 통해 비공개 프로젝트를 관리하거나 조직 내에서 소스 코드를 관리하는 데에도 사용됩니다.

📝 Repository 작업 과정

1. Repository 생성

깃허브에 로그인 한 후 New 를 클릭합니다.

메인 화면 리포

프로필 내 리포

2. Repository 상세 내용 입력

Repository 에 적용시킬 내용을 입력 후 Create repository 버튼을 클릭합니다.

Repository name : 생성 할 리포지토리 이름을 작성합니다.
Description : 생성 할 리포지토리에 대한 설명을 작성합니다.
Public : 생성 할 리포지토리를 모든 사람들에게 공개합니다.
Private : 생성 할 리포지토리를 내가 선택한 사람만 접근 가능합니다.
README file : 생성 할 리포지토리에 대한 설명, 사용 방법, 라이센스 등의 내용을 작성합니다.
.gitignore : 특정 파일이나 디렉토리를 git 버전 관리에서 의도적으로 추적하지 않도록 설정하는 파일 입니다.

3. Repository 생성

<> Code 버튼을 눌러서 Clone에 있는 HTTPS 주소를 복사합니다.

repo

4. 작업 폴더 생성

텍스트 에디터 접속 후 원하는 작업 폴더 열기 & 폴더 생성 합니다.

5. 터미널 명령어 작성

폴더 열기 후 텍스트 에디터 에서 새 터미널 또는

Finder(폴더) 에서 해당 폴더 폴더에서 새로운 터미널 열기 후 깃허브 Repository 와 연동하는 명령어를 작성합니다.

5.1 git 초기 설정

로컬 저장소에서 기본값으로 사용할 Git 사용자 이름과 이메일을 설정합니다.

git config --global user.name "본인 이름"
git config --global user.email "본인 이메일"

git config --global --list 입력 시 이름과 이메일 조회를 합니다.

브랜치명 main 변경

깃허브의 초기 브랜치명은 main 브랜치 입니다.
git config --global init.defaultBranch main 으로 브랜치명을 main 으로 변경 가능합니다.

5.2 git init, git remote

git init : Git 저장소를 새로 만드는 명령 입니다.
버전 관리를 하지 않은 기존 프로젝트를 Git 저장소로 변환하거나 새로운 빈 저장소를 생성하고 초기화하는 경우에 사용합니다.

git remote : 외부 저장소와 연결 작성, 내용 확인, 삭제하는 명령입니다.

git init 으로 test 폴더를 Git 저장소로 변환 후
git remote add origin url 으로 깃허브에서 생성 한 Repository 와 연결 합니다.

git remote -v 입력 시 현재 연결된 origin url 을 확인 가능합니다.

5.2 git clone

git clone : 기존 리포지토리를 대상으로 하여 복제본 또는 대상 리포지토리의 복제본을 만드는 데 사용되는 Git 명령줄 유틸리티 입니다.

git clone url 으로 원하는 Repository 를 복제 가능합니다.

clone 시 자동으로 remote url 이 등록됩니다.

6. 파일 생성 후 add, commit, push

깃허브에 올릴 파일을 생성 후
1. 해당 파일을 add 합니다.
2. 파일에 대한 설명을 작성 후 commit 합니다.
3. 설명이 적혀있는 파일을 깃허브에 push 합니다.

6.1 add

깃허브에 올릴 파일을 add 합니다.

파일 생성 후 저장 시 vscode 의 소스제어에 숫자가 생기고, 변경사항이 추가됩니다.

현재 저장 후 add 를 하지 않은 상태이므로 해당 파일은 추적 되지 않는 상태 입니다.

git add 파일명 을 입력 시 변경사항에서 스테이징된 변경 사항으로 이동합니다.

git add . 을 입력 시 모든 파일이 스테이징 됩니다.

파일 추적 및 스테이징 에 대한 내용은
Git & Github 시리즈의 깃(Git) 정리 글을 참고하시면 도움됩니다.

6.2 commit

add 한 파일에 대한 설명을 적습니다.

commit 을 하게되면 소스 제어에서 commit 한 파일이 없어집니다.

6.3 push

commit 된 파일을 깃허브에 push 합니다.

git push -u origin main 을 입력 시 커밋된 내용이 깃허브로 업로드 됩니다.

-u 를 사용하게 되면 이후에 간단하게 같은 브랜치에서 git push 명령어만 입력해도 자동으로 설정된 원격 저장소와 브랜치로 푸시됩니다.

첫 push 이후에는 git push origin main 을 입력하면 됩니다.

7. Repository 삭제

Repository 를 삭제 합니다.

7.1 Settings

해당 Repository 에 있는 Settings 을 클릭합니다.

7.2 Delete this repository

Settings 의 General 에서 제일 밑으로 가서
Delete this repository 버튼을 클릭합니다.

클릭 후 I want to delete this repository 를 클릭합니다.

입력칸에 깃허브 이름 / Repository 명 을 입력 후
Delete this repository 를 클릭하면 해당 Repository 가 삭제됩니다.

✉️ Commit 메세지 스타일

커밋 메세지를 작성 할 때 규칙을 정해서 개인 / 팀 에서 사용하게 되면 커밋 메세지로 얻을 수 있는 장점이 있습니다.

더 좋은 커밋 로그 가독성
더 나은 협업과 리뷰 프로세스
더 쉬운 코드 유지보수

커밋 메세지 만으로도 어떤 수정 사항이 발생 했는지 파악하는데 도움이 됩니다.

커밋 메시지를 작성하기 위한 7가지 약속

아래 내용은 커밋 메세지를 영어로 작성 시 최적화 되어 있습니다.

제목과 본문을 한 줄 띄워 분리하기
제목은 영문 기준 50자 이내로
제목 첫글자를 대문자로
제목 끝에 . 금지
제목은 명령조로
본문은 영문 기준 72자마다 줄 바꾸기
본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기

커밋 메세지 타입

타입은 태그 : 제목 으로 구성 되며
태그는 영어 로 작성하고 첫 문자를 대문자 로 작성합니다.
ex) Feat: Create index.html

feat : 새로운 기능 추가
fix : 버그 수정
docs : 문서 수정
style : 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등)
design : 사용자 UI 디자인 변경 (CSS 등)
test : 테스트 코드, 리팩토링 (Test Code)
refactor : 리팩토링 (Production Code)
build : 빌드 파일 수정
ci : CI 설정 파일 수정
perf : 성능 개선
chore : 자잘한 수정이나 빌드 업데이트
rename : 파일 혹은 폴더명을 수정만 한 경우
remove : 파일을 삭제만 한 경우

팀원 간 소스코드가 충돌하지 않도록 적어도 하루에 한번은 커밋 해주는 것이 좋습니다.

📝 README

README 는 디렉토리나 압축 파일에 포함된 기타 파일에 대한 정보를 가지고 있으며, 일반적으로 소트프웨어와 함께 배포됩니다.

깃허브에서는 해당 저장소에 대한 설명, 기능, 사용방법, 라이선스 정보 등을 작성합니다.

README.md 에서 md는 Markdown(마크다운) 문법을 사용하기 때문에 확장자는 .md 를 사용합니다.

Markdown(마크다운) 작성법은 Git & Github 시리즈의 마크다운(MarkDown) 정리글을 참고하시면 도움됩니다.

📝 .gitignore

gitignore 는 프로젝트 작업시 로컬 환경의 정보나 빌드 정보등 원격 저장소에 관리하지 말아야되는 파일들에 대해서 지정하여 원격 저장소에 실수로 올라가지 않도록 관리하는 파일 입니다.

gitignore 파일 생성

.gitignore 파일은 프로젝트 최상위 위치에 존재합니다.

아래의 패턴을 활용하여 git이 untracked할 파일 또는 디렉토리등 을 정의하여 파일을 생성합니다.

'#'로 시작하는 라인은 무시합니다.
표준 Glob 패턴을 사용합니다.
슬래시(/)로 시작하면 하위 디렉터리에 적용되지(recursivity) 않습니다.
디렉터리는 슬래시(/)를 끝에 사용하는 것으로 표현합니다.
느낌표(!)로 시작하는 패턴의 파일은 무시하지 않습니다.

gitignore.io

https://www.gitignore.io/ 에서 원하는 ignore 파일을 생성할 수 있습니다.

아래 예시는 node, macOS 에 대한 ignore 파일 입니다.

# Created by https://www.toptal.com/developers/gitignore/api/node,macos
# Edit at https://www.toptal.com/developers/gitignore?templates=node,macos

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

### Node ###
# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*
.pnpm-debug.log*

# Diagnostic reports (https://nodejs.org/api/report.html)
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json

# Runtime data
pids
*.pid
*.seed
*.pid.lock

# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov

# Coverage directory used by tools like istanbul
coverage
*.lcov

# nyc test coverage
.nyc_output

# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
.grunt

# Bower dependency directory (https://bower.io/)
bower_components

# node-waf configuration
.lock-wscript

# Compiled binary addons (https://nodejs.org/api/addons.html)
build/Release

# Dependency directories
node_modules/
jspm_packages/

# Snowpack dependency directory (https://snowpack.dev/)
web_modules/

# TypeScript cache
*.tsbuildinfo

# Optional npm cache directory
.npm

# Optional eslint cache
.eslintcache

# Optional stylelint cache
.stylelintcache

# Microbundle cache
.rpt2_cache/
.rts2_cache_cjs/
.rts2_cache_es/
.rts2_cache_umd/

# Optional REPL history
.node_repl_history

# Output of 'npm pack'
*.tgz

# Yarn Integrity file
.yarn-integrity

# dotenv environment variable files
.env
.env.development.local
.env.test.local
.env.production.local
.env.local

# parcel-bundler cache (https://parceljs.org/)
.cache
.parcel-cache

# Next.js build output
.next
out

# Nuxt.js build / generate output
.nuxt
dist

# Gatsby files
.cache/
# Comment in the public line in if your project uses Gatsby and not Next.js
# https://nextjs.org/blog/next-9-1#public-directory-support
# public

# vuepress build output
.vuepress/dist

# vuepress v2.x temp and cache directory
.temp

# Docusaurus cache and generated files
.docusaurus

# Serverless directories
.serverless/

# FuseBox cache
.fusebox/

# DynamoDB Local files
.dynamodb/

# TernJS port file
.tern-port

# Stores VSCode versions used for testing VSCode extensions
.vscode-test

# yarn v2
.yarn/cache
.yarn/unplugged
.yarn/build-state.yml
.yarn/install-state.gz
.pnp.*

### Node Patch ###
# Serverless Webpack directories
.webpack/

# Optional stylelint cache

# SvelteKit build / generate output
.svelte-kit

# End of https://www.toptal.com/developers/gitignore/api/node,macos

💡 Issues, Labels, Milestones

Issue

Issue 는 프로젝트를 진행하면서 다양한 이벤트들을 의미합니다.

발견된 버그나 추가할 기능, 개발해야 할 새로운 이슈나 설계사항들을 이슈로 만들어서 동료들과 협업을 진행할 수 있습니다.

Issue 작업 과정

깃허브 Repository 의 Issues 탭에서 새로운 Issue 를 생성할 수 있습니다.

해당 Repository 에서 이슈를 생성할 수 있는 권한을 가지고 있어야 합니다.

Issues 탭에서 New Issue 버튼을 클릭합니다.

제목(Title) 과 내용(comment) 를 작성 후 Submit new issue 버튼을 클릭합니다.

Issue 작성 화면의 오른쪽에서 Assigness 를 지정할 수 있습니다.

해당 Issue에 대한 내용의 해결 및 커뮤니케이션을 할 수 있습니다.

Assigness 는 최대 10명까지 지정할 수 있습니다.

해결된 Issue는 Close issue 버튼을 클릭 후 닫아줍니다.

Issue가 닫힌 후 나중에도 볼 수 있습니다.

닫힌 Issue를 Reopen issue 버튼을 클릭 후 다시 열 수 있습니다.

Issue 페이지의 하단에 Delete issue 를 클릭 후 이슈를 삭제할 수 있습니다.

Issue 를 삭제하면, 이슈에 대한 내용이 완전히 지워지고 나중에 다시 볼 수 없습니다.

히스토리를 남기기 위해 Delete issue 보다는 Close 를 하는 것이 좋습니다.

Transfer issue 를 클릭 후 해당 이슈를 다른 저장소로 이전(Transfer) 할 수 있습니다.

사용자 문의, 사용자로부터 받은 버그를 내부 작업용으로 돌리거나, 내부 저장소에서 다루던 이슈를 공론화 시키고 싶을 때 사용할 수 있습니다.

중요한 Issue 는 Pin Issue 를 클릭 후 Issue 탭 상단에 고정 할 수 있습니다.

프로젝트 진행 사항 페이지나 중요한 설계 이슈, 꼭 논의해야 하는 이슈 등 Pin 을 합니다.

Label

저장소에서 발생하는 다양한 이벤트, 협업 등 이슈로 만들어 집니다.

각 이슈가 어떤 종류인지 구별하기 위해 라벨(Label) 기능을 사용할 수 있습니다.

이슈에 라벨을 붙혀 각 이슈가 버그인지, 문서작성을 위한 이슈인지 등 빠르게 확인할 수 있습니다.

라벨은 Issues , Pull requests 에서 사용 가능합니다.

Labels 를 클릭 후 해당 페이지에서 이슈에 붙일 라벨은 새로 추가하거나 제거, 편집할 수 있습니다.

Milestones

마일스톤(Milestone) 은 유사한 이슈들을 하나로 모아 일정관리를 할 수 있는 기능 입니다.

마일스톤 기능은 스프린트(Sprint) 개발 방법론을 지원하기 위한 기능입니다.

개발 목표를 마일스톤으로 만들어 두고, 관련된 이슈들을 생성합니다.

엮여 있는 이슈들을 Open, Close 상태를 추적하여 전체 이슈 중 몇 개의 이슈가 Close 되었는지 추적해서 마일스톤의 진척상황을 퍼센트로 보여줍니다.

Milestone 작업 과정

Issues 탭에서 Milestones 을 클릭 후 New milestone 버튼을 클릭합니다.

제목(Title) , 설명(Description) 을 작성 후 Create milestone 버튼을 클릭합니다.

이슈(Issue) 탭에서 마일스톤에 해당하는 이슈를 클릭합니다.

이슈 페이지 우측에 있는 Milestone 를 클릭 후 해당하는 마일스톤을 클릭합니다.

해결한 이슈에 대해서 마일스톤의 진행률이 올라갑니다.

마일스톤에 있는 이슈를 전부 해결한 뒤 마일스톤을 Close 해줍니다.

📌 Fork

Fork 는 오픈 소스 프로젝트를 공부하거나 Contributors가 되고 싶을 때, 해당 원격 저장소를 자신의 원격 저장소로 복사할 수 있습니다.

깃허브의 경우 공개된 모든 자료가 오픈 소스로 다른 사람의 자료를 Fork 할 수 있습니다.

오픈 소스 프로젝트 Fork 과정

아래 링크 접속 후 우측 상단의 Fork 버튼을 클릭합니다.
https://github.com/facebook/react

Repository name, Description 을 입력 후 Create fork 버튼을 클릭합니다.

본인이 설정한 저장소 이름으로 Repository 가 생성됩니다.

해당 Repository 를 clone(복제) 후 자유롭게 사용 가능합니다.

📌 Pull Request

Pull Request 는 다른 사용자가 작성한 저장소에서 변경 사항을 병합(merge) 하기 위한 요청을 의미합니다.

오픈소스 프로젝트에서 많이 활용되며, 다수의 개발자들이 하나의 프로젝트를 함께 개발할 때 사용합니다.

Pull Request의 장점

Pull Request 는 개발자들 간의 협업에 있어서 다음과 같은 장점을 가지고 있습니다.

코드 리뷰 : 다른 개발자들이 작성한 코드를 리뷰할 수 있습니다. 코드 리뷰를 통해 전체적인 코드 품질을 향상시킬 수 있습니다.
개발 생산성 : 여러 개발자들이 하나의 오픈소스에 기여하고, 변경 사항이 충돌하지 않도록 관리할 수 있습니다.
투명한 협업 : 다른 개발자들이 작성한 코드를 쉽게 볼 수 있고, 코드 리뷰나 논의를 통해 투명한 협업이 가능합니다.
버그 발견 및 수정 : 버그를 발견하고 수정하는 과정을 간소화할 수 있습니다. 다른 개발자들이 작성한 코드를 검토하면서 버그를 발견하고 수정하는 것이 가능합니다.
커뮤니티 참여 : 깃허브에는 많은 오픈소스 프로젝트가 있는데, 이러한 프로젝트에 참여하면 자신의 기술력을 향상시키는 것 뿐만 아니라 개발 커뮤니티에서 활발하게 활동할 수 있습니다.

Pull Request 작업 과정

깃허브에 원하는 Repository를 Fork 합니다.

Fork 한 Repository를 Clone 합니다.

원본 Repository remote 설정을 합니다.

원본 Repository 내용과 동기화 하기 위해 Fork 한 Repository에 remote 등록을 합니다.

새로운 Branch를 생성 후 이동합니다.

프로젝트 진행 시 브랜치 분기는 필수 입니다.

브랜치 관련 내용은 Git & Github 시리즈의 깃(Git) 정리 글을 참고하시면 도움됩니다.

코드 작업 후 Add / Commit / Push 를 진행합니다.

Fork 한 Repository에 Push 내용이 반영 됩니다.

Compare & pull request 버튼을 클릭합니다.

제목 및 내용을 입력 후 Create pull request 버튼을 클릭합니다.

Pull Request를 받은 원본 Repository 관리자는 내용을 확인 후 Merge pull request 버튼을 클릭합니다.

해당 Pull Request에 대한 Comment 작성도 가능합니다.

Merge 에 대한 내용을 입력 후 Confirm merge 버튼을 클릭합니다.

Confirm merge 후 Main 브랜치로 Merge 됩니다.

References

https://meetup.nhncloud.com/posts/106

https://udacity.github.io/git-styleguide/

https://brownbears.tistory.com/233

https://velog.io/@psk84/.gitignore-적용하기

https://hbase.tistory.com/211

https://bulmang-ios.tistory.com/60