쵸코쿠키의 연습장

요즘 GitHub가 불안정하다는 말이 많은데, 진짜 문제는 사이트가 잠깐 느린 것이 아니라 PR 병합 정확도와 검색 흐름이 함께 흔들리면 팀의 하루가 통째로 날아간다는 점입니다. 의외로 더 중요한 건 공식 업타임 숫자가 아니라, 우리 팀에서 어느 고리부터 배포와 리뷰가 멈추는가입니다.GitHub는 저장소 호스팅 하나로 끝나는 서비스가 아닙니다. 코드 저장, 리뷰, CI/CD, 이슈 추적, 검색, 협업 기록이 한데 묶인 작업 기반에 가깝습니다. 그래서 여기서 생기는 문제는 "사이트가 조금 불안정하네"가 아니라 "오늘 배포와 검토가 실제로 밀린다"로 번집니다.2026년 4월 말에 터진 사건들은 그 차이를 아주 또렷하게 보여줬습니다. 이번 글은 최근 GitHub 이슈를 요약하는 데서 멈추지 않고, 이 상황에서..

금요일 오후, 손이 살짝 떨리는 상태로 Merge 버튼을 눌렀다가… 몇 분 뒤 슬랙 알림이 폭주하기 시작한 경험, 혹시 있으신가요? 저는 아직도 그 순간이 생생합니다. 사무실에 잔잔하게 깔리던 키보드 소리, 모니터에서 뿜어져 나오던 흰빛, 그리고 머릿속을 스치는 생각 하나.“아, 이건 뭔가 잘못됐다.”이런 순간이 반복된다면, 문제는 개인이 아니라 Git workflow에 있을 확률이 큽니다. 이 글에서는 Gitflow, GitHub Flow, Trunk-Based Development(TBD)가 왜 등장했고, 어떻게 진화했으며, 어떤 상황에서 각각이 빛을 발하는지 아주 현실적인 관점에서 풀어보려고 합니다. 교과서 말고요. 실제 현장에서 겪는 이야기로요.이 글을 다 읽고 하나만 기억한다면, 이 문장이면 충..

깃허브 정상화 이후: 개발자들이 탈주하는 진짜 이유와 대안의 물결최근 몇 년 사이, 개발자 커뮤니티의 심장부였던 깃허브(github)에서 느껴지는 미묘한 균열을 감지하고 계십니까? 한때 모든 코드가 모여드는 거대한 디지털 대성당(Cathedral) 같았던 이 공간이, 알 수 없는 이유로 '정상화'라는 이름 아래 개발자들의 등을 돌리게 만드는 역설적인 상황에 직면해 있습니다. 우리는 겉으로 보이는 변화가 아닌, 그 깊은 곳에서 일어나는 협업의 본질에 대한 불신이 이 거대한 흐름을 만들고 있음을 이해해야 합니다.우리는 이 사태를 에릭 레이몬드(Eric S. Raymond)가 제시한 '성당과 시장(The Cathedral and the Bazaar)' 모델의 관점에서 조망해 볼 필요가 있습니다. 깃허브는 그 ..

컴퓨터와 대화하는 두 가지 방식: CLI vs GUI (Git 실전, 2025)한 줄 요약(모니터에 붙여두기): Doing은 CLI, Seeing은 GUI. 이 한 문장만 기억해도 길을 잃지 않습니다.우리가 컴퓨터를 다루는 방법은 크게 둘입니다. 키보드로 명령을 쓰는 CLI(Command Line Interface), 그리고 아이콘과 버튼을 클릭하는 GUI(Graphical User Interface). 둘 다 옳고, 둘 다 강력합니다. 다만 말투가 다를 뿐이죠.작은 심호흡. terminal을 열고, 커서가 깜박이는 걸 봅니다. 이제 시작해볼까요? ELI5로 1분 요약: CLI vs GUICLI: 컴퓨터와 텍스트로 대화합니다. 명령을 치면 결과가 텍스트로 돌아오죠. 아주 솔직한 친구에게 카톡 보내는 ..

소프트웨어 개발의 세계에서 품질 관리는 프로젝트의 성공에 있어 중추적인 역할을 합니다. 이러한 품질 관리의 핵심 요소 중 하나가 바로 단위 테스트입니다. 단위 테스트는 작은 코드 조각이 예상대로 작동하는지 확인함으로써, 전체 애플리케이션의 신뢰성을 보장합니다. 그러나 단위 테스트를 수동으로 실행하는 것은 시간이 많이 소요되며, 오류의 여지를 남겨둡니다. 이러한 문제를 해결하기 위해, 많은 개발자들이 GitHub Actions 같은 CI/CD 도구를 활용하여 자동화된 테스트 및 배포 파이프라인을 구축하고 있습니다. 이 글에서는 GitHub Actions를 사용하여 단위 테스트를 자동화하는 방법을 단계별로 안내합니다. GitHub Actions는 개발자가 코드 변경 사항을 자동으로 검증하고, 실패한 테스트를..

