2025 OSSCA 체험형 Next.js 1주차 요일별 회고록

감사하게도 2025 OSSCA 체험형 Next.js 과정에 6주간 참여하게 됐다.

기왕 선정된 거, 열심히 해야지예.

아래는 날짜별로 있던 일을 기록해놓은 회고록이다.

0419

이 날은 레포에 자기소개를 올렸다. 팀원분들이 나보다 깃허브를 잘 사용하시는 것 같지만, 정리차원에서 글을 정리해 공유드리고 첫 PR을 보냈다.

진짜 거짓말 안치고 그냥 push 할 때마다 심장이 떨어져나가는 줄 알았다 혼자할 때는 그냥 main 브랜치만 사용했는데, 여러 사람과 동시에 작업하니까 모든게 떨렸다 ㅋㅋㅋ

아래는 정리글이다.

📌 정리

1. 원격 저장소에서 변경된 내용을 로컬로 갖고 오고 수동으로 병합하고 싶다면

→ git fetch origin 후 git merge origin/[브랜치명]

git fetch origin 뒤에 아무런 브랜치명도 안 적는다면 원격 저장소의 모든 브랜치에 있는 변경사항을 다 갖고옴.

2. 원격 저장소의 변경사항을 로컬에 갖고 오고 로컬 브랜치에 병합까지 자동으로 하고 싶다면

→ git pull origin [브랜치명]

pull 명령어 안에는 git fetch + git merge origin/[브랜치명] 과정이 다 포함되어 있음.

📌 과정

Collaborator로 repo에 초대되었을 경우
1. 클론하고 싶은 로컬 디렉토리로 이동 후 클론 → git clone [레포 주소]
2. 팀 작업을 위한 브랜치 생성
  → git checkout -b [생성하고 싶은 브랜치명] 또는 git branch [생성하고 싶은 브랜치명]
  - git branch [브랜치명]은 only 브랜치명만 생성. 반면 새 브랜치를 생성하고 바로 거기로 이동하고 싶다면 git checkout -b [브랜치명].
  - team-5/00처럼 팀원 각자별로 브랜치를 나누는 방식도 고려했으나, 일단은 team-5만 생성 후 main으로 PR을 보내는 방식을 채택.
  - 추후 깃허브 사용이 익숙해지면 팀원별로 team-5/00와 같이 개인 브랜치를 만든 다음 team-5로 PR을 생성하고, 조장이 확인하면 team-5에서 다시 main으로 PR을 생성하는게 나을 것 같음.
  - 브랜치 변경은 git switch [브랜치명]. (옛날엔 git checkout [브랜치명])
3. 작업 후 커밋 & 푸시
  - git add .
  - git commit -m "docs: 5조_000 자기소개" (커밋 컨벤션은 type: 설명 형태 유지)
  - git push origin [현재 브랜치명]
4. PR 전에 main 브랜치에 변경사항이 있다면 (team-5 브랜치에서 작업 중일 경우)
  - git fetch origin
  - git merge origin/main
  - 또는 git pull origin main
  - 병합 완료 후엔 다시 → git push origin team-5
만약 Collaborator가 아니었다면
- Fork 후 → 개인 저장소에서 작업 → 원본 저장소에 PR 요청

참고

왜 merge 할 땐 /를 붙이고, pull할 땐 안 붙여도 될까?
- merge를 할 땐 먼저 fetch를 하고 병합을 해야되는데, fetch가 로컬 저장소에서 이뤄졌으니 마지막으로 fetch했을 때의 원격 저장소 상태인 git merge origin/main을 갖고와야함.
- 반면 pull은 실제 원격 저장소에서 직접 데이터를 갖고오기 때문에 슬래시가 필요 없는 것.
- 참고로 origin이란,
- 내가 처음에 깃헙에서 클론해온 원격 저장소의 기본 이름을 의미함. 마치 주소 단축키(?) 처럼.

0422

PR 템플릿

초기에는

아래와 같은 형식으로 .github/pull_request_template.md 파일을 생성했다.

## 📌 주제
> 오늘 배운 내용을 한 줄로 표현해주세요.
## 📌 요약
> 오늘 어떤 내용을 학습했는지 간략하게 정리해주세요.
## 📁 관련 파일
- `til/USERNAME/날짜.md`

그러나

어떤 분께서 관련 파일 부분은 커밋 기록에도 나오는데 왜 적은건지 여쭤보셨다. 마냥 깔끔해보일 것(?) 같아서 추가해놨는데,

생각해보니 각자 폴더별로 til을 공유하는게 아니라 한 til 파일 안에서 다같이 내용을 공유하고 있기도 하고, 말씀해주신대로 커밋 기록에도 나오니 불필요할 것 같아 이 부분은 삭제했다.

나중에(?) 자동화가 다 끝나면 메인에 병합해야겠다. ~~=> 멘토님께서 어사인해주셔서 추가했당~~

TIL 파일 자동 생성

순서도

한국 시간 기준 매일 자정
1. main 브랜치의 til 폴더 안에 해당 날짜의 파일이 없다면
2. %m%d 형식의 md파일을 til 폴더 안에 추가 후
3. main 브랜치에 push한다.

