(1)  C / C++ 확장 프로그램 설치하기   

 

 

  vscode 확장(마켓 플레이스)로 가서 c++을 검색하고 위 그림과 같이 제일 첫번째에 나오는 것을 선택하여 설치합니다. 하지만 컴파일러가 없기 때문에 이것만 가지고는 컴파일이나 디버깅을 할 수 없다. 따라서, 컴파일러를 설치해줘야 한다. 

 

 


 

    (2)  MinGW 설치하기   

 

 Window 환경에서 GCC c++ 컴파일러(g++) 및 GDB 디버를 사용하기 위해서는 MinGW라는 프로그램을 설치해야 한다.

(참고로, MinGW는 마이크로소프트 윈도로 포팅한 GNU 소프트웨어 도구 모음이다.)

 

 구글에 MinGW를 검색해 Window download 페이지를 들어가 [File] 부분에 들어가거나

 https://sourceforge.net/projects/mingw/files/ 에 접속하여 초록색 버튼인 Download Latest Version을 누른다. 

 

 

 

 mingw-get-setup.exe 파일을 다운받고 실행을 하면 다음과 같은 화면이 뜬다. [install] 버튼을 누르고 

 

 

 [install] - [continue] - [continue] 버튼을 차례대로 누르면 다음과 같이 바탕화면에 installer가 생성되고 다음과 같은 화면이 뜬다. 

 

 

 

 이 화면에서 mingw-developer-toolkit의 체크박스를 클릭하면 옵션창이 뜨고 [Mark for installation]을 선택한다.

mingw 32-base와 mingw32-gcc-g++도 같이 선택해준다. mysy-base는 리눅스 환경처럼 작업하고 싶으면 체크하면 된다. 

여기까지 하면 다음과 같이 된다. 

 

 

 다음으로 왼쪽 상단에 [Installation] - [Apply Changes]를 누르면 다음과 같은 창이 뜨고 [Appay]를 눌러준다. 

 

 

 다음으로 왼쪽 상단에 [Installation] - [Apply Changes]를 누르면 다음과 같은 창이 뜨고 [Appay]를 눌러준다. 

설치가 완료되면 close 버튼으로 바뀐다. close 버튼을 누르고 이제 Window에서 g++, gcc를 사용하기 위해서는 환경변수를 세팅해줘야 한다. [제어판] - [시스템]을 누르고 왼쪽에 [고급 시스템 설정]을 누르면 시스템 속성 창이 뜨게 되고 [고급] 탭의 맨 하단 [환경 변수] 탭을 누른다. 시스템 변수에서 Path를 찾고 더블 클릭을 한다. 그리고 C:\MinGW\bin를 추가해준다. 지금까지 했으면 다음과 같은 화면이 된다. 

 

 

 이제 잘 깔렸는지 확인을 하기 위해 cmd 창에서 g++ -version 또는 gcc -v 명령어를 입력하고 버전을 확인한다.

 

 


 

    (3)  VSCode  C++ file 빌드   

 

 이제 VSCode로 돌아가 작업영역에 폴더를 하나 추가하고 hello.cpp을 작성해준다.

 

 

#include <iostream>
#include <vector>
#include <string>

using namespace std;

