블로그

코딩을 처음 배우기 시작하면 반드시 마주치는 첫 번째 벽이 있습니다. 바로 깃 사용법입니다. 저도 처음엔 “이걸 왜 써야 하지?” 싶었어요. 그냥 파일 저장하면 안 되나 싶었는데, 막상 써보니 이게 없으면 개발 자체가 굉장히 불편해지더라고요.

주변에서 코딩을 배우다 초반에 포기한 분들 이야기를 들어보면, Git을 제대로 설정하지 못해서 시작도 못 하고 접은 경우가 생각보다 많습니다. 진짜예요. 설치 단계에서 막혀서요.

이 글에서는 Git 설치부터 기본 환경 설정까지, 완전히 처음 시작하는 분들 기준으로 하나씩 짚어드리겠습니다.

Git이 뭔지, 왜 필요한가요?

💡 Git은 코드의 변경 이력을 저장하는 도구입니다. 파일이 망가져도 언제든 과거로 돌아갈 수 있어요.

쉽게 말하면 코드용 타임머신입니다. 수정하다가 완전히 망쳤을 때, Git이 있으면 “어제 버전으로 돌아가!” 하고 복구할 수 있어요. 없으면? 그냥 망한 거예요.

제가 처음 웹 개발을 배우던 시기에, 한 번은 CSS 파일을 잘못 건드려서 사이트가 통째로 깨진 적이 있었어요. 백업도 없었고요. 그때 Git을 알았더라면 5분 안에 해결했을 텐데, 그날 밤을 꼬박 새웠습니다. 진짜 뼈아픈 경험이었어요.

그런데 말이에요, Git은 그냥 개인 백업 용도에서 그치지 않습니다. 여러 사람이 같은 코드를 동시에 수정할 때도 충돌 없이 관리할 수 있어요. 그래서 회사에서도, 오픈소스 프로젝트에서도, 사이드 프로젝트에서도 기본으로 씁니다.

Git 다운로드 및 설치 방법

💡 운영체제에 맞는 설치 방법이 다릅니다. 아래 표를 참고해 본인 환경에 맞게 설치하세요.

잠깐, 이건 꼭 알아야 해요. Git은 공식 홈페이지(git-scm.com)에서 무료로 다운로드할 수 있습니다. 근데 운영체제마다 설치 방법이 조금씩 달라요.

Windows 사용자분들께 특히 드리고 싶은 말이 있어요. 설치 중에 “Adjusting your PATH environment” 옵션이 나오면 반드시 “Git from the command line and also from 3rd-party software”를 선택하세요. 기본값으로 두면 나중에 VSCode 같은 편집기에서 Git을 못 찾는 상황이 생깁니다. 솔직히 이 부분에서 저도 한 번 헤맸어요.

설치가 끝났다면 터미널(또는 명령 프롬프트)을 열고 git –version을 입력해보세요. “git version 2.xx.x” 이런 식으로 버전 번호가 나오면 성공입니다. 아무것도 안 뜨거나 에러가 난다면 설치가 제대로 안 된 거예요.

flowchart TD
    A[git-scm.com 접속] --> B{운영체제 선택}
    B --> |Windows| C[.exe 파일 다운로드]
    B --> |macOS| D[Homebrew 또는 Xcode]
    B --> |Linux| E[apt 패키지 설치]
    C --> F[설치 마법사 실행]
    D --> F
    E --> F
    F --> G[git --version 입력]
    G --> H{버전이 출력되나요?}
    H --> |예| I[설치 완료]
    H --> |아니오| J[PATH 설정 재확인]

Git 계정 설정하기 (이름과 이메일)

💡 Git 설치 후 이름과 이메일을 반드시 등록해야 커밋 기록에 내 정보가 제대로 남습니다.

여기서 반전인데, 많은 초보자들이 Git 설치하고 바로 쓰려다가 “왜 내 이름이 안 뜨지?” 하고 당황합니다. 이유는 간단합니다. 이름과 이메일을 아직 설정 안 해서입니다.

터미널에서 아래 두 줄을 입력하세요.

• 이름 설정: git config –global user.name “내이름”
• 이메일 설정: git config –global user.email “내이메일@example.com”

💡 이메일은 나중에 GitHub 계정과 연결할 거니까, GitHub 가입 시 쓸 이메일과 동일하게 입력하는 게 좋습니다.

–global 옵션은 “이 컴퓨터에서 Git을 쓸 때 항상 이 설정을 사용하겠다”는 의미입니다. 특정 프로젝트에만 다른 설정을 적용하고 싶다면 –global을 빼면 돼요. 처음엔 그냥 –global 쓰는 게 훨씬 편합니다.

아 그리고, 이름은 꼭 실명이 아니어도 됩니다. 닉네임도 괜찮아요. 다만 협업 상황에서 “이 코드 누가 작성했어요?” 할 때 본인인 걸 알 수 있도록 설정해두면 나중에 편합니다.

주변에 개발을 막 시작한 10대 후반 친구가 있었는데, 이 단계에서 이메일을 임시로 넣었다가 나중에 GitHub 연동할 때 계정이 안 맞아서 고생했어요. 처음부터 제대로 설정해두는 게 훨씬 이득입니다.

설정 확인 및 Git 버전 업데이트

