협업환경 구성
마크다운, 버전관리, 깃
1. 포트폴리오
프로젝트: 프로그램을 만들기 위한 일련의 프로세스
소스구현과 더불어 기획, 설계, 테스트, 배포
협업을 위한 공유가 필요하다.
read.md 의 역할
- 완성된 프로그램의 설명서.
- 구현 중인 프로젝트의 현황.
2. MarkUp vs MarkDown
1. MarkUp
- HTML(Hyper Text MarkUp Language)
- 프로그래밍 언어x, 웹페이지가 어떻게 구조화 되어있는지 브라우저가 알 수 있게 하는 언어!
- 각각의 태그로 구조를 세운다.
-
3. MarkDown
- MarkUp 언어의 일종. 태그가 빠져 읽고 쓰기 쉬운 문서 양식.(웹 전용 텍스트)
- 위키백과, tistory, notion, github
- 문법
-
글씨: 1단계 제목
-
글씨: 2단계 제목
- 글씨, 글씨: 기울여
- 글씨: 굵게
- 글씨: 귀울여+굵게
코드
: 코드- 링크내용: 링크생성
-
: 인용구 (강조)
-
4.버전
- 유의미한 수정
- 무엇이 바뀌었는지 잘 적어놓고 관리해야한다.
- 버전 관리 시스템(version control system)
- 버전 관리
- 백업 복구
- 협업 (선택)
- 종류
- 로컬 vcs: 내 컴퓨터 (로컬), 협업X
- 중앙집중식 vcs: 협업 O, 필요한 파일만
- SVN, CVS
- 분산 vcs: 통째로→ 안꼬인다(안정적)
- Git
- Mecurial
- Bazaar
Git과 협업
Git 관리 기본
- 레포지토리에 올리고 가져오기
- git pull origin main (가져오기)
- git push origin main (올리기)
- origin: 원격저장소 별칭
- main: 원격저장소 브랜치(이름)
- remote add origin [repo url]: url의 origin브랜치추가
- git log: 깃 내역 확인
- 깃 잘못 연결했을 때
- git remote -v: 확인 후 브랜치 네임 확인
- git remote remove [브랜치네임(보통은 origin)] :
- git remote -v
- git init :다시 생성
- 만약 다른 레포에 있는 것을 로컬로 다 뒤집어 씌우고 싶을때 git pull origin을 하면 refusing to merge unrelated histories의 에러 해결
- git fetch –all
- git reset –hard origin/main
- git pull origin main
브랜치
- 브랜치란, 각 기능별로 독립적으로 개발하기 편하게 나눠 놓는 것.
- 브랜치 관리 법
- git branch -v : branch 확인하기
- git branch [브랜치 명]: 브랜치 생성
- git branch -d [브랜치명]: branch 삭제하기
- git checkout [브랜치명]: 해당 브랜치로 넘어가기.
Merge
- 작업 내용 합치기
- 명령어
- git merge [a]: 현재 내가 있는 브랜치에 a라는 브랜치의 코드를 합침.
- 충돌 예방법 ( 만약 main 브랜치에 a브랜치를 합치는 경우)
- git checkout [a]: a 브랜치로 이동
- git pull origin [a]: a 브랜치를 최신으로 업데이트
- git checkout [main]: 다시 main으로 이동
- git merge [a]: a브랜치를 main에 머지 요청
branch
- Main (메인) 잘 건드리진 않음
- 다 쓴 후에는 (merge후) 삭제.
- 기능 개발 (git flow)
- develop의 브랜치를 딴 뒤 하위 브랜치로 들어간다
- feature/[기능명] ex) feature/login, feature/select-product
- 출시 준비: release-[버전명]: release-1.3, release-1.4
- 긴급 수정: hotfix-[버전명]: hotfix-1.2.1
- 기능 개발 (git flow)
- 명령어
- 깃허브에 실행하는 명령어: push, clone, pull
- 로컬: add
- git clone [저장소 https]: **원격 저장소의 코드를 로컬로 복제
- git branch (새로운 브랜치 생성 또는 기존 브랜치 목록 조회)
- -d [브랜치 명]: branch 삭제
- -D [브랜치 명]: branch 오류 무시 강제 삭제
- -v: 좀 더 구체적인 branch 정보 확인 가능. (각 브랜치의 마지막 커밋 정보)
- -r: 원격 브랜치 확인
- git push
- git push origin [깃 브랜치명]: 깃허브에 브랜치 생성하고 깃(로컬) 브랜치 복제하기
- git push [깃 브랜치명] origin: 깃허브에 브랜치 생성 후, 깃에 받아오기
- git pull origin main: origin(깃 허브)에서 main(깃 메인branch)으로 땡겨오기( 동기화 )
- git checkout
- -t origin/[허브 브랜치 명]: 깃허브에 있는 브랜치를 깃(로컬)에 가져오기
git flow(브랜치 전략)
- main(master): 서비스을 직접 배포하는 브랜치
- feature(기능): 각 기능 별 개발 브랜치
- develop(개발): feature에서 개발된 내용을 가진 브랜치
- release(배포): 배포를 하기 전 내용을 QA(품질 검사)하는 브랜치
- hotfix(빨리 고치기): main 브랜치로 배포를 하고 나서 버그가 생겼을 때 빨리 고치기 위한 브랜치
merge 종류
1. fast-forward
- main 에서 feature/login 브랜치를 생성한 시점부터
- main에는 추가 구현 하지 않고
- feature/login만 추가 구현한 뒤에 main에 merge
2. 3-way (많이 사용함)
- A에서 B를 생성한 시점 부터
- A도 추가구현. B도 추가 구현 후
- 비교해서 바뀐것을 정리해서 merge
- 차근차근 merge함. A 먼저 merge 후, B 를 main에 merge. 이후 브랜치 삭제
-
pull request때 메시지 작성하기(관리 잘해야 포트폴리오 관리에도 좋음!)
###주요 구현 내용 -로그인 -계정 정보: 아이디(이메일)
###이슈
- 에러가 있어 –알고리즘으로 대체
Merge
- 협업을 위해 브랜치를 나눈 뒤 그 결과물을 합치는 것
- main 브랜치 보호
- flow
- main이외 브랜치를 main에 병합 ( pull request)
- 충돌 확인(자동)
- PR(Pull Request) 메시지 작성 중요!
- merge commit (병합 시 작성하는 커밋)
- branch 삭제
fetch
- git fetch -p: 허브와 브랜치 목록 동기화
- error: the branch ‘feature/login’ is not fully merged 해결법
- 허브에서는 머지 커밋 후 삭제 완료했지만, 로컬에선 머지 기록이 없어서 에러 발생
- 해결 방법: 허브와 동기화 후 삭제 진 1. git checkout main : 지우려면 해당 브랜치에서 빠져나와야 함. 2. git pull origin main: 허브에서 merge한 커밋을 가져오기 위함. 3. git branch -d [지우고 싶은 branch]: 4.
- 허브에서는 머지 커밋 후 삭제 완료했지만, 로컬에선 머지 기록이 없어서 에러 발생
정리
- origin은 깃허브의 별칭
- git fetch -p: 허브의 브랜치 목록 동기화
- git pull origin main: 깃 허브의 커밋, 상태 동기화
- git checkout - t origin/[허브의 브랜치 명]: 허브에 있는 브랜치 가져오기
- 지울 때는 지울 브랜치에서 벗어나기
- 현재 브랜치 잘 확인에서 커밋하기