개발 일기

PR에 대한 공부를 위해 다른 블로그에서 정리된 글을 제가 읽기 쉽도록 글 구조만 살짝 변경한 글입니다. (원글)https://hyoloui.tistory.com/110 Project: Develife - ✨PR(pull request) 사용법(git hub)🎯목적 : Git hub : Pull request 개념 정리 적용 : Pull request 활용, 팀원들과 코드 리뷰하기 1. PR은? 프로젝트의 Contribute로 등록되지 않는다면 Fork 하여 repository를 복사해 나의 깃허브 repo로 가져오는 방hyoloui.tistory.com1. PR은?해당 포스팅 내용에서는 팀원으로써 같이 프로젝트에 참여 한다고 가정한다.주된 기능이 모여있는 dev 나 develop 브랜치로'내 작업 내..

🍒 cherry-pick이란?특정 브랜치에 있는 커밋 하나 또는 여러 개를 현재 브랜치로 "선택적으로" 복사해오는 Git 명령어.merge, rebase는 브랜치 단위로 히스토리를 합치는 방식이라면,cherry-pick은 특정 커밋만 골라 적용하는 방식⚙️ 기본 사용법git cherry-pick 예: feature/login 브랜치에 있는 커밋을 main 브랜치에 가져오고 싶을 때git checkout maingit cherry-pick 1a2b3c4→ 해당 커밋이 main 브랜치에 새로운 커밋으로 복사됨.🧪 실습 예시 (Windows 환경)명령어는 Git Bash 또는 VS Code 터미널(cmd/powershell/git bash)에서 실행✅ 1. 프로젝트 초기화mkdir cherry-pick-d..

Important ● 전역 설정 파일Nice To Have ● 커스텀 명령어 작성 깃 저장소는 각각의 로컬 설정 파일(config)이 존재하고 한 사용자가 생성한 저장소에 모두 적용되는 전역 설정 파일(.gitconfig)이 존재한다.전역 설정 파일전역 설정 파일도 이전 로컬 설정 파일과 같이 텍스트 에디터에서 직접 추가가 가능하고 CLI 환경에서도 조작이 가능하다. 텍스트 에디터 [alias] 밑으로 별칭 = 명령어를 임의로 설정하여 사용할 수 있다.commit -m "message"와 같이 인자가 있는 경우도 똑같이 명령어 입력에 인자를 입력해주면 된다. 위 .gitconfig 파일에서 별칭으로 등록한 s 명령어에 대해 잘 작동하는 것을 확인할 수 있다. CLIgit config --gl..

dangling commit 어떤 브랜치나 태그 등에서 더 이상 참조되지 않는 커밋을 말한다.쉽게 말하면, Git 저장소 안에는 존재하지만 어디에서도 가리키고 있지 않기 때문에 보이지 않는 커밋이다. 🔍 왜 생기는 걸까? git commit 후, rebase나 reset으로 HEAD를 되돌렸을 때git rebase -i로 커밋을 삭제(drop) 했을 때브랜치를 삭제했는데, 해당 브랜치에만 있던 커밋이 다른 브랜치와 공유되지 않았을 때이런 경우 기존 커밋은 Git 내부에는 아직 존재하지만, HEAD도 브랜치도 더 이상 그 커밋을 가리키지 않게 된다.→ 즉, dangling 상태 🕵️‍♀️ 확인 방법 git fsck --lost-found 이 명령은 Git 저장소 내에서 dangling commit ..

Interactive rebase에서 최초 커밋을 수정할 수 없는가?[Git & Github 실무 활용 완벽 가이드] 인터넷 강의를 듣던 중 Interactive rebase를 실습할 때 저장소의 최초 커밋은 텍스트 에디터에서 확인하지 못하는 것을 확인하였다.git rebase -i 명령은 지정한 커밋의 다음 커밋부터를 대상으로 interactive list를 보여주기 때문이다. HEAD~N 항목 지정을 통해 interactive list에 최초 커밋을 조회할 수 있도록 명령어를 입력했을땐,fatal : invalid upstream 'HEAD~N' 에러가 발생하였다.항목 지정을 하여도 git은 여전히 해당 항목의 이전 커밋을 참조하려고 하기 때문이다. 결국, 최초 커밋은 참조하고 있는 부모 커밋이 없..