💡 git config –list 명령어 하나로 현재 설정된 모든 Git 환경 정보를 한 번에 확인할 수 있습니다.

설정을 마쳤으면 제대로 됐는지 확인해봐야겠죠. 아 그리고, 버전 확인도 이 타이밍에 같이 해두면 좋습니다.

• 전체 설정 확인: git config –list
• 이름만 확인: git config user.name
• 이메일만 확인: git config user.email
• 현재 버전 확인: git –version

git config –list를 치면 내용이 쭉 나오는데, 겁먹지 않아도 됩니다. 그 중에서 user.name이랑 user.email이 내가 입력한 대로 나오면 완벽하게 설정된 거예요.

참고로 Git은 꽤 자주 업데이트됩니다. 지난 주말에 확인해봤더니 버전이 2.47 이상까지 올라와 있더라고요. 최신 버전을 유지하면 보안 취약점 패치도 받고, 새 기능도 활용할 수 있으니 가끔씩 업데이트해주세요.

Windows는 git-scm.com에서 최신 버전을 다시 받아 설치하면 되고, macOS는 brew upgrade git이면 됩니다. Linux는 sudo apt upgrade git으로 해결돼요. 간단하죠?

이 과정에서 막히는 부분이 있으신가요? 처음엔 터미널 자체가 낯설어서 명령어 치는 것 자체가 무서울 수 있어요. 이거 저만 그런 건 아닐 거예요. 천천히 하나씩 따라 해보시면 금방 익숙해집니다. 진짜예요.

mindmap
  root((Git 초기 설정))
    설치
      Windows .exe
      macOS Homebrew
      Linux apt
    계정 설정
      user.name
      user.email
      global 옵션
    확인 방법
      git --version
      git config --list
    업데이트
      정기적 최신화
      보안 패치 수신

관련 글 더 보기

• Git 명령어 기초와 버전 관리
• GitHub 초기 설정 및 저장소 생성
• 협업 워크플로와 풀리퀘스트 사용법

전체 가이드로 돌아가기: 깃허브 사용법: 초보자를 위한 Git과 GitHub 완벽 튜토리얼

혼자서 처음으로 코드를 짜기 시작했을 때, 누구나 한 번쯤 이런 상황을 겪습니다. “잘 되던 코드가 갑자기 안 돼. 뭘 고쳤더라?” 그 순간 머릿속이 하얘지죠. Git 명령어를 알았더라면 이런 공포가 없었을 겁니다.

이 글은 Git을 처음 쓰는 분들이 실제로 프로젝트를 혼자 시작할 때 가장 많이 쓰는 명령어들만 골라서 설명합니다. 이론 말고, 바로 써먹을 수 있는 것들로요.

저장소 시작하기: git init과 git add

💡 git init으로 Git을 시작하고, git add로 저장할 파일을 선택합니다. 이 두 명령어가 버전 관리의 시작입니다.

프로젝트 폴더에서 터미널을 열고 처음 입력하는 명령어가 바로 git init입니다. 이걸 치면 폴더 안에 .git이라는 숨김 폴더가 생겨요. 여기에 모든 변경 이력이 저장됩니다.

근데 말이에요, git init을 한다고 해서 파일이 자동으로 Git에 저장되는 건 아닙니다. “어떤 파일을 저장할 거야?”를 Git에게 알려주는 과정이 따로 필요해요. 그게 바로 git add입니다.

• git init — 현재 폴더를 Git 저장소로 초기화
• git add 파일명 — 특정 파일을 저장 대상으로 지정
• git add . — 현재 폴더의 모든 파일을 저장 대상으로 지정

제가 처음 git add .를 배웠을 때, 점(.)이 “현재 폴더 전체”를 의미한다는 걸 몰라서 왜 이게 되나 한참 헷갈렸어요. (이건 진짜 초보 시절 얘기예요.) 이제는 너무 당연한 거지만요.

혹시 “git add를 했는데 아무것도 안 일어나는 것 같아요”라고 느끼시는 분? 맞아요. git add는 눈에 보이는 변화가 없어요. 그냥 “내가 이 파일들을 저장할 준비가 됐어”라고 목록에 올려두는 것뿐입니다. 실제 저장은 다음 단계에서 이루어집니다.

변경 사항 저장하기: git commit

💡 git commit은 add로 선택한 파일들을 실제로 저장하는 명령어입니다. 메시지를 꼭 남겨야 나중에 무슨 작업이었는지 알 수 있습니다.

잠깐, 이건 꼭 알아야 해요. git commit은 단순히 저장하는 게 아닙니다. 하나의 의미 있는 작업 단위를 기록하는 것입니다. 나중에 “3일 전에 뭘 바꿨더라?”를 확인할 때 이 기록이 생명줄이 됩니다.

기본 문법은 이렇습니다.

• git commit -m “메시지 내용”

메시지는 짧고 명확하게 쓰는 게 좋습니다. “수정함”, “고침” 같은 말은 의미가 없어요. 대신 “로그인 버튼 클릭 시 오류 수정”, “메인 페이지 레이아웃 변경” 이런 식으로 써두면 나중에 한눈에 파악됩니다.

주변에서 개발을 막 배우기 시작한 20대 초반 분이 “커밋 메시지가 귀찮아서 그냥 ‘1’, ‘2’, ‘3’으로 남겼더니 나중에 뭐가 뭔지 몰라서 전부 다시 짰다”고 했어요. 웃프지만 이게 현실입니다. 처음부터 습관 들이는 게 훨씬 이득이에요.

