[UMC] 2주차💭 - Git

Madeline👩🏻‍💻·2022년 9월 28일

git github 깃 깃허브

개발 지식

목록 보기

4/9

Git이란? Git과 Github 차이
1. 커밋 규칙?
Github desktop이나 Git 이용해서 Github에 간단한 커밋 해보기

Git?

: 개발계의 SNS.
-개발 프로젝트를 위한 소스코드 관람, 버그 관리, SNS 기능 등

1. Repository

-로컬 저장소: 자신의 컴퓨터
-원격 저장소: 서버 등 네트워크
: 로컬 저장소에서 작업 수행 => 원격 저장소에 저장

2. Branch

-여러 버전을 관리하기 위한 기능
-흐름을 나눠 기록한다.
-같은 저장소에서 각자 개발할 수 있다.

0. 커밋 메시지의 7가지 규칙

  1. 제목과 본문을 빈 행으로 구분한다
  2. 제목을 50글자 내로 제한
  3. 제목 첫 글자는 대문자로 작성
  4. 제목 끝에 마침표 넣지 않기
  5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다
  6. 본문의 각 행은 72글자 내로 제한
  7. 어떻게 보다는 무엇과 왜를 설명한다

< 커밋 메시지 구조 >
헤더는 필수이며, 범위(scope), 본문(body), 바닥글(footer)은 선택사항입니다.

<type>(<scope>): <subject>          -- 헤더
<BLANK LINE>
<body>                              -- 본문
<BLANK LINE>
<footer>                            -- 바닥글

은 해당 커밋의 성격을 나타내며 아래 중 하나여야 합니다

feat : 새로운 기능에 대한 커밋
fix : 버그 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋
ci : CI관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋

는 본문으로 헤더로 표현할 수 없는 상세한 내용을 적습니다.

헤더로 표현이 가능하다면 생략 가능합니다.

는 바닥글로 어떤 이슈에서 왔는지 같은 참조 정보들을 추가하는 용도로 사용합니다 예를 들어 특정 이슈를 참조하려면 close #1233 과 같이 추가하면 됩니다. close는 이슈를 참조하면서 main브랜치로 푸시될 때 이슈를 닫게 됩니다.

참조: https://simbasimba.tistory.com/34

1. fork

gitgub에서 Repository를 확인한다.
fork 버튼을 누른다.
Create fork => (github아이디)/(Repository이름) 이 뜨면 성공!
초록색 Code 버튼 -> URL 복사
(fork해온 repository를 clone해온다.)
cmd 창에서 원하는 폴더로 이동하여 clone 해준다.
복사한 URL을 붙여넣어 clone한다.
명령어: git clone {복사한 URL}
clone한 폴더로 이동한다. 여기서 원하는 이름의 폴더를 생성한다.
다시 cmd로 돌아가 Repository로 이동한다.

git add .
git commit -m "~~"
git push

git add : working directory(clone을 받은 폴더)에 내용을 추가했으면 staging area(working derectory와 저장소 사이에 존재하는 가상의 영역)으로 내용을 보내야 하는데 그 명령어가 add!
git commit : add한 파일들을 clone 받은 repo(원본x 로컬0)에 보내기
git push : 로컬 repo에 올린 내용을 원본 repo에 보내기

깃허브에서 fork한 repository를 확인해보면 업데이트 되어 있음을 확인할 수 있다!

2. Pull request

Pull requests 버튼 클릭
초록색 New pull request 버튼
Create pull request
comment에 내용 작성(선택)
관리자가 내용 확인 후 Merge를 진행하면 원본 repository에 변경 내용이 적용된다!

3. 주의사항

Readme.md 오류가 나면 Readme.md 파일을 수정해서 conflict를 해결한다.
오류가 났을 때는 원인을 찾은 후 Commit, push, pull request 진행한다. 오류 나서 파일이 날아가는 경우도 있다고 한다.
기능 개발용 브랜치를 만든다.
master 브랜치에 오류가 생기면 마찬가지로 파일이 날아갈 위험이 있다.
꼭 브랜치를 나눠서 (feature/~) 오류가 생겨도 백업할 수 있게 협업한다.
Pull request의 제목과 내용은 수정이 되지 않아, 자신이 수정한 부분에 대한 자세한 설명이 필요하다.

Madeline👩🏻‍💻

Major interest in iOS 🍀 & 🍎

이전 포스트

[UMC] 🛒1주차 - 안드로이드 스터디

다음 포스트