SK네트웍스 Family 엔코아 AI 오케스트레이션 프리코스 8｜GitHub 협업과 브랜치 활용

 

이번 프리코스에서는 Git을 혼자 사용하는 것을 넘어 원격 저장소의 코드를 가져오고, 여러 사람이 함께 작업하면서 발생하는 충돌을 해결하고, 브랜치를 활용하는 방법을 학습했다.

앞선 강의에서는 로컬 작업을 GitHub에 연결하고 변경사항을 확인하는 방법을 배웠다면, 이번에는 실제 협업 환경에서 Git을 어떻게 사용하는지에 초점을 맞췄다.

이번에 학습한 내용은 크게 세 가지였다.

• git clone을 이용한 원격 저장소 복제
• Git 협업 과정에서 발생하는 충돌과 해결 방법
• 브랜치를 이용한 독립적인 작업과 병합

---

1. GitHub의 저장소를 내 컴퓨터로 가져오기

앞선 강의에서는 로컬에서 작업한 프로젝트를 GitHub에 연결하는 과정을 배웠다.

이번에는 반대 방향의 작업을 배웠다.

이미 GitHub에 만들어져 있는 프로젝트를 다른 사람이 내 컴퓨터로 가져와 작업하려면 Repository를 복제(Clone) 해야 한다.

git clone 저장소주소

예를 들어 GitHub Repository 주소가 다음과 같다면,

git clone https://github.com/example/project.git

명령어를 실행하면 원격 저장소의 파일과 Git 관리 정보가 내 컴퓨터에 함께 내려온다.

여기서 중요한 점은 git clone을 실행하면 단순히 파일만 다운로드하는 것이 아니라 Git 저장소로 사용할 수 있는 상태까지 만들어진다는 것이다.

따라서 이미 GitHub에 존재하는 프로젝트를 가져오는 경우에는 보통 다음과 같이 다시 실행할 필요가 없다.

git init
git remote add origin ...

clone 과정에서 원격 저장소와 연결된 Git 저장소가 만들어지기 때문이다.

git clone과 git init의 차이

처음에는 둘 다 Git을 시작하는 명령처럼 보이지만 목적이 다르다.

git init

내 컴퓨터의 기존 폴더를 Git 저장소로 만들기

git clone

이미 존재하는 원격 저장소를 내 컴퓨터로 복제해서 작업하기

이 차이를 이해하는 것이 중요했다.

---

2. 협업에서는 왜 충돌이 발생할까?

여러 사람이 하나의 프로젝트를 함께 작업하면 자연스럽게 같은 파일을 수정하는 상황이 발생할 수 있다.

예를 들어 팀원 A와 B가 같은 파일을 가지고 작업한다고 생각해보자.

              GitHub
                │
        ┌───────┴───────┐
        ↓               ↓
      A의 PC           B의 PC
        │               │
     파일 수정        같은 파일 수정
        │               │
        └───────┬───────┘
                ↓
              Push

A가 먼저 변경사항을 GitHub에 Push한 뒤 B가 자신의 변경사항을 Push하려고 하면 문제가 발생할 수 있다.

Git 입장에서는 GitHub에 이미 새로운 변경사항이 있는데, B가 가지고 있는 코드에는 그 변경사항이 반영되어 있지 않기 때문이다.

이때 발생할 수 있는 것이 충돌(Conflict)이다.

---

3. Git의 충돌은 무엇을 의미할까?

처음에는 Conflict라는 단어 때문에 Git이 자동으로 코드를 망가뜨리는 것처럼 느껴질 수 있지만, 실제로는 조금 다르다.

Git이 어떤 변경사항을 선택해야 할지 자동으로 판단할 수 없는 상황이라고 이해하는 것이 쉽다.

예를 들어 같은 코드가 다음처럼 변경되었다고 해보자.

<<<<<<< HEAD
안녕하세요.
=======
반갑습니다.
>>>>>>> 다른 브랜치

이런 표시가 나타난다면 Git이 두 변경사항 중 어떤 것을 최종 코드로 사용할지 결정하지 못했다는 의미다.

개발자가 실제로 사용할 내용을 선택해서 충돌 표시를 제거해야 한다.

즉, 충돌 해결은 단순히 오류를 없애는 것이 아니라

