개발이론 및 git 추가 정리(branch, merge)

Waterfall Model(폭포수 모델)

: 가장 익숙한 소프트웨어 개발 기법

• 병행 수행되지 않고 순차적으로 수행

 

장점

단순한 모델, 이해하기 쉬움

단계별로 정형화된 접근이 가능해 문서화 가능

프로젝트 진행상황 한눈에 명확하게 파악 가능

 

단점

수정이 어려움

시스템의 동작을 후반에 가야지만 확인 가능(그 전까지는 상상으로만)

따라서, 대형 프로젝트에 적용하기는 부적합

 

 

 

 

 

Agile(방법론X 사상O)

: 짧은 주기의 개발 단위를 반복해 하나의 큰 프로젝트를 완성해 나가는 것

요구사항을 작은 단위로 쪼갬 → 하나씩 해결해나감

• 협력과 피드백 중요
• 반복적으로 일을 진행해나가기 때문에 빠르고 유연하게 문제 해결 가능

 

Agile 방법론

1) scrum(스크럼)

: 작은 기능에 관한 계획, 개발, 테스트, 기능 완료를 주기적으로 시행하는 것

• 일반적인 스프린트 주기: 1~2주

2) kanban(칸반)

: 단계별 작업 현황을 열 형식의 보드 형태로 시각화하는 프로젝트 관리 방법

• 장점

     업무 흐름 시각화

     명시적 프로세스 정책 수립

     업무 흐름의 측정과 관리 용이

 

 

 

 

 

 

---

git(깃)

: 소스 코드를 효율적으로 관리하기 위해 만들어진 “분산형 버전 관리 시스템”

 

사용이유?

1) 소스 코드의 변경 이력을 쉽게 확인하기 위해

2) 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 돌아가기 위해

 

 

 

git 용어 추가 정리

전 정리)  https://palette77.tistory.com/7

git 설명

git commit -am

: add+commit

• 수정한 파일 중 특정한 파일만 올릴 수 없음

//README.md와 test.html파일을 수정한 경우(git status에서 수정된 파일 확인 가능)
//1) add와 commit 명령어를 따로 주는 경우
git add README.md  //README.md만 add 가능, test.html은 add 안 함
git commit -m "커밋메세지"

//2) commit -am 명령어를 사용하는 경우
git commit -am "커밋메세지"
//▲ git add .(무조건 현재 파일에 있는 모든 파일 add 됨) + git commit

 

git reset

• 가장 최근의 커밋 취소

     : add와 commit 동시에 취소(파일이 local Repository에서 작업공간으로 다시 돌아감)

git reset HEAD^

• 특정 커밋 취소

git log //id를 알 수 있음, Q키 눌러서 나오기
git reset —hard [id] //id시점 후의 커밋을 모두 삭제 가능

 

 

.gitignore

: 깃 버전 관리에서 제외할 파일 목록을 지정하는 파일

• 단, 아직 한 번도 올라가지 않았던(추적되지 않았던) 파일만 무시 가능
• git 관리에서 특정 파일을 제외하기 위해서는 git에 올리기 전 .gitignore에 파일 목록을 미리 추가해야 함.
• Remote Repository와 연결된 폴더에 .gitignore을 파일명으로 한 파일 생성 → 제외할 파일을 내용에 추가

 

 

 

 

 

branch(브랜치)

: 독립적으로 어떤 작업을 하기 위해 필요한 개념

branch 설명

 

branch 생성하기

git branch
// 내 local repository에 몇 개의 branch가 있는지 확인할 수 있음

git branch “브랜치명”
// 현재 branch에서 새 branch 생성

git checkout [브랜치명]
// 다른 브랜치로 이동

git branch -d [브랜치명]
// 브랜치 삭제(일반), 삭제하려고 하는 branch에서 나와 삭제해야 함(아니면 오류 뜸)
git branch -D [브랜치명]
// 브랜치 삭제(지우려는 barnch에 main보다 최근에 수정된 파일이 있음에도 그 branch를 삭제를 하고 싶은 경우)
git push origin --delete [브랜치명]
// remote repository에 있는 branch 삭제

