GitHub

git은 버전 관리 시스템(VCS), github는 git을 사용해 cloud에 저장하는 서비스! github과 같은 레벨에는 gitlab(사설 서버 구성 가능), bitbucket이 있음

git client에는 gitCLI, git GUI, sourcetree, kraken, smartGit 등이 있고, 나는 fork랑 gitCLI, kraken을 사용해봤는데 fork가 가장 깔끔했으나, gui가 어색해서 gitCLI로 돌아옴


git의 특징

  • 빠른 속도, 단순한 구조
  • 분산형 저장소 지원
  • 비선형적 개발 가능 (브랜치 이용)


git 이용의 장점

  • 동시 작업 가능
  • commit 단위로 수정 내용 관리, 배포 뿐 아니라 원하는 시점으로 checkout 가능!
  • 새 기능 추가 시에는 branch 이용, test 완료 후에는 merge 가능
  • 인터넷이 연결되지 않아도 개발 가능


git object

  • Blob: 파일 하나의 내용에 대한 정보

  • Tree: Blob이나 subtree의 메타 데이터(디렉토리 위치, 속성, 이름 등)

  • Commit: 커밋 순간의 snapshot


image

conventional commits

  1. commit의 제목은 commit을 설명하는 하나의 구나 절로 완성
  2. capitalize 활용
  3. prefix 꼭 달기!
    • feat: 기능 개발 관련
    • refactor: 수정
    • fix: 오류 개선 및 버그 패치
    • docs: 문서화 작업
    • test: test 관련
    • conf: 환경설정 관련
    • build: 빌드 관련
    • ci: Continuous Integration 관련

+) 특정 버전의 api 지원을 중단하는 등의 강조해야하는 커밋이 있는 경우에는 BREAKING CHANGE 프리픽스를 이용하기도 함

  • commit 시에는 동작 가능한 최소 단위로 자주 할 것
  • 해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함
  • 모두가 이해할 수 있는 log 작성


LICENSE

  • MIT License: MIT에서 만든 라이센스로, 모든 행동에 제약이 없으며, 저작권자는 소프트웨어와 관련한 책임에서 자유로움(완전한 오픈소스!!)
  • Apache License 2.0: Apache 재단이 만든 라이센스로, 특허권 관련 내용이 포함되어 있음
  • GNU General Public License v3.0: 가장 많이 알려져 있으며, 의무사항 존재


.gitignore 파일을 이용해 특정 파일 혹은 디렉토리를 추적하지 않게 할 수 있음

.gitattributes를 이용해 파일 단위, 디렉토리 단위로 다른 설정을 부여할 수 있음


파일 rename 시에, github에 바로 push를 하게 되면 deleted되고, 새로운 파일이 생성되었다고 로그가 남기 때문에 git mv [이전 파일] [새로운 파일]로 이름을 변경해야함!


commit을 잘못했을 경우

*reset보다는 revert를 이용하기!

revert에서 --no-commit 옵션의 경우, 매 revert마다 commit 메시지를 작성하는 게 아니라 revert가 전부 끝나면 한번에 commit할 수 있음


CI

  • 자동화된 프로세스(빌드, 테스트, 머지)
  • 코드 변경사항의 정기적 빌드, 테스트 병합 자동화
  • 장점
    • 빠른 디버깅
    • 코드 품질 개선
    • 검증 및 릴리즈 시간 단축


CD

  • Continuous Delivery: 공유 저장소로 자동 Release(Test → Staging)
  • Continuous Delivery: Production Level까지 자동 Deploy(Test→Staging→Production)
  • MSA + Agile일 경우, 사용자에게 최대한 빠른 시간 안에 Production 제공 필요


깃헙의 CI/CD = GitHub Actions

→ 개발 workflow를 자동으로 관리

Workflow

  • Job들로 구성된 최상위 개념
  • event에 의해 자동 트리거
  • YAML파일로 작성, 레포의 .github/workflows에 저장

Event

  • Workflow를 실행하는 규칙 (workflow 동작의 조건)
  • push, pull request, cron, webhook으로 연결된 외부 이벤트에 의해 실행

Job

  • Step들로 구성
  • 가상환경의 인스턴스에서 실행
  • 다른 Job에 의존 관계를 가질 수 있고, 독립 병렬 실행도 가능함!

Step

  • Task들의 집합으로 커맨드를 실행하거나 action을 실행

Action

  • 가장 작은 단위
  • Step을 연결해서 Job을 구성함
  • 재사용 가능
  • marketplace나 개인이 만든 action을 사용할 수 있음

Runner

  • workflow가 실행될 인스턴스
  • github-hosted runner와 self-hosted runner로 나뉨


Branching

  • git flow
    • (hotfix)-master-(release)-develop-feature
    • :-) 가장 많이 사용함, 각 단계가 명확히 구분됨
    • :-( 복잡
    • gitflow init 명령으로 시작
  • github flow
    • master - feature
    • :-) 브랜치 모델 단순화, master의 모든 커밋은 deployable
    • :-( CI의존성이 높음, 실수한 코드도 바로 배포됨 (PR 이용으로 완화!)
  • gitlab flow
    • production(위 방식의 master 역할) - pre-production(test server) - master - feature
    • :-) deploy, issue에 대한 대응이 가능하도록 보완
    • :-( git flow와 반대됨


issue에 들어가는 내용: 설명, 할 일, 참조


느낀점

그동안 깃헙으로 협업을 해올 때 issue template같은 부분을 정확히 지키지 못했는데 이번 경험을 통해 컨벤션을 좀 더 정확히 정하고 실제 프로젝트에 반영해야겠다고 생각함


REF

DPA 2일차 오전 강의

https://velog.io/@lucasonestar/Git-work-flow-Fundamental-Command



Jira & Confluence

Jira

  • 흩어진 업무들 한 눈에 정리
  • 장기적으로 봤을 때 좋은 전략을 수립할 수 있음


프로젝트

팀 단위의 업무 혹은 팀 내의 큰 단위의 업무를 프로젝트로 묶어서 관리함

→ 단위가 많음


이슈

업무의 작은 단위로, 처리해야 하는 업무를 의미함

jira 내에서 중요한 정보는 누가 담당할 것인지(담당자), 언제 시작하고 마감 기한이 언제인지, 현재 진행 상태가 무엇인지 알아야 이슈 발행 가능


워크플로

업무의 상태를 변경하고 조절할 수 있음. 워크플로는 거의 고정되어서 사용됨.


기타 Jira 특징

  • git service에서 소스 연동을 하면 jira issue id를 가지고 소스 tracking이 가능함
  • webhook을 이용해 슬랙으로 알림을 줄 수 있음
  • 스프린트 → 특정 기간을 잡아 점검하고 뭐하고를 반복함
  • 필터링 기능: 원하는 필터에 따라 사용자 정의 필터링이 가능함(JQL 사용)


Confluence

: 노션, wiki와 같이 공동 작업이 가능한 보드

confluence는 jira와 연동이 가능하기 때문에 이슈 관리 및 자세한 정보 관리 시에 용이함


REF

DPA 오후 강의