본문 바로가기
  • Build Up Routine
Basic/멀티캠퍼스__AI플랫폼을 활용한 웹서비스 개발

멀티캠퍼스 AI플랫폼을 활용한 웹서비스 개발 - 5일차.

by 까느.dev 2022. 4. 8.

📢 day05__GIT특강

💡 Recap

  1. 깃은 왜 쓰는걸까?
    • 버전관리를위해서 사용하는것임
    • 백업(git add, git commit git push), 복구(gir reset), 협업(gir clone, pull, branch, merge) 을 통해서 버전관리를 만듦.
  2. Git-hub 포트폴리오
    • 1일 1커밋 or TIL을 통해서 깃헙에 올려 내 포트포리오을 만들 수 있음.
  3. CLI, VScode, Markdown 을알아야 Git을 이해하기 편함. Git은 CLI만으로만 사용이 가능하다.
  4. 블로그내용들이 보기 편하고 좋으나 잘못된 정보도 있을수 있어 공식문서를 활용하는것을 추천함.
  5. 깃은 WorkingDirectory -> Staging Area -> Commits 과정으로 저장됨.
  6. 절대하지 말아야할 3가지, 아래 3가지를 할경우 git에서 충돌이 생길 경우가 있다. (.git은 관리하는 프로젝트에 하나만 있어야한다!)
    1. git init을 두번 하지않는것.
    2. git init을 상위폴더에 또 하지 말것.
    3. git-hub에서 변경하지 말것

💡 Gitignore

  • girignore를 통해서 내가 커밋하기 원하지 않는 파일들 .gitignore 파일안에 두어서 관리가 가능하다.

