[DAY 17] Git & Web

[천재교육] 프로젝트 기반 빅데이터 서비스 개발자 양성 과정 9기
학습일 : 2024.08.02

📕 학습 목록

• Git
• GitHub
• Web 

 

📗 기억할 내용

 

1) Git

 

① Git 이란?

• 파일의 버전 관리 / 백업 / 협업을 위한 s/w
• 분산 버전관리 시스템; 개발 구성원 모두 현재 상태의 파일 & 프로젝트의 전체 이력을 가짐

[버전 관리 방식 2가지]

* 중앙 집중식 버전관리 시스템(CVCS) 
  - 중앙저장소를 팀원들이 공유하면서 같이 수정•관리
  - 추적이 안된다는 단점때문에 이전 버전을 되돌리거나 할 때 어려움이 있음
  - ex : SVN(Subversion)

* 분산 버전관리 시스템(DVCS)
  - CVCS의 추적 불가 단점을 해결
  - 중앙저장소를 팀원들이 공유 & 팀원 개개인의 로컬저장소를 따로 가짐
  - 팀원 개개인의 로컬저장소에 저장 → 다같이 검토•토론 → 최종적으로 중앙저장소에 업로드; 프로그램 작동   
  - ex : Git

• Git의 커밋 흐름

작업물을 임시저장공간(staging area)에 등록 → local repository에 실제로 저장 → remote repository에 등록

• Git 을 사용해야하는 이유

Git의 기능	설명
변경 취소	- 실수를 했을 경우, 구 버전의 작업 파일 복구 → 이전 단계로 돌아갈 수 O
모든 변경에 대한 history	- 구 버전의 프로젝트 확인 → 그 당시 파일 상태를 확인
변경한 이유 기록	- Commit message를 통해 변경한 이유를 참조
변경에 대한 확신	- 언제든지 이전 버전으로 복귀 가능
여러 갈래의 history	- 별도의 branch를 생성 → 다른 기능을 독립적으로 실험해 볼 수 O - 성공시 변경 내용을 main branch로 병합(성공X 시, 삭제)
충돌 해결 능력	- 여러 사람들이 동시에 같은 파일 작업 → 자동으로 변경 사항 병합(충돌이 날 경우, 충돌이 무엇인지 알려줌. 해결하기 쉽게 함)
독립된 history	- 여러 사람들이 다른 Branch에서 작업 → 기능을 독립적으로 개발. 완료시 기능 병합
기록 요구	- Issues를 사용 → 버그를 기록/개발하고 싶은 새로운 기능 구체화
독립된 history에 대한 협력	- Branch & Pull request를 사용 → 다른 Branch • 기능에 협력
진행중인 작업 검토	- Pull request 목록을 통해 현재 무슨 작업이 진행되고 있는지 확인 - 특정 Pull request를 클릭 → 최근 변경 내용 & 변경에 관한 논의 내용 확인
팀의 작업 진척 사항 확인	- Pulse • Commit history를 통해 팀의 진척 상황 확인

• Git 용어 설명

Git 용어	설명
Commit	- 파일에 대한 변경 내용을 저장할 때마다, 새로운 commit 생성
Commit message	- commit을 생성할 때마다 변경 이유 작성
Branch	- 따로 떨어진 독립적인 commit  - 테스트 or 새로운 기능 개발을 위해 사용
Main branch	- 작업이 최종적으로 마무리되는 branch - 새로운 Git 프로젝트 만들 때 마다 생성됨
Feature(or Topic) branch	- 새로운 기능을 개발할 때 마다 작업할 feature branch 생성
Release branch	- QA 작업을 하거나, 구 버전의 s/w를 지원해야할 때 모든 수정 • 업데이트를 위한 release branch 가 필요
Merge	- 한 branch에서 완성된 작업을 가져와 다른 branch에 병합 - 흔히, feature branch를 main branch로 병합
Tag	- 특정 이력이 있는 commit에 대한 참조 - 제품 배포 기록에 자주 사용; 어떤 버전의 코드가 언제 배포(release) 되었는지 정확히 알 수 있도록
Check out	- 프로젝트 history의 다른 버전으로 이동 → 해당 시점의 파일을 확인 - 흔히, branch에서 완료된 작업을 모두 보기 위해 check out (commit 도 check out 가능)
Pull request	- branch에서 완료된 작업을 다른 사람이 리뷰 → main으로 병합하도록 요청 - 흔히, 개발 가능한 기능에 대한 논의를 시작하는 초기 작업 단계에서 사용
Issue	- 기능에 대해 논의 • 버그 추적시 사용 (GitHub의 기능)
Wiki	- 링크들을 서로 연결해 간단하게 웹 페이지를 만드는 방법 - GitHub : 문서작성에 Wiki를 자주 사용
Clone	- repository를 사용자의 컴퓨터로 복사하는 과정 - 종종 local로 작업하기 위해 프로젝트 복사본을 GitHub에서 다운
Fork	- 프로젝트를 직접 변경하는데 필요한 권한을 보유X 경우, 프로젝트 변경시 GitHub의 사용자 계정에 프로젝트 복사본을 만드는 과정 - 그 다음, 복제(clone) → 변경 → pull request; 원본 프로젝트에 변경 내용을 반영

• 주요 Git 명령어

Git 명령	설명
-h –help	- Git 명령어 리스트 출력
clone [git_url]	- 현재 파일 위치에 원격 Git 프로젝트 복사
init	- 현재 파일 위치에 로컬 저장소 생성
add [파일 위치]	- 주어진 파일, 폴더들을 Git 변경사항 인덱스로 적재
status	- 현재 Git 상태를 확인 (branch, 파일 상태, …)
branch [브랜치 이름]	- 현재 브랜치에서 새로운 브랜치 생성
commit [-m 메시지]	- add로 등록한 Git 데이터를 커밋

 

② Git 브랜치 전략

• 여러 개발자가 하나의 저장소를 사용하는 환경에서, 저장소를 효과적으로 활용하기 위한 work-flow
• 즉, 브랜치 생성 규칙을 만들어 협업을 유연하게 하는 방법론
• git-flow 전략 

- 브랜치 이름 : feature > develop > release > main > hotfix
* feature : 추가 기능 개발 브랜치. develop 브랜치에 들어감
* develop : 다음 출시 버전을 대비하여 개발하는 브랜치. feature 들을 모으는 역할
* release : 다음 출시 버전을 대비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트 진행. 테스트 서버에 올라가는 버전이 들어감(develop과 통합하여 사용하기도 함)
* main : 라이브 서버에 실제 제품•서비스로써 출시되는 브랜치
* hotfix : main 브랜치에서 발생한 버그를 수정하여 반영하는 브랜티

• github-flow 전략 

- git-flow의 단점을 해결(브랜치 생성이 많고•복잡. 적용이 어려움)
- main 브랜치 하나로 진행됨
- main 브랜치에 모든 기능•오류 수정을 merge → main이 업데이트 됨

 

📙 내일 일정

• 웹 개발 언어(HTML, CSS, Javascript) 학습