변경 사항 확인하기: git status와 git diff

💡 git status로 어떤 파일이 변경됐는지 확인하고, git diff로 구체적으로 무엇이 바뀌었는지 볼 수 있습니다.

아 그리고, 이 두 명령어는 거의 매일 쓰게 될 거예요. 특히 “내가 지금 뭘 바꿨더라?” 싶을 때 바로 쓰는 명령어입니다.

• git status — 현재 저장소 상태 확인 (어떤 파일이 수정됐는지, add됐는지)
• git diff — add 전 파일의 구체적인 변경 내용 확인
• git diff –staged — add 이후 commit 전 변경 내용 확인

git status를 치면 빨간색과 초록색 글씨가 나옵니다. 빨간색은 “아직 add 안 한 파일”, 초록색은 “add 해서 commit 준비된 파일”이에요. 처음엔 헷갈릴 수 있는데, 색깔 기억해두면 금방 익숙해집니다.

git diff는 실제로 줄 단위로 뭐가 바뀌었는지 보여줍니다. 추가된 줄은 + 표시, 삭제된 줄은 – 표시로 나와요. 솔직히 처음 보면 뭔지 모르겠는데, 두세 번 써보면 바로 읽힙니다.

브랜치 생성과 전환, 그리고 히스토리 확인

💡 브랜치는 메인 코드를 건드리지 않고 새로운 작업을 시도할 수 있는 복사본 같은 개념입니다.

여기서 반전인데, 브랜치는 처음엔 “이게 왜 필요하지?” 싶지만 한 번 쓰고 나면 없으면 못 삽니다.

예를 들어 “새로운 기능을 추가해봐야 하는데, 원본은 건드리기 싫어”라는 상황에서 브랜치를 만들면 됩니다. 원본은 그대로 두고 새 브랜치에서 마음껏 실험할 수 있어요.

• git branch 브랜치명 — 새 브랜치 생성
• git checkout 브랜치명 — 해당 브랜치로 이동
• git checkout -b 브랜치명 — 생성과 이동을 동시에
• git log — 커밋 히스토리 전체 확인
• git log –oneline — 한 줄씩 간결하게 확인

git log –oneline은 특히 자주 쓰게 될 거예요. 커밋 내역을 한 줄씩 깔끔하게 보여주거든요. 히스토리가 길어졌을 때 한눈에 파악하기 좋습니다.

gitGraph
   commit id: "초기 프로젝트 생성"
   commit id: "메인 페이지 레이아웃 작성"
   branch feature/login
   checkout feature/login
   commit id: "로그인 폼 추가"
   commit id: "로그인 유효성 검사"
   checkout main
   commit id: "README 업데이트"
   merge feature/login id: "로그인 기능 병합"

이게 실제 브랜치 흐름을 시각화한 거예요. main 브랜치를 건드리지 않고 feature/login 브랜치에서 작업한 뒤 나중에 합치는 방식입니다. 혼자 작업해도 이렇게 관리하면 나중에 어떤 기능을 언제 추가했는지 한눈에 보입니다.

Git 명령어 처음 배울 때 가장 헷갈리는 게 init → add → commit의 흐름인데, 이 세 가지만 확실히 잡으면 나머지는 자연스럽게 따라옵니다. 이거 저만 어렵게 느꼈던 건 아닐 거예요. 분명 공감하실 분들 계실 겁니다.

관련 글 더 보기

• Git 기초: 설치 및 환경 설정
• GitHub 초기 설정 및 저장소 생성
• 협업 워크플로와 풀리퀘스트 사용법

전체 가이드로 돌아가기: 깃허브 사용법: 초보자를 위한 Git과 GitHub 완벽 튜토리얼

깃허브 사용법을 검색해서 이 글을 찾아오셨다면, 아마 팀 프로젝트를 앞두고 있거나 포트폴리오를 만들어야 하는 상황일 겁니다. 맞죠? GitHub는 이제 개발자의 이력서라고 해도 과언이 아니에요. 면접관들이 GitHub 프로필을 직접 확인하는 시대입니다.

근데 처음 GitHub를 시작할 때 “계정은 만들었는데 이걸 어떻게 써요?”라는 막막함이 있어요. 그 느낌 압니다. 저도 처음에 저장소(Repository)가 뭔지도 모르고 버튼만 누르다가 한참 헤맸으니까요.

이 글에서는 GitHub 계정 생성부터 저장소 만들기, 로컬 코드를 GitHub에 올리는 방법까지 단계별로 설명드리겠습니다.

GitHub 계정 생성 및 기본 설정

💡 GitHub 계정은 개발자의 온라인 포트폴리오 공간입니다. 처음 만들 때 사용자명을 신중하게 정하는 게 좋습니다.

github.com에 접속해서 Sign up을 누르면 됩니다. 이메일, 비밀번호, 사용자명(username)을 입력하면 끝이에요. 근데 말이에요, 사용자명은 한 번 정하면 바꾸기 꽤 불편합니다. 그래서 처음부터 잘 정해두는 게 중요해요.

이상적인 GitHub 사용자명 기준을 몇 가지 정리하면:

