Git에 대해서 몰랐던 사실들
git book ch1
git과 다른 비슷한 것들과의 차이
다른 것들은 시간순으로 파일을 관리하며, 파일들의 집합을 관리함. (델타 기반 버전 관리 시스템)
git은 스냅샷을 연속으로 취급하고, 크기를 작게 유지한다. 성능을 위해서 파일을 새로 저장하는 것이 아니라, 파일이 달라지지 않았다면, 과거에 대한 링크만을 갖고 유지한다.
git 브랜치의 장점은 로컬에서 대부분을 처리하기에 중앙과 연결이 적어 네트워크 필요량이 적다. history조회도 서버와의 통신 대신, 자신의 과거 데이터를 읽는 방식으로 가져온다.
변경 체크를 단순하게 HASH로 처리하는 방식으로 간단하게 확인한다.
git의 3가지 상태. commited, modified, staged. 가 있다.
commited는 로컬 db에 안전하게 저장되었다는 것을 의미함
modified는 아직 local db에 commit이 되지 않은 상태
staged는 곧 커밋할 것이라고 표시한 상태
git의 directory는 git이 프로젝트의 메타데이터, 객체 db를 저장하는 곳을 의미함. clone할 때 git directory가 나옴.
워킹 트리란 특정 버전을 checkout한 것. staging area도 git directory에 있다.
git의 config설정.
1. /etc/gitconfig 파일 : 모든 사용자, 모든 저장소에 적용. git config --system 옵션으로 적용할 수 있고, 관리자 권한 필요
2. ~/.gitconfig, ~/.config/git/config 파일. 특정 사용자에만 적용. git config --global 옵션으로 가능. 특정 사용자 모든 저장소 설정
3. .git/config 파일. git directory에 있고, 특정 저장소에 만 작용. --local 옵션을 이용해 저장 가능
1=>2=>3 순서로 구체적인 단위이기에, 3=>2=>1 순서로 적용됨. 3이 가장 우선
git help로 도움말 찾기 가능
gitbook ch2
git init 명령어가 .git이라고 하는 하위 디렉토리를 만듦. 저장소에 필요한 뼈대 파일만을 담고 있고, 아무것도 관리하지 않는다.
git add 를 통해 staging area로 간다.
git commit을 통해 commited 상태로 감
git clone 부분은 다른 프로젝트에 참여하거나, git 저장소를 복사하고 싶은 경우에 사용 가능
git clone의 커다란 점은 모든 히스토리까지 다 복사한다는 점. 서버가 망가져도, 서버에 있는 설정을 제외하면 완벽하게 복구할 수 있다.
git clone https://github.com/libgit2/libgit2 mydirectory이렇게 디렉토리명을 바꿀 수 있음
working directory에 있는 파일은
- Tracked 파일 : 스냅샷에 이미 포함되어 있는 파일
Unmodified : 수정되지 않음
Modified : 수정됨
Staged : 커밋으로 저장소에 기록할 예정 - Untracked 파일
git status로 확인할 수 있음
add 커맨드는 단순하게 새로 추적할 때 뿐만 아니라, 이미 수정한 파일을 Staged 상태로 옮길 때도 사용함.
또 Merge시 충돌난 파일의 상태를 Resolve 상태로 옮길 때도 사용.
다음 커밋에 반영할 것이라고 생각하면 됨
git status -s 나 --short를 통해서 현재 변경한 상태를 볼 수 있음
이는 git diff와 유사함
git diff는 추후에 더 다룸.
. gitignore로 무시할 수 있음.
#나 아무것도 없는 경우 무시
Glob 패턴 사용
/로 시작하면 하위 디렉토리는 적용되지 않음
디렉토리는 /를 끝에 사용한다
!로 시작하는 패턴의 파일은 무시되지 않는다.
git commit 부분에서 자동 생성의 경우 첫 랑니은 비어있고, 2번째부터는 git status의 결과가 저장된다. git commit -v 를 하면 diff한 메세지도 포함.
git commit -m 으로 인라인 메세지도 가능
git commit -a 옵션으로 했을 경우 자동으로 tracked파일을 staging area로 넣고 commit을 해줌
git rm 으로 staging area에 있는 파일을 삭제하고,워킹 디렉토리에 있는 파일도 삭제한다. 커밋을 하는 방식으로 삭제된다는 것이 중요함. 당장 삭제되는 것이 아님
git rm --cashe 파일명 을 통해서 git ignore에서 빼먹었을 경우 따로 뺄 수 있다. 그러면 이게 staging을 취소하는 방법중 working directory에 있는 것은 남겨두는 방법임
단순 working directory 에서 삭제하고, status를 보면 unstaged 상태라고 표시해줌.
git rm 으로 삭제하면 Staged상태가 된다. 이미 파일을 수정했거나, Staging area에 추가했다면 -f 옵션으로 강제 삭제를 해야 한다. (데이터의 실수로 삭제를 방지)
git mv로 파일을 옮길 수 있다. 다른 명칭으로 바꾸는 것도 가능하고 여러 당연한 것들을 해준다. 복사, rm, add 부분을 한꺼번에 해준다는 정도의 차이가 있다.
Github 시스템을 알아보자
pull request
간단한 요약
내 branch에 작업을 해뒀는데, 코드 주인이 알아서 보고 쓸만하면 합쳐보세요
목적
- 코드 리뷰
- push권한이 없는 오픈 소스 프로젝트 기여
- collaborator에 속했을 경우, 그 저장소에서 브런치를 따고, 푸쉬하면 발생
push로 작업하는 경우와의 차이점은 push는 다른 사람의 commit을 볼 경우가 많지 않고, master branch와 merge를 할 때만 제대로 살펴보게 되는데, 변경 사항의 범위가 커지고, 어디서부터 문제가 발생했는지 찾기 어렵다는 단점이 생김.
이런 부분을 pull request를 통해 하면 당장 merge하지 않기에, 조금 더 구체적인 로그를 남긴다는 느낌
으로 받아들이면 좋을 것 같다.
방법
1. 기여를 원하는 저장소를 fork
2. fork 한 url을 clone하기(브라우저 url이 아닌, clone or download url), remote add로 기여를 원하는 저장소를 추가하기
3. branch를 추가해 branch에서 작업을 한다.
4. git push origin branch명을 통해서 자신의 origin branch 에다 병합한다.
5. 이때 이 변경사항을 pull requets를 통해 보내겠다고 하면 원본 저장소에 관리자에게 확인할 수 있도록 할 수 있다.
6. 원본 저장소는 코드를 보고 합칠지, 말지를 결정하면 된다.
7. 원본 저장소와 merge가 되었을 때, pull을 통해서 원본 저장소의 코드와 동기화 하고, 작업했었던 branch는 삭제하고
3번부터 다시 반복하면 된다.
github actions
빌드, 테스트, 패키지, 릴리스나 배포 과정을 자동화 할 수 있는 프로세스
추가 ci/cd 툴 대신 깃허브 대신 바로 할 수 있다는 장점
기초 개념
커다란 개념 4가지
1. workflow : 여러 job들과, event로 이루어져 있다. event에 의해 실행되고, job들을 병렬적으로 실행한다.
2. event : 트리거의 역할을 하고, 어떨 때 ci/cd flow를 진행할 지를 결정함
3. jobs : 하나의 덩어리 역할을 함. testing할 때 예를 들면 배포 단계가 하나의 job이 될 수 있고, 테스트가 하나의 job 같은 여러가지 기능을 job으로 등록함
4. steps : job이 등록되었을 때, 어떤 일들이 어떤 방식으로 진행 되는지 명시한 것
커다란 틀은
전체가 work flow가 되고
이벤트
name: CI/CD - Production
on:
push:
branches: [ main ]가 되고
이벤트의 종류는 매우 많음
check_run, deployment, issue_comment, pull_request, pull_request_review_comoment, push, schedule, repository_dispatch 등등
수많은 것들이 있음 이런 부분이 github와의 연동의 장점
branch 의 옵션을 주는 방법으로,
on.<push|pull_request>.<branches|tags>
on.<push|pull_request>.paths
이렇게 되어있는 문법을 지키면 다양한 것들에 대한 시도가 가능함.
여기서 paths 부분이 조금 특이할 수 있는데, 폴더 구조에서 path 하위에 있는 것들에 대한 변화가 왔을 때에만 작동이 가능하다는 특이한 설정이 가능함
on:
push:
paths:
- 'test/*'라고 적은 경우에는 test의 하위 폴더에 변화가 있을 때에만 이 프로세스를 반복한다는 것이 작동을 보장함
jobs
workflow는 리눅스 가상머신, docker, window같은 수많은 버전의 운영체제 위에서 실행이 가능함
strategy: 키워드를 이용한 매트릭스를 만들 수 있음
strategy:
matrix:
os: [ubuntu-16.04, ubuntu-18.04]
node: [8,10,12]이 부분에 적용되었을 경우 총 6번에 해당하는 테스트를 작동시켜준다는 점이 있음
steps
하나의 job이 여러 스텝이나 하나의 스텝을 포함할 수 있다.
steps의 하위에 step의 이름, 동작을 정의하는 방식으로 실행할 수 있다.
step을 사용할 때 수많은 일반 사용자들이 만들어 놓거나, 공식적으로 지원하는 action들을 marketplace에서 가져올 수 있다..
steps:
- name: run index.js
run: |
cd ./example
node index.js만약 없다면 직접 만들어야 하기에, 이런 방식으로 직접 하나하나 다 커맨드를 작성할 수 있다.
git flow, github flow
단일 main에다가 merge를 하는 방식은 여러 문제가 발생함. 사람의 협업시 같은 코드를 같이 수정하기에 충돌이 너무 많이 발생함
gitflow
main(배포가 가능한 버전), develop(계속 작업을 하는 버전), feature branch(develop 부터 파생됨. 작업을 함)
PR로 develop에다가 merge를 함. 아직 production은 아님
development에 충분한 양의 commit이 모였을 경우에 release branch로 만듦. release/1.0같은 버전으로 관리하는 경우가 많음. 추가적으로 기능을 부여하는 경우는 없는 하나의 배포 직전 단계.
각종 테스트, e2e같은 것들을 시도할 것
시도한 이후에 release를 main에 merge를 하는 방식으로 진행함. tag로 버전을 날림.
그 순간에 develop branch를 새로 만드는 방식으로 진행 함.
hotfix branch
main에서 바로 뻗어 나오고, 바로 merge하고, tag 를 해서 버전 관리를 함
단 ci/cd를 제대로 구축했거나, microservice같은 잦은 변경 과정은 이것을 작동하기 힘들게 만든다
출처
github flow
main branch, feature branch(이것은 배포 가능해야 함.) 이게 끝.
git flow의 커다란 문제가 있음. hotfix가 나면, 작성중인 코드의 베이스가 문제가 생긴 것이기에, 모든 branch에 문제가 되는 부분을 다 제거해 줘야 함.
또한 release 타이밍이 주기적이지 않은 경우, feature을 개발하다가 중간에 포기해야 하는 애매한 상황이 발생할 수 있다.
githubflow의 규칙
master만 제대로 지키면 된다. 다른 브랜치는 임기응변 식으로 어떻게든 돌아가면 된다
master 브랜치에 merge 하면, 이미 deploy 했거나, 곧 deploy할 것을 의미함.
master branch 는 안정 버전만을 의미하기에, merge전에 충분한 테스트가 있어야 한다.
테스트는 로컬 환경이 아닌, 브랜치를 push하고, 외부 ci/cd툴로 테스트 해야 한다.
deploy같은 브랜치로 deploy커밋을 관리할 수 있지만, github는 SHA값을 관리하고, 비교할 때 사용된다
브랜치는 항상 master로 부터 만든다.
이름을 잘 짓는다. feature의 기능을 하기에, new-auth2-kakao 같은 기능명을 나타낸다.
named branch는 자주 push한다. 위의 feature과 유사한 named는 자주 push를 해야 한다.
언제든지 pull request를 사용한다. 도움 필요같은 것을 사용할 수 있다.
pull request 로 리뷰한 이후에만 merge를 한다.
maseter에 merge를 하면 자동으로 deploy를 해야 한다.
gitlab flow
github flow와, git flow의 중간정도의 복잡도를 가짐.
보통 배포 단계가 앱스토어를 거치면 바로 배포라는 github flow의 방침과 어긋남. 그렇기에 master 대신 pre-production단계를 하나 더 둠. 다 테스트를 진행하고 실제로 배포는 가능하지만, 바로 배포가 불가능 하다는 점 때문에 한 단계를 더 추가해서 관리
특징으로는 issue를 pre-production단계에서 조금이라도 수정이 필요한 경우라면 무조건 issue를 작성해서 버그 픽스를 진행한다는 점.
