📖 수업내용

# 개발 방법론

1. 워터폴(Waterfall) 방법론

요구사항 정의(설계) → 디자인 → 개발 → 테스트 → 배포

• 앞 단계에서 요구사항을 분석하고 문서를 정리하는데 많은 시간을 기울인 만큼, 단계마다 소요되는 시간이나 최종 완료일을 파악할 수 있어 일정 관리하기가 용이하다는 장점이 있다. 또한 프로젝트 진행 상황을 한 눈에 명확하게 파악 가능하다.
• 앞 단계가 완전히 종료된 후 다음 단계를 진행하게 된다.(순차적 진행 O, 병행 X)
  -> 한 단계가 완전히 종료되면 고객의 추가 요구사항을 반영하거나 프로젝트의 방향성을 수정하기 어려우며, 시스템의 동작을 후반에 가야지만 확인이 가능하다는 단점이 있다.

이미지 참고

2. 애자일(Agile) 방법론

agile이란?
: 기민한, 민첩한

• 짧은 주기로 설계, 개발, 테스트, 배포 과정을 반복해서 하나의 큰 프로젝트를 완성해간다.
• 짧은 개발 주기를 반복하기 때문에 중간에 프로젝트의 방향성이 변경된다고 해도 변화에 유연하게 대응할 수 있다는 장점이 있다. (-> 빠르게 변하는 고객의 요구사항을 반영하고 수정해나갈 수 있다.)
• 워터폴 방식과 비교했을 때, 정확한 일정을 산정하고 예산이 세우기 어렵다는 단점이 있다.
• 실행하는 방법으로는 스크럼과 칸반이 있다.

이미지 참고

2-1) 스크럼(Scrum)

• 반복적인 개발 주기인 스프린트(일반적으로 1~2주)를 기반으로 제품을 개발하는 프레임워크이다.

  ① 개발자와 고객 사이의 지속적인 커뮤니케이션을 통해 요구사항을 수용한다.
  ② 고객이 결정한 사항을 가장 우선적으로 시행한다.
  ③ 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다. (예: 데일리 스크럼)
  ④ 주기적으로 제품 시현을 하고 고객으로부텅 피드백을 수용한다.

이미지 참고

2-2) 칸반(Kanban)

• WIP(Work In Progress)를 제한하는 방법으로, 이는 동시에 개발이 진행될 수 있는 아이템의 수를 제한하여 업무의 병목 현상과 리소스 낭비를 처리할 수 있도록 하기 위함이다.
• 우선순위가 낮은 이슈를 아래에 배치하고, 해당 이슈의 작업이 끝나면 다음 이슈를 진행한다.
• 칸반 보드에 팀과 조직의 작업을 시각화하여 작업의 흐름을 파악한다.

이미지 참고

참고
참고

# GIT(깃)

1주차에 git의 정의와 사용법에 대해 간단하게 알아보았다면, 이번에는 협업할 때 유용하게 사용할 수 있는 branch, merge 개념에 대해 알아보고자 한다.

branch와 merge에 대해서 알아보기 전에 다시 git이 무엇인지 간략하게 설명해자면,

git이란?
: 소스 코드를 효율적으로 관리하기 위해 만들어진 분산형 버전 관리 시스템이다.

1. Branch(브랜치)

• 독립적으로 어떤 작업을 하기 위해 필요한 개념이다.
• 예를 들어, A라는 사람이 '로그인' 기능을 만들고, B라는 사람이 '버그 수정'을 할 때 A와 B는 최초 브랜치에서 파생한 각각의 브랜치를 만들어 작업을 진행하고, merge를 통해 각자가 작업한 것을 최초 브랜치로 합칠 수 있다.

이미지 참고

1-1) branch 생성하기

// local branch 목록 확인
git branch

// 현재 브랜치에서 새로운 브랜치 생성
git branch "브랜치명"

// 브랜치 이동
git checkout "전환 브랜치명"

// 브랜치 생성과 이동을 동시에
git checkout -b "브랜치명"

