沒入

GIT은 기본적으로 독립적인 히스토리를 병합하지 않는다.  문제 상황시스템 프로그래밍 실습에서, 팀 프로젝트를 하며 4개의 라즈베리파이를 사용했다.팀원들은 각자 하나의 파이에 대응하는 브랜치를 생성해 독립적으로 작업을 진행했다.문제는 최종 코드를 제출하기 위해 각 브랜치를 main 브랜치로 병합하는 과정에서 발생했다.깃허브에서 아래와 같은 메시지가 출력되며 PR 생성이 불가능했다.There isn't anything to compare.main and rfid-and-pir are entirely different commit histories PR이 아예 올라가지 않는 상황이었고, 깃허브 웹 인터페이스만으로는 문제를 해결할 수 없었다.로컬 환경에서 CLI(Command Line Interface)로 간..

git rebase를 진행하다 보면 prepare-commit-msg 훅이 커밋 메시지 형식을 검사하는 과정에서 오류가 발생할 수 있다.커밋 메시지가 정해진 규칙에 맞지 않으면 rebase가 중단되고, 아래와 같은 메시지가 출력될 수 있다.COMMIT REJECTED: { [api|web|infra] feat|fix|refactor|chore|test|docs|style|rename: commit 제목 } 제시된 형식에 맞게 작성해주세요husky - prepare-commit-msg hook exited with code 1 (error)error: could not commit staged changes.prepare-commit-msg를 또 수정하여 새로운 커밋을 작성하기 보다는,rebase 중에 p..

문제 상황git status를 확인하면 분명 로컬에 커밋이 있어서 push가 필요하다고 하는데, git push가 안 되는 상황. 에러 관련 메시지들을 보면error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400원격 프로시저 호출(RPC)이 실패했다, HTTP 400 오류가 발생했다고 한다. 이는 클라이언트 측 요청이 잘못되었음을 의미한다.send-pack: unexpected disconnect while reading sideband packet사이드밴드 패킷(데이터 전송을 위한 패킷)을 읽는 중에 원격 서버와의 연결이 예상치 못하게 끊겼다고 한다. 해결 방법해결 방법 먼저 살펴보자. git config --get http.p..

브랜치 이름 규칙기능 개발: feature/login, feature/select-product출시 준비: release-1.3, release-1.4긴급 수정: hotfix-1.2.1커밋을 해야 그때부터 브랜치다. 병합브랜치를 생성한다는 건, 협업을 위한 것그래서 브랜치를 병합한다. : 깃허브에서 병합 방법 : fast-forward와 3waysfast-forwardA branch에서 B branch를 생성한 시점부터,A branch에는 아무런 추가 구현을 하지 않고B branch만 추가 구현한 뒤B branch와 A branch를 합치면 -> A에 B가 붙으면 끝남.Before merge:main:    A---B              \feature:       C---DAfter fast-for..

깃허브 레포지토리 생성깃허브에서 레포지토리 생성하면 친절하게 세팅 방법을 알려준다. GitHub token처음으로 깃허브 연결한다면 usename, password 필요하다.password는 깃허브 패스워드가 아니라, 토큰 생성해서 집어놔야 한다. 프로필 - Settings - 제일 아래 Developer settings 들어가서Generate new token (classic) 해주면 된다.보안, 관리 효율성을 위해 여러 개의 토큰을 발급하여 사용할 수 있다.  git clonegit clone 원격저장소URL 새 디렉토리 생성: git clone을 실행하면, 지정한 리포지토리의 이름을 가진 새 디렉토리가 생성됨. 이 디렉토리는 클론된 리포지토리의 루트 디렉토리가 되는 것git init 실행: 새로 ..

commit을 하면 그 프로젝트의 버전을 통째로 옮기는 것!?한 수업에서 강사님께서 이렇게 말씀하셨다. 이 말처럼, 커밋을 들어가 browse files 하면 ? 그 당시의 프로젝트의 상태, 버전을 확인할 수 있다.그렇다면 Git은 모든 프로젝트를 새롭게 저장하는 걸까? -> 당연히 아니다. Git의 저장 방식은 효율적이고 강력한 버전 관리를 가능하게 하며,이는 스냅샷(Snapshot)과 델타(Delta, Δ 변화량)의 개념을 결합하여 이루어진다. 1. 스냅샷(Snapshot)Git은 각 커밋 시점에서 프로젝트의 모든 파일을 스냅샷으로 저장함. 그러나 모든 파일을 매번 복사하지 않음. 변경된 파일만 새롭게 저장하고, 변경되지 않은 파일은 이전 커밋의 데이터를 참조함.예를 들어, 100개의 파일이 있는 프..

