SdardewValley의 개발 농사

Squash merge란? GitHub에서 PR을 merge할 때 [Create a merge commit], [Squash and merge], [Rebase and merge]의 3가지 옵션이 있다. create a merge commit은 단순하게 git merge 브랜치명만을 사용하는 방법이다. 해당 방법은 Fast-Forward & 3-way 병합 글을 보면 어떤 방식으로 병합이 되는지 알 수 있다. Rebase and merge는 rebase 글을 보면 된다. 이 글에서는 Sqash and merge에 대해서 다룰 것이다. squash merge는 git 히스토리를 요약해서 병합하는 방법이다. 분기 이후에 발생한 브랜치의 모든 commit들을 하나의 새 커밋으로 요약한다. 위에는 git log..

GitHub Actions란? GitHub Actions를 간략하게 설명하면 아래와 같다. GitHub Actions는 빌드, 테스트, 배포 파이프라인을 자동화할 수 있게 도와주는 CI/CD(지속적 통합/지속적 서비스 제공) 플랫폼이다. push라던가 pull-request 등의 이벤트가 발생했을 때 GitHub Actions에서 이벤트에 대한 워크플로우를 실행한다. 이벤트 처리를 위해서 GitHub에서는 Linux, Window, MacOS 가상머신을 제공해준다. GitHub Actions의 구성요소 이벤트가 발생했을 때 실행할 워크플로를 작성하면 해당되는 이벤트가 발생했을 때 가상머신이나 컨테이너에서 워크플로가 실행된다. 워크플로는 하나 이상의 job으로 구성이 되어 순차적으로 처리될 수도 병렬로 처..

revert 프로젝트를 되돌리기 위해서 reset을 사용하면 commit들이 삭제되기 때문에 좋은 방법이 아니다. 프로젝트를 과거 시점으로 되돌면서 기존의 commit들을 삭제시키지 않기 위해서는 revert를 사용하면 된다. revert는 기존의 commit들을 삭제하지 않고 새로운 commit을 생성하여 프로젝트를 과거의 시점으로 되돌린다. revert에서 log의 변화 git revert를 사용하면 메시지를 작성할 수 있는 vi 에디터가 나타난다. 로그를 출력하면 revert 메시지가 추가된 것을 확인할 수 있다. 그리고 파일들을 확인하면 이전의 시점으로 되돌아간 것을 확인할 수 있다. 여러 commit들을 revert 마침표 2개(..)를 사용하여 여러 commit들을 revert할 수도 있다. ..

reset reset은 이전 commit으로 되돌아 갈 때 사용한다. --soft git log를 간단하게 출력했다. 이를 기준으로 비교할 것이다. git reset에 soft 옵션을 주면 HEAD 포인터의 위치가 변했고 변경된 HEAD 포인터 다음의 commit이 사라진 것을 확인할 수 있다. 하지만 파일들을 출력해보면 다른 변화가 있지는 않다. 그리고 수정된 파일은 모두 stage에 등록되어 있다. 파일을 수정하고 add하고 commit을 한 3개의 상태가 있을 때 soft 옵션은 add를 하고 난 뒤의 상태로 되돌려 준다. 즉 commit을 하기 직전의 상태로 되돌려준다. add는 이미 실행되었기 때문에 스테이지에 파일들은 모두 등록되어 있다. 요약하면 soft 옵션은 HEAD의 위치를 변경하고, ..

rebase rebase도 merge와 마찬가지로 브랜치를 합치는 방법 중 한가지이다. rebase가 merge와 달리 commit들을 재배열한다. base 새로운 브랜치는 기존의 브랜치를 기반으로 생성된다. 그리고 이렇게 새로운 브랜치가 생성됐을 때 분기가 발생했다고 표현한다. 위의 그림에서 feature 브랜치는 main 브랜치 기반으로 생성된다. 분기가 발생한 공통 조상 commit, main commit 1을 base라고 한다. rebase는 이 base 앞에 re가 붙은 단어이다. rebase는 브랜치 분기가 발생한 기준이 되는 브랜치의 base commit을 변경하는 것이다. rebase를 하는 이유 rebase를 하면 commit의 트리 구조가 단순화된다. 브랜치의 개수가 많아지는 경우 co..

