[과제] 협업으로 팀 소개 페이지 만들기(튜터님 피드백 반영)

---------------------------------------------------------------------------------------------------------------------------------------

리마인드 시작

 

 

1. 우리 팀 저장소 복제 (Clone) & 계획 짜기

1️⃣ 목적

• 과제 시작을 위한 기본 세팅을 하는 단계입니다!
• 모두가 함께 작업할 원본 템플릿 코드를 내 PC로 가져오고, 다른 팀원들에게 "저는 이 부분을 맡을게요!"라고 서로의 작업 계획을 공유하고 업무 범위를 공유하는 것이 목표입니다.

2️⃣ 구현 내용

• [팀장] 팀원들과 함께 사용하게 될 하나의 레포지토리(원격 저장소)를 신규로 생성하여, 튜터님이 제공한 레파지토리의 코드를 push 합니다.-> [팀장]컴퓨터(로컬)에 있는 프로젝트 파일들을 GitHub 같은 원격 저장소에 업로드하는 것
• [팀원 공통] 모든 팀원들을 해당 저장소에서 작업할 수 있도록 Collaborator에 팀원들을 초대해줍니다.
• [팀원 공통] 생성된 팀장님의 레파지토리(원격 저장소)에 git clone [저장소 URL] 명령어를 터미널에 입력해서 내 컴퓨터로 그대로 클론합니다.-> 원격 저장소(GitHub)에 있는 프로젝트 전체를 나의 컴퓨터로 복사(다운로드)하는 명령어

즉, 팀장님이 만든 레포지토리를 내 로컬에 그대로 가져오는 과정

그래서 clone 하면:

• GitHub에 있는 코드 전체가 내 컴퓨터로 복사되고
• .git 폴더까지 같이 복사돼서
• 즉시 Git으로 버전 관리가 가능한 상태가 됨
• 이후 push/pull/branch 작업을 바로 할 수 있는 로컬 작업 공간이 준비됨

 

그래서 저장소 URL을 어디서 확인하는데?

GitHub에서 레포지토리 페이지를 열면 오른쪽 위에 초록색 Code 버튼이 있음.

▶ Code 버튼 클릭

그러면 아래처럼 3가지 방식이 보임:

• HTTPS
• SSH
• GitHub CLI

일반적으로 대부분은 HTTPS URL을 사용해.

예시:https://github.com/팀장님계정/레포지토리이름.git

• [팀 전체] 모인 팀원들끼리 서로 몇 번째 파트에 자신을 소개하는 내용을 작성할지 함께 의논합니다.
• [팀 전체] 팀원간 협의된 작업 일정 내용을 README.md 파일에 수정해서 저장소에 함께 커밋합니다.

Git에서 커밋은 단순 저장이 아니고, 내가 변경한 내용을 Git 히스토리에 공식적으로 기록하는 행위.

즉, Git에 “이 시점에 이런 수정이 있었음” 이라고 스냅샷을 남기는 것.

1) README.md 수정

작업 일정 → 역할 분담 → 내용 정리해서 파일 고침

2) Git에 변경된 파일 등록(add)

 

git add README.md

 

EX)회사메일을 받을떄 파일명으로 보내는 신입사원의 모습

3) 변경 내용을 기록(commit)

 

git commit -m "README 업데이트: 팀 작업 일정 및 역할 분담 추가"

이 순간 “버전 하나 생성됨”.

 

EX)그걸 방지하고자 강제로 어떤내용인지 쓰라고 하는것

4) GitHub(원격저장소)에 업로드(push)

 

git push origin main

• 커밋 = 작업 내용을 Git 히스토리에 기록하는 공식 저장
• “작업한 변경을 버전 관리 시스템에 남기는 행위”
• 팀원이 나중에 뭐가 바뀌었는지 다 볼 수 있음
• 커밋 없이는 push도 못 함 (push는 커밋을 올리는 거라)

 

[문제] 커밋을 통해 깃에 하나의 기록을 남기는데 푸쉬랑은 정확히 무슨차이?

[해결]

커밋(commit)과 푸시(push)의 저장 위치

• 커밋(commit)
  • 로컬 Git 히스토리에 기록됨
  • 내 컴퓨터 안에만 존재
  • GitHub 등 원격 저장소에는 아직 없음
• 푸시(push)
  • 로컬 Git 히스토리에 있는 커밋을 원격 저장소(GitHub)로 전송
  • 그래야 팀원들이 볼 수 있음

 

• add만 하고 commit 안 하면
  • 변경 사항이 스테이징 영역에 있음
  • 커밋으로 기록하지 않았기 때문에 언제든 수정 가능
  • 다른 사람이 볼 수도 없고 push도 불가
• 즉, add는 ‘커밋 대기열에 올리는 것’, commit은 ‘기록하는 것’, push는 ‘팀과 공유하는 것’

 

 

2. 나만의 작업 공간 만들기 (Branch)

1️⃣ 목적