• 실명 기반이거나 기억하기 쉬운 닉네임
• 숫자나 특수문자를 너무 많이 섞지 않기
• 다른 플랫폼 아이디와 통일하면 브랜딩에 유리

계정을 만들고 나면 이메일 인증을 해야 정상적으로 사용할 수 있어요. 가입할 때 쓴 이메일로 인증 메일이 오는데, 그걸 클릭하면 됩니다. 간단하죠.

참고로 이전에 Git 계정 설정할 때 입력한 이메일과 GitHub 이메일을 동일하게 맞춰두면 커밋 기록이 GitHub 프로필에 잔디(contribution)로 쌓입니다. 이게 안 맞으면 로컬에서 커밋을 아무리 열심히 해도 GitHub 프로필에 활동 기록이 안 남아요. 이 부분을 놓치면 억울하니까 꼭 확인해두세요.

새로운 저장소(Repository) 만들기

💡 저장소는 프로젝트 하나당 하나씩 만드는 게 기본입니다. Public으로 설정하면 누구나 볼 수 있고, Private는 나만 볼 수 있습니다.

로그인하면 오른쪽 상단에 + 버튼이 있습니다. 거기서 “New repository”를 선택하면 저장소 생성 화면으로 넘어가요.

잠깐, 이건 꼭 알아야 해요. 저장소 이름은 나중에 URL에 그대로 들어갑니다. github.com/내아이디/저장소이름 이런 형태로요. 그래서 의미 있는 이름으로 짓는 게 좋아요. “test123” 같은 건 나중에 포트폴리오로 보여주기 민망할 수 있으니까요.

README 초기화 옵션에 대해 조금 더 설명할게요. 처음 시작할 때 “Add a README file”을 체크하면 GitHub에서 자동으로 README.md 파일이 생깁니다. 근데 이미 로컬에 코드가 있다면 이 옵션을 체크하지 않는 게 좋아요. 나중에 로컬 코드를 올릴 때 충돌이 날 수 있거든요. 솔직히 이 부분은 저도 처음에 체크했다가 한 번 꼬인 적 있어요.

로컬 저장소를 GitHub에 연결하기

💡 로컬에서 만든 Git 저장소와 GitHub의 원격 저장소를 연결해야 코드를 업로드할 수 있습니다.

여기서 반전인데, 이 단계가 처음엔 제일 어렵게 느껴지지만 실제로는 명령어 두세 줄이면 됩니다. 겁먹지 않아도 돼요.

GitHub에서 저장소를 만들면 페이지 하단에 이런 안내가 나옵니다. “…or push an existing repository from the command line” 이 부분을 그대로 복사해서 터미널에 붙여넣으면 됩니다. 명령어를 외울 필요도 없어요.

그래도 내용이 뭔지 알아야 하니까 설명하면:

• git remote add origin [URL] — 로컬 저장소에 GitHub 주소를 “origin”이라는 이름으로 등록
• git branch -M main — 기본 브랜치 이름을 main으로 변경
• git push -u origin main — 로컬 코드를 GitHub에 업로드

처음 push할 때 GitHub 로그인 정보를 요구할 수 있습니다. 요즘은 비밀번호 방식이 아니라 Personal Access Token(PAT)을 써야 해요. GitHub → Settings → Developer Settings → Personal access tokens에서 만들 수 있습니다. 이 토큰을 비밀번호 입력란에 붙여넣으면 됩니다.

sequenceDiagram
    participant L as 로컬 컴퓨터
    participant G as GitHub
    L->>L: git init
    L->>L: git add .
    L->>L: git commit -m "초기 커밋"
    L->>G: git remote add origin [URL]
    L->>G: git push -u origin main
    G-->>L: 업로드 완료
    Note over G: GitHub 저장소에코드가 올라갑니다

README 파일 추가하고 꾸미기

💡 README.md는 저장소의 첫 인상입니다. 프로젝트 설명, 실행 방법, 기술 스택을 담아두면 협업자나 면접관에게 좋은 인상을 줍니다.

아 그리고, README는 생각보다 중요합니다. GitHub 저장소 메인 화면에서 가장 먼저 보이는 게 README거든요. 이게 잘 정리돼 있는 저장소와 아무것도 없는 저장소는 인상이 완전히 다릅니다.

README.md 파일을 로컬에서 만들고 기본 내용을 채워보세요.

• 프로젝트 이름과 한 줄 설명
• 어떤 기술을 사용했는지 (기술 스택)
• 어떻게 실행하는지 (설치 방법, 실행 명령어)
• 스크린샷이나 데모 링크 (있다면)

저는 올해 초에 팀 프로젝트 준비를 하면서 GitHub 저장소를 처음으로 제대로 꾸며봤는데, README 하나 잘 만들었더니 팀원들 반응이 완전히 달라졌어요. “이거 진짜 포트폴리오 같다”는 말을 들었을 때 뿌듯하더라고요.

README.md를 로컬에서 작성했으면 이제 다시 add → commit → push 순서로 올리면 됩니다.

1. git add README.md
2. git commit -m “README 초기 작성”
3. git push

GitHub 저장소 페이지를 새로고침하면 README 내용이 바로 보일 거예요. 처음 이 화면을 봤을 때 뭔가 진짜 개발자가 된 것 같은 느낌이 들었어요. 이 기분, 여러분도 곧 느끼실 겁니다.

