GitHub의 이해

Git과 GitHub

- 깃(Git): 분산 버전 관리 시스템

소프트웨어 개발 프로젝트에서 소스 코드의 변경 사항을 추적하고 여러 사람이 협업할 때 사용된다. 

-  깃허브(GitHub): 깃을 기반으로 하는 웹 기반 호스팅 서비스

깃허브는 소스 코드를 저장하는 리모트 저장소 역할을 하며, 버그 추적, 기능 요청, 작업 관리, 위키 등의 기능을 제공한다. 

- 즉 깃은 소프트웨어이고 깃허브는 서비스이다. 

 

- 분산시스템: "원격저장소"와 "로컬저장소"

Git은 분산시스템으로 저장소가 두 곳에 존재

(1)서버 등 네트워크에 있는 "원격저장소"

(2)자신의 컴퓨터에 있는 "로컬저장소"

기본적으로 원격저장소에 있는 파일을 로컬저장소로 가져와 작업을 수행하고, 그 결과를 원격저장소에 저장(반영)하는 것이다.

 

---

Github Flow

Fork → Clone → Commit → Fetch & Merge → Push → Pull Request

 

1. Fork

 

- Fork 기능은 jQuery 저장소의 지금 상태 그대로를 복사해서 자신의 Github계정(remote, not local)에 jQuery 저장소를 생성한다.

- 이 Fork는 Git 기능이 아니라 GitHub가 Git 기능을 추상화해서 제공하는 기능이므로 git fork같은 명령어는 없다.

즉, git clone을 GitHub 내에서 구현했다고 생각하면 된다

- Fork된 저장소는 jQuery의 원래 저장소와 완전히 동일한(주소만 다른) 자신만의 저장소이다.

분산저장소이기 때문에 저장소가 또 하나 생긴 것이고 다른 사람이 jQuery 원래 저장소 대신 내 저장소를 똑같이 Fork 받아서 수정하는 것도 당연히 가능하다. 각 저장소는 모두 권한외에는 모두 동일한 기능을 가진다

 

2. Clone

- 원격에서는 소스를 수정할 수 없으므로 이 저장소를 작업할 로컬 머신에 내려받아야 하는데 이 과정이 Clone이다.

- Fork가 Github내에서 저장소를 복사한 것이라면 Clone은 원격 저장소를 로컬로 복사한 것이다.

- git clone ~ 실행하면 로컬에 jquery 폴더가 생기고 jquery 폴더안에 git 저장소를 내려받은 것을 볼 수 있다.

 

3. Commit

- Git commit은 현재의 로컬 git 저장소에 소스를 적용해서 히스토리를 남긴 것으로 SVN의 commit과 다르게 원격저장소에 적용되는 것은 아니다.

- Git에서는 브랜치를 생성하는 것을 권장하고 있고 일반적으로 master 브랜치에서 다른 브랜치를 생성해서 작업하는 것이 일반적이다.

 

4. Fetch & Merge

- 로컬에서 작업을 하다보면 원격저장소에 변경사항이 생긴다

- clone 이후에 원격저장소에 누군가 소스를 push하면 이 변경사항을 다시 로컬로 가져와야 하는데 이 과정을 fetch라고 하며,

원격저장소의 변경사항을 로컬로 가져온 뒤에 로컬의 브랜치에 merge하는 과정으로 이루어진다

- 이 과정은 git pull이라는 명령어를 통해서 이루어 질 수 있으나, 일반적으로는 git fetch후에 git merge로 나누어서 작업하는 것을 보통 더 권장한다 (conflict에 유연한 대처가 가능함)

 

5. Push

- 로컬에서 수정작업을 완료했다면 자신의 원격저장소에 수정한 커밋 들을 Push해야 한다.

이 과정은 로컬저장소에 커밋한 내역을 원격저장소에 적용하는 과정이다.

- jQuery의 원본저장소와 자신의 원격저장소의 master 브랜치를 계속 싱크하려면 jquery 원본저장소를 fetch받아서 master에 머지한 뒤에 자신의 원격 저장소의 master로 푸시하면 된다. 이 과정을 계속 반복하면 항상 두 master 브랜치의 동기화를 할 수 있다.

 