• '메인 무대'(main 브랜치)를 바로 건드리면 위험해요! ->파일 작업을 할때 본파일 두고 복사해서 자료를 수정하는것
• 팀원들이 협업하는 저장소에 '개인 연습실'(개인 브랜치)에서 안전하게 나만의 코드를 수정하고 기능을 추가하기 위한 독립적인 공간을 확보하는 것이 목표입니다.
• 이게 바로 협업의 가장 기본이 되는 규칙이에요!

2️⃣ 구현 내용

• git checkout -b feature/내이름 또는 git branch feature/내이름 후 git checkout feature/내이름 명령어를 사용해, 나만의 새로운 브랜치를 만들고 그 브랜치로 바로 이동(checkout)합니다.
  • 또는 최근에 git switch 라는 커맨드를 통해 작업을 수행하는 것도 가능해서, 신규 명령어를 사용해 작업해보시는 것도 좋아요.
  • git switch -c feature/내이름 라고 하면 브랜치 생성과 동시에 이동까지 가능합니다.
• 이제부터 내가 수정할 코드 작업은 모두 이 feature/내이름 브랜치 안에서만 진행합니다. (마음껏 수정하고 저장해도 main은 안전해요!)

브랜치(branch) 관련 명령어 핵심

1️⃣ 브랜치란?

• Git에서 독립적인 작업 공간
• 팀 프로젝트에서 내 작업을 다른 사람 작업과 분리해서 진행할 때 사용

---

2️⃣ 브랜치 만들고 이동

명령어의미

git branch feature/내이름	새 브랜치 생성 (하지만 아직 이동 안 됨)
git checkout feature/내이름	해당 브랜치로 이동
브랜치 생성과 이동을 한번에 하고 싶을 때	git checkout -b feature/내이름
Git 최신 명령어	git switch -c feature/내이름 → 브랜치 생성 + 이동 동시에

 

---

3️⃣ 쉽게 비유하면

• master/main : 공용 작업 방
• feature/내이름 : 나만의 작업 방
• 브랜치를 만들고 들어가면 → 내 방에서 마음껏 작업 가능
• 끝나면 → merge 해서 공용 방에 반영

---

즉, “새 브랜치 만들고 거기로 바로 이동” = 내 전용 작업 공간 만들어서 들어가는 것

 

git checkout -b vs git switch -c

항목git checkout -b feature/내이름git switch -c feature/내이름

기능	브랜치 생성 + 이동	브랜치 생성 + 이동
목적	기존 Git 명령어 방식	새롭고 명확한 문법, 브랜치 작업 전용
사용성	체크아웃은 브랜치 전환, 파일 복원 등 다른 기능도 같이 있어서 헷갈림	브랜치 생성/전환에만 초점, 훨씬 직관적
추천	예전 Git 문서나 강의에서 자주 사용	최신 Git에서는 switch 사용 권장

 

---

2️⃣ 쉽게 비유하면

• checkout = “방 문을 열고 들어가기 + 청소도 가능”
• switch = “방 문을 열고 들어가기만”

즉, switch는 브랜치 전환/생성 전용 명령어라서 의도 명확, 실수 확률 적음

---

✅ 핵심 요약

• 둘 다 브랜치 만들고 이동 가능
• 차이점: switch가 더 직관적이고 브랜치 관련 기능만 있음
• 최신 Git에서는 switch 쓰는 게 깔끔하고 권장

 

• git switch -c 브랜치이름 → 새 브랜치 만들고 바로 들어가기
• 파일 청소(바꾼 내용 되돌리기) 하고 싶으면 → git restore 파일이름
• 즉, switch는 브랜치 이동 전용, restore는 파일 초기화 전용

 

 

# 작업 힌트 # 다만, 본 강의 내용과 차이가 있는 것은 1명의 브랜치만 생성되는게 아니고, # 동시에 여러 사람의 브랜치가 생성될 때 작업 영향도를 생각해보면 좋습니다. # 내 수정 부분에 다른 사람 작업이 영향주지는 않겠지? # 또는 다른 사람 작업이 내 수정 부분에 영향 주진 않겠지?

 

3. "제 작업 다 끝났어요!" (Pull Request, PR)

1️⃣ 목적

• 브랜치에서 완료한 작업을 메인에 합치기 전에, 팀원들에게 "제가 이런 작업을 완료했는데, 한번 검토해주시고 합쳐주세요!"라고 공식적으로 요청하는 것입니다.
• 내가 뭘 했는지 알리고, 팀원들의 검토를 받는 과정이에요.

• git add <파일이름>

로컬 공간에서 작업중인 변경사항을 stage area 로 임시로 저장하는 명령어

 

 

• git commit -m "로그 내용"

stage area 에 임시 저장된 내용을 원격 저장소에 저장하기 바로 전 상태로 만드는 단계로, commit 작업이 없을 경우 원격 저장소에 코드를 업로드할 수 없음

 

 

• git status

현재 git add를 통해 stage area 에 저장되어 있는 변경사항 상태를 확인 가능

 

 

• git log

