깃허브 기본 사용방법

내 기억으로는 대학교 2학년에 처음 깃허브를 접해본것 같다. 당시에는 bash를 사용하는게 최선인줄 알고 명령어에 허덕거렸었던 기억이 있다. 지금은 깃허브 데스크탑 이라는 좋은 도구 덕분에 크게 불편함 없이 소스코드들을 관리할 수 있다. (다른 분들은 소스트리도 괜찮다고 한다)

 

설치 링크는 아래에 있으니 필요한 사람은 가서 다운로드 후 실행해주면 된다

https://desktop.github.com/

GitHub Desktop

 

---

거두절미하고, 이 글을 읽는다고 깃허브를 완전 이해할 수 있다는 건 아니다. 그저 깃과 깃허브가 뭔지, 어떻게 하면 기본적으로 사용할 수 있는지 원리를 이해하는데 도움을 줄 뿐, 숙달하기 위해서는 직접 다수와 프로젝트를 해보는 수밖에 없다. (3년째 쓰는데도 충돌 오류를 보면 심란하다)

 

STEP 1.

Git과 GitHub라는 것이 있는데, Git이라는 것은 Linux의 창시자인 ‘리누스 토팔즈‘가 개발 한 소스코드 관리 프로그램이다.  왜 그가 Git을 개발하게 되었는지 간략하게 살펴보면, 다음 텍스트 파일(또는 여러분이 짜실 소스 코드)를 예시로 들어 설명하겠다.

이후 개발을 할 떄 마다, 혹시 이렇게 수정 하는게 맞는건가 싶어 일단 코드를 따로 한번 저장해두고 이어서 개발한 경험이 있을 것이다.(없다면 대단한 개발자십니다)

 

그러다보면 이렇게 될 것이고

아마 모듈(또는 기능)별로 코드를 나누어 개발을 할텐데, 그 각 모듈 별로 아까와 같은 상황이 발생한다면 또 이렇게 될 것이고

지금까지의 행위를 팀원 각자가 모두 해나간다면 통제가 안되는 소스코드 파일들이 탄생 하게 될 것이다.

 

이것을 처음에 말씀드린 ‘리누스 토파즈’도 똑같이 느꼈고 따라서 만든 협업을 위한 (분산) 버전 관리 기반 프로그램이 바로 ‘Git’인 것이다!! (여기서 분산 이라는 말은 팀원들 각각이 소스코드 를 저장할 공간을 따로 사용할 수도 있다는 뜻) 즉, Git은 개발에 있어서 1.버전 관리 2.팀원과의 협업 을 쉽게 만들어준다.

 

Git과 GitHub의 차이점은, Git은 지금까지 말씀드린 모든 것을 하기 위해 사용해야하는 ‘프로그램＇인 것이고, GitHub는 팀원 간 소스코드 공유가 가능한 저장소인 것이다. 이러한 저장소를 제공해주는 호스팅 서버들은 GitHub뿐만 아니 라 GitLAB, RocketGit 등 다양하지만, 보통 GitHub를 쓴다. (물론 버전 관리 프로그램도 Git 뿐만 아니라 SVN, Mercurial 등 다양합니다.)

 

 

STEP 2.

깃허브 계정으로 새로운 레포지토리를 생성하면 아래와 같은 웹페이지를 볼 수 있다.

오른쪽 위에 clone or download가 있다. 여기서 clone은 github에 저장되어 있는 개발환경을 각 개인의 컴퓨터로 복사해오는걸 의미한다. 두 가지의 repository가 있는데,

local repository(개인 저장소) – 팀원 각각이 자신이 개발하는 코드를 저장할 저장소. 개인 노트북이라고 생각하시면 편하다.

Remote repository(원격 저장소) – 팀원이 공유할 코드를 저장할 저장소.

지금까지 계속 이야기한 GitHub가 remote repository라 고 보면 된다.(물론 같은 개념은 아니고 GitHub가 여러 remote repository들을 가지고 있는 더 큰 개념) 

그 외에 fork라는 것은 다른 사람 계정에 있는 remote repository를 내 github 계정의 remote repository에다가 복사하는 좋은 기능이다.

 

 

STEP 3.

먼저 왼쪽의 Clone or download를 누르면 다음과 같이 https://github.com~라는 현재 페이지의 url이 나오게 되는데 저 주소를 이용해 clone 해야한다. 우선 오른쪽 그림처럼 먼저 ‘여러분이 개발하게 될 폴더’ -> 오른쪽 클릭 -> Git Bash Here을 누르면 아래와 같다.

누르기 전