int main()
{
    vector<string> msg {"Hello", "C++", "World", "from", "VS Code", "and the C++ extension!"};

    for (const string& word : msg)
    {
        cout << word << " ";
    }
    cout << endl;
}


 

 작성이 완료되었다면 ctrl+ s 눌러 저장하고 이제 빌드를 하는 과정이 필요하다. 맨 위 [터미널] - [기본 빌드 작업 구성]을 클릭하면 다음과 같은 그림이 나오고 빨간색으로 표시된 부분인 C/C++: g++.exe build active file을 선택한다. 

 

 

 그러면 .vscode라는 폴더가 생성이 되고 tasks.json이라는 파일이 생성된다. 

 

 

 여기서 command 변수는 실행할 프로그램을 지정해주는 변수로 여기서는 g++ 이다. args 변수에는 배열이 들어가는데 g++로 전달 될 명령 행의 인수들의 집합이라고 보면 된다. 여기서 인수는 순서대로 컴파일러가 실행하므로 순서에 맞게 지정해야 한다. 여기서는 g++에게 실행할 파일을 가져와 컴파일하고 현재 디렉토리의 활성 파일과 이름이 같은 .exe 확장자 파일(hello.exe)을 사용하여 실행 파일을 생성하도록 지시한다.

 

 task.json에 대한 변수 참조는 https://code.visualstudio.com/docs/editor/variables-reference 여기서 자세히 확인할 수 있다.

 

 다시 hello.cpp로 돌아와서 ctrl + shift +b를 눌러준다. 그럼 터미널 창에 다음과 같은 화면이 뜨고 생성도 한 적 없는 hello.exe 파일이 생겼다.

 

 

 


 

    (4)  VSCode  C++ file 디버그   

 

 다음으로는 F5 키를 눌렀을 때 GDB 디버거를 통해 디버깅을 할 수 있도록 launch.json 파일을 생성합니다. 맨 위 [실행] - [구성 추가]를 선택하면 드롭다운이 뜨는데 거기서 C++(GDB/LLDB)를 선택한다. 그리고 새 드롭 다운이 뜨면 g++.exe build and debug active file을 선택한다.

 

 

 

 그러면 launch.json파일이 생성된다. 다시 hello.c++로 돌아가 F5를 누른다. 그러면 디버깅이 시작되고 터미널의 [디버그 콘솔]에 파란색으로 해당 내용이 찍히는 것을 볼 수 있다. 

 

 

 해당 내용이 깔끔해 보이진 않는다. 찾아보니 더 깔끔하게 출력하는 방법이 많이 있는 것 같다. 시간이 나면 좀 꾸며 보는 걸로...

 

 

 

참고: Visual Studio Code docs

https://code.visualstudio.com/docs/cpp/config-mingw

 

Get Started with C++ and Mingw-w64 in Visual Studio Code

Configuring the C++ extension in Visual Studio Code to target g++ and gdb on a Mingw-w64 installation