혹시 아직 “이게 다 뭔 소리야” 싶은 부분이 있으신가요? 처음엔 당연히 낯설 수 있습니다. 근데 딱 한 번만 처음부터 끝까지 따라 해보면, 두 번째부터는 자연스럽게 손이 갑니다. 깃허브 사용법은 결국 반복이에요.

관련 글 더 보기

• Git 기초: 설치 및 환경 설정
• Git 명령어 기초와 버전 관리
• 협업 워크플로와 풀리퀘스트 사용법

전체 가이드로 돌아가기: 깃허브 사용법: 초보자를 위한 Git과 GitHub 완벽 튜토리얼

💡 풀리퀘스트는 단순한 코드 제출이 아니라, 팀원과 대화하는 공식 채널입니다. 포크→브랜치→커밋→PR→리뷰→머지 흐름만 몸에 익히면 어떤 팀 프로젝트도 두렵지 않습니다.

처음 팀 프로젝트에 들어갔을 때의 그 막막함

풀리퀘스트, 줄여서 PR. 취업 전에 이 단어를 처음 들었을 때 솔직히 ‘그냥 코드 올리는 거 아닌가?’ 싶었습니다. 근데 막상 팀 프로젝트에 들어가 보니 이게 전혀 다른 세계더라고요.

제 주변에 개발 부트캠프를 막 졸업한 20대 중반 분이 있었는데, 처음 오픈소스 기여를 시도하다가 포크도 안 하고 원본 저장소에 직접 푸시하려다 에러를 만났다고 했습니다. “이게 왜 안 되지?” 하고 2시간을 혼자 붙잡고 있었다는 거예요. 저도 비슷한 경험이 있어서 그 답답함이 딱 와닿았습니다.

그래서 오늘은 풀리퀘스트를 중심으로 GitHub 협업 워크플로 전체를 한 번에 정리해드리려 합니다. 포크부터 머지까지, 실제로 쓰이는 순서 그대로요.

포크와 브랜치, 뭐가 다른 건가요?

💡 포크는 저장소 자체를 내 계정으로 복사하는 것, 브랜치는 같은 저장소 안에서 작업 공간을 나누는 것입니다.

여기서 반전인데, 많은 분들이 포크와 브랜치를 혼용해서 쓰다가 협업 흐름을 망가뜨리는 경우가 꽤 있습니다.

포크(Fork)는 타인의 저장소를 내 GitHub 계정으로 통째로 복사하는 행위입니다. 오픈소스 기여나 외부 프로젝트에 참여할 때 주로 씁니다. 반면 브랜치(Branch)는 같은 저장소 내에서 독립적인 작업 공간을 만드는 개념입니다. 같은 팀, 같은 저장소 내에서 기능별로 나눠 작업할 때 쓰죠.

팀 내부 프로젝트라면 대부분 브랜치 전략을 씁니다. 오픈소스처럼 외부인이 기여하는 구조라면 포크 후 PR을 올리는 흐름이 일반적이에요.

flowchart TD
    A[원본 저장소\noriginal repo] -->|Fork| B[내 계정의 복사본\nforked repo]
    B -->|git clone| C[로컬 PC]
    C -->|브랜치 생성\ngit checkout -b feature/기능명| D[작업 브랜치]
    D -->|코드 작성 후\ngit add & commit| E[로컬 커밋]
    E -->|git push origin\nfeature/기능명| F[내 원격 저장소]
    F -->|풀리퀘스트 생성| A
    A -->|리뷰 & 승인 후| G[머지 완료]

흐름이 보이시나요? 포크를 쓰든 브랜치를 쓰든, 결국 풀리퀘스트가 최종 관문이 된다는 건 똑같습니다.

풀리퀘스트 생성, 이렇게 하면 됩니다

💡 브랜치에서 커밋을 올린 뒤 GitHub 웹에서 “Compare & pull request” 버튼을 누르는 것만으로 PR이 시작됩니다.

실제 순서를 단계별로 따라가 보겠습니다.

1. 브랜치 생성: git checkout -b feature/login-button 처럼 기능 이름을 붙인 브랜치를 만듭니다.
2. 작업 및 커밋: 코드를 수정하고 git add . → git commit -m "로그인 버튼 UI 추가".
3. 원격 저장소에 푸시: git push origin feature/login-button.
4. GitHub에서 PR 생성: 저장소 페이지 상단에 “Compare & pull request” 버튼이 뜨면 클릭. 안 뜨면 Pull requests 탭 → New pull request.
5. PR 제목과 설명 작성: 여기가 진짜 중요합니다. 아래에서 따로 다룰게요.

잠깐, 이건 꼭 알아야 해요. PR 제목과 설명은 코드보다 먼저 읽힙니다. 리뷰어 입장에서 “이 PR이 왜 필요한지”, “어떤 변경이 있는지”를 한눈에 파악할 수 있어야 하거든요. 대충 “기능 추가”라고만 써놓으면 리뷰어가 코드를 전부 읽어야 하는 상황이 됩니다. 팀원에게 민폐가 되는 거죠.

좋은 PR 설명의 구성은 대략 이렇습니다.

• 변경 이유: 왜 이 작업을 했는가
• 변경 내용 요약: 무엇을 어떻게 바꿨는가
• 테스트 방법: 어떻게 확인할 수 있는가
• 스크린샷 (UI 변경 시): 직관적인 이해를 도움

