git | 2005년 리누스 토르발스가 처음 소개. 여러 명의 사용자들 간에 파일들의 작업을 조율하기 위한 Distributed Version Controll System(분산 버전 관리 시스템)으로 파일들을 추적하는 방식이다. 모든 파일들의 변경사항을 트래킹하고, 변경사항들을 허용함. 파일을 주시하며 관리해주는 도구. https://git-scm.com/ 사이트에서 git을 다운로드해야 한다.
github | Cloud Git Provider 중 하나. 같은 기능을 하는 Gitlab, Bitbucket 등이 있다. 작업한 git 파일(git 변경사항)들을 올리는 일종의 원격 저장소 또는 온라인 저장이며 파일들의 history들을 공유하기 위한 곳이라고도 할 수 있다.
버전 관리 (Version Control)
수정1, 수정2, 최종, 진짜최종, 진짜진짜_최종 등 여러가지의 파일 버전을 만들 필요 없이 파일 이름은 유지하면서 문서를 수정할 때마다 언제 수정했는지, 어떤 것이 변경되었는지 기록 가능하다.
백업 (Backup)
현재 내 컴퓨터에 있는 자료를 다른 곳에 복제하는 것으로 USB 디스크, 외장하드, 드롭박스(Dropbox) 등이 해당된다. 깃허브에 백업을 한다고 생각.
협업 (Collaboration)
팀원들이 파일을 편하게 주고받으면서 일할 수 있고, 누가 어느 부분을 수정했는지 기록에 남는다.
Git Bash로 환경설정
$ git config --global user.name "이름"
$ git config --global user.email "깃허브에 가입한 메일 주소"
$ git config --list <- 이름이랑 메일 주소 잘 입력되어 있는지 확인
git 버전 확인
$ git -v
줄바꿈 문자열
윈도우에서는 엔터 처리를 \r과 \n의 조합으로 인식하고, 맥에서는 \n으로만 인식한다. 이 충돌을 방지하기 위해 줄바꿈 문자열을 처리
Windows
$ git config --global core.autocrlf trueMac
$ git config --global core.autocrlf input
버전 만들기 (스테이지와 커밋)
Areas(Stage)
working area(working directory) | 텍스트 에디터에서 working을 하고 있는 공간
staging area | commit이 되기를 기다리고 있는 공간. 어떤 파일들이 commit될 건지, 어떤 것들이 다시 추가될 건지 등. 항상 모든 수정사항들은 staging area에 추가된다.
repository area | commit 된 파일들이 있는 공간.
커밋메시지 템플릿
################
# <타입> : <제목> 의 형식으로 제목을 아래 공백줄에 작성
# 제목은 50자 이내 / 변경사항이 "무엇"인지 명확히 작성 / 끝에 마침표 금지
# 예) feat : 로그인 기능 추가
# 바로 아래 공백은 지우지 마세요 (제목과 본문의 분리를 위함)
################
# 본문(구체적인 내용)을 아랫줄에 작성
# 여러 줄의 메시지를 작성할 땐 "-"로 구분 (한 줄은 72자 이내)
################
# 꼬릿말(footer)을 아랫줄에 작성 (현재 커밋과 관련된 이슈 번호 추가 등)
# 예) Close #7
################
# initial: 초기 세팅 추가
# feat : 새로운 기능 추가
# fix : 버그 수정
# build: 빌드 관련 수정
# chore : 빌드 부분 혹은 패키지 매니저 수정사항
# ci : CI 관련 설정 수정
# docs : 문서 수정
# style : 코드 의미에 영향을 주지 않는 변경사항
# refactor : 코드 리팩토링
# test : 테스트 코드 추가
# release : 버전 릴리즈
################
| git 명령어 | 실행 내용 |
| git init | 프로젝트를 처음에 올릴 때만 |
| git branch -M main | master가 아니라 main으로 브랜치 변경 (커밋 메시지 적은 후) |
| git remote add origin (원격 저장소 주소) |
repository 주소 가지고 와서 연결고리를 만듦 |
| git remote rm origin | 기존 repository 삭제 |
| git remote set-url origin (새로운 원격 저장소 주소) |
repository의 이름을 변경했을 때 연결고리를 바꿔줌 바꾼 이후에 git remote -v로 저장소가 바뀌었는지 확인 |
| git add . | 모든 파일을 더할 준비 |
| git add (커밋해서 푸시 할 파일 (ex. index.html)) | 파일 하나만 올리고 싶을 때 |
| git status | 파일 상태 확인 |
| git remote -v | 저장소 확인 |
| git commit -m "커밋 메시지" | 커밋 생성 |
| git commit -am "커밋 메시지" | add와 commit을 동시에. 단, 이전에 add를 한 번은 해야 사용할 수 있다. |
| git commit --amend -m "커밋 내용" |
마지막 커밋을 수정할 때. 파일을 하나 추가하지 않았거나 등의 이유로 사소한..? 수정을 하고 싶을 때 쓰는 것 같다. 만약 파일이 누락되어 추가한 후 커밋 수정을 하려면 'git add 추가파일' 이후로 amend를 실행해야 한다. |
| git push origin main | 저장소에 업로드 |
| 팀 프로젝트 할 때 | |
| git clone 프로젝트주소 코드다운받을폴더 | 깃허브에 있는 프로젝트 다운로드할 준비. cmd에서 실행해야 한다. 코드를 다운받은 후 cd 코드다운받을폴더 code . 으로 프로젝트 열기 |
| git switch -c freshman | 메인이 아닌 freshman이라는 다른 공간을 만들고 이동 |
| git push origin freshman | freshman이라는 branch에 파일 업데이트 |
| git branch -d (삭제할 브랜치) | 브랜치 삭제 |
| main 소스 가져오기 | |
| git pull origin main git pull upstream main |
소스를 가져오기 전, 내가 작성한 코드들을 저장하고 가져와야 한다. (add와 commit) commit까지 한 후, pull을 받고 push를 한다. |
| git checkout 브렌치이름 | 브랜치를 이동하고 싶을 때 |
| 브랜치를 마스터로 merge 하기 | |
| git remote update | 원격 저장소의 브랜치에 접근하기 위해 원격 저장소를 갱신 |
| git branch -r | 원격 저장소의 브렌치 리스트 확인 |
| git switch main | 메인으로 브랜치 이동 |
| git merge freshman | freshman을 메인으로 병합 |
| reset | |
| git log | 커밋 이력 확인 (변경된 파일 미리 보기는 할 수 없음) |
| git reset HEAD^ |
복합 리셋. 돌아간 커밋 이후 파일들은 Untracked로 바뀐다. unstage 영역에 추가된 것. HEAD를 과거의 커밋으로 보낸다. reset '^'의 갯수에 따라서 몇 번째 이전의 커밋으로 갈 건지 정할 수 있다 (^ : 1개 전, ^^ : 2개 전) |
| git reset --hard HEAD^ | hard 옵션. 리셋하는 파일들을 모두 삭제함 |
| git reset --soft HEAD^ | 복합 리셋과는 다르게 돌아간 커밋 이후 파일들의 변경사항을 unstage 영역에 추가하지 않고 stage 영역에 추가한다. |
| git push origin master --force | hard HEAD 이후 강제 푸시. 충돌 사항을 무시하고 싶을 때 (왜냐하면 코드 비교 없이 새로운 코드를 push할 거니까..?) |
| 과거의 commit으로 돌아가서 새 branch 만들기 | |
| git checkout (과거 commit) -b (브랜치 이름) | ex) git checkout 2f87a9a13d89e1091f2514a980960683aea593ab -b new_branch |
.gitignore | github에 올리고 싶지 않은 파일들의 리스트
| stage 영역에 추가된 파일 제외시키기 | |
| git rm -r (제거할 파일) --cached | -r은 폴더를 제외시킬 때 쓰고, 파일을 제외시킬때는 -r을 빼고 쓰면 된다. 제외시킬 파일은 미리 .gitignore에 추가한 후 실행. |
github desktop 기준
- master가 아닌 branch에서 master 변경사항을 업데이트하기
변경사항을 업데이트할 브랜치로 이동 -> Branch -> Update from Master - branch의 내용을 master로 merge 하기
master로 이동 -> Branch -> Merge into Current Branch -> Default Branch가 master 인지 확인 -> merge할 branch를 선택 - branch가 필요 없어졌다면 해당 branch로 이동 후 Branch -> Delete
- Conflicts in Branches
conflict이 있는 상태로 merge를 실행하면 vscode에서 볼 거냐는 상태창이 뜬다. vscode에서 열었을 때, current change는 현재 있는 branch에서 갖고 있는 것, imcoming change는 우리가 merge 하고 싶은 곳에서 온 것
Accept Current Change | Accept Incoming Change | Accept Both Changes | Compare Changes 중에서 Both Change는 잘 사용하지 않는다. Compare은 각각의 파일을 비교하는 것이며 최종적으로는 current 혹은 incoming 중에 선택하면 된다.
conflict이 사라졌으면 Commit merge 버튼을 클릭
Fork | git의 기능보다는 github의 기능이다. 한 repository를 가져와서 내 계정의 repository로 복사한다.
- New pull request | fork로 작업한 코드를 베이스 저장소에서 merge 해달라고 요청하는 것
- Merge pull request | 베이스 저장소를 만든 사람의 화면에서 볼 수 있는 것. 요청이 들어온 코드를 merge 할지 선택할 수 있다.
베이스 저장소의 작성자가 merge를 하게 되면 pull request가 닫히고, 원한다면 fork를 삭제할 수 있다.
※ fork 한 후에 베이스 저장소에서 변경이 일어난다면?
fork 한 repository에서 branch를 보면 upstream/master라는 branch가 있다. 해당 브랜치는 베이스 저장소의 마스터 브랜치와 커뮤니케이션하는 곳. fork 하면 기본적으로 만들어지는 브랜치이다.
upstream 브랜치를 통해 베이스 저장소의 변경사항을 요청받을 수 있는데 fork한 저장소의 master에서 fetch origin을 클릭하면 upstream에서 fetch를 하게 된다.
fetch 후 master로 upstream/master를 merge 하면 된다. 베이스 저장소에서 fork 할 당시의 커밋에서부터 베이스 저장소의 최신 커밋까지를 master로 병합하는 것.
병합 후 push origin master도 잊지 말 것
fetch -> merge -> push origin master
Issues | 프로젝트 관리 시스템을 위한 것.
프로젝트가 해야 하는데 아직 하지 않은 일이나, 사람들이 발견한 문제나 버그 같은 것을 기록한다. 오픈 소스에서 작업할 때 보거나 테스터들이 문제를 찾아서 이슈를 적을 때 볼 수 있다.
해결해야 할 문제들을 이슈에 적고 fork - Pull request를 진행한다. merge 요청 시 이 request는 해당 issue를 해결하기 위한 것이라고 설명. 이런 방식으로 프로젝트를 관리한다.
milestone | 버전을 올릴 때 필요한 것들을 모아두는 것. 마일스톤 안의 이슈들이 모두 해결되면 마일스톤이 달성되는 것이다.
CLI (terminal) 방식
- HEAD -> mater | 컴퓨터에 커밋된 것
- origin/master | github의 코드 저장소에 올라간 커밋
- 이전 커밋으로 되돌아가고 싶을 때
git checkout 2f87a9a13d89e1091f2514a980960683aea593ab
git checkout master를 하면 원래 상태로 돌아온다.
깃허브에서 static 호스팅을 무료로 제공한다. 단, 프론트엔드(HTML, CSS, JavaScript)만 가능. 백엔드는 불가능하다.
gh-pages branch를 생성한다.
사이트 링크를 확인하고 싶다면 Environments에 github-pages -> View deployment 클릭
페이지를 수정하고 싶을 때, 코드는 마스터에서 수정. 그 이후에 gh-pages도 업데이트를 해줘야 한다. (github desktop 이용 기준)
master -> commit -> push
Branch -> update from master -> push