1. 들어가며: "왜 내 코드는 Push가 안 될까?"머신러닝 모델 가중치 파일(200MB), 게임 개발용 에셋 파일(500MB), 혹은 대용량 데이터셋(1GB). 프로젝트를 진행하다 보면 필연적으로 용량이 큰 파일을 다루게 됩니다. 기분 좋게 코딩을 마치고 git push를 날렸는데, 터미널에 아래와 같은 빨간색 에러 메시지가 뜬 적 있으신가요?remote: error: GH001: Large files detected. You may want to try Git Large File Storage.remote: error: File model.bin is 157.92 MB; this exceeds GitHub's file size limit of 100.00 MBGitHub은 성능 유지를 위해 100M..

1. 들어가며현대 소프트웨어 개발에서 "코드를 어떻게 짤 것인가"만큼 중요한 것은 "코드를 어떻게 안전하게 합칠 것인가"입니다. 수많은 개발자가 동시에 같은 프로젝트를 수정할 때, 서로의 작업을 방해하지 않으면서 최상의 코드 품질을 유지하는 방법이 바로 GitHub의 Pull Request(PR) 시스템입니다.PR은 내가 작업한 내용을 팀에게 정식으로 제안하고, 동료들의 검토(Review)를 거쳐 메인 코드베이스에 반영하는 일련의 소통 과정입니다. 이 과정을 제대로 이해하면 협업의 효율성이 극대화되고 디버깅 시간이 획기적으로 줄어듭니다.입문자부터 실무자까지 아우르는 GitHub Pull Request부터 Merge까지의 완벽 가이드를 정리해 보았습니다.2. 개요 및 정의 2-1. Pull Request ..

1. 들어가며개발자 여러 명이 하나의 프로젝트를 동시에 개발할 때, 각자의 코드가 서로 충돌하고 덮어씌워지는 대참사를 막기 위해 우리는 'Git(깃)'이라는 버전 관리 시스템을 사용합니다. 그리고 이 Git을 사용할 때, 메인 코드에서 가지(Branch)를 쳐서 각자 작업한 뒤 다시 합치는 과정을 거치게 됩니다.하지만 자유도가 너무 높은 Git 환경에서 아무런 규칙 없이 각자 마음대로 브랜치를 만들고 합치게 되면 어떻게 될까요? 프로젝트의 릴리스 일정이 꼬이고, 배포 중에 치명적인 버그가 터지는 등 걷잡을 수 없는 혼란에 빠지게 됩니다.그래서 등장한 것이 바로 '브랜치 전략(Branching Strategy)'입니다. 이는 "어떤 브랜치를 만들고, 언제 합치며, 언제 배포할 것인가"에 대한 팀 차원의 약..

1. 들어가며개발자가 코드를 다 짜고 나면 끝일까요? 아닙니다. 코드가 잘 돌아가는지 테스트(Test)해야 하고, 실행 파일로 빌드(Build)해야 하며, 실제 서비스 중인 서버에 올리는 배포(Deploy) 과정을 거쳐야 합니다. 과거에는 이 모든 과정을 개발자가 수동으로 처리해야 했지만, 이 반복적이고 지루한 작업을 자동으로 해주는 마법 같은 시스템이 등장했습니다. 바로 CI/CD(지속적 통합/지속적 배포)입니다.수많은 CI/CD 도구(Jenkins, Travis CI 등) 중에서도 2018년 출시 이후 전 세계 개발자들을 열광시키며 사실상 업계 표준으로 자리 잡은 서비스가 있습니다. 바로 'GitHub Actions(깃허브 액션)'입니다.GitHub Actions는 우리가 코드를 저장하는 GitHub..

1. 들어가며개발을 하다 보면 "우리 회사 사내 시스템에도 GitHub Copilot처럼 알아서 코드를 찾아주고, 깃허브(GitHub) 이슈를 요약해 주는 똑똑한 AI 비서가 있으면 얼마나 좋을까?"라는 생각을 한 번쯤 해보셨을 것입니다. 하지만 이런 '에이전트(Agent)' 시스템을 바닥부터 직접 만드는 것은 결코 쉬운 일이 아닙니다. 대화 맥락(Context)을 유지해야 하고, LLM이 외부 API(도구)를 적절히 호출하도록 라우팅해야 하며, 에러가 났을 때 스스로 복구하는 로직까지 전부 개발해야 하기 때문입니다.이러한 개발자들의 고충을 해결하기 위해 2026년 3월, 마이크로소프트와 깃허브는 엄청난 무기를 공개했습니다. 바로 'GitHub Copilot SDK'입니다. 이 SDK는 단순히 AI에게 ..