이거 처음에 면찮아 보여도 습관 들이면 본인이 제일 편합니다. 나중에 “내가 왜 이걸 만들었더라?” 할 때 PR 히스토리 보면 다 나오거든요.

리뷰 프로세스: 받는 것도, 주는 것도 기술입니다

💡 코드 리뷰는 코드를 평가하는 게 아니라 더 나은 코드를 함께 만들어가는 대화입니다.

PR을 올리면 팀원이 코드를 검토하고 코멘트를 남깁니다. GitHub에서는 특정 줄을 클릭해서 인라인 코멘트를 달 수 있어요. 리뷰어는 최종적으로 세 가지 중 하나를 선택합니다.

Request changes를 받았을 때 기분이 상하는 분들이 꽤 있는데요. 사실 이건 “네 코드가 형편없어”가 아니라 “같이 더 좋게 만들어보자”에 더 가깝습니다. 오픈소스 프로젝트에서 베테랑 개발자들도 서로 수정 요청을 주고받는 건 일상입니다.

그런데 말이에요, 리뷰를 주는 입장도 꽤 신경 써야 합니다. “이거 왜 이렇게 했어요?”보다 “이 부분을 이렇게 바꾸면 성능이 개선될 것 같아요, 어떻게 생각하세요?”처럼 제안형으로 쓰는 게 협업 분위기에 훨씬 좋습니다. 팀 프로젝트는 결국 사람 사이의 관계니까요.

수정 요청을 반영했다면 같은 브랜치에 새 커밋을 추가하고 다시 푸시하면 됩니다. 기존 PR에 자동으로 반영되니까 새 PR을 만들 필요가 없습니다.

머지와 충돌 해결, 겁먹지 않아도 됩니다

💡 충돌(Conflict)은 두 브랜치가 같은 파일의 같은 줄을 다르게 수정했을 때 발생합니다. Git이 어느 쪽을 선택할지 모르기 때문에 사람이 직접 결정해야 합니다.

승인이 완료된 PR은 머지(Merge)할 수 있습니다. GitHub에서는 머지 방식이 세 가지입니다.

• Merge commit: 기본값. 브랜치 히스토리가 그대로 보존됩니다.
• Squash and merge: 여러 커밋을 하나로 합쳐서 main에 추가. 히스토리가 깔끔해집니다.
• Rebase and merge: 커밋을 main 위에 순서대로 올립니다. 선형 히스토리 유지.

팀마다 선호하는 방식이 다르니 처음 프로젝트 합류 시 팀 컨벤션을 꼭 물어보는 게 좋습니다. (이건 진짜 꿀팁)

아 그리고, 충돌 문제. 처음 Conflict 메시지를 보면 당황스럽지만 구조만 알면 별거 없습니다.

sequenceDiagram
    participant A as 개발자A의 브랜치
    participant M as main 브랜치
    participant B as 개발자B의 브랜치

    A->>M: 먼저 머지 완료
    B->>M: PR 생성 시도
    M-->>B: ⚠️ Conflict 발생!
    Note over B: git fetch origingit merge origin/main
    B->>B: 충돌 파일 직접 수정
    B->>M: 충돌 해결 후 다시 푸시
    M-->>B: ✅ 머지 가능 상태

충돌이 난 파일을 열면 이런 표시가 보입니다.

<<<<<<< HEAD 아래는 현재 브랜치의 코드, ======= 아래는 병합하려는 브랜치의 코드, >>>>>>> 이후가 상대 브랜치 이름입니다. 둘 중 맞는 쪽을 남기거나 둘 다 조합해서 저장하면 됩니다. 그 다음 다시 커밋하면 충돌 해결 완료입니다.

지난주에 사이드 프로젝트에서 이 상황을 직접 겪었는데, 겁먹지 않고 파일 열어서 구분선 찾아서 수정하니까 5분 만에 해결됐습니다. 처음이 어렵지, 한 번만 해보면 “별거 아니네” 하게 됩니다.

PR 기반 협업, 이게 왜 중요한가

결국 풀리퀘스트 문화의 핵심은 모든 변경이 검토를 거친다는 원칙입니다. main 브랜치에 직접 push하는 팀과, PR을 통해 리뷰를 거치는 팀의 코드 품질은 시간이 지날수록 차이가 납니다. 이건 데이터 볼 필요도 없이 현장에서 체감하게 됩니다.

혹시 지금 팀 프로젝트에서 PR 없이 작업하고 있다면, 오늘부터라도 브랜치 전략을 도입해보는 건 어떨까요? 처음엔 번거롭게 느껴질 수 있지만, 나중에 “왜 이 코드가 이렇게 됐지?” 하는 상황이 훨씬 줄어듭니다.

포크, 브랜치, 커밋, 푸시, PR, 리뷰, 머지. 이 일곱 단계가 이제 자연스럽게 머릿속에 그려진다면, 여러분은 이미 팀 협업의 기본 흐름을 익힌 겁니다.

관련 글 더 보기

• Git 기초: 설치 및 환경 설정
• Git 명령어 기초와 버전 관리
• GitHub 초기 설정 및 저장소 생성

