(8월 26일 진행한 Girls In Tech X GitHub의 온라인 교육 행사를 참고하여 정리한 글입니다.
행사는 전반부와 후반부로 나뉘며, 해당 포스트에서는 코딩 어린이인 필자의 수준에 맞는 전반부만 참고했습니다.)

전반부(입문용):
- Git을 사용해야 하는 이유
- Git과 GitHub의 차이점
- Git에서 자주 등장하는 용어 정리
  - Commit, Conflict, Branch, Pull Request, Merge
  
후반부(전문가용): 
- Branch Policy 세팅
- Build Validation 추가
- Azure Board와 GitHub의 연동
- Codespace로 웹에서 디버깅
- GitHub의 코드 리뷰 기능
- GitHub Actions로 빌드/배포 자동화
- Azure Web App 소개

Git, GitHub의 장점

1. 컴퓨팅 사고력 발달
2. 깃의 형상 관리를 이용한 협업 (사실 이는 협업에 반드시 필요하다.)
3. 깃허브를 더욱 확장해 편리하게 사용하는 기술

1. 컴퓨팅 사고력

컴퓨터 사고력(computational thinking)이란, 복잡한 문제를 효육적으로 다루고 해결하는 사고 능력이다. 이는 프로그래밍과는 상이하다.

컴퓨터 사고력은 다음과 같이 나뉘어진다.

1. 문제 분해 Decomposition
   : 문제가 나타난 곳을 찾아낸다.
   
   
2. 패턴 인식 Pattern recognization
   : 과거에 대한 정보를 확인해서 문제일 확률이 높은 것을 색출한다.
   
   
3. 추상화 Abstraction
   : 중요한 정보에 집중하고, 중요하지 않은 정보는 잠시 무시한다.
   
   
4. 알고리즘 설계 Algorithmic Design
   : 문제 해결을 위한 단계를 적어 내려간다.

컴퓨터 사고력은 다음과 같은 예를 들 수 있다.

1. 문제가 발생한 컴포넌트가 사용하는 외부 패키지가 무엇인지 확인한다.
2. 외부 패키지의 공식 status page를 확인한다.
3. 공식 페이지에 확인되지 않는다면, 커뮤니티에 최근 비슷한 문제를 겪는 사람들이 있는지 확인한다.
4. 일전에 동일한 known issue가 fix된 이력이 있는지 확인한다. (regression bug 여부 확인)
5. 최근 외부 패키지에 코드 변경 사항이 있었는지 확인한다.

2. Git의 필요성

깃은 왜 필요할까?

우리가 문서나 파일을 만들 때, 다른 버전의 같은 파일이 계속 생성될 때가 있다. (사실 대부분의 경우가 그렇다. [보고서수정최종_진짜최종]...)

문서 혹은 파일은 수정이 이루어져도 이전의 내용을 그대로 볼 수 있는 경우가 많다.

그러나 코드 상이라면 한 줄 혹은 점 하나만 달라져도 프로그램이 동작하지 않을 수 있다.

따라서 어떤 부분을 누가 작성했는지 추적하거나 과거의 특정 시점의 코드로 돌아가는 것이 필수적으로 중요하나, 일반적인 수정 과정에서는 그것을 알기 어렵다.

Git은 형상 관리 기술의 일종이다.

Git은 컴퓨터 파일의 변경 사항을 추적하고, 여러 명의 사용자들이 협업할 수 있게끔 하는 분산 버전 관리 시스템이다.

GitHub는 Git을 기반으로 하는 서비스이다.
GitHub는 분산 버전 관리 툴인 Git을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스이다.
(지금의 깃허브는 여기에서 많이 확장되었으나, 시작은 이랬다고 한다.)

3. Git에서 사용하는 개념, 용어

우선, 버전 관리 프로그램이 갖추어야 할 요소는 아래의 궁금증에서 비롯된다.

• 어느 단위로 변경된 사항을 저장해야 할지?
• 같은 부분을 다른 사람들이 동시에 변경하면 어떻게 처리할 것인지?
• 개별적인 버전을 관리하고 싶다면 어떻게 처리해야 하는지?
• 개별적인 버전을 최종본에 합치고 싶을 땐 어떻게 해야 하는지?

이에, Git이 제공하는 요소는 아래와 같다.

• Commit: 변경 기록 단위이다. 커밋은 작은 단위로 자주하는 것이 좋다고 한다. 최대한 쪼개야 위험요소가 분산되고 Review하는 분도 더 정확히 확인할 수 있다고 한다.
• Conflict: 여러 명이 같은 브랜치에서 같은 부분을 수정하면 충돌이 난다. 그 때 '컨플릭트가 났다'라고 한다.
• Branch: 마스터 브랜치에서 별도의 브랜치를 만들어 코드를 수정할 수 있다. 그리고 나중에 내 브랜치에서 일부분만 떼어 마스터 브랜치에 합칠 수 있다. (나무에서 가지를 이식하듯이)
• Pull Request: 별도의 브랜치에 올린 코드를 마스터 브랜치에 적용해 달라고 요청하는 기능이다.
• Review: Pull Request 받은 코드를 검토하고 리뷰를 달 수 있다. [Review changes] > [approve]를 하면, 적용이 승인된다.
• Merge: 승인된 '별도 브랜치 상의 코드'가 '마스터 브랜치'에 반영되는 것이다.

• Commit to Master: 이는 깃허브와 연동된 내 PC 파일에서 파일 정리( 혹은 수정)가 끝난 후, 로컬 저장소(Repositories)에 저장하는 작업이다.

(추가: 내가 깃허브에서 코드를 작성하다가, 공유를 원하는 사람에게 메일을 보낼 수 있다. 수락한 공유자는 해당 코드에 대해 일반인보다 조금 더 많은 권한을 가진다. 이 때 공유자는 마스터 브랜치에서 수정하기보다, 별도의 브랜치를 만들어 수정을 하는 것이 좋다. 그래야 conflict를 방지할 수 있다. )

전반부 마무리

여기까지가 전반부의 내용이었다. Git이 GitHub와 같은 것이라고 잘못 알고 있던 내게 핵심적이고 유용한 정보를 알려주셔서 이 행사에 감사했다.

행사 후반부의 내용도 별도로 정리를 했으나, 아직 내가 잘 알고 있지 않기 때문에 GitHub를 직접 사용해보고 알아가면서 추후 다시 포스트를 작성하려고 한다.


행사 마지막 부분에서 업무 문화와 취업과 관련한 이야기가 짧게 있었다.

이미 실무를 보고 있는 분도 자신이 속한 그룹 밖의 새로운 사람들과 만나고 프로젝트를 할 때, 더 크게 성장하는 것 같다고 한다.

그리고, 완벽한 사람을 취업시키는 것이 아니기 때문에 아직 학생이고 완벽히 아는 것이 없더라도 취직을 할 수 있다고 말씀해주셔서 용기를 얻었다.


개발은 마스터를 할 수 없는 분야이기도 하다. 계속 변화하고 발전하기 때문에 항상 공부해야할 게 많기 때문이다.

또한, 완벽한 제품은 없기 때문에 이미 출시된 프로그램도 수정할 일이 많다고 한다.

현재 실무를 보고 있는 사람들이 만든 프로그램도 그러한데, 하물며 학생이 만든 프로그램은 어떻겠는가.

그러니 한 프로그램을 완벽히 완성하지 못할 것 같더라도 일단 하자. 일단 코드 한 줄이라도 쓰고, 구글링 한 번이라도 더 하자.