code.visualstudio.com

    Git이 커밋(Commit)을 관리하는 방식   

 

  git은 두 명 이상의 사람이 동시에 버전 관리를 할 때에도 서로의 작업물에 의존하지 않고 내가 원할 때 코드를 올리고 수정하고 협업자의 코드와 합칠 수 있다. 즉, 병렬적으로 버전 관리를 할 수 있다.

 

 그렇다면 어떤 원리로 작동할까? 우리는 커밋을 통해 코드의 변경사항을 하나로 덩어리로 묶을 수 있었다. 이러한 커밋들은 바로 전 커밋을 가리키며 시간순으로 쌓이게 된다. 

 

 

 혼자서 작업한다면 위의 그림처럼 한 줄로 계속 커밋이 쌓인다. 하지만, 협업을 통해 버전 관리를 한다면 한 줄로 커밋이 쌓일 수 없다. 커밋 3을 기준으로 두 명이서 각각 파일을 수정해 커밋을 한다고 가정하면 아래 그림과 같이 될 것이다.

 

 

 

 이렇게 특정 기준에서 나누어 작업할 수 있는 기능을 브랜치(Branch)라고 한다. 만약 브랜치를 만들지 않고 둘 다 커밋을 하면 원격 저장소에 먼저 푸시한 커밋(커밋 4)은 정상적으로 올라가고, 뒤늦게 푸시한 다른 커밋(커밋 5)은 "너는 낡은 코드에 푸시를 하는 것이다. 최신 코드에 푸시하라"라는 오류가 난다. 

 


 

 

   Git에서 관리하는 파일의 4가지 상태 (1)   

 

  git이 파일을 추적하고 스테이지에 올리는지 과정을 살펴본다. 먼저, 프로젝트 폴더에 git 초기화를 하고 README.md와 app.js를 생성한다고 가정하고 모두 한 번도 커밋되지 않은 상태이기 때문에 파일 상태는 추적 안됨(untracked)이다. 

 

 

  다음으로, add 명령어를 통해 두 파일 모두 스테이지에 올리면 파일 상태는 스테이지됨(staged)으로 바뀐다. 

 

 

  다음으로, commit 명령어를 통해 하나의 버전으로 만들면 파일 상태는 수정 없음(unmodified)으로 바뀐다. 수정 없음으로 된 파일은 다시 수정을 할 수 있다.

 

 

 

  마지막으로, 다른 사람도 함께 협업 하기위해 push 명령어를 통해 원격 저장소에 업로드 하면 파일 상태는 그대로이다.

 

 

 

 


 

   Git에서 관리하는 파일의 4가지 상태 (2)   

 

  위에서 했던 작업에서 더 많은 작업을 한다고 가정한다. app.js 파일을 수정해서 파일 상태를 수정 없음(unmodified)에서 수정함(modified)로 바꾸고 app.css 파일을 새로 만들어 준다. 새로 만들었기에 파일 상태는 추적 안됨(untracked) 상태이다. 

 

 

   변경사항이 없는 README.md 파일은 스테이지에 올릴 수 없지만 add 하지 않아도 이미 올라가 있는 상태이며 나머지 두 파일은 모두 스테이지에 올린다. 이 때, 두 파일 상태는 스테이지됨(staged)로 변경된다. 

 

 

  커밋을 통해 버전을 또 하나 생성한다. 이 때의 커밋은 앞서 만든 커밋인 "프로젝트 초기화"와 연결되어 있기 때문에 git은 쉽게 app.js가 수정되었고 app.css가 추가되었다는 것을 알 수 있다. 커밋을 했기 때문에 세 파일 모두 수정 없음(unmodified) 상태로 변하게 된다.

 

 

  마지막으로,  push 명령어를 통해 원격 저장소에 업로드 한다. 이 때, 파일 상태는 그대로이다.

 

 


   정리   

  

 요약하자면 untraked(추적 없음), staged(스테이지됨), modified(수정함), unmodified(수정 없음), 총 4가지의 파일 상태가 존재하고 각각의 특징은 다음과 같다.

 

 

 

   SVN과 Git의 가장 큰 차이점   

 

  하나의 버전을 만들기 위해 Git에서는 다음과 같은 과정을 진행합니다.

 

    1. 변경서항을 선택(add) - 스테이지에 올리는 작업

    2. 선택한 변경사항을 하나로 묶어 버전으로 만들기(commit)

  

  하지만 커밋 객체에 변경사항의 묶음이 저장되어있지 않다. 변경사항만 부분적으로 저장하는게 아니라 변경된 파일이 통째로 저장되어 있다. 바뀐 것만 저장하면 될 것 같은데 왜 용량을 더 차지하게 파일을 전부 저장할까?

 

  Git이 등장하기 전에는 SVN(SubVersion)과 같은 버전 관리 시스템이 제일 많이 쓰였다. 이 둘의 가장 큰 차이점은 아래 그림과 같이 변경사항만 저장하는가이다. 

 

 

 단순하게 생각하면 전체를 저장하는 Git보다는 차이점만 저장하는 SubVersion 방식이 용량 면에서도 좋고 속도도 빠를 것 같지만 조금 더 생각해보면 SubVersion 같은 방식은 버전을 보여줄 때 파일이 만들었던 맨 처음부터 거슬러 올라가 바뀐 점을 모두 반영해야 한다는 불편함이 있다.

 

 예를 들어, SubVersion에서는 README.txt 파일이 백 번 바뀌었다면 백 번의 계산을 모두 해야한다. 하지만 Git은 바로 앞에서 바뀐 커밋이랑 비교하는 연산 한번 만 하면 된다. 그리고 바뀌지 않은 파일은 링크만 저장하기 때문에 용량도 적고 계산하지 않아도 된다. 

 

   소스트리에서 변경된 사항 커밋(Commit)   

 

  파일을 수정하고 소스트리를 확인해보면 다음과 같이 변하게 된다. 빨간색 부분을 자세히 보면 

     

       1. 아까와는 다르게 커밋하지 않은 변경사항이라는 텍스트가 보인다.

       2. 스테이지에 올라가지 않은 파일 부분에 수정한 파일들의 목록을 확인할 수 있다. 

 

 

  이제 버전 관리를 위해 초록색 부분의 커밋 버튼을 누른다. 커밋을 누르면 첫 번째 사진과 같은 화면으로 바뀌게 되고 여기서 커밋을 하고자 하는 파일을 [+] 버튼을 이용해서 스테이지에 올리거나 [모두 스테이지에 올리기] 버튼을 이용해서 수정한 모든 파일을 스테이지에 올린다.

 

