프로그래밍 노트/GIT

Cache 액션을 사용하면 GitHub Actions에서 workflow가 실행될 때, 잘 바뀌지 않는 파일들을 깃허브 캐시에 올려놓고 CI 서버로 내려받을 수 있음 즉, workflow 성능 최적화에 도움이 됨 의존하고 있는 라이브러리들을 매번 네트워크(원격 저장소)에서 받아 오는 것이 아닌 캐시에 저장해두고 활용 실습 react 프로젝트를 하나 생성하여 package.json에 있는 라이브러리들을 캐싱해보자 1. 테스트용 react-app 생성 $npx create-react-app actions-cache 2. Cache 적용 전 Actions 실행 cache.yml name: cache workflow on: push jobs: cache: runs-on: ubuntu-latest steps: -..
Workflow GitHub Actions의 상위 개념 자동화 해놓은 작업 과정이며 repository내에 .github/workflows폴더 아래 yaml 파일로 설정 가능 여러 개의 워크폴로우 설정 가능 2가지 속성 정의 필요 on : 워크플로우가 언제 실행되는지 정의 jobs : 워크플로우가 구체적으로 어떤 일을 해야하는지 명시 on: push: branches: - master - dev pull_request: branches: - dev jobs: # ... master, dev 브랜치에 push이벤트가 발생할 때 마다 workflow를 실행해라. dev 브랜치에 PR이벤트가 발생할 때 마다 workflow를 실행해라. Jobs 독립된 가상 머신 또는 컨테이너에서 돌아가는 하나의 처리 단위 의..
[ 상황 ] feature 브랜치에서 기능을 개발하고 develop 브랜치로 병합을 하였다. 병합 후 서버를 올렸더니, feature 브랜치의 기능에 오류가 있는 것을 발견하고 병합된 commit 을 revert 시켰다. 오류 수정 후 다시 feature → develop 머지를 진행하는 경우 case1. 이 후 작업한 내용이 revert 작업 파일과 다른 경우 revert 이후 작업들만 develop에 머지된다. (충돌이 나지 않아 실수하기 쉬움) feature 내용들이 모두 develop 에 머지될 것으로 보이지만, revert 한 commit 이 feature 에서 작성한 commit 보다 최신일 경우에는 이 후 작업 내용들만 머지된다. case2. revert 되었던 파일을 수정한 경우 수정된 파..
PR을 올리고 approved가 끝나면 담당자는 merge를 하게 되는 merge 방식에는 3가지가 존재한다. 1. Create a mege commit 기본값으로 선택되어 있는 merge 방식 feature 브랜치가 root 브랜치로 합쳐지는 기본적인 머지 방식 2. Squash and merge feature 브랜치에 커밋 된 여러 개의 변경사항을 1개의 커밋으로 압축하여 root브랜치에 추가하는 방식 Squash and merge 를 사용하게 되면 위와 같은 커밋 이력들을 하나의 커밋 이력으로 압축할 수 있다. 3. Rebase and merge feautre 브랜치에 커밋된 여러 개의 변경사항을 root브랜치의 최상단에 끼워 넣는 방식 위와 같은 상황에서 Rebase and merge 를 하게되면..
작업이 아직 완료되지 않은 상태에서 다른 브랜치로 체크아웃을 하고싶다면, 결과물을 스테이시(stash)영역에 잠시 보관할 수 있다. 현재 진행중이던 내용들을 git stash로 저장해두고 다른 브랜치로 이동하여 작업한 뒤에 다시 돌아와 복구하여 작업진행이 가능하다. git stash : 스테이시로 보관 git stash list : 스테이시 목록 조회 git stash pop : 저장내용 복구 git stash apply : stash에 저장된 내용을 브랜치에 적용 git stash drop stash@{0}: stash에 저장된 내용을 삭제 git stash pop vs git stash apply git stash pop은 저장내용을 현재 브랜치에 적용 후 stash 목록에서 drop 한다. git ..
Git에서 작업 되돌리기 git reset git revert 두 가지 방법 존재 Git 리셋(reset) git reset 은 브랜치로 하여금 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다. ("히스토리"를 고쳐 쓴다.") git reset 은 마치 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것 git reset HEAD~1 Git 리버트(revert) 로컬 브랜치의 경우 리셋(reset)을 잘 쓸 수 있지만, "히스토리를 고쳐쓴다"는 점 때문에 다른 사람이 작업하는 리모트 브랜치에는 쓸 수 없음. 변경분을 되돌리고 이 되돌린 내용을 다른 사람들과 공유하기 위해서는, git revert를 사용해야함 git revert HEAD 로컬 브랜치의 경우 리셋(reset)을 ..
브랜치 강제로 옮기기 -f 옵션을 이용해서 브랜치를 특정 커밋에 직접적으로 재지정 할 수 있음 git branch -f master HEAD~3 강제로 master 브랜치를 HEAD에서 세번 뒤로 옮겨라 => bugFix와 master가 같은 커밋을 바라보고 있었지만, master 브랜치가 HEAD에서 세번 뒤로 옮겨감
Git의 상대 참조 한번에 한 커밋 위로 움직이는 ^ 한번에 여러 커밋 위로 올라가는 ~ Git의 상대 참조 master^ ⇒ master 브랜치의 부모와 같은 의미 master^^ ⇒ master의 조부모(부모의 부모)를 의미 git checkout master^ 를 하면 위와 같은 상태가 된다.
프로젝트를 표현하는 커밋 트리(commit tree)에서 이동할 수 있는 여러가지 방법을 알아보자. 알아야할 용어 HEAD HEAD는 현재 체크아웃된 커밋을 가리킴 (현재 작업중인 커밋) HEAD는 항상 작업트리의 가장 최근 커밋을 가리키며, 작업트리에 변화를 주는 git 명령어들은 대부분 HEAD를 변경하는것으로 시작함 일반적으로 HEAD는 브랜치 이름을 가리키며, 커밋을 하게되면 bugFix의 상태가 바뀌고 이 변경은 HEAD를 통해서 확인이 가능함 HEAD 분리하기 HEAD를 분리한다는 것은 HEAD를 브랜치 대신 커밋에 붙이는 것을 의미 HEAD → master → C1 git checkout C1 HEAD → C1
브랜치끼리의 작업을 접목하는 두 번째 방법은 리베이스(rebase)이다. 리베이스는 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳에 떨궈 놓는 것이다. (리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있음) bugFix 브랜치에서 git rebase master 명령어 실행 후 C3 커밋은 어딘가에 남아있고(흐려진 영역), C3'는 master 위에 올려 놓은 복사본이다. git checkout master git rebase bugFix master 브랜치에서 bugFix쪽으로 리베이스를 하게 되면 아래와 같이 된다.
깡냉쓰
'프로그래밍 노트/GIT' 카테고리의 글 목록