현재 git 저장소에서 commit 된 기록들을 확인 가능

 

 

• git branch <생성할 브랜치이름>

가지라는 뜻 대로 현재 작업중인 개발 공간에서 추가적인 가지를 생성하여 업무 영역이 겹치지 않게 분리해주는 역할을 함.

 

 

• git checkout <브랜치이름>

명령어 뒤에 적힌 브랜치 작업공간으로 이동하라는 명령어

 

 

• git merge <브랜치이름>

현재 checkout 된 작업 공간에 <브랜치이름>에 해당하는 브랜치의 데이터를 합침

 

 

• git rebase <브랜치이름>

<브랜치이름>에 해당하는 브랜치의 데이터를 베이스로 현재 작업중인 commit 동작을 다시 수행하여 커밋 기록 정리 및 작업 공간 최신화를 하는 기능을 함.

 

 

• git cherry-pick <다른 브랜치의 커밋 해시 값>

현재 checkout 된 작업 공간에  <다른 브랜치의 커밋 해시 값> 에 해당하는 커밋을 적용

 

 

• git clone <Github repository url 주소>

해당 주소의 데이터를 내 로컬 저장소에 복사해옴. 이 경우 원격 저장소와 자동으로 연결이 되어서 저장소 init 과정이 필요없음

 

 

• git pull <원격 저장소 이름> <브랜치 이름> 

해당 원격 저장소의 브랜치 이름에 해당하는 브랜치 정보를 로컬 저장소로 다운로드하여, 현재 checkout 되어있는 브랜치와 병합 (fetch 후 merge 동작까지 자동으로 진행)

 

 

• git fetch <원격 저장소 이름> <브랜치 이름> 

해당 원격 저장소의 브랜치 이름에 해당하는 브랜치 정보를 로컬 저장소로 다운로드함( 현재 로컬 작업 공간에 반영 되는 것이 아니라 별도의 공간에 저장됨). 브랜치 이름이 생략될 경우 해당 원격 저장소의 모든 브랜치 데이터를 가져옴

 

2️⃣ 구현 내용

• 내 브랜치에서 작업이 끝나면, git add . → git commit -m "작업 내용 요약"으로 내역을 깔끔하게 저장(커밋)합니다.
• git push origin feature/내이름 명령어로 내 브랜치와 커밋 내역을 GitHub(원격 저장소)에 올립니다.

origin=연결된 원격저장소의 주소(깃허브에 있는 레포지토리의 주소)

git push origin feature/내이름->git push <원격 저장소 이름> <브랜치 이름> ->origin주소에 있는 브랜치 이름으로 전송해라

• GitHub 저장소 페이지로 가서, 'Pull Request' 탭에서 "New Pull Request" 버튼을 눌러 PR을 생성합니다. (합쳐질 곳: main ← 내가 작업한 곳: feature/내이름)
• PR 제목과 본문에 내가 어떤 작업을 했는지, 왜 했는지 팀원들이 알기 쉽게 설명을 자세히 작성합니다.
• 리뷰를 수행할 대상자를 PR에서 Reviewers 목록에 추가합니다.

# Pull Request 포맷 예시

🚀 어떤 작업을 하셨나요? (작업한 내용에 대해 간단히 설명해주세요. 예: '팀원 2 박 디자인 소개 페이지 수정')

🛠️ 주요 변경 사항

[ ] (변경 사항 1: 예: '기술 스택 범위 수정')

[ ] (변경 사항 2: 예: '팀원 2 프로필 이미지 추가')

[ ] (변경 사항 3)

📸 스크린샷 (선택) (UI 변경이 있다면, 변경 전/후 스크린샷을 첨부하면 좋습니다!)

✅ 셀프 체크리스트 (PR 올리기 전 스스로 확인해주세요!)

[ ] (팀원에게) 리뷰를 요청했나요?

 

4. 팀원의 작업 검토하고 합치기 (Code Review & Merge)

1️⃣ 목적

• 팀워크의 꽃! 🌸 동료의 코드를 함께 보면서 더 좋은 방향은 없는지 의견을 나누고(코드 리뷰), 혹시 있을지 모를 실수를 미리 찾아내어 더 완성도 높은 프로젝트를 만드는 것이 목표입니다.
• 한 가지 더 확인해주면 좋을 것이, 동시에 여러 개의 PR이 올라왔을 때 어떤 팀원의 PR 부터 합쳐나갈 것인지도 함께 고민해주시면 좋습니다.

2️⃣ 구현 내용

• 팀원이 올린 PR에 들어가 "Files changed" 탭을 눌러 변경된 코드를 꼼꼼히 확인합니다.
• 코드 라인 옆에 '+' 버튼을 눌러 "오, 이 부분 좋네요!" 또는 "여기는 이렇게 바꾸는 게 어떨까요?" 같은 코드 리뷰 댓글을 자유롭게 남깁니다.->피니쉬 리뷰 코맨트를 남기는게 최종적으로 리뷰를 완료하였다 라는 메세지 전달이 가능했다.
• [팀장] 리뷰가 끝나고 모두가 코멘트를 남기고 LGTM (Looks good to me)를 남기면, PR 페이지에서 초록색 "Merge pull request" 버튼을 눌러 팀원의 코드를 main 브랜치에 안전하게 합칩니다.->원래는 권한설정이 가능하나 과제때는 권한을 설정하지 못해 모든 팀원이 머지할수 있었다.(머지 방지도 중요하다)