코드리뷰를 통해 새롭게 알게 된 사실

github actions checkout 버전 업데이트
- v4가 있는 줄 모르고 v3을 사용했다.
- v4는 node.js 20을 사용해서 워크플로 실행 속도가 더 빨라졌다고 한다.
vscode상에서 md 파일을 볼 때
- 라인에 커서를 올리면 인용문 처럼 보인다.

브랜치 고민

깃허브 브랜치 하나당 용량은 40byte로 그렇게 크지 않다. 참고
하지만 브랜치 개수가 수백, 수천개 정도로 너무 많다면 청소가 필요하다. => 보기 불편하니께.
현재 여기선 TIL만 공유하고 있으니까 브랜치를 생성하는 방법엔 크게 2가지가 있을 것 같다.
1. 각자 개인별 브랜치를 만들어서 꾸준히 til을 기록하거나, (병합 후에도 삭제 X)
2. til/{이름}/{날짜}로 만들어서 main에 병합되면 삭제하거나. 멘토님께선 후자의 방법을 사용하신 것 같다.
  1. 근데 이 방법을 사용하면 til을 작성할 때마다 브랜치도 매번 새로 생성해야되니 전자가 좋지 않을까? 라는 생각을 했다.
  2. 하지만 이 글 을 보고 actions로 브랜치 생성도 자동화를 할 수 있다는 걸 알게됐다. ~~애초에 액션 활용 방법을 잘 몰랐던 것 같다..~~
3. 근데 또 이 글을 읽고는 main 브랜치만으로 관리하는 것도 좋지 않을까? 라는 생각을 했다 ㅋㅋㅋ… til만 올리는데 굳이 여러개의 브랜치가 필요할까.. 라는 생각이 들었기 때문.
하지만 현재 레포엔 20명의 사람이 있다. 만약 여러명의 사람이 동시에 푸시를 한다면? 어떤 사람이 풀을 안하고 푸시하면? 브랜치가 꼬일테니 til/{이름}/{날짜}의 브랜치를 만들어서 관리하는게 제일 안전할 것 같다.
브랜치 관리는 정답이 없는 문제라 더 어려운 것 같다.

=> 멘토님께서도 이 부분을 자동화하는건 부담이 더 클 것 같다는 의견을 주셨다.

0423

TIL 파일 자동 생성

remote: Write access to repository not granted 오류

개인 레포에서 먼저 테스트를 해보고 팀레포에 올렸던거라, 막연히 똑같이 세팅하면 되겠지? 란 생각을 갖고 멘토님께 관련 세팅을 해주실 수 있는지 여쭤봤다.
그 후 권한을 주셔서 보니까 여기선 다 비활성화가 되어있었다.
공식 문서를 읽어보니 조직 안에 있는 레포라 그런 것 같았다.
그래서 다른 방법을 찾아보니, 퍼스널 토큰을 받아 팀 레포에 이를 설정해주면 된다고 하여 이를 적용해봤다. 해결 방법은 다음과 같다.
해결 방법
1. 개인 settings에 들어가 퍼스널 토큰을 발급 받는다. (Developer Settings > Personal access tokens (classic))
2. 이 때 repo 부분의 체크박스를 설정해 해당 토큰이 내가 소유한 레포에 접근 권한을 가질 수 있도록 한다.
3. 퍼스널 토큰을 발급 받은 후엔 팀 레포의 settings에 들어가 secrets and variables > actions 에서 아까 발급 받은 퍼스널 토큰을 원하는 이름과 함께 설정하여 추가한다.
4. 그 후 jobs의 steps에 있는 actions/checkout 액션에서 아까 발급 받은 퍼스널 토큰을 설정해 이가 접근할 수 있도록 한다.

  
jobs:
  create-til-file:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.PERSONAL_TOKEN }}

아래의 명령은 remote url을 @github.com/$.git 로설정해주는 역할을 한다. 앞서 token을 설정했기에 해당 명령어는 빼도 된다고 하지만, 혹시 몰라 추가해놓았다.

# cf. remote url: git이 연결해서 통신할 원격 저장소의 주소
git remote set-url origin https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git

추가로 다른 브랜치에선 조작이 안 되도록, 메인 브랜치일 때만 워크플로가 실행되게끔 if문을 추가했다.

  
if: github.ref == 'refs/heads/main'

번외

1. 오류가 발생했을 때 지피티랑 클로드한테 물어봤는데

git remote set-url origin https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git

팀레포에 퍼스널 토큰을 추가한 후 secrets 부분의 변수를 추가한 이름 변수명으로 바꿔주면 된다고 해서 해봤는데 안됐다. 내 생각엔 actions/checkout이 token에 접근할 수 없어서 안됐던 것 같다.

2. 수동 테스트를 해 본 다음에 다시 내 권한을 다운그레이드(?)하려 했는데 이러면 자동 생성이 안될 것 같아 일단은 냅뒀다. (내 토큰으로 레포에 접근 권한을 생성했기 때문에..) 사실 엄밀히 말하면 아직 자동화가 잘 되는지 모른다. 일단 자정이 오기를 기다려야겠다.

