AI STICKER

본격적으로 Git을 사용하여 파일 버전 관리하는 방법을 배워보도록 하겠습니다.

Git은 리눅스와 같은 큰 프로젝트를 염두에 두고 디자인 되었기 때문에, 아주 많은 명령어들을 가지고 있습니다.

그러나, Git의 기본을 사용할 때에는 몇 개의 명령어만 인지하고 있으면 됩니다.

1. git init 

  깃 저장소를 초기화 합니다. 저장소나 디렉토리 안에서 이 명령을 실행하기 전까지는 일반적인 폴더에 불과하지만, 이 명령어를 입력한 이후에는 Git 명령어를 사용할 수 있게 됩니다. 저장소로 지정할 디렉토리에서 아래의 명령을 입력합니다.

  위와 같은 명령어를 입력하면 아래와 같은 화면이 나타나게 됩니다. (저의 경우에는 이미 해당 디렉토리를 저장소로 지정해 놓았기 때문에 Reinitialized 라고 표현되었습니다.

2. git status

  저장소의 상태를 체크하는 명령어입니다. 어떤 파일들이 저장소에 있는지, Commit이 필요한 변경사항이 있는지, 현재 저장소의 어떤 Branch에서 작업하고 있는지 등에 대한 정보들을 확인할 수 있습니다.

  modified에 나타나는 파일은 경우 기존에 저장소에 저장되어 있던 파일이 수정 되었을 경우에 나타나게 됩니다. 저같은 경우에는 'codefights/intro' 디렉토리 속 boxBlur.py 파일이 수정된 것을 확인할 수 있습니다. 만약 아무것도 수정되지 않았다면 어떠한 파일도 나타나지 않게 됩니다.

  Untracked files에는 기존 저장소에 저장되어 있지 않은 파일이 새로 추가된 것을 알려줍니다. 'minesweeper.py' 파일이 추가된 것을 확인할 수 있습니다.

3. git add

  add 명령은 저장소에 새 파일을 추가하진 않지만, Git이 해당 파일(들)을 지켜보게 합니다. add 명령이 수행된 파일은 Git의 저장소인 'SnapShot'에 포함되게 됩니다.

  add 명령을 통해 'intro/boxBlur.py'를 스냅샷에 추가하였습니다. modified의 전체적인 부분이 초록색으로 변한 것을 확인할 수 있습니다. add 명령을 사용하지 않은 'minesweeper.py' 파일은 여전히 빨간색임을 확인할 수 있습니다.

4. git commit

  Git에서 가장 중요한 명령어라고 할 수 있습니다. 어떤 변경사항이라도 만든 후, 저장소의 'SnapShot'을 찍기 위해 이 명령어를 사용합니다. commit 단위로 파일의 버전 관리가 진행됩니다. 일반적으로 'commit' 명령은 메시지와 함께 입력됩니다. 예시에서는 "-"와 같이 의미없는 메시지를 입력해두었지만, "modified boxBlur.py"와 같이 변경 내용을 한 눈에 알 수 있도록 적는 것이 좋습니다. 입력한 메시지는 추후 Github에 다음과 같이 나타나게 됩니다.

  intro 디렉토리 내의 boxBlur.py 파일이 status 결과 화면에서 사라진 것을 확인할 수 있습니다. 하지만 'minesweeper.py'파일은 사라지지 않았습니다. add 명령을 사용하지 않은 파일의 경우에는 commit되지 않습니다. 

5. git push

  git push 명령은 마지막으로 커밋한 사항을 git repsoitory에 올리겠다는 뜻입니다. 'push'를 하지 않으면 원격 서버에 변경 사항이 저장되지 않습니다. 다시말해서, 프로젝트를 공유하고 싶을 때 리모트 저장소에 'push'할 수 있습니다. 'commit'까지만 명령을 실행했다면 현재의 변경 내용은 아직 로컬 저장소의 HEAD안에 머물고 있을 것입니다. 이제 변경 내용을 원격 서버로 올리기 위해 아래 명령을 실행합니다.

  실행 화면의 명령어 중 'origin'과 'master'는 각각 리모트 저장소와 브랜치를 의미합니다. 또한 '-u'는 원격 저장소로부터 업데이트를 받은 후 'push'를 한다는 의미이므로 습관적으로 '-u'의 사용을 권장합니다.

  만약, 기존에 있던 원격 저장소를 복제(Clone)한 것이 아니라면, 원격 서버의 주소를 git에게 알려주어야 합니다.

  'git remote -v'를 했을 때, 위와 같은 주소가 나타나고, 'git push -u origin master' 명령을 입력했을 때 오류가 발생하지 않는다면 정상적으로 원격 서버 주소가 설정된 것입니다.

References

• Git 기초 - Git 명령어 배워보기

macOS에는 기본적으로 'gcc', 'make'와 같은 컴파일 도구가 설치 되어 있지 않기 때문에 명령어 라인 도구(Command Line Tools)를 설치해야 합니다.

예전에는 Xcode를 전체 설치하고 추가로 명령어 도구를 설치해야 했으나, 용량이 꽤 크기 때문에 명령어 도구만 따로 설치할 수 있게 변경되었습니다.

1. Xcode 설치 없이 Command Line Tools 설치

  커맨드 라인 도구를 사용하기 위해서 Mac에서는 Xcode를 설치해야 합니다. 단순히 커맨드 라인 도구를 이용하기 위해 5GB에 육박하는 Xcode를 설치해야 한다는 것은 상당히 비효율적이고 부담스러운 일입니다. 따라서, Xcode를 설치할 필요 없이 OS X에 내장된 '터미널(Terminal)'만으로 명령어 라인 도구를 내려받을 수 있는 방법을 소개합니다.

설치 방법

Step 1. 아래 코드를 터미널에 입력합니다.

Step 2. 명령어 라인 도구 설치 대화상자가 나타나면 '설치' 버튼을 눌러줍니다

Step 3. 명령어 라인 도구를 다 내려받으면 '사용권 계약'이 담긴 대화상자가 나타납니다. 여기서 '동의' 버튼을 누르면 설치가 완료됩니다.

Step 4. 이제 터미널을 통해 명령어 라인 도구를 사용할 수 있습니다. 'gcc' 컴파일러를 실행해 개발자 도구가 잘 설치 되었는지 확인합니다.

2. Homebrew 설치

  Brew(Homebrew)는 각종 커맨드라인 프로그램을 손쉽게 설치해주는 macOS용 패키지 매니저입니다. 리눅스의 'apt', 'yum'과 비슷하며 brew 외에도 MacPorts 라는 패키지 매니저가 있지만, 몇몇 단점으로 요즘은 거의 brew를 사용하는 추세입니다. 다양한 프로그램을 복잡한 빌드과정 없이 손쉽게 설치할 수 있고 업데이트, 관리도 간단한 필수 프로그램입니다.

설치 방법

Step 1. Homebrew의 설치는 매우 단순합니다. macOS에 기본적으로 설치된 Ruby를 사용하여 설치를 진행합니다.

Step 2. 설치 이후, 다음 명령을 실행하여 아래와 같은 메시지가 나오는지 확인합니다.

3. Git 설치

  Homebrew를 사용하여 Git을 설치합니다.

설치 방법

Step 1. brew를 사용하여 Git을 설치합니다.

Step 2. 설치 이후, 다음 명령을 실행하여 Git의 사용자 정보를 설정해줍니다.

  위의 명령어는 Git을 설치하고 나서 가장 먼저 해야하는 일입니다. Git은 Commit할 때마다 이 정보를 사용한다. 한 번 Commit한 이후에는 정보를 변경할 수 없습니다.

위의 3가지 기본 설정 및 설치를 마쳤다면, macOS에서 Git을 사용할 준비가 된 것입니다.

다음 포스팅에서는 본격적으로 Git을 통해 파일 관리를 해보도록 하겠습니다.

References

• https://git-scm.com/book/ko/v1/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Git-%EC%B5%9C%EC%B4%88-%EC%84%A4%EC%A0%95

• http://theeye.pe.kr/archives/1747

• http://www.popit.kr/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A5%BC-%EC%9C%84%ED%95%9C-%EB%A7%A5mac-%EC%A0%95%EB%B3%B4-%ED%8C%A8%ED%82%A4%EC%A7%80%EA%B4%80%EB%A6%AC%EC%9E%90-homebrew/

(내용 출처 : https://tuwlab.com/ece/22202)

1. GIT이란?

 GIT은 소프트웨어를 중심으로 하는 프로젝트에서 빈번하게 발생할 수 있는 문제를 해결하기 위해 등장한 형상 관리 도구(Configuration Management Tool)입니다.

소프트웨어 공학의 프로젝트 진행 및 관리 방법에서 비중 있게 다뤄지는 영역 중 하나이기도 합니다.

 많이 쓰이는 형상 관리 도구로는 SVN과 GIT이 있습니다. SVN과 GIT은 모드 소스코드의 효율적인 관리를 위한 형상 관리 도구이지만, 비슷하면서도 많은 점이 다르다고 할 수 있습니다. SVN과 GIT의 가장 큰 차이점은 '분산'입니다. SVN은 중앙 집중식 소스코드 관리 방식인데 반해, GIT은 분산 소스코드 관리 방식입니다. 즉, GIT을 사용할 경우 중앙 저장소가 폭파되더라도 분산되어 있는 로컬 저장소를 이용해 중앙 저장소를 복원할 수 있습니다.

 SVN과 GIT은 상호 장단점에 대한 의견이 분분합니다. 하지만, 요즈음에는 SVN을 사용하던 대부분의 기업들이 GIT으로 점차 옮겨가는 추세이고, 형상 관리 도구에 처음 입문하는 사람들 중 대부분이 GIT으로 입문한다는 점으로 미루어 보았을 때, GIT을 사용하는 것을 추천합니다.

2. GIT을 사용하면 어떤 일들이 가능할까?

1. 소스코드 주고받기가 필요 없고, 같은 파일을 여러 명이 동시에 작업하는 등 병렬 개발이 가능해지며, 버전 관리가 용이해져 생산성이 증가합니다. 
   
   

2. 소스코드의 수정 내용이 Commit 단위로 관리되고, Fetch 형식으로 배포할 수 있기 때문에 프로그램의 변동 과정을 체계적으로 관리할 수 있고, 언제든지 지난 시점의 소스코드로 점프(Checkout)할 수 있습니다.
   
   

3. 새로운 기능을 추가하는 Experimental Version을 사용하는 경우, Branch를 통해 충분히 실험을 한 뒤 본 프로그램에 합치는 방식(Merge)으로 개발을 진행할 수 있습니다.
   
   

4. 분산버전관리이기 때문에, 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있으며, 중앙 저장소가 폭파되어도 다시 원상복구할 수 있습니다.
   
   

5. 팀 프로젝트가 아닌, 개인 프로젝트일지라도 GIT을 통해 버전 관리를 하면 체계적인 개발이 가능해지고, 프로그램이나 패치를 배포하는 과정도 간단해집니다.
   
   

1. 저장소(Repository)
    소스코드가 저장되어 있는 여러 개의 브랜치(Branch)들이 모여 있는 디스크상의 물리적 공간을 의미합니다. GIT에서는 저장소가 로컬 저장소(Local Repository)와 원격 저장소(Remote Repository)로 나뉩니다. 
   
    작업을 시작할 때 원격 저장소에서 로컬 저장소로 소스코드를 복사해서 가져오고(Clone), 이후 소스코드를 변경한 다음 Commit을 합니다. 이 때, 커밋한 소스는 로컬 저장소에 저장되며, 푸시를 하기 전에는 원격 저장소에 반영되지 않습니다.
   
   
2. 체크아웃(Checkout)
    특정 시점이나 Branch의 소스코드로 이동하는 것을 의미합니다. 체크아웃 대상은 Branch, Commit, Tag입니다. 체크아웃을 통해 과거 여러 시점의 소스코드로 이동할 수 있습니다.
   
   
3. 스테이지(Stage)
    작업한 내용이 올라가는 임시 저장 영역입니다. 이 영역을 이용하여 작업한 내용 중 Commit에 반영할 파일만 선별하여 커밋을 수행할 수 있습니다.
   
   
4. 커밋(Commit)
    작업한 내용을 로컬 저장소에 저장하는 과정입니다. 각각의 커밋은 의미 있는 변경 단위이고, 변경에 대한 설명을 커밋 로그로 남깁니다. 대개 하나의 커밋은 '회원 가입 기능 추가', '검색 버그 수정'과 같이 하나의 주제로 묶을 수 있는 변경 단위가 됩니다. 
   
   
5. 태그(Tag)
    커밋의 임의 위치에 쉽게 찾아갈 수 있도록 붙여놓은 이정표를 태그라 합니다. 태그가 붙여진 커밋은 Commit ID 대신 태그명을 입력하여 쉽게 체크아웃 할 수 있습니다.
   
   
6. 푸시(Push)
    로컬 저장소의 내용 중 원격 저장소에 반영되지 않은 커밋을 원격 저장소로 보내는 과정입니다.
   
   
7. 풀(Pull)
    푸시와 반대로 원격 저장소에 있는 내용 중 로컬 저장소에 반영되지 않은 내용을 가져와서 로컬 저장소에 저장하는 과정을 의미합니다. 이를 통해 다른 팀원이 변경하고 푸시한 내용을 로컬 저장소로 가져올 수 있습니다.
   
    푸시 과정에서 충돌(Collision)이 일어나서 푸시가 거절된 경우, 풀을 통해 원격 저장소의 변경 내용을 반영한 뒤 다시 푸시를 시도해야 합니다.
   
   
8. 브랜치(Branch)
    커밋을 단위로 구분된 소스코드 타임라인에 분기해서 새로운 커밋을 쌓을 수 있는 가지를 만드는 것, 혹은 그 가지를 브랜치라 합니다. 브랜치 중에 개발의 주축이 되는 브랜치를 마스터 브랜치(Master Branch)라 하며, 모든 브랜치는 마스터 브랜치에서 분기되어 최종적으로 다시 마스터 브랜치에 병합(Merge)되며 개발이 진행됩니다.
   
   
9. 포크(Fork)
    저장소를 복제해서 새로운 독립된 저장소를 만드는 작업을 의미합니다. 공개된 오픈 소스 프로젝트를 자신이 프로젝트 매니저가 되어 입맛대로 수정하고 싶을 때 사용하는 기능이 바로 Fork입니다. 원격 저장소를 로컬 저장소로 복제한 뒤 새로운 원격 저장소에 푸시하는 과정을 한 번에 해결할 수 있도록 도입한 기능이 Fork입니다.
   
   
10. 병합(Merge)
     브랜치와 반대되는 개념으로, 하나의 브랜치를 다른 브랜치와 합치는 과정을 의미합니다.
    
     두 개의 브랜치를 합쳐 하나의 브랜치로 만드는 3-Way Merge가 모든 병합 작업의 기본이 됩니다. 병합의 대상이 되는 두 브랜치는 주종관계가 성립하며, 따라서 'A브랜치와 B브랜치를 병합한다'라는 말은 모호한 표현이 됩니다. 즉, 'A 브랜치를 B 브랜치에 병합'하는 작업과 'B 브랜치를 A 브랜치에 병합'하는 작업은 서로 다른 작업입니다.
    
      병합도 커밋의 한 종류입니다. 일반적인 커밋은 조상 커밋이 하나인 커밋인데 반해, 병합의 조상 커밋이 둘 이상인 경우입니다. 3-Way Merge는 '서로 다른 두 커밋으로부터 하나의 새로운 커밋을 생성하는 작업'입니다.
    
     병합 과정에서 두 개의 브랜치에서 파일의 같은 부분을 서로 다르게 수정한 경우 충돌이 발생하며, 병합이 일시정지 됩니다. 이 경우, 충돌이 발생한 부분을 직접 수정하거나, Merge Tool 등을 활용하여 충동을 해결한 뒤 병합을 계속 진행하면 됩니다.