6. Pull Request (PR)

- 이제 원격에 올린 변경사항을 원본 jQuery 저장소에 적용하기 위해서 Pull Request를 보내야 한다.

Pull Request도 git 자체에 있는 기능은 아니고 Github에서 제공하는 기능이라고 할 수 있다.

- Pull Request를 사용하는 이유는 jQuery 원본저장소에는 쓰기 권한이 없기 때문이다.

- 수정한 내용을 Pull Request로 보내면 jQuery 저장소의 커미터들이 내용을 확인한 뒤에 승인을 한다.

승인 이후 Pull Request의 내용이 jQuery 원본저장소에 merge가 된다 (물론 승인하지 않고 거절할 수도 있음)

---

 

요약정리 

1. Git은 버전 관리 시스템이고, GitHub는 Git을 기반으로 하는 협업 및 원격 저장소 호스팅 서비스예요.
2. GitHub에서 프로젝트의 원본 저장소를 만들어, 다른 사용자가 이 저장소를 fork하여 자신의 GitHub 계정에 복사할 수 있습니다. 이렇게 생성된 저장소가 "나의 원격 저장소"가 되는 거죠.
3. clone 명령어를 사용해 "나의 원격 저장소"를 로컬 머신으로 복사해오면, 이게 바로 "나의 로컬 저장소"입니다.
4. 로컬 저장소에서 코드를 수정하고 commit하여 변경 사항을 기록할 수 있습니다.
5. 로컬 저장소에는 master 또는 main 브랜치가 기본으로 존재하며, 새로운 기능이나 수정 작업을 위해 별도의 branch를 생성해 작업할 수 있습니다. 작업을 완료하면 로컬 저장소에서 merge를 통해 main 브랜치에 병합할 수 있죠.
6. push: 로컬에서 작업한 변경 사항을 "나의 원격 저장소"로 업로드하는 과정입니다.
7. pull request (PR): "나의 원격 저장소"의 변경 사항을 "원본 원격 저장소"에 반영해달라고 요청하는 과정입니다. 원본 저장소의 관리자나 커미터가 PR을 확인하고 승인해야 원본 저장소에 병합됩니다.
8. 원본 원격 저장소의 변경 사항 반영: 다른 사람이 원본 원격 저장소에 반영한 pull request가 있다면, 내 로컬에도 최신 변경 사항을 가져와야 하죠.
9. fetch와 merge: 원본 원격 저장소의 최신 변경 사항을 가져오는 것을 fetch라고 하고, 가져온 변경 사항을 내 로컬 브랜치에 merge해서 반영합니다.
10. pull: fetch와 merge를 한 번에 실행하는 명령어이지만, 각 단계를 나누어 작업하는 것이 종종 추천됩니다.

이유: fetch로 원본 원격 저장소의 변경 사항을 확인한 후, 내가 예상하지 못한 충돌이나 변경 사항을 미리 검토할 수 있습니다. 이런 식으로 작업하면, merge하기 전에 변경 사항을 검토하거나 필요시 충돌 해결을 위한 준비를 할 수 있어 더 안전하게 작업을 진행할 수 있습니다.

 

---

 

협업을 염두에 둔 GitHub 사용 흐름

1. 프로젝트 리더가 GitHub에 원본 원격 저장소 생성

• 프로젝트 리더는 GitHub에 새로운 원격 저장소를 만듭니다.
• 프로젝트 설명과 함께 초기 설정 (예: README.md, .gitignore 파일)을 포함하면 좋습니다. 이 저장소가 팀의 원본 원격 저장소가 됩니다.

2. 프로젝트 리더가 프로젝트 뼈대를 생성

• 리더는 IDE (예: IntelliJ)에서 프로젝트 뼈대를 만들고, 기본 파일과 폴더 구조를 설정합니다.
• 이 초기 뼈대 프로젝트를 로컬에서 GitHub 원본 원격 저장소로 push합니다.