두 사람이 변경한 내용을 확인하고 최종적으로 어떤 코드가 남아야 하는지 결정하는 과정

이라고 이해했다.

---

4. 충돌이 발생했을 때 확인해야 할 것

충돌이 발생하면 우선 Git이 어떤 파일에서 문제가 발생했는지 확인해야 한다.

git status

git status를 사용하면 충돌이 발생한 파일을 확인할 수 있다.

그다음 해당 파일을 열어 Git이 표시한 충돌 부분을 확인한다.

<<<<<<< HEAD
내가 작업한 내용
=======
다른 사람이 작업한 내용
>>>>>>> branch-name

여기서 실제로 남겨야 할 코드를 결정하고 충돌 표시를 제거한다.

그 후 다시 해당 파일을 Stage에 올리고 Commit하면 된다.

git add .
git commit -m "충돌 해결"

필요하다면 이후 GitHub에 Push한다.

git push

결국 충돌 해결 역시 기존에 배웠던 Git의 기본 흐름과 연결된다.

변경
 ↓
status / diff로 확인
 ↓
add
 ↓
commit
 ↓
push

---

5. 브랜치(Branch)란?

이번 강의에서 특히 중요하게 느껴진 개념은 Branch(브랜치)였다.

브랜치는 쉽게 말하면 하나의 프로젝트에서 작업 공간을 나누는 기능이라고 생각할 수 있다.

예를 들어 새로운 로그인 기능을 개발한다고 해보자.

현재 안정적으로 사용하고 있는 main 브랜치가 있다면 바로 main에서 코드를 수정하기보다는 별도의 브랜치를 만들 수 있다.

main
 │
 └── login

그리고 login 브랜치에서 로그인 기능을 개발한다.

이렇게 하면 새로운 기능을 개발하는 동안 기존 main 브랜치의 코드를 직접 변경하지 않고 작업할 수 있다.

---

6. 브랜치를 사용하는 이유

브랜치를 사용하는 가장 큰 이유는 작업을 서로 분리하기 위해서라고 이해했다.

예를 들어 한 프로젝트에서

• A → 로그인 기능 개발
• B → 회원가입 기능 개발
• C → UI 수정

을 동시에 진행한다고 생각해보자.

각자 별도의 브랜치에서 작업한다면 작업 내용을 어느 정도 독립적으로 관리할 수 있다.

              main
                │
        ┌───────┼────────┐
        ↓       ↓        ↓
      login   signup     UI

작업이 완료된 후 검토하고 필요한 경우 main에 합치는 방식으로 협업할 수 있다.

이 구조를 이해하고 나니 Git이 단순히 파일의 변경 이력을 저장하는 도구가 아니라 여러 사람이 하나의 프로젝트를 나눠서 작업할 수 있게 해주는 도구라는 점이 조금 더 명확해졌다.

---

7. 브랜치 생성과 이동

브랜치를 만들 때는 다음과 같은 명령을 사용할 수 있다.

git branch 브랜치이름

그리고 해당 브랜치로 이동한다.

git switch 브랜치이름

또는 브랜치를 생성하면서 바로 이동하는 방식도 사용할 수 있다.

git switch -c 브랜치이름

예를 들어 로그인 기능을 개발하기 위한 브랜치를 만든다면,

git switch -c feature/login

처럼 사용할 수 있다.

현재 어떤 브랜치에 있는지 확인하려면

git branch

를 사용할 수 있다.

---

8. 브랜치에서 작업한 내용을 합치기

브랜치에서 작업이 끝났다고 해서 자동으로 main에 반영되는 것은 아니다.

작업한 브랜치의 내용을 다른 브랜치에 합치는 Merge(병합) 과정이 필요하다.

예를 들어 feature/login에서 작업을 끝냈고 이를 main에 합치고 싶다면 먼저 main으로 이동한다.

git switch main

그리고 병합한다.

git merge feature/login

그러면 feature/login에서 작업한 내용이 main 브랜치에 합쳐진다.

이 과정에서도 서로 같은 부분을 다르게 수정했다면 Merge Conflict가 발생할 수 있다.

따라서 이번에 배운 브랜치와 앞에서 배운 충돌 해결은 서로 별개의 내용이 아니라 연결된 개념이었다.

---