git checkout -b "만들 브랜치명"
// 새로운 branch 생성하면서 동시에 그 branch로 이동

• 새로운 브랜치를 만들고 수정을 한 뒤 push를 하면, main브랜치는 수정 전 상황으로 유지되고 새로운 브랜치에만 수정사항이 적용돼서 저장됨

 

 

 

 

Merge

: git branch를 다른 branch로 합치는 과정

 

[  a브랜치에 b브랜치를 합치고 싶은 경우  ]

Case1) 서로 다른 파일을 수정 후 병합

1) merge하기

git checkout a //a 브랜치로 이동
git merge b  //b 브랜치와 병합

2) 커밋메세지 수정하기

• 알파벳i키를 누르면 insert모드로 전환됨 → 커밋메세지 수정 가능
• 수정 후 ESC키 눌러 insert모드에서 나오기
  • ": wq!" 입력: 수정된 메세지로 커밋메세지 저장 후 빠져나옴
  • ": q!" 입력: 수정한 메세지를 저장하지 않고 빠져나옴(커밋메세지를 수정하지 않은 경우 사용)

3) push하기

git push origin [브랜치명]

 

Case2) 서로 같은 파일에서 다른 부분(코드)을 수정 후 병합

• Case1과 방법 동일

 

Case3) 서로 같은 파일에서 같은 부분을 수정 후 병합

• Case1/2와 같이 할 경우 충돌(Conflict)이 생김

case3 merge오류

→ 수동으로 해결해야 함

충돌이 생기는 이유?

: 서로 다른 파일을 모두 수정했기 때문에 어떤 파일을 더 최신 파일로 두어야 할지 인식을 하지 못해 충돌이 일어나게 됨

 

 

[  해결 방법  ]

1) 충돌 부분 수정하기

충돌이 일어난 파일

• Aceept Current Change: 내가 지금 위치하고 있는 브랜치를 반영
• Aceept Incomming Change: 합치고자 하는 브랜치를 반영
• Aceept Both Changes: 브랜치 둘 다 반영(어떠한 것도 삭제하지 않음)
• Compare Changes: 수정한 부분을 비교해서 보고싶을 경우
• 위 선택들을 사용하지 않고 문제가 난 부분(꺽쇄부분)을 직접 지운 후, 다시 직접 코드를 입력하여 수정해도 됨!

2) add, commit, push하기

git add .
git commit -m "feat: 커밋 메세지 입력"
-> merging완료
git push origin [브랜치명]

>>> 해결완료!

 

 

 

참고) Pull Request

: 내가 수정한 코드가 있으니 내 branch를 가져가 검토 후 병합(merge)해 달라는 의미

• 당황스러운 코드 충돌을 줄일 수 있음

 

 

 

 

 

 

 

 

 

 

 

Branch 종류

branch 종류

1) master(main)

: 제품으로 출시될 수 있는 브랜치

• 배포(release)이력을 관리하기 위해 사용
• 배포 가능한 상태만을 관리하는 브랜치

2) develop

: 다음 출시 버전을 개발하는 브랜치

• 평소 개발을 진행하는 브랜치
• 기능 개발을 위한 브랜치들(feature)을 병합하기 위해 사용

3) feature

: 기능 개발을 진행하는 브랜치

• 새로운 기능 개발 및 버그 수정을 할 때마다 ‘develop’에서 분기
• 공유할 필요가 없어 로컬에서 진행 후 develop에 merge해 공유
• 이름: feature/~~

4) release

: 출시 버전을 준비하는 브랜치

• 배포를 위한 전용 브랜치
• 이름: release-0.0

5) hotfix

: 출시 버전에서 발생한 버그 수정 브랜치

• 배포한 버전에 긴급하게 수정해야 할 필요가 있는 경우 사용
• Master에서 분기
• 이름: hotfix-0.0.0