고등학생때 프로그래밍 조금씩 배우면서 어쩌다가 알게되었던 GitHub..
나는 당연히 그냥 코드 작성해서 올리기만 하면 되는 줄알고 아무 생각없이 회원가입하고 아무것도 하지못했다

대학생이 되어서 프로그램 짜면서 자연스럽게 깃허브를 쓰게 될줄 알았는데 그건 또 아니었고
멋쟁이사자처럼 들어와서 첫 세션으로 깃을 배우게 되었다.

근데 정말 이런 거인줄 몰랐어서 신세계였다.
그래서 선배님들께 엄청 도움받으면서 했다.. 용어조차 이해를 못해서 질문도 어떻게해야할지 모를 정도였다 <( _ _ )>
거기에다 멋사에서 협업도 정말 많을 거고 매주 과제제출도 해야하니 진짜 튼튼하게 공부해와야겠다고 생각했다.
그런데 첫 세션이었어서 집중을 잘 못했던 것도 있었던 것같다.. 집에 와서 강의자료를 차근차근 읽으니 이해하기 쉬웠다!
다음주부터는 조금 여유롭게 강의자료를 한번이라도 훑어보고 세션에 참여해볼까 싶다

아무튼 그렇게 고등학교때 만들었던 깃허브 아이디를 대2가 되어서야 제대로 쓰게 되었다는 말이다..

깃허브가 단지 프로그래밍을 공유하고 기록한다<는게 고등학교 때 추측..했던 거였다면
깃이 뭐고, 깃허브가 뭔지 배우면서 고등학교때 조금이라도 찾아보고 조금 더 해볼걸 하는 생각이 들었다.. 깃 조금 배웠는데도 뭔가 프로그래밍에 대해 시야가 확 확장된 느낌이 들어서 이런 느낌이 드는게 어쩔 수 없는 듯싶다.
그치만 어떡해 나는 이미 대학생이 되었는걸!..
이 위치에서 더 열심히 공부하면 될 것이다

그래서 더 틈틈히 복습하는 겸 블로그에 정리해보려고 이렇게 노트북을 켜봤다

VCS(버전 관리 시스템)

VCS (Version Control System)

버전 관리 시스템

: 파일의 변경사항을 추적하고 관리하는 시스템

VCS 중에 가장 유명한 것이 Git!
Git으로 원격전송 된 내역들이 저장되는 공간 서비스 중 하나가 Github!

이렇게만 들으면 이해가 확 되지않을 것이다. 그런데 여기서 활용 이유를 읽다보면 이해가 확 될 것이다.

ㅡ

활용 이유

1) 코드의 히스토리를 알 수 있음

프로그램을 개발하다보면 여러 파일들을 수정하게 되는데 잘못된 수정을 했을 때에는 그 전에 코드로 돌아오고 싶을 것이다.

원래라면!
-> 중요한 시점마다 프로젝트를 통째로 여러번 저장해야할 것이다.

VCS 사용!
-> 파일이 바뀌기 전 내역들을 모두 쉽게 변경, 확인 가능하기 때문에 그럴 필요없다!
-> 변경 내용 기록으로 데이터 손실 방지 할 수 있다!

2) 협업 시의 편리

원래라면!
-> 프로그램마다 각각 작업하고, 이것을 이메일, 메신저 등으로 공유해야하고, 이를 각자의 컴퓨터에 직접 복사하여야 한다.

VCS 사용!
-> 여러 사람이 동시에 같은 파일을 수정해도 각각의 작업 기록, 병합 가능하다!
-> 비슷한 원리로 여러 기능을 동시에 개발할 수 있다!

ㅡ
ㅡ
이러한 VCS도 종류가 있는데 Git은 분산 버전 관리 시스템에 속한다

분산 버전 관리 시스템

: 개발자들이 로컬 저장소를 가지고 있고, 변경 내용을 서로 주고 받으며 협업.
-> 변경 사항은 로컬에서 관리, 필요할 때 서버에 동기화

시스템&용어

분산 버전 관리 시스템을 더 깊숙히 보자
그냥 용어만 봤을 때에는 사실 이해하기가 힘들었는데 아래의 그림들이랑 함께 보면서 여러번 읽으니 훨씬 더 정리가 잘되었다.

밑에 정리가 안되어있는 것은 >해당하는 곳으로 복사<정도로 이해했다.

개인PC영역 <--> 원격저장소가 크게 있고
개인PC영역 사이에도 staging area->local repository를 거쳐 원격저장소로 옮겨야하고
그 사이에 사용되는 것이 git ~ 인 것이다.

첫번째 구조에서 Local Repository와 Remote Repository사이의 구조이다.
이것도 사실 이해하기가 조금 힘들었다.. 근데 이거또한 예를 들면 쉽게 이해할 수 있는 듯

내가 만약 학교 과제를 낸다고 치자
1. Upstream은 교수님의 서버저장소 < 이곳에 과제를 제출해야함!
2. fork : 교수님의 서버저장소(Upstream)--복제-->내 서버저장소(origin)
3. clone : 내 서버저장소(origin)의 데이터--복사-->내 로컬저장소(Local)
4. 과제를 Working Directory에서 작성하고, git add, git commit해서 local저장소에 저장
5. push : local저장소의 과제 --> 내 서버저장소(Origin)
6. pull request : 내 서버저장소(Origin) --> 교수님의 서버저장소(Upstream)

이렇게 그려보고 이해해도 한 가지 헷갈렸던 개념이 있었는데 바로 'Branch'였다. 약간 다른 차원의 이야기 느낌으로 다가왔던 것 같다.

Branch

: 가지 또는 분기점을 의미하며, 사용자가 독립적으로 작업 진행할 수 있도록 돕는 작업 흐름

그림처럼 Master라는 Branch에서 두개의 가지로 나뉘어져 2명이 한번에 독립된 작업 환경에서 작업할 수 있는 것을 예로 생각하면 쉽다!

명령어

이제 이것들을 어떻게 명령어로 써서 써먹을지 알아보자
보통은 git ~으로 작성하고 목적어가 필요하면 git ~ [브랜치명]정도가 되는 것같다

Branch 관련

git branch # 브랜치 확인한다.
git branch [브랜치명] #브랜치 생성
git checkout -b [브랜치명] #브랜치 생성하고 해당 브랜치로 전환
git checkout [브랜치명] #특정 시점이나 브랜치의 소스토드로 이동
git branch -d [브랜치명] #브랜치 삭제

버전 관련

git add . #Working Directory --> Staging Area로 올림 (모든 파일)
git add [파일명] # (특정 파일)

git commit -m "commit message" #Staging Area --> 로컬 저장소

git pull [연결된 원격저장소 명] [브랜치명] #원격 저장소의 특정 브랜치 변경 내역 --> 로컬 저장소

git push [연결된 원격저장소 명] [브랜치명] #로컬 저장소 변경 내역 --> 원격저장소

기타

git init #특정 저장소를 로컬 저장소로 만듦
git status #파일 상태 확인

이러한 명령어들을 명령 프롬프트 or 개발환경의 터미널에서 작성하여 진행한다

ㅡ

프로그래밍 공부하면서 어떤 건 이론에서 이해를 못해도 실습을 하면 이해되는 것들이 꽤있었는데
이것들은 이론을 오래 자주 돌아보고 이해한 뒤에 실습을 해보는 것이 훨씬 더 효율적인 것같다는 생각이 들었다
그래서 이론에 대해 이해한 대로 최대한 나만의 언어로 풀려고 노력했던 것같다.
진짜 자주보고 시도해보면서 마스터해야지