[30기 2차 세미나] (1) Git Desktop 세미나

중간 고사가 끝나고, SOLUX 30기는 2차 세미나와 함께 프로젝트 활동을 시작하게 되었습니다. ✨

 

 

이번 2차 세미나는 Git과 관련하여 Bash와 Desktop으로 나눠져서 진행되었는데요!

해당 세미나가 부원분들께 어떤 도움이 되었을지, 지금부터 함께 알아봅시다 ~ 😄

 

 

주제

---

 

 

기간

 

4월 28일 (월) ~ 5월 4일 (일)

 

 

 

---

 

 

 

세미나 소개

 

 

김지윤 멘토님께서 진행해 주신 Git Desktop 세미나에서는

 

깃허브 데스크탑의 사용 방법을 알고, 협업 응용 방법을 습득 하는 것이 목표였습니다.

 

 

 

내용

---

 

1. GitHub Desktop 기초

 

1) GitHub Desktop, 왜 써야 할까?

 

 

GitHub를 사용해야 하는 건 알겠는데, 명령어를 하나하나 외우고 터미널에 입력하는 게 막막하게 느껴졌던 적, 아마 누구나 한 번쯤 있었을 겁니다.

 

그런 사람들을 위해 나온 게 바로 GitHub Desktop라고 보시면 됩니다.

 

 

즉, 깃허브 데스크탑은 터미널 대신 클릭과 버튼만으로도 대부분의 Git 기능을 쓸 수 있도록 도와주는 그래픽 기반의 무료 애플리케이션으로, 

 

Git에 방금 입문한 사람이거나, 협업을 위해 GitHub를 처음 써보려는 분들에겐 정말 좋은 도구로 활용할 수 있습니다. 🖥️

 

 

 

 

이번에는 GitHub Desktop을 처음 설치하고, 기본적인 흐름을 직접 따라가는 방식으로 워크플로를 설명해주셨습니다.

 

로컬 디렉토리와 GitHub 계정과 연동한 뒤, 클론 기능을 이용해서 원격 저장소의 레포지토리를 내 컴퓨터로 가져오는 과정을 진행했습니다.

 

 

 

2) GitHub Desktop에서 클론(Clone) 기능이란?

 

 

클론(clone)은 쉽게 말해 GitHub에 올라가 있는 프로젝트를 내 컴퓨터로 복사해오는 작업입니다.

 

 

해당 레포지토리의 URL을 복사해서 GitHub Desktop에 붙여넣고,

 

저장 경로를 지정해주면 몇 초 만에 로컬 저장소를 만드는 과정을 이해할 수 있었습니다.

 

 

 

3) GitHub Desktop에서 Commit과 Push 차이 알아보기

 

 

마지막으로는 VS Code 같은 편집기를 연동해서 파일을 수정해보고, 수정한 내용을 커밋하고 푸시하는 실습을 했습니다.

 

 

여기서 중요한 건 커밋과 푸시의 차이를 정확히 아는 것이었는데요.

 

커밋은 내 컴퓨터에서 코드 변경 이력을 저장하는 것이고, 푸시는 그 변경 사항을 GitHub 서버에 반영하는 것입니다.

 

 

GitHub Desktop에서는 이 모든 과정이 버튼 클릭으로 처리되니,

 

터미널 명령어에 대한 부담이 크게 준다는 장점을 느낄 수 있었습니다. 🙌

 

 

 

---

 

2. GitHub Desktop으로 협업하기

 

1) GitHub Desktop에서 각자 브랜치 생성하기

 

 

앞선 강의에서 기초적인 사용법을 익힌 뒤에는, 실제 팀 프로젝트에서 GitHub Desktop을 활용하는 방법도 배울 수 있었습니다.

 

 

협업을 하다 보면 동일한 파일을 여러 사람이 동시에 수정하게 되는 경우가 생기고, 이때 흔히 '충돌'이라는 문제가 발생합니다. ⚠️

 

 

 

2) GitHub Desktop에서 Merge와 Pull의 흐름 이해하기

 

 

그래서 우리는 각자의 브랜치를 만들어 따로 작업한 뒤, 작업이 끝난 후에 메인 브랜치에 병합(merge)하는 과정을 따라갔어요.

 

 

커밋 메시지를 잘 작성하면 서로 어떤 작업을 했는지 파악하는 것에도 큰 도움을 얻을 수 있습니다!

 

 

 

 