[git ignore link](https://www.toptal.com/developers/gitignore)

  • gitignore.io 웹사이트를 통해서 운영체제,개발환경프로젝트,개발언어를 선택해서 필요가 없는 목록들을 추가 할 수 있다.

(1).gitignore에 작성하는 목록

  1. 민감한 개인 정보가 담긴 파일(전화번호, 계좌번호, 각종 비밀번호, API KEY 등)
  2. OS에서 활용되는 파일
  3. IDE(통합 개발 환경) 혹은 Text editor(vscode)등에서 활용되는 파일.
  4. 개발 언어 혹은 프레임워크에서 사용되는 파일

(2).gitignore 작성시 주의 사항

  1. 반드시 이름을 .gitnore로 작성 접 (.)은 숨김파일이라는 뜻
  2. .gitignore 파일은 .git폴더와 동일한 위치에 생성한다.
  3. 제외 하고 싶은 파일은 반드시 `git add` 전에 `.gitignore`에 작성한다.
  4. `git add` 이후 작성하면 그 파일은 버전 관리의 대상으로 여겨지며, 한번 버전 관리 대상이 된 파일은 이후에 `.gitignore`작성하더라도 무시되지 않고 게속 버전 관리의 대상으로 인식이 되어 추후에 충톨이나 오류가 날 수 있다.

(3)Git 작성 패턴규칙

  1. 아무것도 없는 라인이나, `#`로 시작하는 라인은 무시합니다.
  2. `슬래시(/)`로 시작하면 하위 디렉터리에 재귀적으로 적용되지 않습니다.
  3. 디렉터리는 `슬래시(/)`를 끝에 사용하는 것으로 표현합니다.
  4. `느낌표(!)`로 시작하는 패턴의 파일은 ignore(무시)하지 않습니다.
  5. 표준 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의 도구이다.
  • **브랜치의 장점**
    1. 독립 공간을 형성하기 때문에 원본(main)에 대해 안전하다.
    2. 하나의 작업은 하나의 브랜치로 나누어 진행되므로 체계적인 개발이 가능하다.
    3. Git은 브랜치를 만드는 속도가 굉장히 빠르고, 용량이 적어 작업이 용이하다.
  • **브랜치를 써야하는 이유**
    1. master branch는 상용을 의미한다. 그래서 언제든 세상에 공개되어 있다.
    2. 만약 상용에 상용에 에러가 있을 경우
    3. 고객이 사용하고 있는데(서비스중), 함부로 버전을 되돌리거나 삭제할 수 있다.
    4. 브랜치를 통해 별도의 작업 공간을 만들고, 그곳에서 되돌리거나 삭제가 가능하다.
    5. 브랜치는 완전하게 독립이 되어있어서 어떤 작업을 해도 master에는 영향을 끼치지 않는다.
    6. 브랜치를 통해 에러가 해결 되었다면, 후에 master에 반영(merge)할 수 있다.
    7. 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가지 상황

  1. **Fast-Forword** : 전버전에 있는 branch를 최신 버전으로 합쳐주는 것. (one line 임)
  2. ![image-20220408163549076](day05__GIT2.assets/image-20220408163549076.png)
  3. **Auto metging** : 다른갈래의 버전을 자연스럽게 합친 것 (여러 갈래가 하나의 갈래로)
  4. ![image-20220408163905541](day05__GIT2.assets/image-20220408163905541.png)
  5. **Conflict** : 다른 버전끼리 충돌하는 것. 같은 라인을 수정한 다른 버전을 merge하면 충돌이 발생한다. 이러한 경우 2가지 버전중하나를 선택해서 수정 혹은 2가지 버전 모두 등록 하여 수정한후 `git add` -> `git commit` 을 통해 수정이 가능하다.

 

💡Git workflow

(1) 원격 저장소 소유권이 있는 경우(Shared repository model)

1. 개념

  • 원격 저장소가 자신의 소유이거나 collaborator로 등록되어 있는 경우
  • master에 직접 개발하는 것이 아니라, 기능별로 브랜치를 따로 만들어서 개발.
  • `pull request`를 같이 사용하여 팀원 간 변경 내용에 대한 소통을 진행.

2. 작업흐름

  1. 소유권이 있는 원격 저장소를 로컬 저장소로 `clone`을 받음.
  2. 사용자는 자신이 작업할 기능에대한 브랜치를 생성 하고, 그 안에서 기능을 구현.
  3. 기능 구현이 완료되면, 원격 저장소에 해당 브랜치를 `push`
  4. 원격 저장소에는 `master`와 각 기능의 브랜치가 반영됨.
  5. `pull request`를 통해 브랜치를 master에 반영해달라는 요청을 보냄. (팀원들과 코드 리뷰를 통해 소통할 수 있다.)
  6. 병합이 완료되면 원격 저장소에서 병합이 완료된 브랜치는 불필요하므로 삭제.
  7. `master`에 브랜치가 병합되면, 각 사용자는 로컬의 `master`브랜치로 이동.
  8. 병합으로 인해 변경된 원격 저장소의 `master`내용을 로컬에 받아옴.
  9. 병합이 완료된 `master`의 내용을 받았음으로, 기존 로컬 브랜치는 삭제. (한 사이클 완료)
  10. 새로운 기능을 추가를 위해 새로운 브랜치를 생성하여 위 과정을 반복.

(2) 원격 저장소 소유권이 없는 경우 (Fork & Pull model)

1. 개념

  • 오픈 소스 프로젝트와 같이 자신의 소유가 아닌 원격 저장소인 경우 사용.
  • 원본 원격 저장소를 그대로 내 원격 저장소에 복제. (이 행위를 `fork`라고 함.)
  • 기능 완성 후 push는 복제한 내 원격 저장소에 진행.
  • 이후 `pull request`를 통해 원본 원격 저장소에 반영할 수 있도록 요청.

2. 작업 흐름

  1. 소유권이 없는 원격 저장소를 `fork`를 통해 내 원격 저장소로 복제.
  2. `fork`후, 복제된 내 원격 저장소를 로컬 저장소에 `clone`함.
  3. 이후 로컬 저장소와 원본 원격 저장소를 동기화 하기 위해서 연결. (`git remote add upstream <주소>` 원본 원격 저장소에 대한 이름은 upstream을 붙이는 것이 일종의 관례.)
  4. 사용자는 자신이 작업할 기능에 대한 브랜치를 생성하고, 그 안에서 기능을 구현.
  5. 기능 구현이 완료되면, 복제 원격 저장소(origin)에 해당 브랜치를 `push`함.
  6. 복제 원격 저장소(origin)에는 master와 브랜치가 반영됨.
  7. `pull request`를 통해 복제 원격 저장소(origin)의 브랜치를 원본 원격 저장소(upstream)의 master에 반영해달라는 요청을 보냄. (원본 원격 저장소의 관리자가 코드 리뷰를 진행하여 반영 여부를 결정.)
  8. 원본 원격 저장소(upstream)의 master에 브랜치가 병합되면 복제 원격 저장소 복제 원격 저장소(origin)의 브랜치는 삭제하고 사용자는 로컬에서 master브랜치로 이동.
  9. 병합으로 인해 변경된 원본 원격 저장소(upstream)의 master 내용을 로컬에 받아옴 (한 사이클 종료.)
  10. 새로운 기능 추가를 위해 새로운 브랜치를 생성하여 위 과정을 반복한다.

댓글