이 가이드를 통해 깃과 깃허브의 세계로 들어가 보세요! 저장소 및 분기를 설정하고 변경사항을 커밋하고 푸시하는 방법을 10가지 간단한 단계로 학습합니다. Git와 GitHub는 소프트웨어 프로젝트에서 협업하고, 변경 사항을 추적하고, 버전 제어를 관리하고자 하는 개발자들에게 필수적인 도구가 되었습니다. 깃허브는 깃 저장소를 위한 웹 기반 호스팅 서비스인 반면 깃은 분산 버전 제어 시스템입니다. 이 기사에서는 Git 및 GitHub 사용을 시작하기 위한 10가지 쉬운 단계를 살펴보겠습니다. 1. Git 설치 Git 사용을 시작하려면 컴퓨터에 Git를 설치해야 합니다. 공식 웹사이트에서 Git를 다운로드하고 설치 지침을 따를 수 있습니다. 2. Git 설정 Git 설치 후 이름과 이메일 주소로 Git를 구성..

때때로 Git으로 작업할 때 최신 커밋을 실행 취소해야 할 수도 있습니다. 커밋은 지정된 시간에 Git 저장소의 스냅샷입니다. Git에는 현재 작업 분기의 최신 커밋을 가리키는 HEAD라는 참조 변수가 있습니다. 커밋을 실행 취소하려면 HEAD 변수를 이전 스냅샷을 가리키기만 하면 됩니다. 이 가이드에서는 마지막 Git 커밋을 실행 취소하는 방법을 설명합니다. 커밋이 이미 공유 리포지토리로 푸시된 경우 실행 취소하지 않는 것이 좋습니다. 커밋 메시지만 변경하려면 이 문서를 확인하십시오. Git Three-Tree 아키텍처 Git에서 git reset 명령과 커밋 식별자를 차례로 사용하여 변경 사항을 실행 취소할 수 있습니다. git reset은 명령 동작을 제어할 수 있는 추가 인수를 사용합니다. 재설정..

Git은 오늘날 대부분의 소프트웨어 팀에서 사용하고 있는 분산 버전 제어 시스템입니다. 시스템에 Git을 설치한 후 가장 먼저 해야 할 일은 Git 사용자 이름과 이메일 주소를 설정하는 것입니다. Git은 당신의 정체성을 당신이 하는 모든 약속과 연관시킵니다. Git을 사용하면 글로벌 및 프로젝트별 사용자 이름과 전자 메일 주소를 설정할 수 있습니다. git config 명령을 사용하여 git ID를 설정하거나 변경할 수 있습니다. 변경 사항은 향후 커밋에만 영향을 미칩니다. 변경 전 커밋과 관련된 이름 및 이메일은 영향을 받지 않습니다. 글로벌 Git 사용자 이름 및 암호를 설정 글로벌 git 사용자 이름 및 암호는 리포지토리별 값이 없는 시스템의 모든 리포지토리의 커밋과 연결됩니다. 글로벌 커밋 이름..

이 가이드에서는 Git 리모컨을 제거하는 방법을 설명합니다. Git remote는 일반적으로 원격 서버에서 호스팅되는 리포지토리의 다른 복사본을 참조하는 포인터입니다. 일반적으로 Git으로 작업할 때 서로 다른 기능과 환경에 대해 하나의 원격 명명 오리진 및 다른 분기가 있을 수 있습니다. 오리진은 저장소를 복제할 때 자동으로 생성된 원격 이름으로 복제된 저장소를 가리킵니다. 하지만, 한 프로젝트에 한 그룹의 사람들과 협력할 때, 여러 Git를 사용하는 것이 매우 편리하다는 것을 발견할 수 있습니다. 원격 저장소는 GitHub, GitLab, BitBucket과 같은 Git 호스팅 서비스나 개인 Git 서버에서 호스팅할 수 있습니다. 원격 리포지토리가 다른 호스트로 마이그레이션되었거나 기여자가 기여를 중..

Git remote는 일반적으로 원격 서버에서 호스팅되는 리포지토리의 다른 복사본을 참조하는 포인터입니다. 원격 저장소를 다른 호스트로 마이그레이션하는 경우와 같은 경우에 원격 URL을 변경해야 합니다. 이 가이드에서는 Git 리모컨의 URL을 변경하는 방법을 설명합니다. Git Remote의 URL을 변경 각 Git 리포지토리에는 0개 이상의 Git 원격이 연결될 수 있습니다. 저장소를 복제하면 원격 이름이 자동으로 오리진으로 설정되고 복제한 저장소를 가리킵니다. 로컬에서 저장소를 만든 경우 새 원격 을 추가할 수 있습니다. 원격은 GitHub, GitLab, BitBucket과 같은 Git 호스팅 서비스 또는 개인 Git 서버에 호스팅된 저장소를 가리킬 수 있습니다. 리모컨의 URL을 변경하려면 다음..

