| 일수 | 일자 | 교과목 | 내용 | 편성시간 |
|---|---|---|---|---|
| 4 | 24/11/25 | 기반기술 | SW공학 | 8 |
[지난 학습 복습]
서버 :
클라이언트 :
IP 주소 :
포트 번호
프론트엔드 :
백엔드 :
웹 서버(프론트) : 서버에 저장된 파일을 클라이언트가 다운로드할 수 있게 해준다.
웹 클라이언트(웹 브라우저) : URL을 이용해서 서버에게 특정 파일을 달라고 요청하고, 서버로부터 받은 파일을 화면에 보여준다.
WAS(웹 어플리케이션 서버, 백) : 서버 컴퓨터에 저장된 파일을 클라이언트가 요청하면 파일을 실행하고 실행된 결과만 보내준다.
[Git & GitHub]
git을 들어가기 전에
1. 계획
1) 타당성 분석
경제적, 기술적, 법적
2) 프로젝트 계획서 작성 (v)
프로젝트 범위, 자원 점검(HW 사양, OS 버전, SW), 인원, 예산, 일정
3) 팀 구성 (v)
4) 개발비용 산정
5) 프로젝트 스케줄링 (v)
소작업 분해 -> WBS -> CPM -> 최소 비용 산정 -> CPM 수정 -> 간트 차트
(마인드맵)
2. 분석
1) 요구사항 분석 (v)
3. 설계
1) 아키텍처
인프라(v) : 시스템 아키텍처
프론트엔드(v) : UI/UX 설계도, SW 아키텍처
백엔드(v) : API 명세서, ERD, SW 아키텍처
4. 구현
5. 시험
TDD(v)
6. 유지보수
개발이 끝난 후 서비스를 운영하면서 기능을 추가하거나 에러를 잡는 일*(v)는 실습하면서 프로젝트에서 직접 해볼 것
git
git은 내 컴퓨터에 설치되는 프로그램
형상 관리를 해주는 프로그램
깃이란?
- Git이란 소스코드를 효과적으로 관리하기 위해 개발된 '분산형 버전 관리 시스템'
- Git에서는 소스 코드가 변경된 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 되돌아갈 수도 있다.
- 또 내가 올리려는 파일이 누군가 편집한 내용과 충돌한다면 서버에 업로드 할 때 경고 메시지가 발생함.
이전 버전으로 되돌리기
git reset [옵션][커밋 해시]
--hard : 작업 디렉토리 변경, 스테이징 영역 변경, 저장소 변경
--mixed : 작업 디렉토리 유지, 스테이징 영역 변경, 저장소 변경, 옵션을 따로 안쓰면 기본으로 실행되는 옵션
--soft : 작업 디렉토리 유지, 스테이징 영역 유지, 저장소 변경
- 이전 버전 파일 확인만 할 때
git checkout 커밋해시
주의
작업을 저장하지 않은 상태에서 다른 버전으로 왔다갔다 하지 않아야 한다.
저장하지 않고 왔다갔다 하면 HEAD가 특정 브랜치가 아닌 커밋을 가리키는 상태가 됨
정상 : HEAD -> 브랜치 -> commit
비정상 : HEAD -> commit
해결 : git branch -f main HEAD
-
이전 버전 (현재 상태 유지)
git reset --soft [커밋 해시]
-
이전 버전 (작업 디렉토리 유지)
git reset --mixed [커밋 해시]
-
이전 버전 (완전 이전 버전으로)
git reset --hard [커밋 해시]
commit 메시지 작성 규칙
무조건 지켜야 하는 건 아니지만 지켜지면 좋은 문화
-
레포 이름 규칙
기수-프로젝트회차-팀명-주제
ex) be01-1st-best-danggeun
be01-2nd-power-ddara
be01-3rd-dragon-hakit -
커밋 규칙
1) 커밋 템플릿
기본 적인 커밋 메시지 구조는 제목,내용,꼬리말 세가지 파트로 나누고, 각 파트는 빈줄을 두어 구분한다.
꼬리말은 있어도 되고 없어도 된다.[제목 타입] 제목 (#이슈 번호) 내용 꼬리말 타입 : #이슈 번호 # 제목은 최대 50글자까지 아래에 작성: ex) [Feat] Upload 기능 추가 # 본문은 아래에 작성 ex) 이미지 업로드 기능을 이러이러한 이유로 추가 # 꼬릿말은 아래에 작성: ex) Resolves: #123 # --- COMMIT END --- # [제목 타입] 리스트 # Feat : 기능 (새로운 기능) # Fix : 버그 (버그 수정) # Refactor : 리팩토링 # Design : CSS 등 사용자 UI 디자인 변경 # Comment : 필요한 주석 추가 및 변경 # Style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음) # Docs : 문서 수정 (문서 추가, 수정, 삭제, README) # Test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음) # Chore : 기타 변경사항 (빌드 스크립트 수정, assets, 패키지 매니저 등) # Init : 초기 생성 # Rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우 # Remove : 파일을 삭제하는 작업만 수행한 경우 # ------------------ # 제목 끝에 마침표(.) 금지 # 제목과 본문을 한 줄 띄워 분리하기 # 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다. # 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분 # ------------------ # <꼬리말> # 필수가 아닌 optioanl # Fixes :이슈 수정중 (아직 해결되지 않은 경우) # Resolves : 이슈 해결했을 때 사용 # Ref : 참고할 이슈가 있을 때 사용 # Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우) # ex) Fixes: #47 Related to: #32, #213) 제목
제목은 최대 50글자 넘지 않기
마침표 및 특수기호 사용x
적용 내용을 간략하게만 작성4) 꼬리말
Fixes: 이슈 수정중(아직 해결되지 않은 경우)
Resolves: 이슈를 해결한 경우
Ref: 참조할 이슈가 있을 때 사용
Related to: 해당 커밋에 관련된 이슈 번호(아직 해결되지 않은 경우)
-
브랜치 전략
main : 실제 운영중인 프로젝트의 브랜치
develop : 새로운 기능을 개발하는 프로젝트의 브랜치
feature : 새로운 기능을 개발하기 위해 개발자가 사용하는 브랜치
feature/기능
기능 작성 규칙 : 영어 소문자, 특수문자 X, 띄어쓰기 대신 _, 25자 이하
브랜치로 작업 후 해당 브랜치 그대로 push한 다음,병합은 github에서 하기
VSCode 설치
설치할 때 빨간 박스 안에 있는 체크박스도 체크해주자
2) github
github란?
git으로 관리하는 프로젝트를 업로드하거나 공유할 수 있는 웹 사이트
(git과 github는 서로 다름을 주의)
git과 github에 연동된 아이디는 서로 연관이 없으므로, PC와 연결된 github를 바꾸고 싶은 경우 제어판의 자격증명에서 내용을 수정해주어야 한다. (헷갈리지 않도록 가급적 통일하기)
git flow
Master : 시스템이 완성되었을 때만 커밋(최종)
Feature : 기능 구현이 완성된 후 합칠 때 develop에 커밋
브랜치
원본을 수정하지 않고 안전하게 새로운 기능을 추가해볼 수 있도록 하는 프로젝트의 복사본
-
브랜치 생성
git branch 브랜치이름 -
브랜치 변환
git checkout 브랜치이름
내 컴퓨터의 main 브랜치와 github의 main 브랜치는 서로 다르다. (꼭 구분짓기)
- 브랜치 병합
git checkout 브랜치이름 메인이 되는 브랜치
git merge 다른브랜치이름
브랜치 합치기는 가급적 깃허브에서 하기
(다 함께 의견을 나누고 합칠 수 있으므로)
VSCode에서 브랜치는 좌측하단의 브랜치를 통해 확인 및 이를 눌러서 변경 가능
+)
만약 깃허브에 commit을 잘못했을 때, 이전버전으로 돌리고 (현재 내 origin으로 덮어쓰고) 싶다면
git push origin main --force
단, 백업 파일이 없는 경우 되돌릴 수 없음 주의
