[포스코x코딩온]개발문화(Waterfall, Agile,Git)

개발 문화

Waterfall 모델

• 가장 익숙한 소프트웨어 개발 기법
• 고전적인 소프트웨어 생명 주기
• 병행 수행되지 않고 순차적으로 수행

• 장점
  • 단순한 모델이라 이해가 쉽다.
  • 단계별로 정형화된 접근이 가능해 문서화가 가능하다.
  • 프로젝트 진행 상황을 한눈에 명확하게 파악 가능하다.
• 단점
  • 변경을 수용하기 어렵다.
  • 시스템의 동작을 후반에 가야지만 확인이 가능하다.
  • 대형 프로젝트에 적용하는 것이 부적합하고, 일정이 지연될 가능성이 크다.

---

Agile(애자일)

• 짧은 주기의 개발 단위를 반복해 하나의 큰 프로젝트를 완성해 나가는 것
• 협력과 피드백
• 유연한 일 진행 + 빠른 변화 대응
• 요구 사항을 작은 단위로 쪼개 그에 대한 솔루션을 만들고, 빠르게 보여줌으로써 요구 사항에 대한 검증을 진행
• 계획 -> 디자인 -> 발전 -> 테스트 -> 검토 순으로 반복 작업을 한다.

• Scrum(스크럼)
  • 개발자와 고객 사이의 지속적인 커뮤니케이션을 통해 요구사항을 수용
  • 고객이 결정한 사항을 가장 우선적으로 시행
  • 팀원들과 주기적인 미팅을 통해 프로젝트를 점검
  • 주기적으로 제품 시현을 하고 고객으로부터 수용
  • Sprint : 작은 기능에 대해 "계획, 개발, 테스트, 기능 완료"에 대해 주기적으로 시행하는 것 / 1~2주

• Kanban(칸반)
  • 단계별 작업 현황을 열(column)형식의 보드 형태로 시각화하는 프로젝트 관리 방법
  • 업무 흐름의 시각화
  • 진행 중 업무의 제한
  • 명시적 프로세스 정책 수립
  • 업무 흐름의 측정과 관리

---

Git

• 소스 코드를 효율적으로 관리하기 위해 만들어진 "분산형 버전 관리 시스템"
• 소스 코드의 변경 이력을 쉽게 확인하고 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 돌아가기 위해
• Branch
  • 독립적으로 어떤 작업을 하기 위해 필요한 개념
  • git branch : local branch 목록 확인
  • git branch "브랜치명" : 현재 branch에서 새로운 branch 생성
  • git checkout "전환 브랜치명" : branch 이동
  • git branch -d "브랜치명" : 삭제할 branch가 현재 branch에 합쳐저 있는 경우 삭제 (무조건 삭제는 -D)
  • git checkout -b "만들 브랜치명" : branch 생성 & 이동
    • 종류
      • master 
        • 제품으로 출시될 수 있는 브랜치
        • 배포(Release) 이력을 관리하기 위해 사용
        • 배포 가능한 상태만을 관리하는 브랜치
      • develop
        • 다음 출시 버전을 개발하는 브랜치
        • 기능 개발을 위한 브랜치들을병합하기 위해 사용
        • 평소 개발을 진행하는 브랜치
      • feature
        • 기능 개발을 진행하는 브랜치
        • 새로운 기능 개발 및 버그 수정을 할 때마다 'develop'에서 분기
        • 공유할 필요가 없어 로컬에서 진행 후 develop에 merge해 공유
        • 이름: feature/~~
      • release
        • 출시 버전을 준비하는 브랜치
        • 배포를 위한 전용 브랜치
        • 이름: release-0.0
      • hotfix
        • 출시 버전에서 발생한 버그 수정 브랜치
        • 배포한 버전에 긴급하게 수정해야 할 필요가 있는 경우 사용
        • Master에서 분기
        • 이름: hotfix-0.0.0

• Merge
  • git branch를 다른 branch로 합치는 과정
    • a브랜치에 b브랜치 합치는 경우 : git checkout a (a로 이동) -> git merge b(b와 merge 진행)
    • Case1. 서로 다른 파일을 수정했을 경우 : 알아서 Merge 된다.
    • Case2. 서로 같은 파일에서 다른 부분을 수정했을 경우 : 알아서 Merge 된다.
    • Case3. 서로 같은 파일에서 같은 부분을 수정했을 경우 : Conflict 발생
      • 충돌난 부분을 확인하고 코드를 수정하여 다시 add -> commit -> push 한다.

이처럼 충돌 결과에 대해 알려준다. (Git입장에서 같은 곳을 다르게 수정하면 어느 것이 맞는건지 모르기 때문에 충돌이 난다.)

Git의 전체 프로세스

 

-am은 add+commit / reset은 커밋 취소

 

• Pull Request
  • Push 권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용
  • 수정한 코드를 branch에서 가져가 검토 후 병합
  • 코드 충돌을 줄일 수 있음
• .gitignore
  • git버전 관리에서 제외할 파일 목록을 지정하는 파일
  • git관리에서 특정 파일을 제외하기 위해서 git에 올리기 전에 .gitignore에 파일 목록을 미리 추가
  • *.txt : 확장자가 txt로 끝나는 파일 모두 무시
  • !test.txt : test.txt는 무시되지 않음
  • test/ : test폴더 내부의 모든 파일을 무시
  • /test : (현재 폴더)내에 존재하는 폴더 내부의 모든 파일 무시

---