5. 공통 파일 수정하고 충돌 경험하기

1️⃣ 목적

• (충돌을 의도적으로 일으켜보세요!) 여러 사람이 index.html처럼 공통으로 쓰는 파일을 동시에 수정했을 때 어떤 일이 벌어지는지, 즉 '충돌(Conflict)'이 왜, 어떻게 발생하는지 그 원인을 직접 경험해보는 것이 목표입니다.
• 공통 파일은 index.html 파일이 아니라 README.md 등 프로젝트 소개 페이지의 특정 라인을 동시에 편집해서 충돌을 만들어보아도 괜찮습니다.
• 중요한건 “공통 편집 부분”에 대해 어떻게 충돌을 해결해 나갈지를 확인해 나가는 과정이에요.

2️⃣ 구현 내용

• 이번에는 내 개인 브랜치가 아닌! main 브랜치에서 직접 index.html 파일의 <title> 태그 내용 같은 공통 부분을 수정합니다. (예: 팀 소개 -> 우리팀 소개)
• 수정 내용을 git commit 합니다.
• git push origin main으로 GitHub에 바로 올려버립니다.

로컬 main보다 GitHub main이 더 최신이라서 (가장 흔함)

즉:

• GitHub(main)이 더 앞서 있음
• 너 로컬(main)은 뒤쳐짐
• 그래서 GitHub이 “너 뒤쳐졌는데 밀어버리면 덮어씌우는 거라서 안됨” 하고 막는 것

• 커밋 순서에 따라 reject 에러 문구가 발생할 수 있습니다.
• 그 경우, git pull origin main을 통해 main 브랜치를 최신화 시켜 conflict를 로컬에서 확인합니다.

# 아래와 같은 비슷한 메세지가 나오면, 정상적으로 충돌 상황을 생성한 것입니다. # <<<<<<< HEAD, =======, >>>>>>> 브랜치명 # 충돌이 발생했을 때, 수정 내용을 합칠지 기존 내용을 유지할지 각 팀에서 자유롭게 논의하고 합쳐봅니다.

 

도전기능

1. 의도적 충돌 발생시키기 ⭐⭐⭐

1️⃣ 목적

• 협업 시 가장 흔하게 발생하는 '머지 충돌(Merge Conflict)'이 대체 왜, 어떤 상황에서 일어나는지 그 원인을 직접 몸으로(...) 경험하고 이해하는 것이 목표입니다.
• 필수기능 5에서 수행한 것과 약간 차이는 이번엔 브랜치에서 작업한 내용을 main으로 병합하는 과정을 가정한 것이에요.
• 무서워 마세요! 일부러 터뜨려 보는 거예요!

2️⃣ 구현 내용

• (상황 선택하기) 아래 3가지 시나리오에 따른 예제 저장소 코드의 index.html에서 의도적으로 충돌을 발생시키는 내용이 구성되어 있습니다.
  • 시나리오 1: CSS 스타일 충돌
  • 시나리오 2: JavaScript 함수 수정 충돌
  • 시나리오 3: HTML 구조 변경 충돌
• (충돌 발생)
  • 각 시나리오에 따라 팀원 A, B의 충돌 시나리오를 실습하고 충돌을 해결해 나가는 과정을 수행합니다.
  • 팀원이 2명을 넘어간다면, 각 실습을 돌아가면서 한 번씩 수행해보시는 것을 권장 드립니다.
• 그 후, 팀원 B가 자신의 PR을 Merge 하려고 시도하면... GitHub가 "앗, 같은 곳을 다르게 수정했네요! 충돌 발생!" (Conflict!) 메시지를 띄우게 됩니다.

시나리오 개요
- 팀 프로젝트에서 index.html 파일을 여러 팀원이 동시에 수정하는 상황을 가정합니다.

시나리오 1: CSS 스타일 충돌

상황
- 개발자 A: --main-font-color 변수 값을 #222425에서 #1a1a1a로 변경
- 개발자 B: 같은 변수를 #000000로 변경

충돌 발생 전 (원격 저장소)
:root {
    --main-font-color: #222425;
}

개발자 A의 변경사항 (로컬)
:root {
    --main-font-color: #1a1a1a;  /* 더 부드러운 검정 */
}

개발자 B의 변경사항 (로컬)
:root {
    --main-font-color: #000000;  /* 순수 검정 */
}

충돌 발생 시 Git 표시
:root {
<<<<<<< HEAD
    --main-font-color: #1a1a1a;
=======
    --main-font-color: #000000;
>>>>>>> feature/dark-theme
}

