git checkout
git checkout 이라는 명령어는 해당 브랜치로 이동 혹은 변경사항 취소해버리는 기능을 수행한다.
그래서 Git 측에서 최신 버젼에서 switch랑 restore 명령어를 만들어 두 기능을 확실히 갈라놨다.
하지만 여전히 checkout을 쓰는 경우가 많다.
git conflict
필요없는 내용물과 구분선을 지우고 다시 해보면 된다. vscode 상에서 에러가 나면 기존 사항과 변경사항중 어떤걸
살릴지 사용자에게 딱 보여준다.
git push -u origin <branchName>
여기서 -u 는 -upstreamset 을 뜻하며 로컬에서 브랜치를 만들고 원격저장소에 없을 경우, 원격 저장소에 해당 브랜치를
만들어주면서 로컬의 해당 브랜치를 Tracking 하게끔 동기화를 시켜는 것이다. 안붙이면 이름만 같은 동명이인 브랜치됨.
git fetch
remote의 변경사항을 local로 가져와서 FETCH_HEAD 라는 임시브랜치에 변경사항을 넣어놓고 그 변경사항을 받아드릴거면 main에 사용자가 직접 merge를 하면된다. 보통은 github.com에서 직접 편하게 변경사항을 확인하고 git pull로 댕겨서 합친다. git fetch, merge가 그냥 합쳐진거라고 보면 된다.
Rename
Worst - $ mv server.py main.py -> deleted, new file
Best - $ git mv server.py main.py -> renamed
파일의 history를 남기기 위해서는 삭제 후 생성이 아닌 이름바꾸기로 추적
Branch Model
git flow
(hotfix)- master -(release)- develop - feature
hotfix - 긴급 패치같은때 쓴다.
마스터와 디벨롭이라는 중요한 브랜치를 놓고 어떤일 하느냐에따라 다른 브랜치에서 작업하고 push하는 방식
장점 : 가장 많이 적용, 각 단계가 명확히 구분
단점 : 복잡
github flow
master - feature
장점: 브랜치 모델 단순화, master 의 모든 커밋은 deployable
단점: CI 의존성 높음. 누구 하나라도 실수했다간..(pull request로 방지)
gitlab flow
production - pre-production - master - feature
장점: deploy, issue에 대한 대응이 가능하도록 보완
단점: git flow와 반대 ( master -develop, production -master)
git flow strategy
내 머릿속에서 기억하는 git flow 의 흐름
1. 포크한 리포지토리를 클론하고, 로컬로 가져와서 킨다.
2. git remote add upstream URL 로 최상단 레포지토리 주소를 등록한다.
3. git flow init 을 해서 develop branch를 만들어준다. 이미 있다면 그 develop으로 잡아준다.( 다 enter 눌러버리기 )
4. develop 브랜치에서 추가, 수정할 사안을 보고 git flow feature start <featurename> 을 입력해준다.
5. feature/featurename 이라는 브랜치가 생성되면서 checkout이 되고 여기서 본인이 수행할 작업을 시작한다.
6. 작업이 다 끝난다면 git flow feature finish featurename 입력하여 작업을 마무리해준다.
7. develop 브랜치로 자동으로 merge되면서 checkout 이 됩니다.
8. 그리고 add, commit 하고 다른 기능 작업을 수행해야한다면, 다시 feature start를 하면되고, 다 끝났다면 push한다.
9. 본인이 포크한 레포지토리에 변동사항이 정상적으로 올라왔다면 pull request한다.
10. 본인의 develop 브랜치에서 -> 최상단의 develop 브랜치로 pull request 해야한다는 점 잊지말자.
11. 이제 팀장(?) 입장에서 시작을해보자. 최상단 레포지토리를 로컬로 클론한다. 릴리즈를 시킬것이다.
12. git flow release 입력을 해준다. 그리고 git flow release start <version> 을 입력한다.
13. release/version 이라는 브랜치가 자동으로 생성 및 체크아웃 될 것이다. 여기서 최종적으로 고민한다.
14. 더 이상 볼게 없다면 git flow release finish <version> 을 입력한다..
15. release/version은 없어지고, main 과 develop 브랜치에 변동사항 및 태그가 합쳐진다.
16. 그리고 원격저장소로 각 브랜치로 checkout 하여 push해주고, git push --tags 를 사용해서 태그도 푸시한다.
'Git' 카테고리의 다른 글
Git flow init 초기 설정 다시 하기 (0) | 2022.09.17 |
---|---|
Git branch Recap (0) | 2022.07.08 |
Git Initialization Command (0) | 2022.06.27 |
Github - Profile ReadME 꾸미기 (0) | 2022.06.23 |