포스팅 주제
- 개발모델(agil, watetfall)
- Git, Branch
개발자들이 협업을 위해 사용하는 방식에 대해 알아보자
개발자들이 협업하기 위해서는 체계적인 개발진행 과정과 코드에 대한 수정, 업데이트가 즉각적으로 이루어져야한다.
여기, 애자일(Agile)과 Git이 있다.
개발진행 과정에는 다양한 모델 기법이 존재한다. 대표적으로는
- Waterfall
- Agile
등이 있고, 이외에도 다양한 모델 기법이 존재한다.
Waterfall
Waterfall(폭포수 모델)은 가장 익숙한 소프트웨어 개발 기법이다.
가장 고전적인 소프트웨어 생명 주기를 가지고 다음 작업과 병행 수행되지 않고 순차적으로 업무가 수행된다.
장점
- 단순한 모델이라 이해가 어렵지 않다.
- 단계별로 정형화된 접근이 가능해 문서화 하여 관리할 수 있다.
- 프로젝트 진행 과정이 정확히 나뉘어 있어 명확히 식별할 수 있다.
단점
- 단계별로 진행하기 때문에 변경이 발생하면, 수정하기 어렵다.
- 시스템이 제대로 작동하는지 확인하기 위해서는 후반 단계까지 가야해서 즉각적인 수정이 불가능하다.
- 대형프로젝트에 적용하는 것이 부적합하고, 일정이 지연될 가능성이 크다.
Agile
Agile(애자일 모델)은 짧은 주기의 개발 단위를 반복해 하나의 큰 프로젝트를 완성하는 방식이다.
장점
- 짧은 개발 주기로 협력과 피드백 적용이 쉽다.
- customer에 요구에 즉각적 반영이 가능하다.
Agile의 방법론은 Scrum(스크럼)과 Kanban(칸반이)이 있다.
- Scrum
- 개발자와 고객의 커뮤니케이션이 쉽고, 빠르게 요구사항을 적용 가능
- 팀원들과 주기적인 미팅을 통해 프로젝트를 쉽게 점검
- 추가적인 피드백을 간단히 수용(적용)가능
- Kanban
- 업무의 흐름을 시각화
- 진행 중 업무의 제한
- 명시적 프로세스 정책 수립
- 업무 흐름의 측정과 관리
Git
Git - 소스코드 효율적 관리를 위해 만들어진 "분산형 버전 관리 시스템"
소스 코드의 변경 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 돌아가기 위해 사용한다.
Branch(브랜치)
Branch는 나뭇가지, 분기라는 의미를 가진 영어로, 개발에서 브랜치는 코드관리에 필요한 개념이다.
브랜치를 통해 개발자들은 독립적으로 작업을 수행할 수 있다.
의미 그대로 Branch(브랜치)는 하나의 뿌리가 되는 master(원본)에서 Branch하여 나뭇가지 처럼 여러 분기를 생성하여,
원본을 훼손시키지 않고 각자 작업을 수행하고 'merge'를 통해 각자 작업한 업무를 합칠 수 있도록 해준다.
협업에 있어서는 업무 효율을 높일 수 있는 장점이 있다.
Branch(브랜치)는 어떻게 생성 할까?
브랜치는 터미널상에서 작업을 수행한다.
- git branch - local branch 목록 확인( 가지고 있는 branch 목록 )
- git branch '브랜치명' - '브랜치명' 새로운 branch 생성
- git checkout '전환 브랜치명' - '전환 브랜치명'으로 branch 전환 ( -b 를 사용하면 생성, 전환 한번에 진행 )
- git branch -d '브랜치명' - branch 삭제( 단, 삭제할 branch가 현재 branch에 합져저 있을 경우에만 )
Branch 합치기 Merge
branch로 나뉘어 작업한 결과 물들을 우리는 다시 합쳐서 하나의 결과물로 만들 필요가 있다.
이때! 사용하는 것이 merge, branch 합치기이다.
사용 방법은 아래와 같다.
ex) a브랜치에 b브랜치를 합치고 싶을 경우
- git checkout a - 우선 합칠 장소로 이동
- git merge b - b를 해당 장소에 합침
이를 통해 우리는 서로 작업한 결과물 들을 하나의 결과물로 합칠 수 있다!
하지만 여기서 3가지 케이스의 결과가 생길 수 있으니 조심해야 한다.
case 1 : a 브랜치와 b브랜치에서 서로 다른 파일을 수정했을 때
- 문제가 생기지 않는다.( 파일 이름이 같지 않다면 )
- 서로 다른 파일이라 충돌이 일어 나지 않는다.
동영상을 보시면, branch q와 w를 생성하고 각 branch에서 파일 newQ.html과 newW.html을 생성했다.
이후 branch newQ에서 merge w로 branch W와 합쳤을 때, 아무런 문제가 생기지 않았고 branch Q에서 W에서 만든 파일이 생긴 것을 확인할 수있다.
case 2 : 서로 같은 파일에서 다른 부분을 수정했을 때
- merge를 통해 합쳤을 때, 자동적으로 작성한 내용이 합쳐진다.
먼저 main에 new1.html 이라는 파일을 생성하고 이것을 master로 삼고 branch q와 branch w에서 수정하고 발생하는 일을 체크했습니다.
branch q와 w를 이번에는" git checkout -b q " 형식으로 생성했습니다.
각 branch에 들어가 보면 main에서 생성한 new1.html이 생성되어 있는 것을 확인 할 수 있습니다.
branch q에서 <body>태그에 <p>태그를 하나 만들고, banch w에서 확인하면 파일은 수정되어 있지 않습니다.
왜냐하면 현재 독립적으로 파일 작업이 진행되고 있기 때문이죠, 따라서 q에서 작업하는 업무들이 아직까지는 w에 아무런 영향을 끼치지 않고 있습니다.
branch w에서는 <head>태그에 <p>태그를 만들고 저장했습니다.
이 후 banch q에서 확인하면 변경사항은 수정되어 있지 않습니다. 이 때 branch q에서 merge w를 하여 둘을 합칩니다.
그러면 branch q에서 작업한 내용과 branch w에서 작업한 내용들이 합쳐지는 것을 확인할 수 있습니다.
* main에 new1.html(원본)은 최초 생성했을 때 모습을 유지하고 있습니다.
case 3: 서로 같은 파일이고 같은 부분을 수정했을 때
- 같은 부분을 수정하면 충돌(conflict)이 발생한다!
- 발생한 충돌은 수동으로 해결 해야한다.
branch q, w를 생성한다.
이 후 각 branch에서 파일을 수정 시킴니다. branch q에서는 <title> 태그와 <h1>태그를 수정
branch w에서는 <h1>태그를 수정 시킴니다.
이후 branch q에서 merge w를 사용해 branch q에 branch w를 합침니다.
이 때 <h1>태그에서 충돌이 발생 합니다.
왜냐하면 branch q와 w에서 같은 부분을 수정했기 때문에 누구의 수정본을 사용할지 골라야 합니다.
q 수정본을 쓸지 w 수정본을 쓸지 아니면 둘다 사용할지 고를 수 있습니다.
또는 직접 <<<<<로 시작하는 부분과 ==== >>>>> w로 나타나는 부분을 지워서 어떤 수정본을 사용할 지 직접 선택할 수 있습니다.
※ 모든 branch에서 파일을 만들거나 수정, merge할 때 먼저 파일을 저장하고 "git add ." , "git commit -m"를 통해서 파일을 로컬에 올려놔야 한다.
Branch 종류
대형 프로젝트를 위해 알아 두면 좋은 지식!
각 Branch마다 특정 용도로 사용하는 이름이 있다.
종류는 5가지로
- master
- develop
- feature
- release
- hotfix
등이 있다.
Branch - master
- 제품으로 출시될 수 있는 브랜치
- 배포(Release)이력을 관리하기 위해 사용한다
- 배포 가능한 상태만을 관리하는 브랜치이다.
Branch - develop
- 다음 출시 버전을 개발하는 브랜치
- 기능 개발을 위한 브랜치들을 병합하기 위해 사용
- 평소 개발을 진행하는 브랜치
Branch - feature
- 기능 개발을 진행하는 브랜치
- 새로운 기능 개발 및 버그 수정을 할 때마다 'develop'에서 분기
- 공유할 필요가 없어 로컬에서 진행 후 develop 에 merge해 공유
- 이름 : feature/~~
Branch - release
- 출시 버전을 준비하는 브랜치
- 배포를 위한 전용 브랜치
- 이름 : release-0.0 (버전 number)
Branch - hotfix
- 출시 버전에서 발생한 버그 수정 브랜치
- 배포한 버전에 긴급하게 수정해야 할 필요가 있는 경우 사용
- master에서 분기
- Master에서 분기
- 이름 : hotfix-0.0.0
* 분기를 원하는 브랜치가 있으면 뒤에 써주면 된다.
* ex) git checkout -b hotfix-0.0.0 master
git add. 와 git commit -m ""을 한번에 진행하고 싶으면
git commit am "커밋 메세지" 를 통해 한번에 진행 가능하다.
가장 최근 커밋 취소 기능은
git reset HEAD^ 명령어로 취소 가능하다
오래된 특정 커밋을 취소 하고 싶다면
git log를 통해 각 commit의 number값을 찾아서
git reset --hard number 를 사용해서 취소 가능하다.
( 하지만 해당 커밋 이후 다른 커밋이 있었으면 그 특정 커밋까지 진행된 모든 커밋이 취소 된다. )
Pull Request
- push 권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용한다.
- 직접 github사이트에서 내가 수정한 코드를 merge해달라는 요청을 해야한다.
- 당황스러운 코드 충돌을 줄일 수 있다.
.gitignore
.gitignore 란?
- Git 버전 관리에서 제외할 파일 목록을 지정하는 파일이다.
- Git 관리에서 특정 파일을 제외하기 위해서는 git에 올리기 전에 .gitignore에 파일 목록을 미리 추가해야 한다
- 미리 추가해 놓지 않았다면, 제외 목록을 그 이전 작업 파일이 올라갈 수 있다.
사용 방법
*.text - 확장자가 text로 끝나는 파일 모두 무시
!test.txt - test.txt는 무시되지 않음
test/ - test 폴더 내부의 모든 파일 무시
/test - (현재폴더) 내에 존재하는 폴더 내부의 모든 파일 무시
등과 같은 방식을 사용해서 사용할 수 있다.
git협업 방법을 배우면서 초반에 저장과 관련한 실수가 많아서, 헷갈리는 부분이 많았었는데 생각외로 엄청 복잡한 부분은 없었던거 같습니다.
아직 다른 사람들과 협업을 해본적이 없어서 실감은 안나는데 지금까지 느끼는 바로는 협업시에 매우 도움이 될거라 생각이드네요
하지만 여러 사람이 동시에 같이 분기 시키고 합치는 과정에서 소통이 안돼면 코드가 꼬일 거 같다는 생각이 듭니다😅
'웹 개발' 카테고리의 다른 글
| [포스코X코딩온] Bootstrap 및 Grid (0) | 2023.11.11 |
|---|---|
| [포스코X코딩온] 반응형 웹(Responsive Web) (0) | 2023.11.11 |
| [포스코X코딩온] jQuery를 이용한 캘린더 실습 (0) | 2023.11.07 |
| [포스코X코딩온] jQuery (0) | 2023.11.07 |
| [포스코X코딩온] JavaScript 사칙연산 계산기 만들기 (0) | 2023.11.06 |