conflict 같은 위치의 코드를 동시에 수정하는 경우자동 병합이 실패하고 conflict가 발생한다. 파일의 동일한 부분을 수정하고 merge를 하면 CONFLICT 메시지가 출력된다. conflict가 발생했을 때 자동으로 commit이 생성되지 않는다. 이런 경우 직접 conflict를 해결하고 commit을 생성해야 한다. git status로 충돌시 상태를 확인하면 unmerged 메시지를 확인할 수 있다. 이런 충돌을 최소화 하기 위해서는 같이 작업할 때 상의를 하거나 혹은 자주 병합하는 것이 좋다. 💡 merge 취소하기 merge를 취소할 때 git merge --abort 명령어를 실행하면 된다. conflict 해결 > 병합하고자 하는 브랜치명(feature) conflict가 발생..

Fast-Forward Fast-Forward는 직역하자면 빨리감기이다. Fast-Forward 병합은 혼자 개발할 때 사용한다. 혼자 개발할 때 commit은 순차적으로 생성된다. commit이 순차적으로 발생한 경우 사용하는 병합 방식이 Fast-Forward이다. 혼자 작업 할 때 새로운 기능을 추가하기위해서 새로운 브랜치를 생성한다고 하자. commit들은 그림에서 볼수 있듯 순차적으로 생성된다. 해당 commit들은 Fast-Forward 방식으로 병합한다면 아래의 그림과 같이 병합될 것이다. 여기서 가장 큰 특징은 분기가 시작된 브랜치, 즉 main 브랜치에 아무런 변경도 없어야 한다. main commit 이후로는 어떤 commit도 없기 때문에 fast-forward 병합이 가능했다. 3-..

clean untracked 파일들을 clean 명령어를 통해서 제거할 수 있다. new라는 이름의 텍스트 파일을 생성했다. 해당 파일은 Untracked files, 즉 추적되지 않는 파일이다. 단순히 git clean 입력시 실행되지 않고 추가적인 옵션을 덧붙여야 한다. git clean -help를 실행하면 git clean 관련한 추가적인 옵션들이 출력된다. git clean -n을 입력하면 어떤 파일들이 제거될지 알 수 있다. n 옵션과 함께 d 옵션을 주면 어떤 디렉토리도 제거될지 알려준다. gitignore에 new2.txt 파일을 추가해 주었다. x, X 옵션이 없을 때 gitignore에 있는 파일은 제거 대상이 아니다. x (소문자 x) 옵션이 추가된다면 gitignore에 있는 파일 ..

스태시 스태시는 완료되지 않은 작업들을 임시로 저장할 수 있게 도와주는 기능이다. 스태시를 통해서 워킹 디렉토리의 작업을 스택 영역에 임시로 보관할 수 있다. 스태시를 사용하면 마지막 커밋 이후로 작업한 내용은 임시 저장되고 마지막 커밋 상태로 돌아간다. 변경사항이 남아 있을 때 git checkout으로 브랜치를 변경할 수 없다. 변경 작업을 도중 완료되지 않은 상태에서 브랜치를 변경해야 할 때 스태시 기능을 사용하면 된다. 실습 stash - 변경 내용 저장 새로운 브랜치에서 stash.txt라는 파일을 변경한 뒤 변경내용을 저장하지 않고 main 브랜치로 변경할 때 main 브랜치로 변경되지 않고 error가 출력된다. "Please commit your changes or stash them be..

새로운 브랜치를 생성하고 git branch -r로 원격 저장소의 브랜치를 출력하면 새로운 브랜치가 보이지 않는다. 따라서 원격 저장소의 정보를 업데이트해줘야 한다. 이때 git fetch 명령어를 사용하면 된다. git fetch를 하고 git branch -r로 원격 저장소의 브랜치들을 출력하면 새로운 브랜치도 출력된다. 로컬 저장소에서 원격 저장소의 브랜치를 가져와서 사용하기 위해서 git checkout -b [로컬 저장소 브랜치명] [원격 저장소 브랜치명]으로 브랜치를 생성해 주었다. 위와 같이 작업을 하고 commit, push를 하면, 원격 저장소의 thirdbranch에 작업 내용이 반영 되는 것을 확인할 수 있다.