Important ● reflog 파일 탐색 ● reflog 명령어 ● 잃어버린 커밋 복구 ● 리베이스 되돌리기Nice To Have ● 시간 기반 reflog 수식자 reflog는 reference log의 약어이다.커밋을 잃어버리거나 rebase를 하지 말아야 할 때 rebase를 하는 등 문제를 되돌리고 싶을 때 사용한다. reflog는 지역적으로 동작한다. 내 컴퓨터의 참조목록에 대한 변경사항만을 저장하고 기록한다.또한 로그가 영구적으로 남지 않고 기본 설정으로는 90일 정도 지나면 삭제된다.git reflogshow, expire, delete, exists 총 4가지의 하위 명령어와 같이 사용하지만 show 말고는 별로 사용되지 않는다.git reflog show ..

해시 함수해시 함수는 입력값의 크기와 무관하게 항상 고정된 길이의 출력값을 생성하는 함수이다.예를 들어 한 글자만 입력해도, 수백 MB짜리 파일을 입력해도 출력값은 항상 일정한 길이이다. Git에서는 이 해시 값을 객체로 식별하는 ID로 사용한다.이 ID는 객체의 "내용"에서 직접 생성되기 때문에, 내용이 바뀌면 ID도 바뀐다.이 원리를 내용 주소 지정(content-addressed storage)이라고 부른다.Git이 사용하는 해시 함수 : SHA-1Git은 오랫동안 SHA-1(Secure Hash Algorithm 1) 해시 함수를 사용해 왔다.출력 길이 : 40자리의 16진수 문자열 (160비트)예시 : f5a1c3e0b1b3f95fa3dfb77deee3a6d1c84e4a59 동일한 입력값에 대해..

Important ● 로컬 설정 파일Nice To Have ● refs 디렉토리 ● HEAD ● 해싱 함수의 기초 ● 깃 오브젝트 로컬 설정 파일 깃 설정은 글로벌과 로컬 두 가지 방식으로 설정 할 수 있다.글로벌로 설정할 경우 모든 깃 repository에 동작하는 설정을 할 수 있으며로컬로 설정할 경우 설정한 해당 repository에서만 적용되는 설정을 적용할 수 있다. 해당 챕터에서는 로컬에서 간단한 설정 조작만 맛 볼 예정이다.로컬 설정은 config 파일을 직접 수정하거나 명령어를 통해서 깃의 설정을 바꿀 수 있다. config 파일 수정 CLI 환경에서 config 수정 refs/이 폴더 안에는 heads, tags 등의 하위 폴더가 있다.heads 폴더는 저장..

Important ● git tag 이해하기 ● 태그 보기 ● 태그 생성 및 푸시Nice To Have ● Semantic versioning ● 태그 비교/삭제/옮기기 깃 태그는 특정 커밋에 추가하는 일종의 라벨이다. 주로 릴리즈 버전을 표시하는 용도로 사용된다.커밋이 추가되면 같이 이동하는 브랜치 참조와 다르게 처음 지정된 커밋을 계속 참조한다. * 태그의 두 종류 *일반 태그(lightweight) : 특정 순간에 이름을 붙인다.주석 태그(annotated) : 태그 메시지, 생성자 이름, 이메일, 날짜 등을 포함한다. 큰 프로젝트에서는 주석 태그를 선호하는 편이다. 시멘틱 버저닝 (Semantic versioning)버전 번호를 매기는 일종의 규칙이다.버전명은 숫자 세..

git push -f (git push --force)로컬 브랜치의 변경 사항을 강제로 원격 저장소에 덮어쓰는 명령어이다.보통은 로컬 브랜치의 커밋 히스토리를 변경(예: rebase, amend) 한 후에 사용된다. ⚠️ 왜 "강제(push -f)"가 필요한가? Git은 기본적으로 push 할 때, 원격 브랜치가 로컬 브랜치의 조상이 아닐 경우 push를 거부한다.(= 히스토리가 "앞으로"만 가야지, "되돌리면" 위험하다고 보기 때문이다.) 하지만 git commit --amend, git rebase, git reset 같은 작업은 커밋 해시를 변경하므로 push 하려면 -f 옵션이 필요하다. 📘 예시: amend 후 push -f 1. 이미 커밋을 pushgit commit -m "Fix bug..