3. 팀원들이 원본 원격 저장소를 fork

• 팀원들은 GitHub에서 원본 원격 저장소를 fork하여 자신의 GitHub 계정에 복사본을 만듭니다. 이것이 각 팀원의 개인 원격 저장소가 됩니다.

4. 팀원들이 자신의 원격 저장소를 로컬에 clone

• 각 팀원은 자신의 원격 저장소를 로컬 컴퓨터에 clone합니다. 이를 통해 팀원들은 로컬에서 프로젝트 파일을 수정할 수 있게 됩니다.

5. 작업할 브랜치 생성 및 작업 진행

• 팀원들은 로컬 저장소에서 브랜치를 새로 생성하여 작업을 진행합니다. (예: feature/새로운기능, bugfix/오류수정 등으로 브랜치 이름을 명확하게)
• 각 팀원은 작업 후 로컬에서 commit을 통해 변경 사항을 저장하고, push하여 자신의 원격 저장소로 반영합니다.

6. 원본 원격 저장소로 Pull Request 요청

• 작업이 완료되면 팀원들은 자신의 원격 저장소에서 원본 원격 저장소로 Pull Request를 생성해 요청을 보냅니다.
• 리더나 관리자 역할을 맡은 사람이 PR을 확인하고, 문제가 없다면 merge하여 원본 원격 저장소에 반영합니다.

7. 원본 원격 저장소의 최신 상태 동기화

• 팀원들은 원본 원격 저장소가 업데이트되면 fetch하여 로컬 저장소를 최신 상태로 동기화하고 merge합니다.
• 이를 통해 충돌 가능성을 줄이고 모든 팀원이 최신 변경 사항을 반영할 수 있습니다.

이 과정을 거치면 협업에서 최신 상태 유지와 각자의 기능 개발이 체계적으로 이루어집니다. 

---

GitHub Desktop으로 프로젝트 관리하기 

🌟 Create Repository (저장소 생성)

• 역할
  • 로컬(내 컴퓨터)에 새로운 Git 저장소를 생성하는 과정이야.
  • .git 폴더를 만들어 Git이 해당 디렉토리를 관리할 수 있도록 설정.
  • Git이 변경 사항을 추적할 수 있는 상태로 만들어 줘.
• 사용 시점
  프로젝트가 Git으로 초기화되지 않았을 때 사용.
  (예: "This directory does not appear to be a Git repository" 메시지가 나왔을 때.)
• 결과:
  • 프로젝트 폴더가 Git 저장소로 전환됨.
  • 이 상태에서는 아직 로컬에서만 관리되고, 깃허브(GitHub)에는 업로드되지 않음.

🌟 Publish Repository (저장소 게시)

• 역할
  • 로컬에서 생성된 Git 저장소를 깃허브(GitHub)에 업로드하는 과정이야.
  • GitHub에 저장소를 생성하고, 로컬 저장소와 연결.
  • 원격 저장소(remote repository)가 생기면서 다른 사람과 협업하거나, 백업할 수 있게 됨.
• 사용 시점:
  이미 Git으로 초기화된 프로젝트를 깃허브에 업로드하려고 할 때 사용.
  (예: Create Repository를 통해 로컬 저장소를 생성한 후.)
• 결과:
  • 로컬에서 관리 중이던 저장소가 깃허브(GitHub)에 업로드됨.
  • 푸시(push)를 통해 이후 변경 사항도 깃허브에 동기화 가능.

🌟 깃허브 데스크탑으로 프로젝트 깃허브에 업로드하기 

1. 내 컴퓨터에서 프로젝트 시작

• File > Add Local Repository를 선택하고 프로젝트 폴더를 지정.
• Create Repository를 사용해서 프로젝트를 Git으로 초기화.
• 변경 사항을 커밋하면서 로컬에서 작업 관리.

2. 작업을 깃허브로 업로드

• Publish Repository로 로컬 저장소를 GitHub와 연결하고 업로드.

3. 이후 관리

• 로컬에서 계속 작업하면서 변경 사항을 푸시(Push)로 깃허브에 반영.