Git을 사용하는 프로젝트에서 작업할 때 특정 파일 또는 디렉터리를 원격 리포지토리에 푸시하지 못하도록 제외하는 경우가 많습니다. 여기서 .gitignore 파일이 유용합니다. .gitignore 파일은 추적되지 않은 파일 Git가 무시해야 하는 파일을 지정합니다. 무시해야 할 파일 무시되는 파일은 일반적으로 플랫폼별 파일이거나 빌드 시스템에서 자동으로 생성된 파일입니다. 몇 가지 일반적인 예는 다음과 같습니다. - 로그, 잠금, 캐시 또는 임시 파일과 같은 런타임 파일입니다. - 암호 또는 API 키와 같은 중요한 정보가 있는 파일입니다. - .class 또는 .o와 같은 컴파일된 코드입니다. - /vendor 또는 /node_modules 와 같은 종속성 디렉토리입니다. - /public, /out ..

강력한 테스트 제품군이 있는 프로젝트에서 작업할 때 리포지토리에 푸시하는 모든 작업이 프로젝트의 테스트에 영향을 미치지 않도록 해야 합니다. 즉, git push를 미리 만들기 전에 phpunit을 실행하고 모든 테스트를 통과했는지 확인해야 합니다. 이 튜토리얼에서는 git 리포지토리에 규칙을 추가하여 테스트가 통과되지 않으면 리포지토리에 새 코드를 넣을 수 없도록 하고 이를 위해 git 후크를 사용합니다. Git Hooks Git 후크를 사용하면 git 프로세스의 여러 단계에서 이벤트를 실행할 수 있습니다. 이러한 이벤트에서 명령이 실패할 경우 프로세스를 종료할 명령을 실행할 수 있습니다. 이것들은 사용할 수 있는 git 훅입니다. applypatch-msg commit-msg post-update p..

이 튜토리얼에서는 스테이징 또는 프로덕션 환경에 코드를 배포하는 가장 쉬운 방법에 대해 알아봅니다. 과거에는 FileZilla와 같은 FTP 클라이언트를 사용하는 것이 일반적이었지만, SCP, rsync 또는 배포 도구와 같은 코드를 보다 신뢰할 수 있는 방법으로 배포했기 때문에 이 클라이언트를 사용하는 것이 일반적입니다. 코드를 배포하는 데 도움이 되는 가장 일반적인 도구로는 Anable, Capistrano, Beanstalk, Deploy가 있습니다. 하지만 Git 후크를 사용하여 코드를 배포할 수 있습니다. 즉, Git 푸시만 하면 코드를 배포할 수 있습니다. git push production master 이 포스팅의 목표는 위의 명령을 사용하여 마스터의 코드를 프로덕션 서버에 배포입니다. 필수..

이전에 Github 작업을 사용하여 마스터로 병합할 때, 응용 프로그램에 대한 PHPUnit 테스트 방법에 대해 조사해보았습니다. 테스트가 성공하면 다음 단계는 도커 이미지를 작성하여 리포지토리에 푸시하는 것입니다. 이렇게 하려면 새 워크플로 파일을 생성해야 합니다. 이 파일은 테스트가 성공한 후 실행되어 도커 이미지를 저장소로 푸시해야 합니다. 먼저 워크플로 폴더 .github/workflows/docker.yml에 새 파일을 만들고 해당 파일에 다음 파일을 붙여넣습니다. name: Docker on: push: branches: [ master ] jobs: build: runs-on: ubuntu-latest steps: - name: 'Checkout GitHub Action' uses: acti..

이 튜토리얼에서는 GIT 저장소의 URL을 변경하여 코드를 새 서버 또는 호스트로 이동하는 방법에 대해 알아봅니다. 이 작업에 대해 수행할 수 있는 여러 가지 방법이 있습니다. 원본 URL을 변경하고 모든 항목을 새 리포지토리에 커밋하면 새 서버에서 처음부터 시작할 수 있습니다. 그러나 프로젝트에서 이전 분기와 태그를 모두 잃게 됩니다. 문제가 없는 경우 오리진 URL을 변경해도 괜찮습니다. 대부분 이전 분기를 모두 사용하고 이 튜토리얼을 사용하면 도움이 됩니다. 리포지토리 원본을 변경 먼저 리포지토리의 오리진 URL을 간단히 변경할 수 있는 방법에 대해 설명하겠습니다. GIT가 설정된 프로젝트의 루트에서는 다음 명령만 실행하면 됩니다. git remote set-url origin git://{NEW_..

