특강
Git 등장 배경
버전 관리 시스템 (Version Control System)
문서나 설계도 또는 소스 코드 등 다양한 파일의 변경 사항을 관리하는 소프트웨어
Git 주요 기능
원격 저장소와 로컬 저장소
원격 저장소
로컬 저장소가 바라보는 공유 저장소
개인 컴퓨터가 아니라 별도 서버로 관리한다
로컬 저장소
개인 컴퓨터에 존재하는 저장소
원격 저장소의 코드를 복제한다.
로컬에서 작업한 뒤 원격 저장소에 올린다.
명령어 및 순서
원격 저장소 생성 (git init) -> 개인 저장소로 코드 복제 (git clone) -> 코드 작업 -> 원격 저장소로 코드 동기화 (git push) -> 원격 저장소에 변경된 코드가 있다면 (git pull)
pull
fetch + merge
fetch
- 로컬에 원격 트래킹 저장소 갱신
- 로컬 코드에 변화를 주지 않음.
Repository
저장소, 원격 저장소에 동기화하여 사람들과 코드를 공유한다
Commit
- 코드 변경사항을 저장하는 단위, 여러 개 파일에 여러 라인을 수정하더라도 하나로 묶을 수 있다.
- Commit 단위마다 메세지를 남길 수 있다.
Branch
코드를 분기하는 기준
Revert
- 특정 커밋 변경 사항을 취소하고 취소한 변경 사항을 반영하는 새로운 commit 생성
- 히스토리를 보존하고 잘못된 변경을 되돌리고 싶을 때 사용
Reset
- HEAD 기반으로 이전 commit 상태로 되돌아가는 방식
- 히스토리를 보존하고 싶지 않을 때 사용
Github
git
- 버전 관리 시스템 중 하나
- 소스코드와 파일 변경 이력을 추적/관리
github
- Git을 기반으로 한 웹 호스팅 서비스
- Git repository를 호스팅하고, 협업 및 프로젝트 관리를 돕는 다양한 기능 제공
.gitignore란?
- Git에서 특정 파일이나 디렉토리를 버전 관리에서 제외
- 빌드 결과물, 임시 파일, 개인 설정 파일 등 제외
readme.md
- 소프트웨어 프로젝트의 중요한 문서 파일
- 프로젝트 개요, 설치 방법, 사용법, 기여 방법 등
markdown
- 단순한 텍스트 형식을 HTML로 변환하도록 설계
Pull Request
- 다른 사용자 Repository에 내가 수정한 코드를 반영하도록 할 때
- 혹은 같은 Repository를 담당하는 동료에게 코드 리뷰를 부탁할 때
실무 노하우
-
Rebase를 생활화하자
Local 작업이 길어질수록 Base 브랜치 코드 변경이 자주 일어난다.
협업한다면 rebase를 자주 해야 코드 충돌을 줄일 수 있다. -
Git 리뷰 코멘트 템플릿
- 사람마다 표현 방식이 다르기 때문에 코멘트만으로 리뷰어가 남긴 의도를 정확히 파악하기 힘들다. Github 기능을 사용하면 일관적으로 분명한 리뷰를 남길 수 있다.
- 협업의 기본 API docs, Swagger
Restful API 문서화 및 테스트하는 오픈소스
- API 문서 표준화
- 문서 생성 자동화
- 손쉬운 테스트
- 다양한 언어와 프레임워크 지원
브랜치 전략
Git 브랜치 전략이란?
소스 코드 관리 정책
- 여러 개발자가 동시에 다양한 기능을 개발하고, 최종적으로 안정적인 소프트웨어 배포를 보장한다.
- Git workflow라고도 불린다.
Git-flow
브랜치 5단계
feature - develop - release - hotfix - main
feature
기능 개발 브랜치
develop
고정 브랜치로, 개발 중인 코드가 모이는 곳
release
배포 준비 단계로, 배포할 코드가 모이는 곳
hotfix
배포된 코드 이슈를 긴급 대응할 때 생성
main
고정 브랜치로, 최신 배포 코드가 담김
git-flow는 언제 사용하는가?
버저닝이 필요하고, 오로지 정기배포를 하는 앱 어플리케이션에 적합하다.
GitHub-flow
Git-flow는 개발자가 요구하는 상황보다 훨씬 더 프로세스를 가진다.
그래서, 워크플로우는 단순할수록 오버헤드가 발생하지 않고, 브랜치 전략을 이해하지 못하여 생기는 문제가 사라진다는 생각으로 만들어졌다.
main, feature 브랜치가 있다.
Github-flow 정책
- main 브랜치는 언제든지 배포 가능
- 모든 브랜치는 main 브랜치에서 파생
- local 브랜치에 commit하고, 정기적으로 remote 브랜치로 push
- 도움이 필요하거나, 코드 병합할 준비가 되면 pull request 생성
- 다른 사람이 변경한 코드를 승인하면 main 브랜치에 merge
- main 브랜치는 즉시 배포 가능한 상태를 유지한다.
=> 상시 배포에 적합!
결론
만약 장기간 프로젝트가 존재하고, 핫픽스 등 유지보수 작업을 수행하는 팀은 Git-flow가 타당하다.
상시 배포하는 팀은 간단한 Github-flow가 적합하다.
코드 리뷰
https://school.programmers.co.kr/learn/courses/30/lessons/181187
위의 문제를 풀었다.
이중 for문을 하면 답은 찾기 쉬울 것 같았지만 반지름 최대 길이가 1,000,000이라 시간 초과가 날 것 같아 최대한 규칙을 찾으려고 했다.
하지만,, 찾지 못하고,, 찾았다 ! 싶었을 땐 점점 원이 커질 땐 적용되지 않는 규칙이었다.
그래서 수업이 끝나고 다시 풀어보았다.
class Solution {
public long solution(int r1, int r2) {
long answer = 0;
for(int x = 1;x<=r2;x++){
long maxY = (long)Math.floor(Math.sqrt((Math.pow(r2,2) - Math.pow(x,2))));
long minY = (long)Math.ceil(Math.sqrt((Math.pow(r1,2) - Math.pow(x,2))));
answer += maxY - minY + 1;
}
answer *= 4;
return answer;
}
}x² + y² = r² 를 이용하여 풀면 되는 문제였다. 수학 문제는 식으로 풀이하면 좋다는 것을 알게 되었다.
y = ±√(r² - x²) 라는 식을 만들면 반복문을 하나만 둘 수 있었다.
느낀 점
오늘 11시에 시작하는 거.. 얼마나 좋던지.. 후
내일부터 스프링을 배운다고 하는데 기대되면서 무섭다..하하
파이팅해서 평일의 절반,, 수요일 잘 보내보자~!
