어제 자 복습 - git 허브에서 새로운 (branches , readme 포함) repo를 만들어서 git clone의 방법으로 로컬저장소에서 가져오기 - hello.py를 만들고 print('hello')를 추가한 뒤 해당 내역을 add, commit, push
1. github 사이트에서 새로운 레포스토리를 만들고 url을 가져오기 2. 터미널에서 dev 위치를 찾아가기 시작 위치 -> pwd로 확인 -> ls -> cd documents로 들어가기 -> ls -> cd dev -> dev 폴더 도착 3. git clone branches 로포스토리_url -> branches 폴더가 생긴 것을 보기 4. cd branches로 branches파일로 들어가기 5. touch helllo.py를 생성 6. vi hello.py로 들어가서 print(hello.py) 하고 :wq로 저장하고 나온다 7. git status로 상태 확인 8. commit hello.py로 commit 수정 9. git status로 상태 2차 확인 10. git push origin main으로 올리기
branch - 분기점을 생성하여 독립적으로 코드를 변경할 수 있도록 도와주는 모델 - 코드의 여러 버전을 동시에 작업할 수 있게 해주는 독립된 작업 영역 - 주로 새로운 기능을 추가하거나 버그를 수정할 때, 원본 코드를 안전하게 유지하면서 별도의 공간에서 작업가능하게 도와줌
- 기본 branch는 main이다. : Git 저장소를 처음 만들면 기본 브랜치가 생성 - 프로젝트의 안정적인 버전이나 출시 가능한 상태의 코드를 유지하는 곳 - git branch를 하면 main이 뜬다.
- 목록을 보여주는 명령어 - git branch -r : **원격 저장소(Remote)**에 있는 브랜치 목록 - git branch -a : 로컬과 원격 저장소에 있는 모든 브랜치 목록
- git branch (폴더명, 예시(if)) : git branch if 라고 하면 if라는 branch가 생김 - main과 if 가 둘다 있는 것을 확인
- git switch if 로 하면 main에서 if으로 바뀜
- if 에서 바꾸기 - vi hello.py 으로 내용 수정 -> cat hello.py 에서 확인 -> python hello.py 에서 작동 확인 - git status 으로 상태 확인 -> git add hello.py -> git commit -> git push origin main
- 다시 main으로 돌아가서 확인해보기 - git switch main으로 main으로 돌아오기 git branch으로 현 위치 확인 - cat hello.py -> print('hello')로 뜸 : main이랑 if랑 다른 작업창이다
- if 에 있는 내용을 main으로 불러오기 - git merge if 으로 if 내용을 main에 덮어쓰기 - cat hello.py -> 수정 내용이 확인됨 : if에 있는 게 main으로 옴 - git push origin main : github에 올리기 -> 깃허브에서 내용이 수정된 거 확인가능
- if 브랜치 삭제하기 - git branch -D if : 삭제 명령어 - git branch : if가 사라진 거 확인가능
- 새기능, 테스트 등등에 활용이 가능 : 코드의 보존이 필요할 때 가능
위치를 고정하고 싶은 곳을 고정하는 방법 1. 원하는 위치에서 원하는 시점 잡기 2. git branch를 하기 - main 확인하기 3. git branch if라고 하면 if라는 branch가 만들어짐 4. git switch if 로 위치 변경 후, vi hello.py ->cat hello.py->python hello.py -> git status ->git add hello.py ->git commit -> git push origin main 5. git switch main으로 main에 돌아와서, 확인 작업 : cat hello.py -> git merge if -> cat hello.py -> git push origin main 6. if branch 삭제하기 git branch -D -> git branch
main이랑 for이랑 둘다 바꾸고 하면, merge가 바로 안 되고, Auto-merging hello.py CONFLICT (content): Merge conflict in hello.py Automatic merge failed; fix conflicts and then commit the result. 라는 충돌이 뜬다, - vi hello.py로 들어가면 내용이 겹쳐져서(코드가 길어져도 충돌된 일부만 저렇게 됨) 코드사용 불가능 - 여기서 코드를 고쳐줘야함 : commit 도 고쳐주기
git branching strategy
git flow
- 가장 전통적이고 많이쓰이는 모델 (이제는 앱설계빼고는 안 쓴다..) - git flow cheatsheet : https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html - 각 단계가 명확히 구분되어 배포주기가 주기적인 서비스에 유리. 하지만 복잡.. - 프로젝트의 개발 단계가 복잡하거나 배포 주기가 정해져 있는 경우에 유용(앱스토어에 들어가는 앱들) - 여러 단계의 브랜치를 사용하는 방식이므로 비교적 복잡하지만, 명확하게 각 작업의 단계를 구분할 수 있다는 장점 - 장점 : 안정적인 배포, 명확한 구조 - 단점 : 명확한 구조
github flow 검수한 코드만 master에. feater라고 적힌게 각각의 브랜치
- 브랜치 모델의 단순화. - https://docs.github.com/en/get-started/using-github/github-flow - CI 의존성이 높고, pull request가 없으면 실수에 대처가 힘듦 - Git Flow보다 더 간단하고, **지속적인 통합(CI)**과 같은 자동화된 빌드 프로세스에 의존하는 환경에 적합한 브랜치 전략 - GitHub에서 많이 사용되며, 모든 기능은 브랜치를 만들고 Pull Request(PR)를 통해 병합하는 방식 - 장점 : 단순함, 빠른 배포 - 단점 : Pull Request에 의존( Pull Request를 통해 코드 리뷰와 테스트를 반드시), 단일 브랜치 ( 대규모 프로젝트에서는 병렬 작업이나 복잡한 작업 흐름을 관리하는 데 어려움)
gitlab flow
- deploy, issue에 대응을 하기 쉽도록 한 모델 : github flow를 조금 더 체계화하고 구분화 한 모델 - 조금더 편리하고 구분하기 좋음 - https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/ - Git Flow의 복잡함을 줄이면서, 배포 환경이나 이슈(문제 해결)에 맞춘 브랜치 전략을 제공 - GitLab의 CI/CD 기능을 활용해 production(프로덕션), staging(스테이징) 환경에 대응하기 쉽게 설계 - 장점 : 배포 관리 용이, 이슈 트래커와 통합 - 단점 : 유연함 부족, CI/CD의존성 - CI (지속적인 통합): 개발자들이 작업한 코드를 정기적으로 병합하고, 자동화된 빌드 및 테스트를 통해 코드의 문제를 빠르게 찾아내는 과정. - CD (지속적인 배포): 코드를 배포 가능한 상태로 자동으로 준비하는 과정(Continuous Delivery) 또는 프로덕션 환경에 자동으로 배포하는 과정(Continuous Deployment)
github flow 실습 - fibo라는 이름을 가진 새로운 repository를 만들기 - dev 에서 작업시작! -> git clone fibo_repo url - ls -> cd fibo 로 fibo로 들어가기 - ls 하고 git branch fibo로 fibo 브런치 만들어서 git switch fibo로 fibo 들어가기, git branch로 확인 - touch fibo.py로 생성 후 vi fibo.py로 fibo.py 수정하고 cat fibo.py랑 python.fibo.py로 확인 - git add fibo.py 로 올리고, git commit -m "fibo"로 commit
- git push -u origin fibo : Git에서 특정 브랜치를 원격 저장소에 푸시하고, 해당 브랜치를 추적하도록 설정하는 명령 -fibo라는 브랜치에 올림
- 깃허브에서 pull requests 탭으로 들어가기 - New Pull Request 버튼을 클릭하여 새로운 PR -
Trouble-shoot
Stash : 작업중인 변경사항 잠시 미뤄두기 - 작업 중 브랜치 이동이 필요할 때, 작업사항을 잠시 미뤄둘 때 사용
- git stash # 변경사항을 임시로 저장 - git checkout other-branch # 다른 브랜치로 이동# 작업 완료 후 - git checkout my-branch # 다시 원래 브랜치로 이동 - git stash pop # 스태시를 적용하고 작업 이어나감
RENAME : 파일 이름 혹은 위치 수정
Undo : Working Directory에서 변경사항 취소하기
Unstaging : Stage의 변경사항을 Working directory로 내리기 - git - Unstaging and remove : Stage의 변경사항을 Working directory로 내림과 동시에 삭제 -
Edit commit message : 직전의 commit message 수정 - Edit commit message : 이전 commit message 수정하기
Reset commit : 없었던 일로 만들기 -$ git reset --hard HEAD~{nums of commit} - $ git push -f origin - {nums of commit}개의 커밋을 삭제 후 remote 에 강제 push - 협업 시에는 나의 local과 clone한 remote repo에서 지워졌다고 해도 다른 곳에 남아있던 이력으로 인해 살아나거나, 충돌이 발생함
Revert commit : 잘못을 인정하고 특정시점으로 되돌리기 - $ git revert --no-commit HEAD~{nums of commit}.. $ git commit $ git push origin - {nums of commit}개의 커밋을 되돌린 후 remote 에 push - 잘못하기 직전 시점으로 되돌리고 해당 되돌림의 이력을 팀원들에게 전달하여 어떤 문제가 있었고, 어 떻게 수행되는지에 대해 뚜렷한 설명 가능 - commit을 따로 하지 않을 땐 ‘—no-edit’ - merge commit을 되돌릴 땐 ‘-m’ (ex) $ git revert -m {1 or 2} {merge commit id})
터미널로 녹화하기 : asciinema
팀 일 하기 new orgainztion을 만들기 -> free로 선택 - 이름은 길고 신박하게 짓는 게 좋고 / 개인 이메일 / My personal account / coplit은 안해도 된다 + 팀원 초대 바로도 가능하고 아니면 만든 후에 people 탭에서 가능함!
- 팀장 이외는 오너보다 멤버로 하는 게 좋음 : 오너는 렢포를 지우는 등등 너무 위험함! - 멤버에게 메일을 보내면 수락하면 실행시작!
팀장은 이제 미리 레포를 만들어두기! - 꼭 public으로 하고, readme , licencse는 mit로 하기! - dev로 이동을 해서 클론을 하기 : 오너만 바로 작업 가능. 하지만 팀원은 불가능, 하지만 일할땐 동일하게 팀원처럼 - gitignore 을 하기 : 무얼 쓰는지 다 적어두기 - 동작파일 만들어두기 - git push origin main 까지 해두기! - issue templates 만들기 : setting 에서 issue를 찾아서 만들면 됨 - custome issue template으로 가서 이름 수정, 내용 수정, 라벨 선택 - issue 탭에 milestones 하기 : 일반적으로 .sprint를 사용. 2주정도 잡음, description엔 목표 적기, - issue는 팀원들이 일하는 거다! - backlog : 기간동안 할 모든 일, ready : - 이제 배분
팀원 일하기!
- vscode의 터미널에서 가능 dev로 가서 git clone 주소 해서 팀의 폴더로 들어가서 py를 불러오기
- 작업 -> 저장 -> git 관련 작업
- main에서 절대 작업 금지!!!! : 각가의 branch를 만들어서 가져오기
- 작업 후에, 터미널에서 git status 하고 git에 올려주기(git add, git commit 까지 하기)
- fizz는 완료가 되었으니까, fizz가 끝난 걸 말해주기! -> 그래야 팀원들이 아니까, 이해 잘 하기
- git push -u origin (branch명) : 처음이니까 -u를 해주기
- 팀에게 넘겨주기 : comparment requit를 하기 : 방향 잘 보기!!!!!!!