충돌 마커 설명:
- <<<<<<< HEAD: 현재 브랜치(로컬)의 변경사항
- =======: 구분선
- >>>>>>> feature/dark-theme: 병합하려는 브랜치의 변경사항

시나리오 2: JavaScript 함수 수정 충돌

상황
- 개발자 A: loadTeamMembers() 함수에 에러 핸들링 개선
- 개발자 B: 같은 함수에 로딩 애니메이션 추가

충돌 발생 전
async function loadTeamMembers() {
    const container = document.getElementById('team-container');
    container.innerHTML = '<div class="loading">팀원 정보를 불러오는 중...</div>';
    
    try {
        const membersListResponse = await fetch('members/members.json');
        // ... 나머지 코드
    } catch (error) {
        console.error('Error loading team members:', error);
    }
}

# 개발자 A의 변경사항
async function loadTeamMembers() {
    const container = document.getElementById('team-container');
    container.innerHTML = '<div class="loading">팀원 정보를 불러오는 중...</div>';
    
    try {
        const membersListResponse = await fetch('members/members.json');
        // ... 나머지 코드
    } catch (error) {
        console.error('Error loading team members:', error);
        container.innerHTML = '<div class="error">팀원 정보를 불러오는 중 오류가 발생했습니다. 잠시 후 다시 시도해주세요.</div>';
        // 에러 재시도 로직 추가
        setTimeout(() => loadTeamMembers(), 3000);
    }
}

# 개발자 B의 변경사항
async function loadTeamMembers() {
    const container = document.getElementById('team-container');
    // 로딩 애니메이션 추가
    container.innerHTML = '<div class="loading"><div class="spinner"></div>팀원 정보를 불러오는 중...</div>';
    
    try {
        const membersListResponse = await fetch('members/members.json');
        // ... 나머지 코드
    } catch (error) {
        console.error('Error loading team members:', error);
    }
}

# 충돌 발생 시
async function loadTeamMembers() {
    const container = document.getElementById('team-container');
<<<<<<< HEAD
    container.innerHTML = '<div class="loading">팀원 정보를 불러오는 중...</div>';
=======
    // 로딩 애니메이션 추가
    container.innerHTML = '<div class="loading"><div class="spinner"></div>팀원 정보를 불러오는 중...</div>';
>>>>>>> feature/loading-animation
    
    try {
        const membersListResponse = await fetch('members/members.json');
        // ... 나머지 코드
    } catch (error) {
        console.error('Error loading team members:', error);
<<<<<<< HEAD
        container.innerHTML = '<div class="error">팀원 정보를 불러오는 중 오류가 발생했습니다. 잠시 후 다시 시도해주세요.</div>';
        setTimeout(() => loadTeamMembers(), 3000);
=======
>>>>>>> feature/loading-animation
    }
}

시나리오 3: HTML 구조 변경 충돌

상황
- 개발자 A: 팀 제목 텍스트 변경
- 개발자 B: 같은 영역에 아이콘 추가

충돌 발생 전
<div class="team-header">
    <h1 class="team-title font-bold">팀원 소개</h1>
    <p class="team-subtitle font-regular">함께 성장하는 우리 팀을 만나보세요</p>
</div>

개발자 A의 변경사항
<div class="team-header">
    <h1 class="team-title font-bold">우리 팀을 소개합니다</h1>
    <p class="team-subtitle font-regular">함께 성장하는 우리 팀을 만나보세요</p>
</div>

개발자 B의 변경사항
<div class="team-header">
    <h1 class="team-title font-bold">
        <span class="icon">👥</span>
        팀원 소개
    </h1>
    <p class="team-subtitle font-regular">함께 성장하는 우리 팀을 만나보세요</p>
</div>

충돌 발생 시
<div class="team-header">
    <h1 class="team-title font-bold">
<<<<<<< HEAD
        우리 팀을 소개합니다
=======
        <span class="icon">👥</span>
        팀원 소개
>>>>>>> feature/add-icons
    </h1>
    <p class="team-subtitle font-regular">함께 성장하는 우리 팀을 만나보세요</p>
</div>

 

2. 꼬인 코드 풀어내기 (충돌 해결하기) ⭐⭐⭐⭐

 

1️⃣ 목적

• 위에서 발생시킨 충돌(Conflict)을 '해결'하는 방법을 배우는 것이 목표입니다.
• 개발자의 핵심 역량 중 하나죠! 당황하지 않고 어떤 코드를 남기고, 어떤 코드를 버릴지 결정해서 꼬인 매듭을 푸는 방법을 배웁니다.

2️⃣ 구현 내용

• (방법 1: GitHub에서 해결) GitHub의 Pull Request 페이지에 나타나는 "Resolve conflicts" 버튼을 누릅니다.
  • 충돌이 난 부분을 보여주는 github 편집기에서 <<<<< , >>>>> , ===== 기호들을 모두 지우고, 남기고 싶은 최종 코드만 남도록 수정한 뒤 "Mark as resolved"를 누릅니다.