또 한 가지 중요한 포인트는, 다른 팀원이 메인 브랜치에 반영한 변경사항을 내 브랜치로 받아오는 과정, 즉 'pull'도 꼭 필요하다는 점입니다.

 

 

최신 내용을 반영하지 않으면 충돌이 발생할 가능성이 더 커지기 때문에,

 

작업 전에 메인 브랜치에서 pull을 받아오는 습관을 부원분들이 잊지 않으셨으면 좋겠습니다. 🙂

 

 

 

---

 

3. GitHub Desktop에서의 돌발상황

 

1) GitHub Desktop에서 충돌(Conflict)이 발생했을 때

 

그리고 실전에서는 생각보다 자주 '돌발 상황'이 발생하는데요.

 

이번에는 깃 데스크탑에서 발생할 수 있는 돌발 상황과 해결 방법에 대해서 알아보도록 하겠습니다.

 

 

 

가장 대표적인 게 앞서 말한 충돌로, 같은 파일의 같은 부분을 두 명 이상이 수정하면

 

GitHub Desktop에서 ‘Can’t Automatically Merge’라는 메시지가 뜨면서 자동 병합이 안되는 경우가 있습니다.

 

 

이런 경우에는 GitHub Desktop의  'Create Pull Request'와 'Resolve Complete'를 통해 사용해서 충돌이 난 파일을 비교하고,

 

어떤 코드를 살릴지 선택한 뒤 Mark as Resolved를 눌러 수동으로 충돌을 해결할 수 있습니다.

 

 

물론 이렇게 충돌에 대처 방식을 익힐 수 있었지만,

 

미연에 방지하기 위해 메인 브랜치의 내용을 받아온 후 각자의 브랜치에서 작업하는 것이 가장 좋겠죠?

 

 

 

2) GitHub Desktop에서 커밋을 되돌리고 싶을 때

 

마지막으로 실습해본 건, 실수로 잘못 커밋했을 때 이를 되돌리는 방법이었습니다.

 

여기엔 두 가지 방식이 있는데, 하나는 Revert이고, 다른 하나는 Reset이에요.

 

 

 

Revert는 이전 커밋을 취소하는 새로운 커밋을 생성하는 방식이라 히스토리가 남습니다.

 

 

예를 들어 협업 중이라면 다른 사람에게도 커밋 내역이 보여야 하므로 흔히 Revert를 사용하게 된다고 이해하시면 됩니다.

 

 

 

Reset은 특정 커밋 시점으로 되돌아가면서 중간 기록이 남지 않는다는 차이가 있습니다.

 

 

예를 들어서 개인 작업에서 최근 커밋 몇 개를 간단히 없애고 싶을 땐 Reset이 더 깔끔하게 정리되는 경우가 많습니다.

 

 

 

실수의 정도나 작업 맥락에 따라 적절한 방식으로 되돌리는 것이 중요하다는 걸 배우면서 이번 세미나 강의를 마무리했습니다. 😀

 

 

 

과제

---

1) Revert 실습

 

 

Revert 실습에서는 GitHub 웹페이지의 커밋 로그 화면에 나오는 해당 커밋의 해시값과,

 

GitHub Desktop에서 자동으로 생성되는 커밋 메시지인 "This reverts commit (해시 7자리)"가 서로 일치하는지를 확인했습니다.

 

 

이 과정을 통해 Revert가 단순히 내용을 취소하는 게 아니라,

 

정확한 커밋 이력을 참조하면서 새로운 변경 사항으로 되돌린다는 점을 직접 체감할 수 있었습니다. 🔄

 

 

 

2) Reset 실습

 

 

Reset 실습에서는 명령어 실행 후 터미널에 표시된 "HEAD is now at (커밋 해시) (커밋 메시지)" 구문이

 

실제 GitHub 웹페이지에서 로그 상단에 위치한 커밋과 정확히 일치하는지 확인했습니다.

 

 

 

---

 

 

 

이번 과제는 본인의 레퍼지토리를 통해 fork, add, commit, push 기능을 실습해보는 것이었습니다.

 

SOLUX 부원분들이 세미나에서 배운 내용을 토대로 하여 과제를 제출해 주셨습니다. 

 

 

개발자가 필수적으로 활용하는 깃허브를 Git Desktop을 통하여 직접 익혀볼 수 있었던 시간이었습니다.

 

남은 1학기 프로젝트에 대해서 조금만 더 힘내주시길 바랍니다🌟