// 브랜치 삭제 (단 삭제한 브랜치가 현재 브랜치에 합쳐져 있을 경우에만 가능)
git branch -d "브랜치명"

1-2) merge

• git branch를 다른 branch로 합치는 과정이다.

// a 브랜치에 b 브랜치를 합치고 싶은 경우
// a 브랜치로 이동 후 b 브랜치와 merge
git checkout a
git merge b

a 브랜치와 b 브랜치에서 ①서로 다른 파일을 수정했을 때, ②서로 같은 파일에서 다른 부분을 수정했을 때에는 충돌 없이 알아서 merge 한다. 하지만, ③서로 같은 파일에서 같은 부분을 수정한다면 충돌(conflict)이 발생하여 수동으로 해결해주어야 한다!

이미지 참고

• vscode를 사용하여 작업하고 있다면, vscode에서 보여주는 4가지 옵션 중에서 선택하여 충돌을 해결해주면 된다. 충돌을 해결한 후에는 파일을 저장하고 add -> commit -> push 순으로 진행한다.

1-3) 브랜치의 종류
협업에서 활용할 수 있는 branch 종류에 대해 알아보자.

① master : 제품으로 출시될 수 있는 브랜치이며, 배포 이력을 관리하기 위해 사용한다.
② develop : 다음 출시 버전을 개발하는 브랜치이며, 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.
③ feature : 기능 개발을 하는 브랜치이며, 새로운 기능 개발 및 버그 수정을 할 때마다 develop 브랜치에서 분기하여 사용한다.
④ release : 출시 버전을 준비하는 브랜치로, 배포를 위한 전용 브랜치이다.
⑤ hotfix : 출시 버전에서 발생한 버그 수정을 위한 브랜치이며, 배포한 버전에 긴급하게 수정해야 할 필요가 있는 경우에 master 브랜치에서 분기하여 사용한다.

이미지 참고

2.git 명령어

2-1)reset

• 커밋을 취소하기 위해 사용한다.

  // 바로 이전 커밋 취소
  git reset HEAD^
  
  // 특정 커밋 취소
  // 깃 로그 통해 취소하고자 하는 커밋의 SHA-1 체크섬을 확인한다.
  git log
  git reset --hard (커밋의 SHA-1 체크섬)

  커밋의 SHA-1 체크섬
  
  이미지 참고

2-2)Pull Request

• push 권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용한다.
• "내가 수정한 코드가 있으니 내 branch를 가져가 검토 후 merge 해주세요!" 라는 의미이다.

2-3).gitignore

• git 버전 관리에서 제외할 파일 목록을 지정하는 파일이다.
• 특정 파일을 제거하기 위해서는 git에 올리기 전에 .gitignore 파일 목록에 미리 추가해야 한다.
• 사용 예:
  ① *.txt : 확장자가 txt로 끝나는 파일 모두 무시
  ② !test.txt : test.txt는 무시되지 않음
  ③test/ : test 폴더 내부의 모든 파일을 무시
  ④ /test : 현재 폴더 내에 존재하는 폴더 내부의모든 파일 무시)

참고: 포스코x코딩온 강의 자료(1005개발문화,Git.pdf)

👩🏻‍💻 학습

# merge 실습

❗️ 4번까지는 문제 없이 해결하였는데, 수업 중에 'test'라는 브랜치를 이미 만들었다가 삭제했어서 push 하는 과정에서 아래와 같은 오류가 발생하였다. 'test' 브랜치 로컬 저장소에서는 삭제 되었지만, 원격 저장소에는 남아 있기 때문이라고 한다.

🤷🏻‍♀️ 어떻게 해결해야할까?

git push -u origin +브랜치명

-> 위와 같은 명령어를 사용하여 로컬에서 현재 작업한 내용을 원격 저장소에 강제로 push하여 덮어 씌울 수 있다.

-> 성공적으로 push 한 후, 수동으로 merge 충돌을 해결하고 add -> commit -> push 를 진행한다.

참고