[커밋] 스테이지에 파일을 추가하기 전

 

[커밋] 스테이지에 파일을 추가한 후

 

  수정한 파일을 스테이지에 올렸으면 이제 진짜 커밋을 생성해야 한다. 맨 아래에 커밋 메세지를 작성하고 커밋 작성 버튼을 누르면 커밋이 생성된다. 이것은 CLI 환경에서 git commit -m "index.js API 경로 추가"와 동일하다. 

 

커밋 메세지 작성

 

  커밋을 생성하면 다음과 같이 "커밋할 내용 없음"이라는 화면이 뜬다. 그리고 [히스토리]탭으로 가면 커밋 내역이 업데이트 된 것을 알 수 있다. 아직 원격 저장소에 올리는 Push 작업을 하지 않았으므로 로컬 저장소와 원격 저장소의 버전이 다른 것을 알 수 있다. 그리고 밑으로 가면 실제 커밋한 내용에 대한 정보를 확인할 수 있다. 그리고 맨 위 초록색 부분인 Push 버튼의 상태가 바뀐 것을 확인할 수 있다. 

 

 

 


 

   소스트리에서 커밋을 원격저장소 푸시(Push)  

 

 

 

 

  위에서 로컬 저장소의 버전과 원격 저장소의 버전이 다르다고 하였는데 자세히 살펴보면, 로컬 저장소 버전은 master라는 꼬리표가 붙어있고 원격 저장소 버전에는 origin/master라는 꼬리표가 붙어있다. origin은 연결한 github 원격 저장소의 별명이다.

 

 예전에 git remote add origin github 주소 라는 명령어를 수행했었다. 이것은 origin이라는 이름으로 해당 github 주소의  원격 저장소를 추가하라는 명령어이다. 만약,  git remote add orange github 주소라고 입력했으면 origin 대신 orange라는 별명이 보였을 것이다. 정리하면 origin 꼬리표는 원격 저장소의 현재 버전 상태를 가리키는 커밋에 붙어있다고 할 수 있다. 

 

 master는 커밋을 올리는 줄기의 이름이다. [히스토리]탭으로 가면 커밋이 하나의 줄기로 이어져 있는 것을 볼 수 있다. 따로 줄기를 생성하지 않으면 git은 master라는 기본 줄기에 커밋을 올리게 된다. 

 

 종합해보면 맨 처음 master는 내 컴퓨터 로컬 저장소의 버전을 그 다음 origin/master는 github 원격 저장소의 버전을 가리키는 것이다. 따라서 위 사진에서는 내 컴퓨터의 로컬 저장소의 버전은 'index.js API 경로 추가'인데 원격 저장소의 버전은 하나 이전인 'index.js 경로 추가' 상태라는 것이다. 

 

 이제 새로 생성한 커밋을 초록색 부분의 Push 버튼을 눌러 원격 저장소에 업로드해보면 다음과 같은 화면이 뜬다. 

 

 

  위 화면에서 master에 해당하는 체크박스를 체크하고 Push 버튼을 누르면 업로드하는 과정이 나오게 되고 업로드가 완료된다. 이 동작은 git push origin master와 동일하다. [히스토리] 탭으로 가면 원격 저장소에도 최신 커밋 상태가 반영된 것을 확인 할 수 있다. 

 

 

   소스트리에 로컬 저장소를 추가   

 

  소스트리를 실행하고 상단 탭을 보면 아래 그림과 같은 탭이 있을 것이다.

 

 

  셋 다 소스트리에 저장소를 추가하는 방법인데, 각각의 역할은 다르다.

 

 

  [로컬 저장소를 소스트리에 Add]

 

    1. 탭에서 [Add] 버튼을 누른다.

    2. 작업 경로란에 작업했던 폴더를 선택하여 추가한다.

 


 

   로컬저장소의 핵심은 .git 폴더   

 

  Git은 로컬 저장소인 .git 폴더에 버전 관리한 내용과 원격 저장소의 주소 등 필요한 정보를 저장한다. 

 

 

 

 

   Spring boot   

 

 

