IT 엘도라도

1. GitHub Contribution (feat. GitHub 잔디) Git과 GitHub을 사용해본 개발자라면 분명 Git 저장소 생성 혹은 커밋 등의 기록이 GitHub Contribution이라는 형태로 GitHub에 기록되는 것을 본 적 있을 것이다. Contribution 개수에 따라 진한 정도가 조금씩 다르긴 하지만, 전반적으로 녹색으로 표시되기 때문에 흔히들 GitHub 잔디라고 부르곤 한다. 그리고 채용 시장에서는 GitHub 잔디가 무성할수록 성실하게 개발 공부에 임한 사람, 드문드문할수록 개발 공부에 게을렀던 사람으로 평가되기도 하는 것 같다(개인적으로 필자는 조금 다르게 생각하지만). 그런데 GitHub 잔디를 열심히 심고 싶은 사람들은 주의해야 할 점이 하나 있다. 바로 GitH..

실서버 브랜치가 아닌 테스트 서버에서 충돌이 발생하는 경우에 대한 이슈. 1. 문제 상황 내가 브랜치 A에서, 다른 사람이 브랜치 B에서 작업하는데 둘 다 같은 부분인 X를 건드렸다고 해보자. 이 상황에서 브랜치 B가 먼저 테스트 서버 브랜치에 병합이 되었다면, 나중에 브랜치 A를 테스트 서버에 병합하려 할 때 충돌이 발생한다. 왜 그럴까? 브랜치 A와 테스트 서버 브랜치를 병합하는 것이므로 그 두 개의 브랜치만 놓고 생각해 보자. 브랜치 A와 테스트 서버 브랜치는 둘 다 X를 건드렸기 때문에 충돌이 발생하는 것이다. 테스트 서버 브랜치는 X를 건드리지 않고 가만히 있지 않았느냐고 물을 수 있다. 하지만 테스트 서버 브랜치에는 브랜치 B가 병합되어 있는 상태고, 이는 마치 테스트 서버 브랜치에서 누군가 ..

실수로 실서버에 적용한 내용을 되돌리기 위해 Revert 작업을 수행하던 과정에서 겪었던 혼란. 1. 문제 상황 실서버 브랜치에서 갈라져 나온 A 브랜치에서 작업을 했다고 가정하자. 이때 A 브랜치에서 작업이 완료되었는데 실수로 테스트 서버 브랜치가 아닌 실서버 브랜치로 병합을 시켰다고 해보자. 그러면 우선 실서버 브랜치에서 Revert 브랜치를 만들어서 실서버 브랜치로 그걸 다시 병합시켜야 한다. 그래야 실서버에 적용된 A 브랜치의 작업 내역이 그대로 원상 복구될 것이다. 하지만 이렇게 한다고 해서 끝이 아니다. 이후 QA(Quality Assurance) 등의 과정을 통해 추가 개발 요구 사항을 전달받을 수도 있는데, 기존의 A 브랜치에서 추가 작업을 하고 실서버 브랜치에 병합을 시키면 충돌이 발생하..

장고 마이그레이션에 대한 개념이 아직 확립되지 않았던 입사 초창기에 범했던 실수. 1. 문제 상황 개발하던 도중 마이그레이션 파일이 약간 꼬이는 일이 생겨서 무서운 마음에 원격 실서버 브랜치에 있는 모든 마이그레이션 파일들을 복붙 하여 로컬로 가져왔었다. 그러나 실서버 코드를 pull 해오지는 않았다. 즉 실서버에 반영된 마이그레이션 파일은 가져왔지만 로컬의 models.py는 그대로인 것이다. 이 상태에서 실수로 makemigrations 명령을 수행했는데, 그 결과 최신 마이그레이션 파일에 의해 추가하려던 어떤 한 필드(A라고 하자)가 models.py에 정의되어 있지 않았기 때문에 필드 A를 역으로 지워버리는 마이그레이션 파일이 만들어진 것이다. 상황은 여기서 더 심각해진다. 저 상태에서 내 로컬 ..

0. 참고 도식 ▲ Commit 파일, Tree 파일, Blob 파일, Index 파일, Working Directory 파일의 관계 도식 (※ 퍼가실 땐 출처 밝혀주세요!) 1. GIT 내부 동작 원리 이해를 위한 용어 정리 1-1. 로컬 vs 인덱스 vs 저장소 이름 실제 위치 설명 로컬 (Local) = Working Directory = Working Copy 프로젝트 폴더 현재 프로젝트 폴더에 존재하는 파일들 그 자체를 의미한다. 인덱스 (Index) = Staging Area = Cache 프로젝트 폴더 하위 .git/index 파일 개념적으로는 커밋이 이뤄질 준비가 된 파일의 내용들이 위치하는 영역을 의미하며, 실제로는 하나의 파일(.git/index)로서 존재한다. 로컬에 변동 사항이 생겼..