Growth Diary

[PR] 실전 Fork & PR

전에 Fork와 PR을 간단하게 코드로 설명하면서 진행했던 글이 있는데, 이번에는 조금 더 심화적으로 협업중 발생한 문제를 해결하면서 PR을 진행하는 과정에 대해 설명하도록 하겠습니다. 현재 장기간 Merge & PR을 하지않아, 원본 레파지토리의 히스토리가 쌓이고 Fork한 원격 레파지토리에서 새롭게 브랜치를 생성해서 커밋이 쌓인 상황입니다. 따라서 히스토리 충돌이 발생하지 않도록, 원본 레파지토리의 코드를 잘 가져와서 병합 후 PR을 요청하는 과정을 다뤄보도록 하겠습니다. 원본 레파지토리의 최신 코드를 가져오기 위해 "git fetch upstream" 명령어를 실행했는데 아래의 에러가 발생하였습니다. 확인해보니 upstream이라는 이름의 원격 저장소가 등록이 되지 않아 발생한 에러였습니다. "g..

간단한 프로젝트나 제가 지금까지 진행한 프로젝트에서는 Github에서 프로젝트를 관리할때 각자 기능별 브랜치를 만들고 메인 브랜치에 반영하고 싶으면 로컬에서 commit, merge 를 통해 검증이 되면 그 main 브랜치를 원격 레파지토리에 push해서 병합하는 구조를 사용했었습니다. 그런데 이번에 새로운 프로젝트를 진행하면서 Fork + Pull Request 조합으로 프로젝트를 관리하게 돼서 이 과정에 대해 알아보려고합니다. 1. Fork란 무엇인가?Fork는 다른 사용자의 GitHub 저장소(Repository)를 내 계정으로 복제하는 기능입니다. 이는 단순한 복사본이 아니라 원본 저장소와의 연결을 유지하면서 독립적으로 작업할 수 있는 공간을 만들어줍니다. Fork의 주요 목적오픈소스 프로젝트 기..

이전에 GitHub와 티스토리 블로그를 연동해서 잔디 심기를 만들어보았고 연동이 잘 된 것을 확인했습니다. 그런데 그 이후 제가 따로 생성한 레포지토리에서 push한 내용이 잔디가 심어지지 않는 현상을 발견했습니다. 오늘은 제가 최근에 겪었던 GitHub 잔디 심기 문제와 그 해결 과정을 공유하려고 합니다.1. 문제 상황저는 여러 개의 GitHub 레포지토리에서 작업을 하고 있었습니다. 그런데 이상한 점을 발견했습니다.레포지토리 A: 코드를 push했더니 GitHub 프로필에 잔디가 잘 심어짐레포지토리 B: 코드를 push했는데 GitHub 프로필에 잔디가 심어지지 않음처음에는 레포지토리 설정 문제인가 싶었지만, 둘 다 제가 직접 만든 public 레포지토리였기 때문에 설정 차이는 없었습니다. 2. 원인..

티스토리 블로그에 글을 작성하면 깃허브 계정에서 자동으로 잔디가 심어지도록 설정해보도록 하겠습니다. 그러기 위해 Github Action을 이용하여 하루에 한번 티스토리의 RSS를 기반으로 Github에 커밋이 되도록 하겠습니다. 1. 티스토리 RSS 설정먼저 티스토리 블로그에서 RSS 를 설정해줍니다. 내 블로그 설정 -> 관리 -> 블로그 -> 기타 설정에 위치한 RSS를 "전체 공개"로 설정 후 저장해줍니다. "https://striver.tistory.com/rss" 와 같이 자신의 블로그 주소에 접속하면 RSS 정보가 확인 가능합니다.  2. Repository 생성Github Action으로 연동할 새로운 repository를 생성합니다.  3. 로컬 환경과 Repository 연동자신이 편한..

1. Branch 개념 2. Clone 및 Merge 과정 3. reset, revert 사용 4. git name, email 변경 오늘은 원격 저장소의 모든 내용을 Clone을 통해 가져와 특정 Branch의 내용을 수정하고 Merge하는 과정에 대해 말씀드리겠습니다. 1. Branch 개념 일련의 과정들을 말하기에 앞서 Branch란 무엇인지, 왜 사용해야 하는지 간단하게 말씀드리고 넘어가도록 하겠습니다. Branch란 "동일한 소스 코드에서 파생된 독립적인 개발 라인" 이라고 말할 수 있습니다. 여기서 중요한 포인트는 "독립적인" 이라는 키워드입니다. 보통 프로젝트를 진행하게 되면 여러 명이 함께 작업을 진행하게 되는데, 이때 각 개발자는 자신이 생성한 브랜치에서 작업을 수행하고, 이후 변경 사항..

이번시간에는 git 명령어에 대해서 알아보도록 하겠습니다. 깃 명령어를 알아야 하는 이유 1. 빠르고 편리하다 GUI 방식인 Sourcetree로 버전을 관리하는 방법을 알았는데 굳이 명령어까지 알아야하는건가요? Sourcetree가 더 직관적이고 편리하니까 깃 명령어보다 많이 쓰지 않나요? 라고 생각할 수 있습니다. 물론 깃 명령어보다 Sourcetree를 선호하는 사람들도 있을것입니다. 하지만 대다수의 개발자는 깃 명령어를 사용할 것 입니다. 왜냐하면 깃 명령어를 사용하는것이 훨씬 더 빠르고 편리하기 때문입니다. 깃 명령어를 익혀두면 일일이 소스트리를 열고 마우스로 버튼을 클릭해서 버전을 관리하는것이 아니라 명령어 한두줄로 간단하게 버전을 관리할 수 있기때문에 훨씬 더 간편합니다. 2. 제한된 개발 ..

Git은 버전 관리를 도와주는 소프트웨어로, 버전 관리 시스템(Version Control System, VCS)입니다. 우리는 깃을 이용해 버전을 만들고 되돌리며, 다른 개발자들과 협업 할 수도 있습니다. 깃은 리눅스의 아버지 리누스 토르발스가 전 세계 수많은 개발자와 함계 오픈 소스 프로젝트(리눅스 커널)를 진행하다가 버전 관리에 어려움을 느껴 만든 도구입니다. 깃 또한 오픈 소스 프로젝트로, 모든 소스 코드가 공개되어 있습니다. GitHub는 원격 저장소 호스팅 서비스를 말합니다. 간단히 말하면 깃으로 버전을 관리하는 프로젝트들이 모여 있는 웹 사이트 라고도 말할 수 있습니다. 우리는 우리가 만든 프로젝트들을 깃을 통해 깃허브에 업로드 할 수 도 있고, 깃허브에 업로드한 프로젝트에 새로운 버전을 추..