Jetbrains Webstorm에서 프로젝트를 만들려고 할 때 .idea라는 폴더가 생성됩니다. 이것을 삭제해도 괜찮을까요? 내 프로젝트에 영향을 줄까요? 최근 git push를 했는 데, 함께 포함되어 푸시를 해서 찾아보게 되었습니다. Intellij IDE를 사용하면 프로젝트의 모든 프로젝트 특정 설정이 .idea 폴더에 저장됩니다. 프로젝트 설정은 각 특정 프로젝트와 함께 .idea 폴더 아래에 xml 파일 세트로 저장됩니다. 기본 프로젝트 설정을 지정하면 새로 만든 각 프로젝트에이 설정이 자동으로 사용됩니다. IDE 설정에 대해서는 제트 브레인 문서를 확인해보세요. 여기는 소스 제어에 대한 권장 사항과 .gitignore 파일 예제에 대한 내용들이 포함되어 있습니다. git 또는 일부 버전 제어..

git cherry-pick은 임의의 Git 커밋을 참조로 선택하고 현재 작동하는 HEAD에 추가 할 수 있는 강력한 명령입니다. cherry pick은 지점에서 커밋을 선택하여 다른 커밋에 적용하는 행위입니다. git cherry-pick은 변경 사항을 취소하는 데 유용할 수 있습니다. 예를 들어, 실수로 잘못된 분기에 커밋이 있다고 가정하십시오. 올바른 브랜치로 전환하고 커밋이 속한 곳으로 커밋을 선택할 수 있습니다. git cherry pick을 사용하는 경우git cherry-pick은 유용한 도구이지만 항상 모범 사례는 아닙니다. cherry pick은 중복 커밋과 체리 피킹이 작동하는 많은 시나리오를 유발할 수 있으며 대신 전통적인 병합이 선호됩니다. git cherry-pick은 몇 가지 시..

Git은 분산 버전 제어 시스템으로 설계되었습니다. git format-patch 기능을 사용하여 중앙 집중식 Git 저장소가 없어도 실제로 검토 할 수있는 patch를 보낼 수 있습니다. 이것은 원격 Git 리포지토리가 다운되었을 때 매우 유용합니다. patch 준비변경 사항을 보낼 준비가되면 git format-patch [BASE_BRANCH_NAME]을 사용하십시오. $ git format-patch master0001-Update-build-matrix.patch0002-Display-current-gemfile-when-run-bundle-update.patch 내 feature branch는 마스터보다 두 개 앞에 있는 커밋이므로 Git은 각 커밋마다 하나씩 두 개의 파일을 만듭니다. 파일을..

저장소를 깔끔하게 유지하는 것을 좋아하는 개발자 유형이신가요? 인터랙티브 리베이스의 팬이며 커밋이 제대로 될 때까지 커밋을 수정하고 있습니까? pull request을 완료 할 때 –no-ff 병합에 대한 대안을 원하십니까? PR 분기 프로세스에 새 항목이 추가되어 topic 분기 변경 사항을 squash merge 할 수 있어 대상 분기 히스토리가 크게 단순화되었습니다. squash merge이란 무엇입니까?squash merge은 Git에서 하나의 부모와 병합 커밋을 생성하는 병합 옵션입니다. 파일은 일반 병합과 동일하게 병합되지만 커밋 메타 데이터는 상위 커밋 중 하나만 표시하도록 변경됩니다. 결과는 대상 분기에서 단일 병합으로 일반 병합의 모든 변경 사항이 적용됩니다. 왜 squash merge을..

pull request이란 무엇입니까? pull request는 공개 개발 프로젝트에 기여하는 방법입니다. Git과 같은 분산 버전 제어 시스템 (DVCS)을 사용하여 프로젝트에 컨트리뷰션을 제출하는 것이 선호되는 방법입니다. pull request은 개발자가 프로젝트의 기본 저장소에 포함되도록 외부 저장소에 커밋된 변경 사항을 요청할 때 발생합니다. “pull request”은 워크 플로 방법이며 버전 제어 시스템 자체의 기능이 아닙니다. 이 문서는 Git 버전 제어 시스템과 GitHub 호스팅 사이트를 예로 들어, 풀 요청에 대한 간단한 개요와 요청 작성 방법을 알아보겠습니다. 변경DVCS를 사용하여 오픈 소스 프로젝트에 기여할 때는 로컬 개발 환경에 소스 코드 저장소의 사본 또는 "clone"이 있..