• (방법 2: 로컬에서 해결) 내 PC에서 git pull origin main을 실행해 main의 최신 코드를 가져오면 내 로컬에서 충돌이 납니다.
  • 이 때 VScode 같은 툴에서 충돌 부분(<<<<< , >>>>> , =====)을 직접 수정한 뒤, git add . -> git commit으로 충돌을 해결했다는 새 커밋을 만듭니다.
  • 그리고 자신의 feature 브랜치로 push 해줍니다.

 

3. "내 작업, 최신 무대에 올리기!" (Rebase로 브랜치 정리) ⭐⭐⭐⭐⭐

1️⃣ 목적

• 내가 작업하는 동안 main 브랜치에 다른 팀원들의 코드가 잔뜩 합쳐졌을 때, 내 작업물을 그 최신 코드 '위에' 깔끔하게 다시 쌓는 방법을 배웁니다.
• Merge 대신 Rebase를 쓰면 커밋 내역(History)이 한 줄로 깔끔하게 정리되는 효과가 있어요.

협업 관점에서 merge vs rebase 차이

🔹 1) merge는 기록을 절대로 안 바꿈 → 협업 안전 기존 커밋을 건드리지 않음. 새로운 merge 커밋 하나만 추가됨. 그래서 팀원 누구랑 작업하든 문제가 거의 없음.

👉 협업 규모가 크면 대부분 merge를 쓴다.

🔹 2) rebase는 내 커밋 히스토리를 바꿈 → 협업 주의 필요 feature 브랜치의 커밋들이 “다른 커밋으로 다시 만들어짐”. 로컬에서만 바꿀 때는 문제 없는데, 이미 GitHub에 push 된 상태에서 rebase 해버리면? ➡ 팀원들이 가진 커밋과 기록이 어긋남(= 히스토리 충돌) ➡ 강제로 push --force 해야 하고, 실수하면 팀원 작업도 꼬일 수 있음.

👉 협업에서는 절대 main이나 공유 브랜치에서 rebase 금지.

👉 본인 개인 feature 브랜치에서만 조심해서 사용.

🔥 핵심 요약 (협업 기준)

✔ merge 히스토리 안 건드림 안전 기록 조금 지저분해도 상관 없음 협업 친화적(대부분 이걸 기본으로 씀)

✔ rebase 히스토리 깨끗해짐 대신 커밋 자체가 다시 만들어져서 공유된 브랜치에 쓰면 팀원들 히스토리 꼬임 개인 작업 브랜치에서만 안전하게 사용 가능

✨ 결론 (협업 관점 단 한 줄)

👉 협업이면 기본은 merge, rebase는 본인 feature 브랜치를 깔끔하게 정리할 때만.

 

 

                                                 왼쪽은 rebase, merge 전 / 중앙은 merge 후 / 오른쪽은 rebase 후

 

2️⃣ 구현 내용

• 내 개인 브랜치(feature/내이름)에서 작업 중입니다.
• git fetch origin으로 main의 최신 내역을 일단 가져옵니다.
• git rebase origin/main 명령어를 실행합니다.
• 이 명령은 "내 브랜치의 시작점을 main의 최신 지점으로 옮기고, 그 위에 내 커밋들을 차곡차곡 다시 쌓아줘!"라는 의미입니다. (이때도 충돌이 날 수 있으며, 해결해야 합니다!)
• rebase를 수행하는 커밋 갯수는 각 팀의 팀원별로 커밋을 몇 개를, 어떻게 했느냐에 따라 약간씩 차이가 존재할 수 있습니다!

 

4. "커밋은 깔끔하게!" (Squash로 커밋 합치기) ⭐⭐

 

1️⃣ 목적

• "오타 수정", "CSS 살짝 변경", "아, 이거 빼먹었네" ... 이렇게 자잘하게 쌓인 여러 개의 커밋들을, main에 합칠 때는 "회원가입 기능 완성!" 같은 의미 있는 커밋 하나로 합쳐서 넣는 방법을 배웁니다.
• main 브랜치의 커밋 내역을 깨끗하게 관리할 수 있습니다.->오타나 다른 팀원들이 굳이 보지않아도 되는 사소한 수정일 경우 공지를 하고 사용을 해야한다.

2️⃣ 구현 내용

• 내 Pull Request(PR)가 코드 리뷰까지 모두 통과한 상태입니다.
• main 브랜치 관리자가 "Merge pull request" 초록색 버튼 옆의 작은 화살표를 누릅니다.
• 여러 옵션 중 "Squash and merge"를 선택합니다.
• "회원가입 기능 완성"처럼 이 PR을 대표하는 커밋 메시지 하나로 요약해서 작성한 뒤, Merge를 확정합니다.

5. "앗, 방금 커밋 실수!" (commit --amend 로 수정하기) ⭐

1️⃣ 목적

