Git 문법
1. commit 규칙
- feat: 주요파일 변경사항 설명
- fix: css나 이미지 변경 사항 설명
- docs: 주석만 변경 설명
이렇게 3가지 규칙으로 작성
2. Git 써보기
- git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
- git config user.name 'codeit' : 현재 사용자의 아이디를 'codeit'으로 설정(커밋할 때 필요한 정보)
- git config user.email 'teacher@codeit.kr' : 현재 사용자의 이메일 주소를 'teacher@codeit.kr'로 설정(커밋할 때 필요한 정보)
- git add [파일 이름] : 수정사항이 있는 특정 파일을 staging area에 올리기
- git add [디렉토리명] : 해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기
- git add . : working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기
- git reset [파일 이름] : staging area에 올렸던 파일 다시 내리기
- git status : Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력(문제 상황이 발생했을 때 현재 상태를 파악하기 위해 활용하면 좋음)
- git commit -m "커밋 메시지" : 현재 staging area에 있는 것들 커밋으로 남기기
- git help [커맨드 이름] : 사용법이 궁금한 Git 커맨드의 공식 메뉴얼 내용 출력
3. GitHub 시작하기
- git push -u(또는 --set-upstream) origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용합니다.
- git push : 위의 커맨드를 한번 실행하고 난 후에는 git push라고만 쳐도 로컬 레포지토리의 내용을 리모트 레포지토리에 올릴 수 있습니다.
- git pull : 바로 위의 위에 있는 커맨드를 한번 실행하고 난 후에는 git pull이라고만 쳐도 리모트 레포지토리의 내용을 로컬 레포지토리로 가져옵니다.
- git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기
4. Git에서 커밋 다루기
- git log : 커밋 히스토리를 출력
- git log --pretty=oneline : --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있습니다. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줍니다. --pretty 옵션에 대해 더 자세히 알고싶으면 **이 링크**를 참고하세요.
- git show [커밋 아이디] : 특정 커밋에서 어떤 변경사항이 있었는지 확인
- git commit --amend : 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦
- git config alias.[별명] [커맨드] : 길이가 긴 커맨드에 별명을 붙여서 이후로는 별명으로도 해당 커맨드를 실행할 수 있게 설정
- git diff [커밋 A의 아이디] [커밋 B의 아이디] : 두 커밋 간의 차이 비교
- git reset [옵션] [커밋 아이디] : 옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨)(2) staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행)그리고 이때 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^, HEAD~3)을 사용해도 됨
- (3) working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행)
- (1) HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행)
- git tag [태그 이름] [커밋 아이디] : 특정 커밋에 태그를 붙임
5. Git에서 브랜치 사용하기
- git branch [새 브랜치 이름] : 새로운 브랜치를 생성
- git checkout -b [새 브랜치 이름] : 새로운 브랜치를 생성하고 그 브랜치로 바로 이동
- git branch -d [기존 브랜치 이름] : 브랜치 삭제
- git checkout [기존 브랜치 이름] : 그 브랜치로 이동
- git merge [기존 브랜치 이름] : 현재 브랜치에 다른 브랜치를 머지
- git merge --abort : 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감
6. Git 실전 I
- git fetch : 로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴(가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음)
- git blame : 특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력
- git revert : 특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성
7. Git 실전 Ⅱ
- git reflog : HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력
- git log --all --graph : 모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력
- git rebase [브랜치 이름] : A, B 브랜치가 있는 상태에서 지금 HEAD가 A 브랜치를 가리킬 때, git rebase B를 실행하면 A, B 브랜치가 분기하는 시작점이 된 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어붙여짐(git merge와 같은 효과를 가지지만 커밋 히스토리가 한 줄로 깔끔하게 된다는 차이점이 있음)
- git stash : 현재 작업 내용을 스택 영역에 저장
- git stash apply [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용
- git stash drop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 스택에서 삭제
- git stash pop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용하면서 스택에서 삭제
- git cherry-pick [커밋 아이디] : 특정 커밋의 내용을 현재 커밋에 반영
! 그 밖에 알아야할 사실
(1) git commit이라고만 쓰고 실행하면 커밋 메시지를 입력할 수 있는 텍스트 에디터 창이 뜹니다. 거기서 커밋 메시지를 입력하고 저장하고 나면 커밋이 이루어집니다.
(2) git push와 git pull은 그 작업 단위가 브랜치입니다. 예를 들어, master 브랜치에서 git push를 하면 master 브랜치의 내용만 리모트 레포지토리의 master 브랜치로 전송되지, premium 브랜치의 내용이 전송되는 것은 아닙니다.(git push에 --all이라는 옵션을 주면 모든 브랜치의 내용을 전송할 수 있기는 합니다.)
작업 수행 방식
- git pull: 먼저 원격 저장소에서 최신 코드를 받아옵니다. 이를 통해 현재 로컬 코드가 최신 상태인지 확인하고, 다른 사람이 진행한 작업을 로컬 리포지토리에 포함시킵니다.
- git checkout -b add_profile_page: 새로운 기능을 위한 브랜치를 생성합니다. 이 브랜치는 "사용자 프로필 페이지"를 추가하는 작업을 포함하며, 브랜치 이름에 이 내용을 반영하는 것이 좋습니다.
- git add -A: 새로운 프로필 페이지에 필요한 모든 파일과 변경 사항을 staging area에 추가합니다. 이는 새로운 HTML, CSS, JavaScript 파일 등이 될 수 있습니다.
- git commit -m "feat: add user profile page": staging area에 있는 변경사항을 커밋하여, 작업 내용에 대한 스냅샷을 생성합니다.
- git push: 커밋한 변경 사항을 원격 저장소에 푸시합니다. 이를 통해 다른 팀원들이 이 변경 사항을 볼 수 있게 됩니다.
git pull → 브랜치 생성 (git checkout -b) → 변경 사항 커밋 (git add & git commit) → git push
1. 이슈 만들기
Issue 탭에 들어가서 본인이 어떤 작업을 할 것인지 이슈를 생성합니다. [Issue] - [New Issue] 클릭
n
기능 관련 이라면, Feat 템플릿을 Get Started 하고, bug수정을 위한 개발이라면 bug 탬플릿을 이용합니다.
이슈 사항, 개발관련 사항을 아래 markdown 문법 형식을 지켜서 작성합니다.
이슈 생성이 완료되면, 아래와 같이 이슈가 생성되고, 오른쪽에 #N 이라고 이슈번호가 생성됩닌다. 지금은 #1번이네요!
2. branch 만들기
이슈번호와 일치하게 branch를 생성해 줄겁니다. 보통 github desktop을 사용하시니, 그걸 기준으로 말씀드릴게요.
일단 저희가(?)제가(?) 정한 규칙은 아래와 같습니다.
<aside> ✔️ #이슈넘버/feat/기능설명
</aside>
혹시 bug 관련이라면, #4/bug/modifyUIButtonSize 이런식으로 하면 될것같습니다.
3. commit 잘게 쪼개서 하기
<aside> ⚠️ commit 메시지 규칙 잘 지켜서 commit 하기
</aside>
4. branch에 할당된 기능 구현 완료 후 PR 날리기
branch가 만약 “UIButton 생성” 이라면, UIButton이 완료되는 커밋을 기준으로 pull request 를 날립니다.
pull request를 날릴 때도, 제목과 적당한 설명을 덧붙여 PR를 날립니다!
PR 한번 날릴 때, 해당 branch에서 작업한 commit 들이 모아져서 한번에 날려집니당.
5. Issue에 commit 고유번호 남기기
issue에 comment로 본인이 어떻게 커밋을 남겼는지 커밋 고유번호를 남겨줍니다.
5. PR날리고 팀원들에게 승인받기
PR 날린채로, 팀원들에게 공유합니다. 그리고 팀원들이 ok 하면 머지 go!
충돌위험이 있기 때문에 주로 다같이 동의 후, 한명이 머지할 예정입니다.