전체 가이드로 돌아가기: 깃허브 사용법: 초보자를 위한 Git과 GitHub 완벽 튜토리얼

코드를 처음 작성했을 때 기억나시나요? 열심히 만든 파일을 실수로 덮어쓰고, 어떤 버전이 최신인지 몰라서 파일명에 “최최최종_진짜최종_이게맞음.zip”을 붙여본 경험, 한 번쯤 있으실 겁니다.

진짜예요. 저도 그랬으니까요. 처음 개발 공부를 시작했을 때 Git이라는 단어를 들으면 괜히 겁부터 났습니다. 명령어가 외계어처럼 보였고, GitHub는 “개발자들만 쓰는 뭔가 어려운 것”이라는 인식이 있었어요. 그런데 막상 써보니 달랐습니다.

Git과 GitHub를 제대로 익히면 버전 관리 걱정은 사라지고, 팀 협업이 눈에 띄게 편해집니다. 이 가이드는 그 첫걸음을 도와드리기 위한 글입니다. 설치부터 협업 워크플로까지, 단계별로 정리해 두었으니 필요한 섹션부터 읽으셔도 됩니다.

목차

1. Git 기초: 설치 및 환경 설정
2. Git 명령어 기초와 버전 관리
3. GitHub 초기 설정 및 저장소 생성
4. 협업 워크플로와 풀리퀘스트 사용법

Git 기초: 설치 및 환경 설정

💡 Git은 컴퓨터에 설치하는 버전 관리 도구입니다. 설치가 반이에요.

Git을 처음 접하는 분들이 가장 많이 막히는 부분이 바로 환경 설정입니다. 운영체제마다 설치 방법이 조금 다르고, 처음 보는 터미널 화면에 당황하는 경우가 많습니다. 솔직히 이 부분은 저도 처음엔 좀 헷갈렸어요.

Windows, macOS, Linux 각각 설치 방법이 다르고, 설치 후 사용자 이름과 이메일을 등록하는 초기 설정도 빠뜨리면 나중에 문제가 생깁니다. 처음 한 번만 제대로 해두면 그 이후는 훨씬 수월합니다.

그런데 말이에요, 설치보다 더 중요한 게 있습니다. 바로 Git이 실제로 어떤 방식으로 파일을 추적하는지를 개념적으로 이해하는 것입니다. 이 개념이 잡혀야 이후 명령어가 왜 그렇게 생겼는지 납득이 됩니다. 단순 암기가 아닌 이해로 접근하면 훨씬 오래 기억할 수 있어요.

자세히 읽어보기: Git 기초: 설치 및 환경 설정

Git 명령어 기초와 버전 관리

💡 init, add, commit 세 개만 익혀도 혼자 쓰는 버전 관리는 바로 시작할 수 있습니다.

Git을 배운다는 건 결국 명령어를 익히는 일입니다. 근데 전부 외울 필요는 없어요. 실제로 자주 쓰는 명령어는 생각보다 많지 않습니다. 제가 지난달에 직접 정리해 봤는데, 일상적인 개인 프로젝트에서는 10개 미만의 명령어로 대부분 해결됩니다.

핵심은 세 단계입니다. 작업 디렉토리 → 스테이징 영역 → 로컬 저장소. 이 흐름을 이해하면 git add와 git commit이 왜 분리되어 있는지 자연스럽게 납득이 됩니다. 처음엔 “왜 두 번이나 해야 돼?” 싶었는데, 써보니 이 구조가 꽤 유용합니다.

아 그리고, 브랜치 개념도 여기서 함께 다룹니다. 브랜치는 실험적인 작업을 메인 코드와 분리해서 진행할 수 있게 해주는 기능인데요. 망해도 괜찮은 브랜치를 하나 만들어놓고 마음껏 수정하고, 잘 되면 합치는 방식입니다. 이게 Git의 가장 큰 장점 중 하나예요.

자세히 읽어보기: Git 명령어 기초와 버전 관리

Git과 GitHub의 핵심 개념 비교

💡 Git은 도구, GitHub는 그 도구를 쓰는 온라인 플랫폼입니다. 둘은 다릅니다.

이 부분에서 많은 분들이 혼동하십니다. Git과 GitHub는 이름이 비슷하지만 본질적으로 다릅니다.

간단히 말하면, Git 없이 GitHub를 쓰기는 어렵습니다. 반대로 Git만으로도 혼자 쓰는 버전 관리는 충분히 가능하고요. 두 개를 함께 쓸 때 진가가 발휘됩니다. 팀 프로젝트라면 특히요.

혹시 이 차이가 아직 헷갈리신다면, 아래 섹션들을 순서대로 읽으시면 자연스럽게 정리될 겁니다.

GitHub 초기 설정 및 저장소 생성

💡 저장소 하나 만드는 것만으로도 포트폴리오의 시작이 됩니다.

GitHub 계정을 만들고 나서 처음 저장소(Repository)를 생성할 때, 막막하게 느껴지는 분들이 많습니다. Public으로 해야 하나 Private으로 해야 하나, README는 뭐고 .gitignore는 왜 선택하라는 건지. 옵션이 많으면 오히려 시작이 어렵죠.