• 방금 막 git commit을 했는데, 오타를 발견했거나, 파일 하나를 빼먹었을 때! "아차!" 싶을 때 쓰는 기술입니다.
• 새 커밋을 추가하는 게 아니라, '방금 한 마지막 커밋을 수정'하는 방법을 배웁니다. (단, 이미 push 한 커밋에는 절대 쓰면 안 돼요!)

commit --amend ->사용하면 vim으로 입장하여 수정을 완료한다.

 

2️⃣ 구현 내용

• 방금 "공통 파일 수정"이라고 커밋했는데, 오타가 났거나 index.html 파일을 커밋할 때 빠뜨린 것을 발견했습니다.
• 빠뜨린 파일을 git add index.html로 추가합니다.
• 그 다음, 새 커밋을 하는 대신 git commit --amend 명령어를 입력합니다.
• 커밋 메시지 수정 창이 뜨면 메시지를 고치거나, (파일만 추가할 거면) 그냥 저장하고 닫습니다.
• 이렇게 하면 새 커밋이 생기는 게 아니라, 방금 전 커밋이 '업데이트'됩니다.

 

 

 

 

여기까지 리마인드.

--------------------------------------------------------------------------------------------------------------------------------------------------

 

 

 

 

 

 

 

 

• 과제명 : 협업으로 팀 소개 페이지 만들기
• 팀번호 : 5조
• 2기 제출자 : 2기 윤민기 외 4명
• 팀 레파지토리 링크 : https://github.com/minky5004/sparta-git.git

✅ 필수 기능

(1) 우리팀 저장소 복제 (Clone) & 계획 짜기

• README.md 파일에 작성한 내용을 아래에 복사하여 붙여넣어 주세요.

# 팀원 소개 페이지

Git 커밋 협업을 통한 팀원 소개 페이지 프로젝트입니다.
### 팀원 정보 추가 예시

```bash
# 1. 브랜치 생성
git checkout -b add-member-kim

# 2. 템플릿 복사 (프론트엔드 개발자인 경우)
cp members/member1.json members/kim.json

# 3. JSON 파일 수정
# members/kim.json 파일을 열어 본인 정보로 수정

# 4. members.json 업데이트
# members/members.json에 "kim.json" 추가

# 5. 커밋 및 푸시
git add members/kim.json members/members.json
git commit -m "Add: 김철수 팀원 정보 추가"
git push origin add-member-kim
```

### 템플릿별 역할 안내

- **member1.json** 윤민기: 프론트엔드 개발자 - Python 중심
- **member2.json** 서하나: 백엔드 개발자 - Python 중심
- **member3.json** 전민우: UI/UX 디자이너 - Figma, 중심
- **member4.json** 정은식: 풀스택 개발자 - HTML, CSS 모두
- **member5.json** 함형우: 데이터 분석가 - Python, SQL, 머신러닝 중심

본인의 역할과 가장 유사한 템플릿을 선택하여 수정하시면 됩니다!

## 문의

프로젝트 관련 문의사항이 있으면 이슈를 생성해주세요.

(2) 나만의 작업 공간 만들기

• 여러분의 팀장이 만들어준 레파지토리의 main 브랜치에서 각자의 이름으로 생성한 브랜치 정보가 보이도록 화면을 캡쳐해 제출합니다.
• 제출 이미지

(3) 제 작업 다 끝났어요! PR 올리기

• 여러분의 브랜치에서 작업이 잘 되었다면 팀장님의 깃헙에 코드를 커밋합니다.
• 제출 이미지

 

(4) 코드 합치기 (Code Review & Merge)

• merge 되어 있는 PR 화면을 캡쳐해 제출합니다.
• 제출 이미지

 

(5) 공통 파일 수정하고 충돌 경험하기

• 충돌을 확인한 내역을 캡쳐해서 제출합니다.
• 제출 이미지

 

 

 

🚀 도전 기능

(1) 의도적 충돌 발생시키기

• A와 B 개발자 2명이 ecommerce-기수-team-N-main 브랜치에 변경 사항을 필수 기능 5번과 같이 충돌 시나리오 3개 중 한 개를 선택해서 충돌을 발생시킵니다.
• 선택한 시나리오로 충돌이 발생한 화면을 캡쳐해서 제출합니다.

시나리오 1 : CSS 변경

(2) 꼬인 코드 풀어내기 (충돌 해결하기)

• 제출할 과제 내용은 총 2개입니다.
• 충돌이 발생한 화면을 캡쳐해서 제출합니다.
• 충돌을 해결한 뒤, push한 결과 화면을 캡쳐해서 제출합니다.
• 변경 내역은 main으로 merge 하지 말아주세요! 도전과제 4번에서 squash라는 기능을 이용해 merge할 예정입니다.

333425색상과 111425색상을 변경하던 도중 충돌발생

 

(3) "내 작업, 최신 무대에 올리기!" (Rebase로 브랜치 정리)

• 필수 과제 5번 등의 수행으로 현재 main 브랜치는 수강생님의 feat/내이름 보다 최신화 되어 있을꺼에요.
• 브랜치 지점을 main의 최신 지점으로 변경합니다.
• 변경 사항들을 반영해 feat/내이름 브랜치를 최신화시키고 intelliJ의 git 화면을 캡쳐해서 제출합니다.

 