0424

SSH와 PAT 차이

어제 remote: Write access to repository not granted 오류로 인해 PAT(Personal Access Token)를 설정했다. 근데 찾아보니 ssh key로 설정하는 방법도 있다. ssh 키란, Secure Shell(SSH) 프로토콜을 사용하여 원격 서버나 서비스(예: GitHub)에 안전하게 인증하는 방법을 말한다.

SSH 키는 두 부분으로 구성된다.

비공개 키(Private Key): 자신의 컴퓨터에만 저장하고 절대 공유 X
공개 키(Public Key): 원격 서버나 GitHub 같은 서비스에 등록

SSH 키의 장점:

암호 입력 불필요: 한 번 설정하면 매번 자격 증명을 입력할 필요 X
편의성: PAT와 달리 만료 기간이 없어 자주 갱신할 필요 X

참고

깃허브 워크플로의 Cron은 제시간에 동작하지 않는다

4/24 밤 12시에 테스트 해봤는데 정각이 아닌 12시 22분쯤 워크플로가 실행됐다.
- 왜 그런지 찾아보니 cron은 최대한 그 시간에 실행하려고 “시도한다”는 거지 절대적인 보장이 아니라고 한다.
- 그래서 시간에 따른 자동화 보다는, workflow_dispatch 를 설정해 수동조작을 활성화 시키는 자동화 방법을 권장한다고 한다.
- 관련 링크: [https://upptime.js.org/blog/2021/01/22/github-actions-schedule-not-working/](https://upptime.js.org/blog/2021/01/22/github-actions-schedule-not-working/

구현할 거는 이슈란에 적은 후 PR을 보내자

멘토님께 어사인을 받지 않고 cron을 테스트 해보겠다는 이유로 메인에 병합시켜버렸다. 이슈란에라도 적고 보냈어야 했는데.. 추가할 기능들은 무조건 이슈란에 먼저 적은 후 PR로 보내는 걸 잊지말자.

2차 멘토링

.git 폴더를 뜯어보면 stage 되어있는 상태를 알 수 있다
커밋 컨벤션 관련 사이트
커서에는 깃허브 커밋 메세지를 자동으로 작성해주는 기능이 있다. 찾아보니 vscode에서도 코파일럿을 활용해 할 수 있다고 한다. 커밋 메시지에 포함되어야 하는 내용은 따로 설정도 가능한가보다. 참고
푸시, PR생성, 브랜치 전환, 풀 관련 단축키 => vscode에서 설정할 수 있음
gitlens, gitgraph 플러그인
git rebase란: 커밋 히스토리를 더 깔끔하게 만들고 싶을 때 사용.
- feature 브랜치에서 작업을 하다가 main 브랜치의 내용을 feature 브랜치에 갖고와서 커밋을 main 브랜치에 이어서 적용하고 싶을 때 rebase 를 사용하면 된다.
git revert와 reset의 차이
- revert
- 특정 커밋을 무효화하는 새 커밋을 생성 => 히스토리가 남아있음 - reset
- 특정 커밋으로 히스토리 자체를 되돌림 => 히스토리가 사라짐
Squash Merge: 여러 개의 커밋을 하나로 뭉쳐서 병합하는 방식
- 커서 활용

팀별 활동

깃 협업 경험 공유: 이슈, PR란에서 라벨 기능을 어떻게 사용하고 계신지 여쭤봤다. 주로 기능추가랑 버그 라벨들을 사용하신다고 한다.
충돌 해결 실습: 하나의 브랜치 안에서 여러개의 파생 브랜치를 만든 후 동일 라인을 수정한 다음 병합을 진행해봤다.
- 새롭게 알게 된 것:
  - epic 브랜치란, 여러개의 기능을 묶은 큰 범위의 브랜치를 나타낸다.
  - 브랜치 이름에 슬래시(/)를 붙이는 건 하위 디렉토리처럼 계층 구조를 표현하려는 목적이다. 실제로 .git 디렉토리 안을 보면 refs/heads/ 폴더 안에 브랜치가 슬래시 단위로 디렉토리처럼 저장되어 있다.
앞으로의 방향성: Next js가 처음인 사람들이 다수라 (나도 그렇고) 이론을 탄탄히 다지고 가야할 것 같다.

OSSCA

2025 OSSCA

This post is licensed under CC BY 4.0 by the author.

0419

📌 정리

1. 원격 저장소에서 변경된 내용을 로컬로 갖고 오고 수동으로 병합하고 싶다면

2. 원격 저장소의 변경사항을 로컬에 갖고 오고 로컬 브랜치에 병합까지 자동으로 하고 싶다면

📌 과정

참고

0422

PR 템플릿

초기에는

그러나

TIL 파일 자동 생성

순서도

코드리뷰를 통해 새롭게 알게 된 사실

브랜치 고민

0423

TIL 파일 자동 생성

remote: Write access to repository not granted 오류

해결 방법

번외

0424

SSH와 PAT 차이

깃허브 워크플로의 Cron은 제시간에 동작하지 않는다

구현할 거는 이슈란에 적은 후 PR을 보내자

2차 멘토링

팀별 활동

Trending Tags