9. 이번 프리코스에서 이해한 Git의 전체 흐름

이번 강의까지 학습하면서 Git의 전체적인 흐름을 이전보다 훨씬 구체적으로 연결할 수 있게 되었다.

혼자 작업할 때

파일 수정
 ↓
git status
 ↓
git diff
 ↓
git add
 ↓
git diff --staged
 ↓
git commit
 ↓
git push

GitHub 프로젝트를 처음 가져올 때

GitHub Repository
 ↓
git clone
 ↓
내 로컬 저장소
 ↓
파일 수정
 ↓
add
 ↓
commit
 ↓
push

팀으로 협업할 때

main
 ↓
브랜치 생성
 ↓
각자 작업
 ↓
commit
 ↓
push
 ↓
merge
 ↓
main에 반영

그리고 여러 사람이 같은 부분을 수정했다면

merge / pull
 ↓
Conflict 발생
 ↓
충돌 내용 확인
 ↓
코드 수정
 ↓
git add
 ↓
git commit
 ↓
git push

와 같은 과정으로 해결하게 된다.

---

10. 이번에 새롭게 이해한 점

이번 프리코스에서 가장 크게 달라진 부분은 Git 명령어를 개별적으로 외우는 것보다 각각의 명령어가 어떤 상황에서 필요한지 연결해서 이해하게 된 것이다.

앞에서는 git add, commit, push 같은 명령어를 각각 학습했다면, 이번에는 그것들이 실제 협업 과정에서 어떻게 이어지는지를 볼 수 있었다.

특히 git clone을 배우면서 GitHub에서 프로젝트를 가져오는 방향과 로컬 프로젝트를 GitHub에 올리는 방향이 서로 다르다는 점을 확실하게 구분할 수 있게 되었다.

또 브랜치를 배우면서 개발자가 작업할 때 항상 main에서 직접 코드를 수정하는 것이 아니라, 기능별로 작업을 분리하고 완료된 내용을 병합하는 방식으로 협업할 수 있다는 것도 이해하게 되었다.

---

11. 아직 더 익숙해져야 할 부분

아직 브랜치와 충돌 해결 과정은 실제 협업 상황에서 여러 번 경험해보면서 익숙해질 필요가 있다고 느꼈다.

특히 명령어 자체를 외우는 것보다

• 어느 시점에 pull을 해야 하는지
• 언제 새로운 브랜치를 만들어야 하는지
• Merge Conflict가 발생했을 때 어떤 변경사항을 남겨야 하는지
• 브랜치와 main의 관계를 어떻게 관리해야 하는지

같은 상황 판단이 더 중요하다고 생각한다.

결국 Git은 명령어를 많이 외우는 것보다 현재 로컬과 원격 저장소가 어떤 상태인지 파악하는 능력이 중요하다는 생각이 들었다.

---

핵심 정리

이번 프리코스에서는 Git을 개인 작업 도구에서 협업을 위한 도구로 확장해서 이해하는 과정을 학습했다.

핵심은 다음과 같다.

1. git clone을 사용하면 원격 Repository를 로컬로 복제할 수 있다.
2. 여러 사람이 같은 프로젝트를 작업하면 변경사항이 충돌할 수 있다.
3. Conflict는 Git이 두 변경사항 중 어떤 것을 선택해야 할지 판단하지 못하는 상황이다.
4. 충돌이 발생하면 코드를 직접 확인하고 적절한 내용을 선택해 해결해야 한다.
5. Branch를 이용하면 기능이나 작업을 서로 분리해서 개발할 수 있다.
6. 작업이 끝난 Branch는 Merge를 통해 다른 Branch에 반영할 수 있다.
7. Git 협업에서는 명령어 자체보다 현재 저장소의 상태와 작업 흐름을 이해하는 것이 중요하다.

이번 강의를 통해 Git을 단순히 "코드를 저장하고 GitHub에 올리는 프로그램"으로 이해했던 단계에서 벗어나, 여러 개발자가 하나의 프로젝트를 함께 관리하기 위한 버전 관리 시스템이라는 관점으로 조금 더 이해할 수 있었다.

---

해시태그

#SK네트웍스 #엔코아 #AI오케스트레이션 #AI오케스트레이션프리코스 #Git #GitHub #GitClone #GitBranch #GitMerge #Git협업