commit 해놓았던 데이터는 남겨두고 없던 데이터들이 받아왔다.

(4) "커밋은 깔끔하게!" (Squash로 커밋 합치기)

• 도전 과제 2번에서 수행한 ecommerce-기수-team-N-main 브랜치의 PR을 squash로 main브랜에 merge하면 아래와 같은 화면이 출력됩니다.
• squash and merge는 Pull Request화면 하단에 아래를 가리키는 화살표로 선택할 수 있고, 이 화면을 실행한 뒤, 합쳐지는 PR 결과를 캡쳐해서 제출합니다.

(5) "앗, 방금 커밋 실수!" (commit --amend 로 수정하기)

• 아래와 같이 commit --amend 를 수행한 뒤의 커밋 메세지를 변경하고 반영된 git log 화면을 제출합니다.

- 아래와 같이 기존 커밋이 수정되어 반영된 화면을 캡쳐해서 제출합니다.

 

 

:단순한 협업툴 정도로 생각하였지만, 깃역시 많은 기능과 규칙이 있었다. 좀더 많이 학습하여 숙련도를 올려야겠다 라는 생각이 든다. 오늘 이외 시간에도 틈틈이 사용하며 숙련도를 일정수준 이상 올려 협업에 문제가 되지않도록 해야겠다.

 

 

 

튜터님 피드백

# 필수

1. 우리팀 저장소 복제 - 원본 저장소 clone 및 새로운 공용 원격지 저장소를 생성하고 정상적으로 template 을 push - README.md 에서 진행 방법 및 작업 범위 확인 README.md 파일은 프로젝트의 설명서로 목적, 설치방법, 사용방법, 개발환경/설정 을 담고 있는 파일로 프로젝트를 처음 접하는 인원의 이해를 돕고자 작성되는 파일 입니다. 요구에 맞게 작업범위를 명확하게 결정하고 진행하였네요.

2. 나만의 작업 공간 - 인원별 Branch 확인 - Branch Merge Commit 확인 과제 요구에 맞게 feature/{name} 형태의 Branch naming 을 사용하여 일관성을 유지하였습니다. 프로젝트가 시작 전에 반드시 git convention과 coding convention 을 확정하고 convetion이 맞지 않은 경우 code review 를 통해 팀원간 검증하고 피드백 하는 것은 매우 중요한 과정입니다.

3. PR - PR log 확인 - Reviewer 확인할 commit message prefix로 일관성을 유지하고 있습니다. 아주 좋습니다. pr template 에 대한 다양한 시도를 확인하였습니다. 공통으로 사용되는 template은 .github 하위에 파일을 만들어 두면 좋습니다. 아래 링크 참고해서 pr template 을 만들어 보세요. 또는 pr template 이라는 키워드로 검색해 보세요. https://docs.github.com/ko/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository https://github.com/axolo-co/pull_request_template

4. Code Review & Merge - Code Review Comments 일부 확인 - Merge Commit 확인

5. Conflict - 내역 확인 Conflict 상황과 단계별 해결과정을 잘 정리하였습니다.

 

# 도전

1. 의도적 충돌 - 필수 5 Conflict 에서 처리한 내용으로 갈음 합니다.

2. 꼬인 코드 풀어내기 - 필수 5 Conflict 에서 처리한 내용으로 갈음 합니다.

3. Rebase & Merge - rebase 과정까지는 확인하였습니다. - rebase 후 main branch 에 merge 하는 과정이 확인되지 않습니다. git log를 확인해 보았는데 rebase commit 된 기록이 확인되지 않습니다. rebase 하면서 commit 이 새로 생성되었다던가 log graph 에서 rebase로 재정렬된 흔적을 볼 수 없습니다. rebase 후 merge 하는 과정을 시도해 보세요.

4. Squash & Merge - squash & merge 과정 확인 Squash & Merge 는 여러 단위의 commit이 존재하는 Branch를 PR Merge 하는 과정에서 하나의 commit 으로 정리하는 방식 입니다. 제출된 이미지에서 여러 단위의 commit 이 통합된 description이 확인되지 않습니다. 한개의 branch 에서 여러단계의 commit 을 진행 한 후 squash & merge 를 이용하여 하나의 commit 으로 재정리 하는 과정을 실제 진행해 보세요.

5. commit --amend - 제출된 이미지는 rebase 와 관련한 내용으로 commit 메시지 변경과는 관련없어 보입니다. # 트러블 슈팅 - 각 인원의 트러블 슈팅 링크를 취합해 주셔야 했는데.. 한분의 링크만 확인됩니다. - 과제 수행과정과 초대 수락 등의 내용을 확인 하였습니다. 다음에는 좀더 구체적인 이슈 내역과 이슈분석, 원인파악, 해결과정 으로 작성해 보시면 좋겠습니다.