GIT로컬 시스템GIT: 내 컴퓨터 안에서 버전 관리. 깃허브와 소통 (백업, 복구, ...)GITHUB: 원격 컴퓨터에서 백업 담당하는 시스템. 내 컴퓨터와 별도로 버전 관리. 다른 컴퓨터와 깃허브를 통해 협업 git installhttps://git-scm.com/ Git git-scm.comOS에 맞게 깃 설치git --version으로 확인 가능 쉘(Shell)셸 (Shell): 운영체제에서 사용자와 시스템 간의 인터페이스 역할을 하는 프로그램.사용자는 쉘을 통해 시스템 명령어를 입력하고, 쉘은 이 명령어를 해석하여 운영체제에서 실행할 수 있는 형태로 변환한다.왜 Shell이라는 이름을?- 사용자와 운영체네 내부(커널) 사이의 인터페이스를 감싸는 층- 껍데기를 통해서 안에 있는 내용물에 접근한다는..

Git LFS란 ? GitHub는 100MB 이상의 파일을 올릴 수 없다. Git LFS는 대용량 파일을 다루기 위한 오픈소스 프로젝트이다. Git LFS는 대용량의 파일들을 Git 내부의 텍스트 포인터로 대체하고, 파일의 내용은 원격 서버에 저장하도록 한다. Git LFS 레포지토리 clone 오류? LFS로 등록된 레포지토리를 그대로 clone 받으면 Git LFS 서버를 추적할 수 있는 텍스트 포인터만 저장되고, 원래의 코드들은 불러오지 않을 수 있다. 아래와 같은 과정으로 해결할 수 있다. 1. macOS 에서 git-lfs 설치하기 brew install git-lfs 2. Repository clone git-lfs를 install 하기 전의 repo에는 lfs 가 적용되지 않는다. 이전에 받..

커밋메시지를 작성할 때, 일관된 규칙을 따르는 정해놓고 따르도록 하는 것을 '커밋메시지 컨벤션'이라고 한다. 커밋메시지 컨벤션 중에서도 많이 사용되는 'Conventional Commits' 을 소개하려고 한다. Conventional Commits 사이트에 방문하면, 구조와 구성 요소, 사용 사례가 자세히 나와있다. Conventional Commits 사용 목적CHANGELOG를 자동으로 생성하기 위해서(포함된 커밋의 타입에 기반하여) 유의적 버전을 자동으로 변경하기 위해서팀 동료, 타인, 그리고 기타 이해당사자에게 변화의 본질을 전달하기 위해서빌드와 배포 프로세스를 수행하기 위해서더 구조화된 커밋 히스토리를 보여줘서 사람들이 프로젝트에 기여하기 더 쉽도록 하기 위해서 구조[적용 범위(선택 사항)]:..

『Do it! 깃 & 깃허브 입문』 3장. 깃과 브랜치 를 참고하였습니다 목차 3-1 브랜치란 3-2 브랜치 만들기 및 이동하기 3-3 브랜치 정보 확인하기 3-4 브랜치 병합하기 3-1 브랜치란? 브랜치(branch) 나무가 가지에서 새 줄기를 뻗듯이 여러 갈래로 퍼지는 데이터 흐름 깃으로 버전 관리를 시작하면 기본적으로 main 브랜치(구 master 브랜치) 만들어짐 사용자가 커밋할 때마다 main 브랜치는 어떤 게 최신 커밋인지 정보를 가짐. 기존 파일은 main 브랜치에 그대로 유지하면서, 새 브랜치에서 기존 파일 내용을 수정하거나 새로운 기능을 추가할 수 있음. main브랜치에서 새 브랜치를 만드는 것을 '분기(branch)한다' 분기했던 브랜치를 main 브랜치에 합치는 것을 '병합(merg..