생각기록
Git, Branch, Merge 사용법 본문
개발 문화
개발팀에는 어떤식으로 개발해야하고 수평, 수직적인 등등의 문화가 있다.
좋은 개발 문화는 따로 없다.
개인에게 맞으면 좋다. 정해진 것은 없다.
나에게 맞는것을 찾기위해 노력해봅시다.
AGILE ( 애 자 일 )
을 알려면,
WATERFALL MODEL(폭포수 모델) 을
알아야 한다.
WATERFALL MODEL(폭포수 모델)
- 가장 익숙한 소프트웨어 개발 기법
- 고전적인 소프트웨어 생명 주기
- 병행 수행되지 않고 순차적으로 수행
- 단점 : 한 단계씩 내려가기 때문에, 오류가 생길 시 하나씩 올라가야하는 큰 단점
장점
- 단순한 모델이라 이해가 쉬움
- 단계별로 정형화된 접근이 가능해 문서화가 가능하다
- 프로젝트 진행 상황을 한눈에 명확하게 파악 가능하다.
단점
- 변경을 수용하기 어렵다
- 시스템의 동작을 후반에 가야지만 확인 가능
- 대형 프로젝트에 적용하는 것이 부적합하고, 일정이 지연도리 가능성이 크다.
AGILE ( 애 자 일 )
- 날렵한, 민첩한
- 짧은 주기의 개발 단위를 반복해 하나의 큰 프로젝트를 완성해 나가는 것
- 협력과 피드백이 중요
- 유연한 일 진행 + 빠른 변화 대응
- 2-3주기로 설계, 개발, 테스트, 배포 과정을 반복
- 요구상 작은 단위로 쪼개 그에 대한 솔루션을 만들고, 빠르게 보여줌으로써 요구 사항에 대한 검증을 진행
회원가입 로그인때 이게 필요하다면, 먼저 만들어 끝내고
하나하나 한가지 기능씩 설계 개발 하고, 정상 작동하는지 테스트를 진행
에자일 방법론, 사상
Scrum(스크럼)
- 개발자와 고객 사이의 지속적 커뮤니케이션 통해 요구사항 수용
- 고객이 결정한 사항을 가장 우선적 수행
- 팀원들과 주기적 미팅 통해 프로젝트 점검
- 주기적으로 제품 시현하고 고객으로부터 피드백 수용
- 주기를 부르는 단어 스프린트 (작은 기능에 대해 “계획, 개발, 테스트, 기능 완료” 에 대해 주기적으로 시행하는 것)
Kanban(칸반)
- to do / doing / done 으로 나뉨
- 업무 흐름의 시각화
- 진행 중 업무의 제한
- 명시적 프로세스 정책 수립
- 업무 흐름의 측정과 관리
- 예) 외국에서 각자 포스트잇 색깔로 전체 프로세스를 간판식으로 만들어 진행상황을 서로 알림
git hub에도 이런 칸반 보드를 제공하고 있다.
협업에 도움이 되고, 이슈나 풀리퀘스트 연결짓기 가능하고, 업무관리가 용이하다.
GIT
소스 코드를 효율적으로 관리하기 위해 만들어진 "분산형 버전 관리 시스템"
사용이유
소스 코드의 변경 이력 쉽게 확인
특정 시점에 저장된 버전과 비교하거나 특정 시점으로 돌아가기 위해
Branch (나뭇 가지)
독립적으로 어떤 작업을 하기 위해 필요한 개념
- 여러명이 협업하거나 기능을 만들 때 독립적으로 작업위해 필요한 기능
- a라는 사람이 로그인을 만들고
- b라는 사람이 버그 수정을 할 때
- a와 b는 main(최초 브랜치)이란 곳에서 진행 x
- a와 b는 main Branch(최초)에서 파생한 각각의 Barnch를 만들어 작업 수행
= 같은 공간 진행이 아닌 파생된 공간(파생 branch)에서 작업을 진행하고
최초 barnch 로 merge를 통해 각자가 작업한 것을 합친다.
Branch 생성하기
git bash 키고
내 로컬 Branch 목록 확인
git branch
우리는 지금까지 main서만 작업했기때문에, main만 보인다.
새로운 브랜치 만들기
git branch '브렌치이름'
main을 복제 해서 새로운 가지를 만들 수 있다.
*** 항상 새로운 브랜치를 만들 때는!!! main 브랜치에서 파생 시켜야 한다. ***
★ 생성 & 이동 동시에
git checkout -b "만들 브랜치명"
브랜치 삭제하기
git branch -d " 브랜치명 "
*단, 삭제할 브랜치가 현재 브랜치에 합쳐져 있을 경우에만 삭제하자
메인보다 최신인 브렌치를 삭제하게되면, 경고 메세지가 뜬다.
-d를 대문자 D로 바꾸면 지워집니다.
git branch -D " 브랜치명 "
git branch하면, 삭제 된 것을 확인 할 수 있다.
> 깃헙홈페이지 리모트에는 반영이 되지 않아서 사라지지 않았다.
리모트 Branch 지우는 법 (Github 확인)
git push origin --delete "브랜치명"
같은 곳에 위치하면, 지우지 못한다. 다른곳으로 이동하고 지워야 함
* 보통 리모트 관련 push, pull은 origin "브랜치 이름" 인데, delete는 속성으로 쓰여서 사이에 들어간다.
브랜치를 옮겨 다닐 때
git checkout "전환 브랜치명"
git checkout branch2
각각의 파생된 가지에서 add commit push 가 가능하다.
git push
우리는 메인에 할 때
git push 만쳐도 된다.
하지만 파생된 branch를 push하려면!
git push origin '브랜치 이름'
git push origin 'branch2'
브렌치 코드는
add commit push를 한다고 해서 main에 영향을 끼치지 못한다.
*메인과 브렌치2는 다른상황임
Merge
a 브랜치에 b 브랜치를 합치고 싶은 경우
git checkout a //a브랜치로 이동
git merge b // 내가 현재 위치한 브랜치에 합친다. ( b를 a에 merge)
경우는 보통 3가지
1. 다른 파일 수정 했을 경우
1. main에서 test.html 파일을 만들고
2. main에서 브랜치 a 와 b를 만든다.
이런식으로하면 a, b에도 test.html 파일이 복사 되어 있다.
3. a는 readme.md파일 수정한다.
파일을 수정 후 항상 add, commit을 해줘야 한다.
4. 이제는 b로 가서 메인에서 복사된 test.html 파일을 수정한다.
확인을 해보자
5. 이렇게 하면 수정된 파일이 github에 올라가 있는 a, b 브랜치들을 볼 수 있다.
6. a로 이동한다.
a에다가 b를 합칠 거라 a로 이동했다.
git merge b
노랑색은 기본 메세지로 commit 처럼 메세지 쓰면 된다.
7. i 누르면 , 수정모드가 활성화된다.
-- insert -- > 수정모드
메세지를 feat:로 바꾸었다.
8. 수정 후 esc 누르고 나온다.
그리고 : 를 하면 밑에 :가 생기고
:wq! 라는 명령어를 치면, 수정 저장된다.
* :q! 저장 안되고 저장 된다.
9. 리모트 푸쉬 후 github 확인
git push origin a
2. 서로 같은 파일에서 다른 부분 수정( 타이틀 , h1 이 다름)
= 알아서 합쳐진다.
위에서 썻던 a, b 브랜치를 로컬과 리모트 각각 삭제 해주고 시작
* 보통 리모트 관련 push, pull은 origin "브랜치 이름" 인데, delete는 속성으로 쓰여서 사이에 들어간다.
이거 주의해서 씁시다.
1. main에서 c 브랜치 만들고 이동 후 test.html 파일 타이틀 수정, add commit 만 해보기
2. main에서 d 브랜치 만들고 이동 후 h1코드만 수정 후 2번처럼 add commit 하기
현재 같은 test.html 파일의 다른 부분들을 수정했다.
4. c 브랜치에 d를 합친다. merge
git checkout c로 이동해서 git merge d를 해준다.
자동 merge가 되면 이렇게 된다. > changed 라고 뜬다.
아까처럼 이 화면이 뜨지 않는다.
5. c에서 code . 해서 파일 확인해보면
파일에 c에 merge된 d가 보인다.
3. 서로 같은 파일이고, 같은 부분을 수정했을 때
위의 c, d 브랜치들을 지워준다.
push를 하지 않았으니 따햣로 리모트 브랜치 삭제하지 않아도 된다.
1. main에서 브랜치 e, f를 만들고
같은 파일 test.html 파일에서 둘 다 타이틀을 다르게 수정한다.
각 각 브랜치에서 파일 수정 후 add, commit을 해야 파일이 수정된다.
* e f 만들 때 main 에서 만들어야 함!! 같은 파일이 되서 자동 머지가 되버린다.
2. e로 이동 후 f를 머지 한다.
e|MERGING
저렇게 뜨면, 충돌이 생겼다는 뜻이다.
서로 같은 파일에서 같은 부분을 수정시 충돌 conflict가 생긴다. > 자동머지가 안됨!
* 어떤게 최신인지 알 수 없어서 그렇다.
충돌이 난 부분을 보여준다.
Accept current change
현재 위치한 브랜치로 변화
incoming chage
새롭게 추가하고자 하는 얘가 반영됨
both changes
둘다 반영하겠다 > 타이틀이 두개가 생김
compare changes
바뀐걸 구분을 해달라 / 정확히 어떤 라인에서 어떤게 바뀌었는지 자세히 비교해달라
충돌은
- 위에 선택사항 중에서 선택을 해주거나
- 직접 수정해줘야한다.
- 어쨋든 >>>>> 이 꺽쇄들을 삭제만 해주면 된다.
3. 하여간 선택하고 머지 저장을 하고
add commit을 해야 머지 형태가 끝이 난다.
4. 일반 상태로 돌아온다 MERGING이 사라짐
실습 Merge
- main에서 test.html 파일을 만든 후 push
- test브랜치 만들고
- main 에서 test.html 파일 h1 수정하고 commit
- test 브랜치로 옮겨가서
- test 브랜치에서 test.html 안의 타이틀과 h1 수정후 push
- main 브랜치에 test 브랜치 merge하기
- 충돌 해결 후 push
내가 틀렸던 점
파일을 수정하면, 반드시 add, commit을 해야 변경사항이 저장되고 다른 브랜치로 옮겨 갈 수 있다.
push 는 선택사항
main에서 merge를 하니
같은 부분을 수정해서 충돌이 생겼고
수정 사항 선택 후
add commit 하면 충돌이 사라지고,
그 상태에서 push 하면 된다!
github가서 확인해보면
Branch 종류
대형 프로젝트를 위해 알아 두면 좋은 지식!
브랜치 전략
master(main)
- 제품으로 출시될 수 있는 브랜치
- 배포(release)이력을 관리하기 위해 사용
- 배포 가능한 상태만을 관리하는 브랜치 ( 배포 단계를 기록하고 있다 )
develop
- 다음 출시 버전을 개발하는 브랜치
- 기능 개발을 위한 브랜치들을 병합하기 위해 사용
- 평소 개발을 진행하는 브랜치( 안정화 될때 main, master로 )
feature
- develop에서 파생시키고 기능개발을 진행하는 브랜치
- 새로운 기능 개발 및 버그 수정을 할때마다 'develop'에서 분기
- 공유할 필요가 없어 로컬에서 진행 후 develop에 merge해 공유
- 이름: feature/~~
- 보통은 feaure은 공유 안하지만, 우리는 할 것 이다.
release
- 출시 버전을 준비하는 브랜치
- 배포를 위한 전용 브랜치
- 일시적이다 (새롭게 잠깐 생겨서 바로 머지하기 때문에) > 이 기록은 master가 가지고 있다.
- 이름:release-0.0
hotfix
출시 버전(배포했을 때)에서 발생한 버그 수정 브랜치 (개발하는 단게에서 나온 버그는 피쳐)
얘는 master에서 분기
배포한 버전에 긴급하게 수정해야 할 필요가 있는 경우 사용
이름:hotfix-0.0.0
우리 팀프로젝트 할 때
디벨롭 기본 브랜치 두고
각자 맡을 기능으로 피쳐 파고 할 것임
git add . gitignore에 기재된 것 고려하여 모두 추가
git status 파일 상태 확인하기
참고
https://thebook.io/080212/ch03/03/03/
https://seonkyukim.github.io/git-tutorial/git-status/
Changes to be committed 명단에 있는 초록색 파일들이 Staged 상태의 파일
Changes not staged for commit 명단에 있는 빨간색 파일들이 Modified 상태의 파일
Modified 상태
스테이지에 등록된 파일은 깃이 추적 관리한다.
깃이 실제로 기록한 파일이며, 사실상 버전을 의미합니다.
수정하게 되면 '스테이지 영역'에서 제외 된다.
다시 적용하려면 git add 명령어로 재등록
https://iseunghan.tistory.com/322
[Git] Git 3가지 영역 (Staging Area) - Commit 이해하기
Staging Area Commit을 할 때, 총 3가지 영역을 바탕으로 작동합니다. Working Directory : 내가 작업하고 있는 프로젝트의 디렉토리 Staging Area : 커밋을 하기 위해 $ git add 명령어로 추가한 파일들이 모여있
iseunghan.tistory.com
File 관점에서는 다시 4가지 단계로 나뉜다.
- Untracked : Working Directory에 있는 파일이지만 Git으로 버전관리를 하지 않는 상태
- Unmodified : 신규로 파일이 추가되었을 때, new file 상태와 같다. ( $ git add 상태 )
- Modified : 파일이 추가된 이후 해당 파일이 수정되었을 때의 상태
- Staged : Staging Area에 반영된 상태
git commit -am
add . + commit 을 한번에 할 수 있다 => 스테이징 영역 지나서 로컬 저장소로 간다.
단점: 모든 파일을 한번에 다 올린다.
두개의 파일을 수정햇지만, 각각 커밋으로 올리고 싶을 때
git add <경로 및 file명>
add 취소하는 방법
git reset HEAD <경로 및 file명>staged changes 라고 vs코드에 있다. 돌리기 하면
마이너스(-)눌르면 스테이징 영역에 add 햇던 것을 취소한다.
commit을 하면 vs코드에서 해결 불가능 하다.
git reset HEAD^ = 가장 최근 커밋 취소
reset은 commit과 add가 취소 된다.
특정 커밋 취소 (최근게 아닌 특정 시점으로 전부 취소하고 싶을 때)
특정 커밋의 아이디를 알아야한다.
git log - 커밋 로그들이 다 뜸
commit 옆에 있는 숫자영어들이 아이디다
git reset 아이디 (최근게 아닌 특정 시점으로 전부 취소하고 싶을 때)
잘 쓰지 않는다.
Pull Request
프로젝트 할 때 사용할 것
내가 수정한 코드가 있으니 내 브랜치를 가져가 검토 후 병합(merge) 해주세요!!
- push권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용한다.
- 당황스러운 코드 충돌을 줄일 수 있음
open a pull requset에서
- base 내가 지금 올릴 곳
- compare 에 있는것을 base에 올리겟다.
a에 b를 머지 한다고 하면
a: base
b: compare
pull requset 올리고
누가 확인 후 코멘트를 달면, 확인받고 머지 하자
* 클래스명이 동일하면, 기능이 섞이고 망가질 수 있다.
Marge pull requset
gitignore
git 버전 관리에서 제외할 파일 목록을 지정하는 파일
- Git 관리에서 특정 파일을 제외하기 위해서는 git에 올리기 전에 .gitignore에 파일 목록을 미리 추가해야 한다.
- 한번이라도 git이 관리를 시작하면, 무시할 수 없게 된다.
제외할 파일들
라이브러리같은 경우 용량만 차지하기 때문에 올릴필요가 없고,
비밀번호 (데이터베이스), 아이피 > 누구나 내서버에 접속할 수 있기때문에 무시 시켜야 한다.
but 아직 한번도 올라가지 않은 파일만 무시 할 수 있다.
한번이라도 git이 관리를 시작하면, 무시할 수 없게 된다.
- *.txt → 확장자가 txt로 끝나는 파일 모두 무시
- !test.txt → text.txt는 무시되지 않음 (해당 파일만 무시하고 싶을때 파일 앞에 ! 를 붙이면 된다.)
- test/ → test 폴더 내부의 모든 파일을 무시 ( b.exe와 a.exe 모두 무시 )
- /test → (현재 폴더) 내에 존재하는 폴더 내부의 모든 파일 무시 (b.exe 무시)
'SeSAC 풀스택 > git관련' 카테고리의 다른 글
| git 오류! [rejected] develop -> develop (fetch first)error: failed to push some refs to (0) | 2023.03.21 |
|---|---|
| git err : Your local changes to the following files would be overwritten by checkout (0) | 2023.02.20 |
| Git hub 사전 지식 용어 (0) | 2022.11.01 |
| 환경설정 (에디터, GIT, GITHUB 원격저장소 만들고 사용하기) (0) | 2022.10.31 |