- https://github.com/spring-projects/spring-boot

 

spring-projects/spring-boot

Spring Boot. Contribute to spring-projects/spring-boot development by creating an account on GitHub.

github.com

 

 

   Express   

 

 

- https://github.com/goldbergyoni/nodebestpractices

 

goldbergyoni/nodebestpractices

:white_check_mark: The Node.js best practices list (August 2020) - goldbergyoni/nodebestpractices

github.com

 

 

    색 테마 바꾸기    

 

    1. [파일] - [기본 설정] - [색 테마] 선택

    2. 원하는 색을 클릭하여 적용

 

 

 

   한국어 언어 설정하기   

 

    1. Ctrl + Shift + X 또는 좌측 여러개의 아이콘 중 밑 아이콘(확장 아이콘)을 선택한다.

    2. 검색창에 "korean" 이라고 검색한 뒤 , [Korean Language Pack for Visual Studio Code]를 선택해 설치

       한다.

    3. 재시작 안내 메세지가 뜨면 재시작 버튼을 누른다.

  

 

   소스트리 설치   

 

 소스트리(Source Tree) GUI 환경에서 git을 사용할 수 있는 프로그램이다. 커밋, 푸시, 브랜치 등을 CLI와 같이 명령어를 입력하여 실행하는 것이 아닌 버튼을 클릭하는 방식으로 실행된다.  

 

  [소스트리 설치 - Window 버전]

 

    1. https://www.sourcetreeapp.com/ 에 접속하여 [Download for Window]를 클릭한다.

    2. 다운로드가 완료되면 [Atlassian 소프트웨어 라이선스 계약 및 개인정보 보호정책]에 체크를 하고

        Download 버튼을 누른다.

    3. Registration 항목에서 Bitbucket을 선택하고 다음을 누른다. 아틀라시안(Atlassian) 계정 창이 뜨면 회원

        가입을하고 로그인을 한다. [grant aceess] 버튼을 누르면  Authentication Successful이라는 화면이 나

        오게 되고 인증에 성공한다.

    4. 도구설치 항목에서 Mercurial 항목을 체크를 해제하고 다음을 누른다. 

    5. 소스트리에서 Git을 사용할 때 기본 계쩡으로 사용할 Git 계정을 설정하는 화면이 나오고 예전에 작업했던

       git config --global user.email 과 name에 입력했던 내용을 입력한다.(아마 자동으로 입력되어있을 것이

       다.)

    6. SSH 키를 불러오겠냐는 확인창에서는 아니오를 누른다. 

 

 


 

   소스트리에서 Github 로그인 하기   

 

  [Github 로그인]

 

    1. 소스트리 좌측의 계정에서 마우스 오른쪽 버튼을 클릭하고 [계정 편집] 메뉴를 선택한다. 

    2. [호스팅 계정 편집] 창이 뜨면 호스팅 서비스를 Github로 바꿔주고 하단에 [OAuth 토큰 새로고침] 을 클릭

        한다.

    3. Github 인증을 마치면 실제 원격 저장소 목록이 나온다. 

    4. 도구설치 항목에서 Mercurial 항목을 체크를 해제하고 다음을 누른다.