📢 day05__GIT특강
💡 Recap
- 깃은 왜 쓰는걸까?
- 버전관리를위해서 사용하는것임
- 백업(git add, git commit git push), 복구(gir reset), 협업(gir clone, pull, branch, merge) 을 통해서 버전관리를 만듦.
- Git-hub 포트폴리오
- 1일 1커밋 or TIL을 통해서 깃헙에 올려 내 포트포리오을 만들 수 있음.
- CLI, VScode, Markdown 을알아야 Git을 이해하기 편함. Git은 CLI만으로만 사용이 가능하다.
- 블로그내용들이 보기 편하고 좋으나 잘못된 정보도 있을수 있어 공식문서를 활용하는것을 추천함.
- 깃은 WorkingDirectory -> Staging Area -> Commits 과정으로 저장됨.
- 절대하지 말아야할 3가지, 아래 3가지를 할경우 git에서 충돌이 생길 경우가 있다. (.git은 관리하는 프로젝트에 하나만 있어야한다!)
- git init을 두번 하지않는것.
- git init을 상위폴더에 또 하지 말것.
- git-hub에서 변경하지 말것
💡 Gitignore
- girignore를 통해서 내가 커밋하기 원하지 않는 파일들 .gitignore 파일안에 두어서 관리가 가능하다.
[git ignore link](https://www.toptal.com/developers/gitignore)
- gitignore.io 웹사이트를 통해서 운영체제,개발환경프로젝트,개발언어를 선택해서 필요가 없는 목록들을 추가 할 수 있다.
(1).gitignore에 작성하는 목록
- 민감한 개인 정보가 담긴 파일(전화번호, 계좌번호, 각종 비밀번호, API KEY 등)
- OS에서 활용되는 파일
- IDE(통합 개발 환경) 혹은 Text editor(vscode)등에서 활용되는 파일.
- 개발 언어 혹은 프레임워크에서 사용되는 파일
(2).gitignore 작성시 주의 사항
- 반드시 이름을 .gitnore로 작성 접 (.)은 숨김파일이라는 뜻
- .gitignore 파일은 .git폴더와 동일한 위치에 생성한다.
- 제외 하고 싶은 파일은 반드시 `git add` 전에 `.gitignore`에 작성한다.
- `git add` 이후 작성하면 그 파일은 버전 관리의 대상으로 여겨지며, 한번 버전 관리 대상이 된 파일은 이후에 `.gitignore`작성하더라도 무시되지 않고 게속 버전 관리의 대상으로 인식이 되어 추후에 충톨이나 오류가 날 수 있다.
(3)Git 작성 패턴규칙
- 아무것도 없는 라인이나, `#`로 시작하는 라인은 무시합니다.
- `슬래시(/)`로 시작하면 하위 디렉터리에 재귀적으로 적용되지 않습니다.
- 디렉터리는 `슬래시(/)`를 끝에 사용하는 것으로 표현합니다.
- `느낌표(!)`로 시작하는 패턴의 파일은 ignore(무시)하지 않습니다.
- 표준 Glob 패턴을 사용합니다.
- `*(asterisk)`는 문자가 하나도 없거나 하나 이상을 의미합니다.
- `[abc]`는 중괄호 안에 있는 문자 중 하나를 의미합니다.
- `물음표(?)`는 문자 하나를 의미합니다.
- `[0-9]`처럼 중괄호 안에 하이픈(-)이 있는 경우 0에서 9사이의 문자 중 하나를 의미합니다.
- `**(2개의 asterisk)`는 디렉터리 내부의 디렉터리까지 지정할 수 있습니다. (`a/**/z`라고 작성하면 `a/z`, `a/b/z`, `a/b/c/z` 까지 모두 영향을 끼칩니다.
(4)패턴 예시
# .gitignore
# 확장자가 txt인 파일 무시
*.txt
# 현재 확장자가 txt인 파일이 무시되지만, 느낌표를 사용하여 test.txt는 무시하지 않음
!test.txt
# 현재 디렉터리에 있는 TODO 파일은 무시하고, folder/TODO 처럼 하위 디렉터리에 있는 파일은 무시하지 않음
/TODO
# build/ 디렉터리에 있는 모든 파일은 무시
build/
# folder/notes.txt 파일은 무시하고 folder/child/arch.txt 파일은 무시하지 않음
folder/*.txt
# folder 디렉터리 아래의 모든 .pdf 파일을 무시
folder/**/*.pdf
💡 원격 저장소 가져오기.
(1) git clone
- 원격 저장소의 커밋 내역을 모두 가져와서, 로컬 저장소를 생성하는 명령어.
- 원격저장소를 통째로 복제해서 내 컴퓨터에 옮기는것. (다운로드 개념과 일치.)
- `git clone <원격 저장소 주소>` 형태로 작성한다.
- `git clone`을 통해 생성된 저장소는 `git init` 과 `git remote add`가 이미 수행되있다.
- "폴더생성 -> git init -> commit 받아오기 -> git remote add" 의 전과정을 수행함.
(2)git pull
- 원격 저장소의 변경 사항을 가져와서, 로컬 저장소를 업데이트 하는 명령어.
- 로컬 저장소와 원격 저장소의 내용이 완전 일치하면 `git pull`을 해도 변화가 일어나지 않는다.
- `git pull <저장소 이름><브랜치 이름>`의 형태로 작성
(3)git pull의 비정상적인 흐름
- **git-hub은 업데이트가 되고, 나는 업데이트안된 상태서 수정후 git push한경우.**
- **내 컴퓨터와 강의장 컴퓨터에서 서로 다른 파일을 수정한 경우**
- 정상적으로 git pull이 된다.
- **내 컴퓨터와 강의장 컴퓨터에서 같은 파일을 수정했지만, 수정한 라인이 다른 경우**
- 정상적으로 git pull이 된다.
- **내 컴퓨터와 강의장 컴퓨터에서 같은 파일의 같은 라인을 수정한 경우**
- 충돌(conflict)이 발생, 어느 내용을 반영할지 직접 선택해야 한다.
- pull -> 충돌발생. -> 데이터 선택 -> add -> commit -> push
- **내 컴퓨터와 강의장 컴퓨터에서 서로 다른 파일을 수정한 경우**
💡 Branch
- 동시에 작업하기 위해서 branch개념을 사용한다. master(main)은 기둥이고 branch 는 나뭇가지이다.
- 작업 공간을 나누어 독릭접으로 작업할 수 있도록 도와주는 Git의 도구이다.
- **브랜치의 장점**
- 독립 공간을 형성하기 때문에 원본(main)에 대해 안전하다.
- 하나의 작업은 하나의 브랜치로 나누어 진행되므로 체계적인 개발이 가능하다.
- Git은 브랜치를 만드는 속도가 굉장히 빠르고, 용량이 적어 작업이 용이하다.
- **브랜치를 써야하는 이유**
- master branch는 상용을 의미한다. 그래서 언제든 세상에 공개되어 있다.
- 만약 상용에 상용에 에러가 있을 경우
- 고객이 사용하고 있는데(서비스중), 함부로 버전을 되돌리거나 삭제할 수 있다.
- 브랜치를 통해 별도의 작업 공간을 만들고, 그곳에서 되돌리거나 삭제가 가능하다.
- 브랜치는 완전하게 독립이 되어있어서 어떤 작업을 해도 master에는 영향을 끼치지 않는다.
- 브랜치를 통해 에러가 해결 되었다면, 후에 master에 반영(merge)할 수 있다.
- Git에서 branch는 가장 강력한 기능 중 하나이다.
💡 Command
(1)git branch : 조회,생성, 삭제 관련된 GIT 명령어
# 브랜치 목록 확인
$ git branch
# 원격 저장소의 브랜치 목록 확인
$ git branch -r
# 새로운 브랜치 생성
$ git branch <브랜치 이름>
# 특정 커밋 기준으로 브랜치 생성
$ git branch <브랜치 이름> <커밋 ID>
# 특정 브랜치 삭제
$ git branch -d <브랜치 이름> # 병합된 브랜치만 삭제 가능
$ git branch -D <브랜치 이름> # (주의) 강제 삭제 (병합되지 않은 브랜치도 삭제 가능)
git switch : 현재 브랜치에서 다른 브랜치로 HEAD를 이동시키는 명령어
# 다른 브랜치로 이동
$ git switch <다른 브랜치 이름>
# 브랜치를 새로 생성과 동시에 이동
$ git switch -c <브랜치 이름>
# 특정 커밋 기준으로 브랜치 생성과 동시에 이동
$ git switch -c <브랜치 이름> <커밋 ID>
❗ git switch 주의사항❗
- ❗ git switch 를 하기 전에 반드시 브랜치의 변경 사항을 커밋하여야한다. 커밋 하지 않은 상황에서 브랜치를 이동하게되면 수정하던 파일은 그대로 같이 따라오게되며 프로그램이 꼬일 수 가 있다.
💡 merge 의 3가지 상황
- **Fast-Forword** : 전버전에 있는 branch를 최신 버전으로 합쳐주는 것. (one line 임)
- ![image-20220408163549076](day05__GIT2.assets/image-20220408163549076.png)
- **Auto metging** : 다른갈래의 버전을 자연스럽게 합친 것 (여러 갈래가 하나의 갈래로)
- ![image-20220408163905541](day05__GIT2.assets/image-20220408163905541.png)
- **Conflict** : 다른 버전끼리 충돌하는 것. 같은 라인을 수정한 다른 버전을 merge하면 충돌이 발생한다. 이러한 경우 2가지 버전중하나를 선택해서 수정 혹은 2가지 버전 모두 등록 하여 수정한후 `git add` -> `git commit` 을 통해 수정이 가능하다.
💡Git workflow
(1) 원격 저장소 소유권이 있는 경우(Shared repository model)
1. 개념
- 원격 저장소가 자신의 소유이거나 collaborator로 등록되어 있는 경우
- master에 직접 개발하는 것이 아니라, 기능별로 브랜치를 따로 만들어서 개발.
- `pull request`를 같이 사용하여 팀원 간 변경 내용에 대한 소통을 진행.
2. 작업흐름
- 소유권이 있는 원격 저장소를 로컬 저장소로 `clone`을 받음.
- 사용자는 자신이 작업할 기능에대한 브랜치를 생성 하고, 그 안에서 기능을 구현.
- 기능 구현이 완료되면, 원격 저장소에 해당 브랜치를 `push`
- 원격 저장소에는 `master`와 각 기능의 브랜치가 반영됨.
- `pull request`를 통해 브랜치를 master에 반영해달라는 요청을 보냄. (팀원들과 코드 리뷰를 통해 소통할 수 있다.)
- 병합이 완료되면 원격 저장소에서 병합이 완료된 브랜치는 불필요하므로 삭제.
- `master`에 브랜치가 병합되면, 각 사용자는 로컬의 `master`브랜치로 이동.
- 병합으로 인해 변경된 원격 저장소의 `master`내용을 로컬에 받아옴.
- 병합이 완료된 `master`의 내용을 받았음으로, 기존 로컬 브랜치는 삭제. (한 사이클 완료)
- 새로운 기능을 추가를 위해 새로운 브랜치를 생성하여 위 과정을 반복.
(2) 원격 저장소 소유권이 없는 경우 (Fork & Pull model)
1. 개념
- 오픈 소스 프로젝트와 같이 자신의 소유가 아닌 원격 저장소인 경우 사용.
- 원본 원격 저장소를 그대로 내 원격 저장소에 복제. (이 행위를 `fork`라고 함.)
- 기능 완성 후 push는 복제한 내 원격 저장소에 진행.
- 이후 `pull request`를 통해 원본 원격 저장소에 반영할 수 있도록 요청.
2. 작업 흐름
- 소유권이 없는 원격 저장소를 `fork`를 통해 내 원격 저장소로 복제.
- `fork`후, 복제된 내 원격 저장소를 로컬 저장소에 `clone`함.
- 이후 로컬 저장소와 원본 원격 저장소를 동기화 하기 위해서 연결. (`git remote add upstream <주소>` 원본 원격 저장소에 대한 이름은 upstream을 붙이는 것이 일종의 관례.)
- 사용자는 자신이 작업할 기능에 대한 브랜치를 생성하고, 그 안에서 기능을 구현.
- 기능 구현이 완료되면, 복제 원격 저장소(origin)에 해당 브랜치를 `push`함.
- 복제 원격 저장소(origin)에는 master와 브랜치가 반영됨.
- `pull request`를 통해 복제 원격 저장소(origin)의 브랜치를 원본 원격 저장소(upstream)의 master에 반영해달라는 요청을 보냄. (원본 원격 저장소의 관리자가 코드 리뷰를 진행하여 반영 여부를 결정.)
- 원본 원격 저장소(upstream)의 master에 브랜치가 병합되면 복제 원격 저장소 복제 원격 저장소(origin)의 브랜치는 삭제하고 사용자는 로컬에서 master브랜치로 이동.
- 병합으로 인해 변경된 원본 원격 저장소(upstream)의 master 내용을 로컬에 받아옴 (한 사이클 종료.)
- 새로운 기능 추가를 위해 새로운 브랜치를 생성하여 위 과정을 반복한다.
'Basic > 멀티캠퍼스__AI플랫폼을 활용한 웹서비스 개발' 카테고리의 다른 글
멀티캠퍼스 AI플랫폼을 활용한 웹서비스 개발 - 7일차 (0) | 2022.04.12 |
---|---|
멀티캠퍼스 AI플랫폼을 활용한 웹서비스 개발 - 6일차 (0) | 2022.04.11 |
멀티캠퍼스 AI플랫폼을 활용한 웹서비스 개발 - 4일차. (0) | 2022.04.07 |
멀티캠퍼스 AI플랫폼을 활용한 웹서비스 개발 - 3일차. (0) | 2022.04.06 |
멀티캠퍼스 AI플랫폼을 활용한 웹서비스 개발 - 2일차. (0) | 2022.04.05 |
댓글