누른 후

 

bash 창이 뜨면 git 명령어를 써가며 작업을 하면 된다. (꼭 git bash로 이러한 작업을 해야하는 것은 아니며, cmd창이나 터미널 등에서도 똑같이 적용됩니다.) 여기에 git clone ‘아까 복사한 주소＇를 붙여 넣으면 해당 폴더에 github에 있었던 작업환경들이 모두 복사가 된다. 이제 저 폴더에서 코드를 지지고 볶으며 여러분의 프로젝트를 완성해가면 되는 것이다!

 

 

STEP 4.

지지고 볶는데 필요한 기본 명령어는 아래와 같다.

 

<반드시 알아야할 git 명령어들>

먼저 git을 처음 시작하는 것이라면 config과정을 진행해야 한다. 다음 명령어를 창에 입력해줍니다.

git config --global user.name “여러분 네임“
git config --global user.email “여러분 이메일“

(여러분 네임, 이메일은 github가입하실때 입력한 내용들, “ “는 붙여 줘야한다) 이후 “내가 이 폴더에 git을 사용하겠다!!” 라고 해서 git init을 원래 해줘야하지만, 아까 clone을 해왔기 때문에 init은 생략해도 된다.

 

다음으로 개인의 노트북(local repository)에서 공용저장소(remote repository)와의 연결이 필요하다. 다음 명령어를 이어서 입력해주면 된다.

git remote add origin 주소

내가 쓸 ‘remote (repository)’가 ‘주소’이며 ‘origin’이라는 이름으로 사용하겠다라는 뜻이다. 여기서 주소는 아까 clone해온 주소 그대로 쓰면 된다.

혹시나 후에 원격 저장소 주소를 바뀔일이 생긴다면 add 대신 git remote set-url origin 주소 을 입력해면 된다.

+ 설정한 원격 주소지 보기 : git remote show origin

 

Git은 이런 구조로 코드를 저장하고 공유하게 된다. Workspace는 개개인의 작업 공간. 즉, 아까 clone해온 폴더가 될 것이고 여기서 작업하여 변경되 게 된 사항들을 저장하기 이전에 중간 저장 단계인 index에 담아둔다. 이 과정을 git add라고 하고, 여기까지는 저장 기록(스냅샷)이 남지 않는다. 이렇게 index에 담아두다가 “아 내가 이제 정말로 여기까지는 구현이 끝난 것 같다!!”고 생각되면 이제 git commit을 하여 기록을 남기면 된다.

 

<git add 명령어>

다시 말하자면 commit하기 전에 내가 어떤 파일들을 commit 할지 미리 담아두기 위한 명령어이다. ‘git add 파일이름’ 으로 하나씩 추가하거나 ‘git add . ’으로 폴더 속 모든 파일을 staging area에 추가할 수 있다.

+ 내가 추가한 파일들을 보는 명령어 : git status

 

<git commit 명령어>

add 명령어를 통해 staging area에 담은 내용을 local repository에 저장하는 명령어다. 이렇게 저장된 하나하나의 순간을 ‘스냅샷’이라고 한다. local repository에 저장된 스냅샷들은 ‘git reset’ 명령어를 통해 다시 돌아갈 수 있으며, 이 스냅샷들을 remote repositroy로 전송(push)하여 팀원 간 코드를 공유할 수도 있게 된다.

예시 git commit 명령어는 아래와 같다.

git commit –m “data save”

git commit 다음의 –m “~~” 은 저장한 스냅샷의 ‘이름‘이자 ‘주석’을 적는다고 생각하면 쉽다. git log는 commit 명령어를 통해 저장된 스냅샷들을 보여주는 명령어이다.

 

<git push 명령어>

git push는 이제 local repositor에 저장되어 있는 commit 사항들을 remote repositor에 저장하는 명령어이다.

git push origin master

origin은 push를 할 주소 (=remote repository)이며, master는 branch 이름인데, branch에 관해서는 나중에 포스팅할 것이다. 기본적인 branch는 master 이다.

 

<git pull 명령어>

git pull은 반대로 remote repository에 저장되어 있는 코 드들을 local로 옮기기 위해 저장하는 명령어이다.

git pull origin master

각자 개발을 하기전에, 먼저 최신 remote를 pull하여 local의 코드를 변경 시켜놓고 개발을 진행해야 나중에 conflict(충돌) 상황이 덜 발생한다.

 

 

(이 글이 도움이 됐다면 광고 한번씩만 클릭 해주시면 감사드립니다, 더 좋은 정보글 작성하도록 노력하겠습니다 :) )