1. 들어가며개발 프로젝트를 진행하다 보면 최종.zip, 진짜_최종.zip, 이게_마지막_수정.zip과 같이 파일 이름으로 버전을 관리하다가 낭패를 본 경험이 한 번쯤 있을 것입니다. 여러 명의 개발자가 동시에 같은 파일을 수정하다가 코드가 덮어씌워지거나, 과거의 정상 작동하던 코드로 돌아갈 수 없게 되는 문제는 소프트웨어 개발의 고질적인 골칫거리였습니다.이러한 문제를 해결하기 위해 등장한 것이 바로 버전 관리 시스템(VCS, Version Control System)이며, 그중에서도 2000년대 IT 업계의 표준으로 자리 잡았던 전설적인 도구가 바로 SVN(Subversion)입니다.현재는 분산형 시스템인 Git이 대세가 되었지만, SVN은 특유의 직관성과 강력한 중앙 통제 능력 덕분에 여전히 대기업,..

1. 들어가며AI 모델이든, 웹 백엔드든, 혼자 개발하는 게 아니라면 Git으로 협업하는 건 대부분 아실겁니다.Github에서는 내 코드를 메인 브랜치에 합쳐달라고 "Pull"라고 요청해서 Pull Request (PR)라고 부르죠.GitLab은 용어가 좀 더 직관적입니다. "Merge"라고 요청해서 Merge Request (MR)라고 부릅니다. (본질은 100% 똑같습니다.)MR(PR)은 단순히 "코드 합치기"가 아닙니다."내가 이 작업을 왜 했는지(Issue), 어떻게 고쳤는지(Code Diff), 리뷰해 주세요(Review)"를 공식적으로 요청하는 '협업과 소통의 핵심 도구'입니다.이 포스팅에서 GitLab을 기준으로, Issue 확인부터 MR 생성, Code Review까지의 플로우를 A to ..

1. 들어가며: 브랜치(Branch), 왜 필요할까?Git에서 브랜치(Branch)는 '가지'라는 뜻처럼, 기존의 안정적인 코드(예: main 브랜치)에서 새로운 가지를 뻗어 나가는 것입니다.안정성: 신기능 개발이나 버그 수정을 할 때, main 브랜치를 직접 건드리지 않고 **'독립된 작업 공간'**을 만들어 안전하게 테스트할 수 있습니다.동시 작업: A는 로그인 기능을, B는 결제 기능을 각자의 브랜치에서 동시에 작업한 뒤, 나중에 합칠(Merge) 수 있습니다.main (또는 master) 브랜치는 항상 '언제든 배포 가능한 깨끗한 상태'로 유지하는 것이 핵심입니다!2. 브랜치 기본 명령어 (생성, 목록, 이동)2-1. 브랜치 목록 확인: git branch현재 내 로컬 저장소에 있는 브랜치 목록을..

1. 들어가며: 원격 저장소(Remote)란?Git은 로컬(내 PC)에서 버전을 관리하지만, 코드를 백업하거나 다른 사람과 협업하려면 원격 저장소(Remote)가 필요합니다. GitHub, GitLab 등이 대표적이죠.내 로컬 저장소를 원격 저장소와 연결해 코드를 push(업로드)하거나 pull(다운로드)할 수 있습니다.origin: 보통 '내' 원격 저장소를 가리키는 기본 별명입니다.upstream: 보통 내가 Fork(복제)해 온 '원본' 프로젝트의 저장소를 가리킬 때 씁니다.2. 현재 연결된 원격 저장소 확인: git remote -v현재 내 로컬 저장소에 연결된 원격 저장소의 목록과 주소(URL)를 확인합니다. -v는 'verbose'의 약자로, 주소까지 자세히 보여줍니다.git remote -v..

들어가며Git을 사용하다 보면 “이 커밋이 내 계정으로 올라간 게 맞나?” 하는 순간이 옵니다.특히 회사용 계정과 개인용 계정을 함께 쓸 때, 로컬 Git 설정을 정확히 알아두는 게 중요합니다.이번 글은 Git 계정(이름&이메일) 확인 및 변경 방법을 정리했습니다.1. Git 계정 이름 확인하기현재 Git에 어떤 이름이 등록되어 있는지 확인하려면 다음 명령어를 입력합니다:git config user.name출력값: 현재 저장소에 설정된 사용자 이름--global 옵션을 붙이면 전체 시스템(전역)에 설정된 값 확인2. Git 계정 이메일 확인하기git config user.email이메일 역시 같은 원리로 작동합니다.전역 설정을 보려면 git config --global user.email을 사용합니다. ..