잠깐, 이건 꼭 알아야 해요. GitHub의 저장소는 크게 두 종류입니다. Public(공개)과 Private(비공개). 개인 학습용이나 포트폴리오 목적이라면 Public이 유리합니다. 채용 담당자나 협업 파트너가 바로 볼 수 있거든요. 반면 회사 업무나 개인 프로젝트라면 Private으로 관리하세요.

로컬 Git 저장소와 GitHub 원격 저장소를 연결하는 과정도 여기서 다룹니다. git remote add origin 명령어가 바로 그 연결 다리 역할을 합니다. 이 과정을 한 번 직접 해보면 생각보다 간단하다는 걸 느끼실 거예요.

자세히 읽어보기: GitHub 초기 설정 및 저장소 생성

협업 워크플로와 풀리퀘스트 사용법

💡 풀리퀘스트(PR)는 “내 코드 검토해주세요”라고 팀원에게 공식 요청하는 방법입니다.

이 부분이 Git과 GitHub를 배우는 진짜 이유라고 해도 과언이 아닙니다. 혼자 쓰는 버전 관리에서 팀 협업으로 넘어가는 순간이거든요.

제 주변의 한 개발자 지인은 처음 팀 프로젝트에 투입됐을 때 PR 개념을 몰라서 실수를 한 적이 있다고 했습니다. 직접 main 브랜치에 코드를 push해서 팀 전체 작업이 꼬여버린 거예요. 이후로 그 분은 브랜치 전략과 PR 프로세스를 정말 꼼꼼히 익혔다고 합니다. (이건 진짜 흔한 실수예요)

협업 워크플로의 핵심은 간단합니다.

• 메인 브랜치는 항상 안정된 코드만 유지
• 새 기능이나 수정은 별도 브랜치에서 작업
• 작업 완료 후 PR을 통해 코드 리뷰 요청
• 팀원 승인 후 메인 브랜치에 병합(Merge)

이 흐름을 익히면 오픈소스 프로젝트에 기여하는 것도 어렵지 않습니다. GitHub에서 가장 많이 쓰이는 협업 방식이기도 하고요.

flowchart LR
    A[로컬 브랜치 생성] --> B[코드 작성 및 커밋]
    B --> C[GitHub에 Push]
    C --> D[풀리퀘스트 생성]
    D --> E[팀원 코드 리뷰]
    E --> F{승인 여부}
    F -->|승인| G[main 브랜치에 Merge]
    F -->|수정 요청| B
    G --> H[브랜치 삭제]

자세히 읽어보기: 협업 워크플로와 풀리퀘스트 사용법

자주 묻는 질문 (FAQ)

Git과 GitHub의 차이점은 무엇인가요?

Git은 컴퓨터에 설치하는 버전 관리 소프트웨어입니다. 인터넷 없이도 로컬에서 코드 히스토리를 추적하고 브랜치를 관리할 수 있습니다. 반면 GitHub는 Git 저장소를 온라인에 올려두고 다른 사람들과 공유하거나 협업할 수 있게 해주는 웹 플랫폼입니다. 쉽게 말하면, Git이 도구라면 GitHub는 그 도구로 작업한 결과물을 보관하고 공유하는 공간입니다. Git 없이 GitHub만 쓸 수는 없지만, GitHub 없이 Git만 쓰는 것은 가능합니다.

로컬 저장소와 원격 저장소는 어떻게 다릅니까?

로컬 저장소는 내 컴퓨터에 존재하는 Git 저장소입니다. 인터넷 연결 없이 작업하고, 커밋하고, 브랜치를 관리할 수 있습니다. 원격 저장소는 GitHub 같은 온라인 플랫폼에 올라가 있는 저장소입니다. 팀원들과 코드를 공유하거나 백업 용도로 사용합니다. 로컬에서 작업한 내용을 git push로 원격에 올리고, 원격의 최신 내용을 git pull로 내려받는 방식으로 두 저장소를 동기화합니다.

브랜치가 충돌할 경우 어떻게 해결하나요?

브랜치 충돌(Merge Conflict)은 두 브랜치에서 같은 파일의 같은 부분을 서로 다르게 수정했을 때 발생합니다. 겁먹을 필요 없어요. Git은 충돌이 발생한 위치를 파일 안에 명확하게 표시해줍니다. <<<<<<<, =======, >>>>>>> 기호로 구분된 부분이 바로 충돌 구간입니다. 두 버전 중 어느 것을 유지할지, 혹은 두 내용을 합칠지 직접 편집한 뒤 저장하고, 다시 git add와 git commit을 실행하면 됩니다. VS Code 같은 에디터는 충돌 해결 UI를 제공하기 때문에 훨씬 편하게 처리할 수 있습니다.

마무리하며

Git과 GitHub는 처음 접하면 낯설고 복잡해 보이지만, 핵심 개념 몇 가지만 잡히면 생각보다 빠르게 익숙해집니다. 설치와 환경 설정부터 시작해서 명령어, 저장소 생성, 협업 워크플로까지 단계별로 차근차근 따라오시면 됩니다.

위에 정리된 각 서브 포스트는 하나하나 독립적으로 읽을 수 있도록 구성되어 있습니다. 막히는 부분이 생기면 해당 글로 돌아와서 다시 확인하시면 됩니다. 처음부터 전부 외우려 하지 않아도 됩니다. 써보면서 익히는 게 훨씬 빠르거든요.

오늘 배운 내용이 실제 프로젝트에서 도움이 되길 바랍니다.