외관은 자연과 어울리도록 조성했고, 내관은 팔만대장경의 장경각을 모티브로 만들었다고 한다.
과거 팔만대장경의 장경각이, 현대에 와서 데이터센터가 되었다고 생각하니 데이터센터의 의미가 또 색다르게 느껴졌다. 데이터센터의 모습을 보니 현대의 21세기 장경각이라 부를만하다는 생각도 들었다. 미래에는 또 어떤 장경각이 생길까? 지금도 이렇게나 최신화-최적화 되어있는데 미래에는 또 어떤 기술이 접목될까. 데이터센터에는 뭔가 흥미가 생긴다.
데이터센터에는 4 가지 중요한 구성요소가 있다. 전력, 서버, 쿨링, 운영 및 관리이다.
먼저 전력은, 전력손실을 최소화하기 위해 각종 기능들이 적용되어 있으며, 각종 사고(정전 등)시에도 안정적으로 전원이 들어와있을 수 있도록 하기위해 UPS 등의 기능이 사용중이다. 사용자에게 언제나 데이터를 보내주기위해, 데이터를 관리하기 위해 1분 1초도 안멈추고 열일중이다.
서버
효율적으로 전력을 사용하고, 네트워크를 연결하는 것을 생각하며 서버실의 규모와 구조를 생각하는게 데이터센터를 구상할 때 가장 중요한 일이라고 한다. 방대한 양의 서버를 잘 다룰 수 있도록 설계하는게중요하다. 데이터센터가 현대인들에게 중요한만큼, 전쟁이 나면, 적 나라의 각종 대기업 데이터센터 서버실부터 폭파시켜야겠다는 생각이들었다. (뜬금없지만) 그러면 검색엔진 중단에 SNS 통해서 연락할수도 없고.. 엄청난 혼란이 야기될 것 같다.
쿨링
매일매일 쉬지않고 돌아가니, 데이터센터에서의 쿨링은 매우 중요한 요소이다. 네이버의 데이터센터는 AMU 라는 쿨링 시스템을 도입하여 사용중이라고 한다. 이후 NAMU로 업그레이드 된 쿨링시스템을 도입하는 등, 중요한 만큼 효과적, 효율적인 쿨링을 위해 노력하고 있다.
운영관리
데이터센터에서는 데이터의 유실을 막는 이중화설계(분산저장)를 한다고 한다. 예를들어, 네이버 블로그에 글을 작성하면, 만일의 상황(글이 날라가거나..)에 대비해 여러 데이터로 저장한다는 것이다. 한 센센터 저장하는 것이 아니라, 곳곳의 센터에 나눠 데이터를 저장한다고 한다. IT 대기업은 정말 대단하다고 생각했다. 또, 데이터의 유출을 막기 위해 전문보안 기술진이 상주하며 데이터 보안에 힘쓰고 있다고 한다. (현재까지 네이버의 데이터 해킹건이 0건이라고 한다.)
애자일의 탄생 배경은, 소프트웨어 개발에 있어 입력값, 출력값이 명확할 수가 없고, 확정된 목표가 존재할 수 없기 때문이다.(즉, 예측불가하다) 소프트웨어의 특성상 이슈는 존재하며, 고객의 니즈가 달라질 수 있기 때문이다. 아무리 잘 완성된 소프트웨어더라도 고객의 니즈에 맞지 않는다면 쓸모없는 소프트웨어가 된다. 이처럼, 변화할 수 있음을 인정하고, 규정된 프로세스에서 벗어나 유연성있는 방법론을 사용하자는게 애자일의 목표이다.
애자일은 점검, 조정, 변화를 수용하는 “적응적 프로세스”와, 목표시스템을 여러 번 나눠 출시하자는 “반복점증적 프로세스”에 그 근간을 둔다. 이 두 프로세스와 애자일의 차이점은 출시주기가 짧고 유연하다는 점(약 2~4주), 소통과 협력의 극대화를 추구한다는 점이라고 할 수 있다. 애자일에애 중요시하는 것은 자기조직화팀, 적응성, 고객의 참여, 반복 점증적 개발이다. “인간 중심”적 방법론이라고 할 수 있겠다.
2.애자일 방법론 기원, 본질
흔히 많이 쓰는 애자일 방법론은 Scrum이다. 추정, 조정의 경험적 관리 기법이다. Scrum , 즉 애자일의 원칙은 총 4가지가 있다.
개인과 상호작용 >> 프로세스,도구
동작하는 소프트웨어 >> 포괄적인문서
고객과의 협력 >> 계약협상
변화에 대응>> 계획수행
>> 기준 왼쪽에 있는게, 오른쪽에 있는 것보다 중요시 되어야 한다는 것이다.
(다만 그렇다고 왼쪽에 있는걸 무시하자는게 아니다!)
애자일 방법의 적용으로는 일일 스탠드업, 제품 백로그, 짧은 출시주기, 회고, 스프린트 계획 세우기 등이 있다.
컨테이너는 하드웨어를 가상화하는게 아니라, os를 지원하는 기능을 사용하는 프로세스이다. 다시말해, 격리된 환경에서 프로세스를 실행하는 것이다. (운영체제라기보단 프로세스)
이미지
파일들의 집합. 프로세스를 실행하기 위한 환경.
컨테이너 가상화가 필요한 이유
컴퓨터 환경 보편적이지 않기 때문이다. 예를들어 MYSQL -> 설치방법/되는과정이 다 다르다.
특수한 환경이 SW에 필요하다면 상태관리의 어려움, 서버관리 어려움, VERSION관리의 어려움 등이 많다. 그러나 도커를 이용한다면 깨끗한 환경에서 APP 실행환경까지 최단경로로 만들어준다. 또한, 이미지를 만들면 무조건 작동한다는 신뢰성도 보장되어있다. 항상 같은 환경을 보장하니, 초강력한 포터블앱이라고도 볼 수 있다. 이미지로 만들면 공유가 가능하며, 여기서 되면 저기서도 된다는 재현성을 보장하기에 강력한 서버 툴로 자리잡았다.
여러분도 이 문제를 겪고계신가요? 그렇다면 일단 SSD 구입 후 업그레이드를 생각하시기보다,
안쓰는 파일, 필요없는 파일들을 정리합시다.
저는 이렇게 파일을 정리해서 남은공간을 3기가 --> 56기가 까지 늘렸습니다.
(그 후 또 이것저것 다운로드를 받아서 37기가가 남게 되었네요)
저는 일단 Wise Disk Cleaner 라는 무료 컴퓨터 청소 툴을 이용해서 일반 정리/ 고급 정리 다 해주었고,
네이버 클리너 툴도 사용해서 이것저것 더 청소를 해주었습니다.
사실 이런 클리너를 이용해도 실제 "나한테 필요없는파일"을 다 지워주진 못합니다.
그러니, 노트북의 프로그램 파일 삭제/수정 에 들어가서, 하나하나 다운로드 되어있는 파일을 살펴본 후, 제게 필요없는건 과감히 지워주었습니다. 최근 사용 기록이 언제인지도 함께 나오니, 꽤 오래 안쓴건 과감히 지워버리면 됩니다.
(정말 오래전에 다운받았던 게임들, 예전에 잠깐 쓰고 말았는데 용량만 엄청나게 차지하던 그래픽, 영상 제작 툴들 등..)
그리고!! 가장 효과를 많이 봤던건, 다운로드 폴더를 싹 날려주었습니다. 다운로드 폴더에있는걸 3년 반동안 안날리고 계속 가져가니까, 임시파일만 20GB가 쌓여있더라구요 -_-.... (다운로드 폴더는 임시 파일일뿐, 이걸 날린다고 저장된파일이 날라가는게 아니니 걱정말고 싹 청소하면됩니다.)
이렇게해서 약 50기가의 저장공간을 벌었는데, 그래도 RAM 을 추가하는김에 SSD를 추가해야겠다 싶어 SSD를 구매했습니다.
-->
저는 WD Blue SN550 NVMe SSD M.2 2280, 250GB를 구매했습니다.
RAM을 구매하실때와 마찬가지로, 본인의 노트북에 어떤 SSD 가 적합한지 알아보고 구매하셔야합니다.
제 노트북의 경우, 22*80 사이즈의 M.2 식 SSD 여야 했고, 최대 가능 용량이 250GB였습니다.
SSD는 NVMe와 SATA 방식으로 나뉘는데요, 저는 둘 모두를 지원하고 있어서 더 빠르고 성능이 좋은 NVMe식을 구입했습니다. (웬만하면 SATA방식보다 NVMe를 구입하시는걸 추천드려요 *단, 본인노트북이 지원하는지 확인해야함)
참고로 저에게 원래 끼워져있던건 SATA방식의 SSD 였습니다. 포트가 둘 다 지원한다면 하나는 SATA, 하나는 NVMe로 끼워줘도 됩니다.
SSD 끼우는데 가장 큰 문제점은 나사였습니다. SSD는 나사를 풀고, SSD를 넣고, 다시 나사를 조이는 식으로 고정을 하는데요..
이 나사가 진짜 드럽게 안빠집니다.
나사가 안풀려서 끙끙대다가.. 이건 드라이버 문제다 싶어 포기했습니다. 나중에 드라이버 사서 다시 끼워보려구요.
(10.09 추가) 드라이버 다시 사서 풀었더니 잘 풀립니다!! 드라이버 정보는 맨 아래에 적어두었습니다.
끼우다가 사진을 찍는걸 깜빡했는데, 사진을 재탕하면..
네모 표시 되어있는 SSD 아랫쪽 나사를 풀고, SSD 라고 써져있는곳에 홈에 맞게 끼우시면 됩니다.
그리고 다시 나사를 조여주면 끝입니다!
다만 자동으로 인식되는 RAM과 달리, SSD 는 자동으로 인식이 안됩니다.
장착 후 디스크가 보이지 않더라도, 당황하지 마시고 아래의 작업을 해주세요.
1. 먼저 윈도우 검색창을 이용해 컴퓨터 관리창에 들어가주세요
2. 오른쪽에 있는 저장소 - 디스크 관리를 눌러주세요. 그러면 아래와 같은 화면이 뜰텐데, 확인을 눌러주세요.
* 만약에 확인을 안누르고 취소를 누르셨다면, 아래 사진의 네모 표시가 된 곳에서 마우스 우클릭하시고,
'디스크 초기화' 를 누르시고 확인 누르시면 됩니다.
3. 확인 후 나오는 단순 볼륨 만들기 마법사를 실행해주세요.
4. 그러면 끝입니다! 새로운 디스크가 할당된것을 확인할 수 있습니다.
다섯번째로, 노트북 분해용 드라이버 공유합니다! (비추천까지)
먼저 안맞았던 드라이버입니다.
저는 쿠팡을 주로 이용해서, 쿠팡에서 드라이버를 구매했는데요..
제일 첫번째로 썼던 드라이버는 이겁니다. Tree 정밀 드라이버.
사지마세요. 이거로는 노트북 하판 나사도 못엽니다. 저는 이걸 샀다가.. 반품하고 다시 샀습니다.
안녕하세요. 오늘은 학생회 관련 게시글이자, SW 관련 주제인 메타버스에 대해서 다루려고 합니다.
메타버스! 요즘 핫한 주제이지요. 메타버스는 코로나 19의 확산세로 대면 행사를 할 수 없는 현 상황에 맞추어
온라인으로 비대면 행사를 재미있게 구성할 수 있게 해주는 프로그램입니다.
사실 학생회를 하고 있는 저 또한 우리 산업경영공학과 학우들을 위해, 이번년도 학과 공식 마지막 행사인 'IE의 밤'을 어떻게 준비할지 고민을 많이 했었는데요,
지난번 21학번 신입생 오티때 진행했던 '줌을 통한 팀 대항 레크레이션 게임 진행'의 주제는 다시 하기에 식상해서, 이번엔 메타버스를 이용해 재미있게 진행하기로 하였습니다.
다만 조사해보니 메타버스도 그 종류가 다양했습니다. 그리고 저희의 니즈에 맞지 않는 메타버스 프로그램들도 많았구요. 가령, 무거운 프로그램을 다운받아야 한다거나/ 모바일 베이스로만 실행이 된다거나/ 3D의 예쁜 그래픽이아니라 2D그래픽이라거나/ 레크레이션을 하기에 적합하지 않은 프로그램이라거나/ 예산이 너무 초과되거나/ 업체가 맡아 진행하는데 이미 진행중인 다른 단체가 있다거나/ 100명 이상의 단체가 사용하기 불안정하다거나/사용법이 직관적이지 않다거나 등등...
이런저런 문제점들이 많아 고민이 있었는데, 딱 단체 행사를 위한 메타버스 프로그램을 발견해 저와 같은 고민을 하고있을 여러분께 소개해드리고자 가지고 오게 되었습니다.
메타버스 : 게더타운
게더타운은 바람의 나라(게임) + 줌 을 합친것같은 귀엽고 깔끔한 캐릭터 및 공간 디자인이 매력적인 메타버스 입니다. PC 및 모바일로 사용이 가능하고, 최대 500명의 동시접속사를 수용할 수 있으며, 25인 이하로는 비용이 무료이고 25인 이상부터 1인당 2달러씩 비용이 발생합니다.(2시간 기준)
게더타운은 각 사용자가 캐릭터를 커스트마이징하여 나만의 3D 캐릭터를 방향키로 움직이며 돌아다닐 수 있으며, 다양한 어트랙션을 활성화하여 편집자(관리자)가 지정해둔 음악을 듣거나, 글씨를 보거나, 게임(테트리스 등)을 하거나, 영상을 보거나 할 수 있습니다. --> 이를 통해 다양한 게임의 구성이 가능합니다.
사용자끼리 일정 구간 이상 가까이 가게되면, 줌처럼 영상이 켜지며 서로의 목소리가 들립니다. 일정 구간을 벗어나면 자연히 연결이 끊깁니다. 일반 채팅 및 비밀 채팅을 할 수 있고, 각 채널별로 관리가 가능합니다. 별도의 다운로드 없이, 크롬으로 바로 들어갈수있어 접근이 용이합니다.
메타버스의 공간은 여러개 생성이 가능하며, 다양한 채널을 임의로 연결하여 다양한 구조를 만들 수 있습니다. 가령, 방탈출 게임/보물찾기 등을 만들 수 있습니다. 공간은 사용자가 임의로 꾸밀수도, 기본으로 제공되는 템플릿들을 이용할수도, 다른 사용자가 만든 공간을 가져올 수도 있습니다. 한 공간을 편집하는 사람은 여러 명으로 지정이 가능해, 여러 명이 공동 작업을 할 수도 있습니다. 편집 또한 코딩이 아닌, 꾸미기 툴을 이용하는 것으로 아기자기하여 꾸미는 재미가 있습니다.
안녕하세요 :> 지금까지 Git 알아보기 문서에서 Git 에 대한 기본적인 내용들을 얼추 다뤄보았죠!
그래서 이번에는 Git 으로 실전에서 어떻게 협업을 하는지를 알아보려고 합니다. 프로젝트가 수행되는 과정을 처음부터 끝까지 함께 살펴볼텐데요. 이번 글에서 프로젝트를 수행하는 개발자는 2명(A, B)이라 가정하겠습니다.
프로젝트 수행과정
수행 0. 기존에 Gitlab 을 이용해 A가 개발하고 있던 프로젝트에 B가 참여하기로 했습니다.
수행 1. 먼저 A 가 B 를 프로젝트에 초대해야겠죠. A는 Gitlab의 프로젝트 페이지 -> settings -> Members -> select members to invite 란에 B의 계정 혹은 이메일을 입력하고 Add to project 를 누릅니다.
수행 2.A는 해당 페이지의 하단 부분의 Existing members RacingGround 에서 프로젝트에 대해 B가 가지는 권한을 수정합니다.
Gitlab 에서는 프로젝트에 참여하는 권한에 대해 멤버 별 여러 등급으로 나누어 관리가 가능합니다.
디폴트값은 가장 낮은 등급인 Guest 인데요, 이 등급으로는 프로젝트에 제대로된 참여가 불가합니다. 프로젝트에 개발자로 참여하려면 최소한 Developer 로 권한을 수정해주어야 합니다.
참고로, A 의 등급인 maintainer 는 프로젝트에 대한 모든 권한을 갖고있는 최상위 등급을 말합니다.
* 잠깐! 알고가기 Fork 가 뭘까?
Git을 이용해 협업을 할 때, 크게 두 가지 방법론이 있습니다.
1. Git clone 을 통해 gitlab 서버의 프로젝트를 팀원의 컴퓨터로 복사해와서 코드를 작성하고, git push
이 방법은 기존에 저희가 알아보았던 방법이죠. 이 방법의 단점은, 개발자가 만든 소스코드가 바로 프로젝트의 소스코드에 병합된다는 것입니다. 한 명의 개발자가 만든 소스코드가 늘 완벽하기란 불가능 하지요. 그래서 이 방법은 실전에선 거의 사용되지 않습니다.
2. 원래 프로젝트(원본프젝)와 똑같은 프로젝트(복제프젝)를 gitlab 서버의 팀원의 계정 아래에 별도로 카피해 생성하기.
보통 실전에서는 이 방법을 사용합니다. 원본프젝을 복제해 복제프젝을 내 계정에 갖다두고, 복제프젝을 git clone 으로 내 컴퓨터에 가져온 다음, gitlab 서버의 복제프젝에 git push 를 하는 방법입니다. (주의 : 원본프젝에 push가 아닙니다)
이렇게 내 계정의 복제프젝에 업로드가 되면, 이후 원본 프젝에 merge request 를 합니다. merge request 란, 작업물이 완성되었으니 확인하고 이상이 없다면 우리 프로젝트에 반영해달라고 요청을 하는 것입니다. 이후 프로젝트의 관리자가 해당 merge request를 확인하고, 이상이 없다면 승인, 혹은 거절을 합니다.
자 그러면, 다시 프로젝트 수행과정으로 돌아갑시다.
수행 3.B는 지금까지 A 가 한 최신의 커밋을 가져오기 위해, 웹페이지의 프로젝트의 상단부에 있는 " Fork " 란을 누릅니다.
그러며 Fork Project 창이 뜨는데요, 누구의 계정에 Fork 할지 선택합니다. 이렇게 하면 원본프젝과 동일하지만 별개의 프로젝트인 나의 복제프젝이 생성됩니다.
수행 4. B는 생성된 내 계정의 복제프젝을 git clone으로 내려받고 확인합니다.
B가 하는 수행4의 세부 과정 예시는 이렇습니다. (VScode 터미널에서 실행한다고 가정)
- cd .\desktop\ : 바탕화면으로 이동
- mkdir {만들 폴더명] : 프로젝트 디렉토리를 넣을 폴더 생성
- cd {폴더명} : 생성한 폴더 안으로 들어가기
- git clone {복제용 프로젝트의 url} : B의 계정에서 gitlab 서버의 (복제)프로젝트를 받아옵니다. (복제프젝은 원본프젝에 비해 사용자 이름부분만 다릅니다.)
- 정보를 요구하는 창에 아이디와 암호를 입력합니다.
- ls : 해당 폴더에 잘 clone 되었는지 디렉토리를 확인합니다.
- cd {이동할 폴더명} : clone 한 프로젝트의 폴더로 들어갑니다.
- git log --all --graph : 지금까지 A가 만든 branch를 확인합니다.
수행 5.B는 커밋을 작성한 후, 자신의 계정의 복제 프젝에 올립니다.
- git checkout develop : master branch에 위치한 HEAD를 develop branch 로 옮깁니다.
- git push : gitlab의 B계정의 복제프젝에 지금까지 커밋한 내용을 반영합니다.(현재 헤드는 develop branch를 가리키고 있습니다. 자동으로 develop branch에 해당하는 신규 커밋들만 복제용 프젝에 업로드 됩니다. 여기서, 그 외의 것도 모두 업로드 하고싶다면 개별적으로 지정해줘야 합니다. 예를 들어, master branch도 업로드 하고싶다면 git push origin master 라고 하면 됩니다.)
- 바로 뜨는 New merge project 창에서 Change branches 를 눌러 업로드할 branch를 변경합니다. 아래의 그림에 보이는 From ~ into ~ 를 확인하고 변경해주면 됩니다. 현재 원본프젝의 master branch로 되어있는데, develop으로 변경합니다.
- Title 과 Description 란에 지금껏 작성한 커밋에 대한 설명을 적습니다. merge request 를 적는 규칙은 회사마다 다릅니다. 이후 Assignee 를 설정해 내가 한 merge request 를 가장 먼저 점검할 담당자를 지정해줍니다. 이 경우 A를 지정해주면 되겠지요. (이후 나오는 Milestone 과 Labels 는 일단 넘어가겠습니다.)
- 페이지의 하단에서 신규 commit 들과 commit으로 인한 변경 사항을 확인하고 submit 합니다.
수행7. A는 gitlab 페이지에서 B가 보낸 request를 확인합니다. 커밋과 체인지에서 변경사항을 한눈에 확인할 수 있으며, merge request 에 대해 논의하고 싶다면 discussion 카테고리에 질문을 남기면 됩니다. 이후 B가 확인하고 답장을 해주겠죠?
수행8. A는 논의 및 검토가 끝난 후 Merge 버튼을 누릅니다. 원본 프로젝트를 확인하면, B가 올린 커밋들이 새롭게 업로드 된 것을 확인할 수 있습니다. B의 커밋과 함께, 새로운 커밋이 만들어진것도 확인할 수 있죠. 다른 복제본 프로젝트에서 보낸 매 Merge Request 마다 그에 대응되는 Merge commit이 생성되기 때문에, 우리는 정확한 이력을 파악할 수 있습니다.
MergeRequest 정책
여기서 한 가지 의문이 들 수 있는데요, B가 업로드 한 branch에 대해 Fast-Foward merge 를 하면 되는데, 왜 굳이 새로 커밋을 생성하였는가 하는 것입니다. Fast-forward 머지를 할 수 있는 경우에도 새 Merge Commit을 만들게 되면 커밋 히스토리의 가독성이 다소 떨어지게 되겠지요.
새로운 커밋을 생성할지, Fast-forward merge를 할지는 적용한 MergeRequest 정책에 따라 달라집니다.
gitlab 페이지의 settings 카테고리에 가면, MergeRequest 설정 부분을 확인할 수 있는데요.
위의 그림을 보면, 현재 merge commit 정책이 적용되어있는 것을 볼 수 있습니다.
Merge commit 정책은 어떤 경우라도 항상 merge를 할 때, 새로운 commit 을 생성하겠다는 것입니다.
맨 아래의 Fast-forward 정책을 선택하면, Fast-forward merge 가 가능할 때 새로운 commit을 생성하지 않고, 실제로 fast-forward merge 를 해줍니다. 이외 나머지 두 정책은 fast-forward 가 가능해도 항상 새로운 merge commit을 생성합니다.
더 알아보기
git push 를 해줄때, 내 commit이 gitlab의 원본 프로젝트를 포함하지 않는다면 push가 되지 않는다고 했었죠.
그러면, 그런거에 상관없이 지금까지 gitlab 서버에서 진행된 commit log 들을 내 컴퓨터에 있는 commit log로 몽땅 덮고 싶을땐 어떻게 해야할까요?
그런 경우엔 git push --force 명령어를 입력해 강제로 업로드를 해주면 됩니다. 이 명렁어는 내 commit이 gitlab 프로젝트의 commit을 다 포함하지 않더라도 무조건 push 해라 라는 명령어 입니다.
사실 이 명령어는 실무에서 절대 쓰지 않는다고 볼 수 있습니다. 만일 불가피하게 사용할때는 반드시 주의하시길 바랍니다.
오늘의 포스팅이 git을 이용해 협업해보려하는 초보 분들께 도움이 되었으면 좋겠네요.
다음 글에서는 기타 Merge 정책 이해, Git Rebase 해보기, Detached HEAD 이해하기 등의 내용을 다뤄보겠습니다.
Branch 란 우리말로 나뭇가지, 분기된 흐름 등의 뜻을 가진 단어이죠. 깃에서는 특정 커밋을 가리키는 '포인터'를 의미합니다. Branch는 최신 커밋을 가리키는 흐름이며, 하나의 프로젝트에서 특정 목적으로 서로 다른 개발 흐름을 병렬적으로 가져가기 위해 사용합니다. 이러한 브랜치를 통해 여러 개발자 혹은 여러 개발팀이 한 프로젝트의 세부 과제를 병렬적 진행하며, 각 목적에 맞는 개발 흐름을 관리할 수 있습니다.
이미지 출처 : 한국정보산업연합회
위의 그림처럼, master branch(기본으로 셋팅되는 main branch) 에서 개발 분야를 feature-A 와 feature-B로 나눠 각각의 팀이 개발을 진행하기로 했을 때, branch 를 나누어 관리할 수 있는 것이죠. branch는 나누거나 합치기가 가능합니다.
git log를 입력할 때, HEAD -> master 라는 문구를 보셨을겁니다. master 란, 앞서 말했듯이 Master branch 의 master 이고, 현재 3번째 커밋을 가리키고 있는 것을 알 수 있습니다. HEAD 는 branch를 통해 특정 커밋을 가리킵니다. 즉, 여기서 master branch를 통해 3번째 커밋을 가리키는 것 입니다.
지금 깃 랩 서버에 연동시키지 않은 상태라 보이지는 않지만, 깃 랩 서버(이름 : origin)에 연동하게 되면 origin/master 라는 붉은 단어가 뜨는데요, 이것은 깃 랩 서버에 존재하는 master 브랜치를 의미합니다. 만약, HEAD -> master, origin/master 라고 되어있디면 지금 컴퓨터의 master branch 와 gitlab 서버의 master 브랜치가 모두 3번째 커밋을 가리키고 있다는 의미이죠.
Branch 만들어보기
1. 한 갈래로 나누기
git branch {branch_name} 입력
git branch develop 를 입력해 develop branch를 생성해주도록 하겠습니다.
기존에 있던 master branch 에 더해, develop branch 가 생겼네요. branch 를 생성할 때는 나누기를 원하는 기점(커밋)으로 이동해 HEAD를 옮겨주고 생성해주면 됩니다.
보통 master branch 에는 배포할 정도로 완성된 커밋들만 넣고, develop branch 에는 개발하는 중에 사용할 커밋들만 넣습니다.
커밋 간 HEAD를 옮기는 법은 살펴봤는데, 브랜치 간 HEAD를 옮기려면 어떻게 해야 할까요?
git checkout {branch_name} 을 입력해주면 됩니다.
git checkout develop 를 입력해주면,
HEAD 가 develop branch 를 가리키는 상태로 바뀐 것을 확인할 수 있지요. 이 상태에서 commit 하면 이제 새 커밋들을 develop 브랜치가 가리키게 됩니다.
지금까지 순서를 정리해보면, 분기점이 될 커밋으로 이동해 Branch 생성(git branch), 해당 Branch로 HEAD 이동(git checkout), Branch 에서 commit(git add, git commit) 로 정리할 수 있겠습니다. 위의 코드를 보면 분기점이던 세번째 커밋을 포함한 이전은 master branch 에, 이후의 커밋은 develop branch 에 속해있는 것을 볼 수 있죠. 나무의 기둥에서 뻗어나온 나뭇가지 같습니다. 이렇게, 병렬적으로 나눠서 개발할 필요가 있을때 각 작업에 별도의 브랜치를 할당해줌으로써 수행이 가능해집니다.
지금까지는 master branch 에서 다른 한 갈래로 뻗어나가는 branch를 다뤄봤는데요, master branch 에서 두 갈래로 나뉘어 버전관리를 하는 것도 실습해볼까요?
2. 두 갈래로 나누기
우리가 지금까지 만든 코드에, attack method 와 defend method 를 추가 개발할 것이라 해봅시다. 그리고 각 method 는 다른 팀이 하나씩 맡아 개발하여 관리할 것입니다.
그러면 분기점이 될 가장 최신 커밋으로 HEAD를 이동하고, feature-attack branch 와 feature-defend branch를 생성해주면 되겠지요. 그리고 attack method를 담당하는 팀은 HEAD를 feature-attack branch 에 이동시켜 attack method 소스코드를 커밋해 버전을 관리하고, defend method 를 담당하는 팀은 HEAD를 feature-defend branch 에 이동해서 defend method 소스코드를 커밋해 버전을 관리하면 될 것입니다.
3. 모든 branch 확인하기
이 때, attack method를 맡아 작성하는 팀은 HEAD가 attack branch에 가있을때 defend branch 의 내용이 보이지 않습니다. defend method를 맡아 작성하는 팀도, HEAD가 defend branch에 가있을때 attack branch 의 내용이 보이질 않죠. (master branch의 내용을 보입니다.)
위의 코드를 보면, HEAD가 feature-defend 로 가있을때 master branch와 defend branch의 commit log는 보이지만, feature-attack branch가 보이지 않는 것을 확인할 수 있습니다. (현재 attack method 가 커밋된 상태입니다)
만약, 현재 내가 있는 branch 가 아닌 모든 branch를 보고싶다면 기존의 git log 에 다른 옵션을 추가해 명령해주어야 합니다.
git log --all --graph 입력
--all 은 HEAD 가 가리키는 branch 뿐 아니라 모든 branch를 보겠다는 명령어입니다.
--graph 은 브랜치와 커밋간의 관계를 그래프 형식으로 보여달라는 명령어 입니다.
해당 명령어를 입력해보니 왼편에 나무와 비슷하게 생긴 graph가 생긴 것을 볼 수 있습니다. develop branch 에서 두 갈래로 갈라져 있는 것을 확인할 수 있고, 모든 branch 가 보이지요.
개발 실무에서는 여러 작업을 분담해 처리하기 위해 보통 develop branch 에서 여러 개의 하부 branch 를 생성할때가 많습니다. 그리고 하나의 branch 위에서 팀이 버전을 관리하며 작업해가는 형식이지요.
4. branch 의 병합
이제 각 branch 의 개발이 끝나고, 각각의 feature 브랜치에서 했던 작업을 병합하고 싶습니다. (즉, develop branch에 작업의 결과를 모두 반영하고 싶다는 것입니다) 그러면 어떻게 병합해야 할까요?
먼저 develop branch(결과를 반영하고싶은 branch) 로 이동합니다.
git merge {합쳐주고싶은 branch이름} 입력
git merge feature-attack 을 입력합니다. 이 명렁어의 의미는, HEAD 가 가리키고 있는 브랜치(현재 develop)에 feature-attack 에서 했던 작업을 병합해달라는 것입니다. 보다 상세하게는, 1. 현재 HEAD 가 브랜치를 통해 가리키고 있는 커밋 과, 2. merge 뒤에 쓴 브랜치가 가리키고 있는 커밋을 합쳐달라는 것입니다.
HEAD 가 가리키던 develop branch 와 feature-attack bracnh 가 병합된 걸 알 수 있습니다. 특히 develop branch 의 위치가, six commit 에서 Add attach method 의 위치로 이동해온 것을 볼 수 있는데요, 이 경우를 Fast-Foward Merge 라고 합니다.
Merge 로 branch 가 병합되는 경우에는, 두 가지의 경우가 있습니다.
- 기존의 branch(develop)가 merge를 당하는 branch까지 쭉 당겨져 오는 경우
- 두 branch를 병합한 새로운 커밋이 생성되는 경우
이 중 전자의 경우를 Fast-Foward Merge 라고 하는 것이지요.
Comfilict 발생시 대처
feature-attack branch의 병합을 완료했으니, 이제 feature-defend branch 도 병합해줍니다.
그런데, 이런! 병합 중에, 오류가 발생했습니다.
Auto-merging myfile.txt CONFLICT (content): Merge conflict in myfile.txt Automatic merge failed; fix conflicts and then commit the result.
이러한 오류 문구가 발생한 이유는, merge 중 충돌이 발생했기 때문입니다.
그림을 보면, feature-attack branch 와 feature-defend branch 의 일부 소스코드(attack 와 defend) 가 같은 라인에 위치해있다는 것을 볼 수 있지요. 여기서 문제가 발생합니다. 파이썬이 같은 라인에 다른 코드를 병합하려다보니, 어떤 라인을 선택해야 할 지 모르겠다는 것입니다. 이게 conflict 오류 발생의 원인이 됩니다. 이 경우에 파이썬은 각 파일에 표시를 남겨줍니다.
해결법은 간단한데요, 파일에 파이썬이 남겨준 오류 코드를 확인하고, 이 파일이 가졌으면 하는 최종 코드를 남겨두면 되는 것입니다. 예시의 경우처럼 둘 다 남기고 싶다면, 필요없는 부분을 지우고 원하는 코드의 모습으로 고쳐주면 됩니다. (괄호 수정)
코드의 수정이 완료되었다면, git add . 와 git commit 명령어를 사용해 커밋하면 되는 것이지요.
이제 각 branch 들이 develop branch로 합쳐지면서 새로운 커밋이 만들어진 것을 볼 수 있습니다. merge를 할 때, 새로운 커밋이 만들어지느냐 Fast-Forward merge가 발생하느냐는 대개 "흐름의 분기"의 차이에서 발생합니다. 가령, 기존 branch 와 병합하고픈 최신 branch 의 로그가 직선 모양으로 앞뒤로 위치한다면 merge를 할 때 최신 커밋을 가리키는 쪽으로 이동합니다.(Fast-Forward) 그러나 흐름이 중간에 갈라진 branch 끼리를 merge하면 새로운 commit 이 하나 더 생기는 것입니다.
point
저번에 branch 관련 내용이라며 넘어간 코드를 한번 살펴보죠.
git push -u origin master
이 명령어를 기억 하시나요? gitlab 서버에 프로젝트를 올리라며 push 해주는 명렁어라고 했었지요.
사실 이 명령어를 더 자세히 설명하자면, master branch 를 origin 이 의미하는 gitlab 서버 프로젝트에 올리라는 뜻입니다. push 나 pull 은 "branch 단위"로 작업이 이루어집니다. 즉, push 나 pull 뒤에는 branch 의 이름이 적혀집니다.
가령 git push -u origin develop 하면 gitlab origin 서버에 develop 브랜치가 올라갑니다.
-u 는 "--set-upstream" 의 약자로, 내 컴퓨터의 master branch가 항상 gitlab서버의 master 브랜치를 바라보게 하라는 의미입니다. 그래서 처음에 저렇게 적어주면, 이후 push를 할 때 git push 라는 간단한 명령어만 사용하면 되는 것이죠.
오늘 살펴본 branch 는 깃 전체를 관통하는 내용입니다.
branch가 무엇일까? 왜 필요할까? 어떻게 병합할까? 어떻게 외부 저장소에 올릴까? 등을 잘 알고 있어야 합니다.
생각보다 글이 조금 길어져서 원래 쓰려고 한 다른 내용을 못 썼네요.. 글이 너무 길면 읽기 부담스러우니..^^;
다음 글에서는 프로젝트의 전반적인 과정에서 git과 gitlab 을 어떻게 쓰는지, Fork/Clone, MergeRequest하는 법 등 실전편을 가져오도록 하겠습니다.
저번 시간에 우리는 작업에 대한 이력을 내 컴퓨터에 남길 수 있는 commit 하기를 알아봤습니다.
우리가 commit 하는 이유는 뭘까요? 작업 이력을 남겨두고, 원하는 시점으로 자유롭게 돌아다니기 위해서라고 할 수 있죠.
이번에는 저장한 commit 간 이동하는 방법에 대해 알아보려 합니다.
그리고 외부 저장소에 push/pull 해보는 것까지 다뤄보도록 하죠!
Git history 관리 방법
저번에 git log 를 통해 본 커밋 이력에서, HEAD 란 문자를 본 적이 있으실 겁니다.
HEAD 는 현재 내가 위치해있는 커밋을 가리키는 식별자 입니다. 보통 가장 최신의 커밋을 가리키고 있죠.
커밋과 커밋을 이동할때는 git reset 을 사용해줍니다.
1. 커밋 간 이동하기
git reset --{option} {commit_id} 입력
예시로, git reset --hard 8564 를 입력해주면, 워킹 디렉토리의 모습이 HEAD 가 가리키는 commit 의 모습으로 변하는 것을 확인할 수 있습니다.
git reset 명령어를 이용해, 우리는 언제든지 원하는 커밋으로 돌아갈 수 있는 것입니다.
명령어 중 --hard 의 부분은 옵션인데요, 옵션에 따라 working directory, Staging Area, Repository의 지정 커밋이 바뀝니다. 가령 위의 예시에서 워킹 디렉토리가 함께 바뀌는 이유는 hard 를 옵션으로 설정해주었기 때문입니다.
조금 헷갈리시나요? 옵션 별 차이를 간단하게 정리해보겠습니다.
2. 옵션 별 차이
이미지 출처 : 한국정보산업연합회
- 공통 : Repository 에서 Head 가 특정 commit을 가르킴.
- Hard : Staging Area 와 워킹 디렉토리가 특정 commit 으로 바뀜.
- Mixed : Staging Area 가 특정 commit 으로 바뀌나, 워킹 디렉토리는 바뀌지 않음 (가장 최근 커밋으로 유지)
- Soft : Staging Area와 워킹 디렉토리가 바뀌지 않음 (가장 최근 commit 으로 유지)
그렇다면 soft, mixed 옵션은 언제 사용하면 유용할까요?
예를 들어, 팀원A가 커밋1~6 을 만들었습니다. 그리고 지금은 워킹 디렉토리에서 커밋 6 에 대해 많은 작업을 했습니다.
작업을 하고나니 커밋 1~3은 괜찮지만, 4~6 은 너무 조금씩만 고쳐서 굳이 업로드 하지 않아도 될 것 같습니다.
이런 경우에, mixed/soft 옵션을 사용해서, 현재 작업한 워킹 디렉토리의 내용을 남기고 커밋3으로 이동합니다.
이 상태에서 커밋을 새로 하게 되면, HEAD 가 가리키는 커밋3 위에 새로운 커밋6이 쌓이기 때문에 불필요한 커밋을 없애고 필요한 커밋만을 보여주는 것이 가능합니다.
위의 그림을 보면, mixed/soft 옵션을 사용해 HEAD 만을 변경하고 커밋해 커밋7을 올리는 과정을 알 수 있지요.
git reset 의 옵션 중, hard 옵션을 사용할때는 특히 주의해야 합니다.
hard 옵션은 워킹 디렉토리를 다른 커밋의 버전으로 바꿔주기 때문에, 자칫하면 워킹 디렉토리에서 새롭게 작업하던 내용이 다 날라갈 수 있기 때문입니다.
3. 추가적인 명령어
- git status
git status 는 파일 상태를 알아볼 수 있는 명령어 입니다. 아래의 코드를 볼까요?
캡쳐에 포함되지 않아서 보이지 않지만, 제 디렉토리의 커밋1(이름 : 8564) 에는 BasicCar1 파일이 있고, 커밋2(이름 : aa08) 에는 현재 BasicCar1 파일과 BasicCar2파일이 있습니다.
코드를 보면 가장 처음에 hard 옵션을 이용해 커밋2의 워킹 디렉토리와 스테이징 공간을 불러왔습니다. 그리고 mixed 옵션을 이용해 커밋2의 워킹 디렉토리를 그대로 둔 채 커밋1의 스테이징 공간만을 불러왔죠. 이 때, git status를 입력해 파일의 상태를 알아보면, 빨간색으로 BasicCar2.js 파일의 이름이 나타나며, 커밋되지는 않았지만 워킹디렉토리에 있다. 커밋할거면 get add 명령어로 커밋해라고 말해줍니다. 즉, 워킹디렉토리에는 이 파일이 있는데 스테이징 공간에 없다는 것입니다. 당연하겠죠? 왜냐면 커밋1의 스테이징 공간에는 BasicCar2.js 파일이 없으니까요!
다음으로 다시 hard 옵션을 사용해 커밋2의 워킹 디렉토리와 스테이징 공간을 불러옵니다. 그 후 soft 옵션을 이용해 다른것을 그대로 둔 채 HEAD 가 커밋1을 가리키도록 하였죠. 이 때 git status 를 입력해 파일의 상태를 알아보면, 초록색으로 BasicCar2.js 파일의 이름이 나타납니다. 워킹 디렉토리에도 있고, 스테이징 아리아에도 있으니 이렇게 나타나는 거지요.
이제 각 옵션들의 차이, 그리고 git status 의 기능이 조금 이해가 되시나요?
- git reflog
일전에 알아본 git log 는 사실, HEAD 가 가리키는 커밋을 기준으로 그 이전에 커밋한 이력만을 보여줍니다.
그러면 문제가 있죠. 만약 내 디렉토리에 커밋1, 2, 3 이 있는데, git reset 명령어를 이용해 커밋1 로 갔습니다. 그리고 이제 커밋3으로 다시 돌아가고 싶어요. 그러면 커밋3의 이름을 어떻게 알죠? git log 명령어를 이용해도, 지금 나는 커밋1을 보고있기 때문에 커밋3의 이름을 확인할 수 없습니다.
이 때 사용할 수 있는게 바로 git reflog (reference log) 입니다. get reflog 는 이때까지 HEAD 가 가리켰던 commit 들을 순서대로 보여줍니다. HEAD@{n} 의 숫자가 작을수록 최근의 기록입니다. 각 커밋의 이름 대신에 head@{n} 을 사용해 지정할 수 있습니다.
지금까지는 Git 으로 버전 관리를 하며, 내 컴퓨터에만 저장을 했죠. 하지만 협업을 위해서, 그리고 프로젝트의 복구를 위해서 외부의 저장소에 우리의 파일을 업로드 할 필요가 있습니다.
외부 저장 서비스는 Github, GitLab, Bitbucket 등 다양하고, 서비스마다 각각의 특성과 장단점이 있지만 하나만 능숙히 사용할 수 있으면 다른 것들도 쉽게 사용이 가능합니다. 저희는 Gitlab 을 위주로 다뤄보겠습니다.
외부 저장소로 Push하기
1. 외부 저장소와 연결
git remote add origin {프로젝트의 gitlab url} 입력
git remote 명령어는 내 컴퓨터에서 내 컴퓨터에서 외부 저장소에 관한 작업을 할 때 사용하는 명령어입니다. 뒤에 다양한 종류의 명령어를 추가로 붙여서 다양한 명령을 수행 가능 합니다. 코드의 의미는 " url 이 가리키는 외부 서버의 프로젝트를 원격 저장소로 추가하는데, 이름을 origin 으로 하겠다."는 것입니다. (매번 긴 url을 쓸 수 없으니, origin 이라는 이름을 등록해주는 것.)
2. 디렉토리 내용 업로드
git push -u origin master 입력
git push 명령어는 "현재 내 프로젝트 디렉토리의 내용(.git 디렉토리 내부에서 관리되던 Repository 영역을 업데이트 한 것) 을 전부 origin 에 업로드 해라." 라는 것입니다. (-u , master 는 브런치 관련 내용으로, 추후 다뤄보겠습니다)
입력하면 아이디와 패스워드를 등록하라는게 나오는데, 프로젝트가 등록되어있는 자신의 gitlab 의 계정을 등록해주면 됩니다. url 만 입력해서 수정할 수 있었다면 url을 아는 팀원이 아닌 다른 사람이 함부로 수정할 수 있으니 꼭 필요한 부분이겠죠.
이렇게 외부 저장소와 연결하고, push 해준 후 gitlab 페이지에 가서 확인해보면, 지금까지 내가 한 commit 들이 시간순으로 다 보이는 것을 확인할 수 있습니다.
그리고, 처음에 이렇게 한번 push 를 해주면, 이후 명령시 디렉토리가 처음부터 origin 의 해당 프로젝트를 바라보고 있기 때문에 git push 만 입력해주면 됩니다.
.
외부 저장소에서 Pull 하기
그렇다면 반대로 Gitlab의 프로젝트에서 새로운 커밋이 Push 됐을 때 내 컴퓨터로 가져오려면 어떻게 해야할까요?
혹은 새롭게 팀에 합류하게 되어 기존에 팀이 만들던 프로젝트를 가져오려면 어떻게 해야 할까요?
1. 처음 가져올 때
git clone {가져올 프로젝트의 url} 입력
이 명령어를 입력해주면, 페이지에 올라가 있던 커밋들을 하나의 디렉토리 형태로 그대로 복사해 가져옵니다.
주의할점은 우리가 clone 한 프로젝트 폴더는 지금 있는 폴더가 아니라 가져온 폴더이기 때문에,
리눅스 명령어 cd 를 이용해 clone 한 프로젝트 디렉토리로 이동한 뒤 git 명령어를 실행해야 한다는 점입니다.
( 이때는 원격 저장소에 있던 프로젝트를 clone 한 것이기 때문에 별도로 git remote 를 쓰지 않아도 됩니다.)
2. 새로운 커밋을 가져올 때
git pull 입력
이 간단한 명령어를 통해 현재 디렉토리가 바라보고 있는 gitlab 서버의 최신 커밋을 가져올 수 있습니다.
쉽게 버전을 관리하며 협업이 가능하겠죠?
포인트
1. 이름으로 origin 을 사용하자
git을 사용할 때, 관습적으로 외부 프로젝트 저장소의 이름을 origin 으로 합니다. 앞서 봤던 git remote add origin {url} 에서 봤듯이 말이에요. 그리고, 보통 여러 개발자가 함께 개발할때 새롭게 참여한 팀원은 다른 팀원에게 소스코드를 넘겨받는것이 아니라, git clone {url} 을 통해 가져옵니다. 내부 저장소에서 가져오는 것이 항상 가장 최신의 커밋을 가져온다는 보장을 하기 때문이죠. 이처럼 항상 기준이 되고, 근원이 되는 것은 gitlab에 있는 파일이기 때문에 origin 이라는 이름을 붙입니다.
2. Push 이전에 Pull 이 있다.
새로운 작업의 시작 전에는, 항상 내 컴퓨터에 있는 프로젝트가 gitlab 서버에 있는 최신 프로젝트를 포함하는지 확인하고 작업해야 합니다. 예를 들어 gitlab 의 최신 프로젝트에는 commit1, 2, 3, 4 가 있는데 내 컴퓨터에 commit 1, 2, 3 이 있어서, 이를 작업해 commit 1, 2, 3, 5 를 만들어 Push 하면 안되겠죠. 이렇게 되면 commit 끼리 충돌하며 Fail 할 수도 있습니다. 내 프로젝트로 gitlab 의 프로젝트를 덮어 씌우는 것은 보통 허용되지 않습니다. 포인트는 새 작업을 하기 전에는 무조건 git pull 로 최신 버전을 가져오자는 것입니다. Push 이전에는 Pull 이 있습니다.
오늘로 Git 과 Gitlab 에 대한 기본적인 내용이 마무리된 것 같습니다..
다음 글에서는 중요한 주제인 Git branch 만드는 법, Merge하는 법, Comflict해결 등을 알아보도록 하겠습니다.
안녕하세요. 오늘은 소프트웨어에 관심있는 사람이라면 누구든 한번쯤 들어봤을 " Git " 에 대해 알아보는 시간을 갖도록하겠습니다 :>
Git 을 처음 시작하는 분들을 위한 글로, 기초적인 부분만 다룬다고 생각하시면 되겠습니다^.^
#1 부터 #6 까지 업로드 될 예정이니 차근차근 같이 알아가보아요!
먼저 Git 이란 무엇일까요?
Git은 프로젝트의 개발단계에서, 팀원 모두와 함께 하나의 프로젝트에서 수월하게 코딩할 수 있도록 도와주는 도구입니다. 여러 사람이 하나의 프로젝트를 코딩한다면 여러 문제가 발생할 수 있는데, 그 문제를 쉽게 해결해줄 수 있는 마법같은 도구인것이죠. 오늘날 개발 실무에서는 Git과 GitHub/GitLab 등을 함께 사용함으로써 1. 프로젝트의 버전 관리와 2. 협업을 체계적으로 수행합니다.
하나씩 살펴볼까요?
1. 프로젝트의 버전관리
보통 여러분이 작업을 할 때, 한번에 완성되지는 않지요.
1차 작업물 -> 2차 작업물 -> 최종본 -> 최종최종본....
의 과정을 거쳐 한 프로젝트가 완성 될 것입니다.
하나의 파일에 계속 업데이트 하지 않고, 이렇게 따로 버전을 나눠 저장해두면 히스토리가 남아 언제든지 이전 버전을 활용할 수 있고, 프로젝트가 어떤 모습을 거쳐 현재의 모습이 되었는지 파악할 수 있다는 장점이 있지요. 이는 협업을 할 때도, 중간에 들어온 다른 개발자가 해당 프로젝트의 히스토리를 아는데 도움을 줄 것입니다.
이렇게 한 프로젝트를 여러 작업물로 나눠 관리하는 것을 버전 관리라고 합니다. 업데이트를 통해 기능을 추가한다던지, 버그를 수정한다던지 등 버전 관리는 소프트웨어 개발자에게 중요하며, 많은 개발자가 깃으로 협업 중입니다.
2. 원활한 협업
Git 은 원활한 협업을 지원합니다. 가령 팀원A가 프로젝트 버전1, 2, 3 을 만들고 외부 서버에 올리면, 다른 팀원B가 버전을 확인하고 버전 3를 다운받아 버전 4, 5 를 만들어 다시 서버에 올리는 것이 가능합니다. 추후 또 다른 팀원C가 버전 6, 7 을 만들겠지요. 이런식으로 깃은 다른 사람이 만든 코드를 받아, 업그레이드 하는 것이 수월합니다.
이 때, 프로젝트의 각 버전을 올릴 '서버'가 필요하겠죠? 이 Git 기반의 저장소 서비스가 바로 Github, GitLab 인 것입니다. Git 과 Github, Gitlab 은 다른 것이라 할 수 있죠.
이렇게 Git을 다운받아주면, Git-bash 터미널창을 열지 않아도, VScode 등 프로그램의 내장 터미널에서 깃을 다룰 수 있게 됩니다.
파일 Commit 해보기
VScode를 실행하고, 깃에 올라갈 폴더와 파일을 만들어봅시다. 저는 예시로 BasicCar 파일과, README 파일을 만들었습니다.
파일을 커밋(commit) 한다는 것은 "특정 버전을 저장"하는 것을 말합니다.
커밋은 크게 3 가지영역을 바탕으로 작동합니다.
- Working Directory : 실제로 다루고 있는 프로젝트 디렉토리 폴더 자체 (우리의 경우 Racing Ground)
- Staging Area : 특정 버전으로 관리하고싶은 버전들을 모아둔 폴더
- Repository : 특정 시점의 Staging Area의 모습을 커밋으로 남기면, 커밋들이 저장되는 영역
우리는 Working Directory 에 파일을 생성하고, Staging Area에 업로드 하여, Commit 명령어를 통해 Repository 에 하나의 commit 으로 저장하여 버전 관리를 할 수 있습니다.
여기서 하나의 의문이 들 수 있는데요, Working Directory 에서 바로 Repository 로 올리면 되지, 왜 Staging Area를 거쳐 올리냐는 겁니다.
그 대답은 지금 당장 commit 하고싶지 않은 파일이 있을 수 있기 때문입니다. 즉, commit 하기 애매한 파일이 있으면, 제대로 수정한 파일만 Staging Area 에 업로드 하여 업로드된 파일에 대해서만 commit 을 하는 것입니다.
이제 파일을 직접 commit 해볼까요? 앞서 언급했듯이, 우리는 git 을 다운로드했기 때문에 VScode의 내장 터미널에서 commit 이 가능합니다.
1. 준비
VScode 터미널에 git init 입력 (주의 : commit 하길 원하는 working Directory 폴더에서 해야합니다.)
2. commit 한 사람에 대한 정보 입력
git config user.name "{yourname}"
git config user.email "{youremail}"
3. Staging Area 에 업로드
VScode 터미널에 git add {BasicCar.js} {README.md} 입력 (파일 이름)
파일 이름을 하나하나 넣기 번거롭다면, git add . 을 통해 모든 파일을 add 할 수 있습니다.
4. Repository 에 업로드
VScode 터미널에 git commit -m "{원하는 메모}" 입력
-m 은 메세지를 의미합니다. 메세지는 이전 파일과 비교해 어떤 내용이 변경되었는지, 어느 부분이 변경 되었는지 등 자세하고 친절하게 적습니다.
5. commit 이력 확인하기
VScode 터미널에 git log 입력
git log 를 입력하면, 지금까지 커밋한 이력을 확인할 수 있습니다. 이 이력은 커밋한 사람의 이름과 이메일 주소, 해당 커밋에 할당된 이름, 커밋한 시간 등의 내용을 포함합니다.
6. commit 파일 비교하기
VScode 터미널에 git diff {커밋이름1} {커밋이름2} 입력
해당 코드를 입력함으로써 commit 한 파일간의 다른 점을 확인할 수 있습니다. 가령 어떤 파일이 추가되었고, 어떤 코드가 바뀌었는지를 친절하게 알려줍니다. 복잡하고 긴 커밋 이름을 모두 적을 필요는 없습니다. 파이썬이 알아볼 수 있도록 커밋 이름의 앞의 4 자리만 입력해도 알아서 찾아줍니다.
오늘의 Git알아보기는 여기서 마무리하도록 하겠습니다! 다음은 Commit 관리 및 Gitlab 에 대해서 간단히 다뤄보도록 하겠습니다.
리눅스.. 리눅스를 사용하며 한 학기를 보내보라는 조언을 처음 들었을때는 불안감이 앞섰습니다. 가상 머신이라는 것도 처음 들어봤고, 리눅스도 언뜻 들어본 것 같을 뿐이지 알 지 못하는 것이었기 때문입니다. 리눅스에 프로그램을 다운 받는 것이 윈도우에서의 다운 받는것과 다르다는 얘기를 들었을때는 상상이 안가기도 했습니다. 클릭하고, 다운받고.. 이게 어떻게 바뀔 수 있다는 것인지. 리눅스가 제 삶에 들어왔을 때 검색을 많이 해보았습니다. 대체 리눅스는 어떻게 프로그램을 다운로드 받는 것인가! 윈도우를 두고 리눅스를 쓰는 또 다른 이유는 무엇이 있을까.
다양한 이유들이 있었습니다. 말하자면 오픈 소스이기 때문에 완전한 무료이고, 이는 곧 개발 작업은 물론 홈 레코딩이나 그래픽 디자인 등에 최적화된 강력한 워크 스테이션 환경을 완전히 무료로 구축할 수 있다는 점, 리눅스를 돌리는 많은 서버는 리눅스 말고는 대안이 딱히 없다는 점, 등이 있겠지요. 개발에, 특히 서버에 리눅스가 좋다는 얘길 많이 들었습니다. 정보를 찾다보면 서버 개발자 분들이 리눅스를 매우 좋아하시더라구요. 저에게는 운영체제를 공부하고 명령어를 배울 수 있다는 큰 장점이 있었습니다. 과거 한번 라즈베리파이를 다뤄보며 운영체제를 조금 알게되어 터미널창에 작성해본 것이 처음이라 흥미로웠었는데, 이번에 리눅스를 하며 명령어들에 더 친숙해지고, 터미널 창과 더 대화를 나눠봐야지, 했었습니다.
그렇게 저는 총 10 가지의 프로그램을 다운받았습니다. 다운받은 프로그램의 기준은 이 프로그램을 리눅스에 다운 받음으로써, 리눅스가 나에게 더 매력적이게 되고, 늘 리눅스를 사용하지는 못하더라도 리눅스를 사용하는 것에 큰 불편함을 느끼지 않게끔 하는 것이었습니다. 먼저 개발 코드를 푸시, 풀 하기위한 깃과, 리눅스의 화면을 캡쳐하고 사진을 편집해줄 툴, 자바 개발환경을 위한 JDK와 이클립스, 간간히 즐길 미니게임 같은 SuperTuxKart, 보다 편리하게 웹 서핑을 할 수 있게 해줄 크롬, 우분투를 더 예쁘게 꾸며주고 편의성을 높여줄 Unity Teak Tool, 시스템 내의 프로그램과 환경을 관리해줄 Stacer, 노래를 들을 수 있는 Amaroc, 영상 편집이 필요하여 다운받은 shoutcut, 그리고 사람과 연결되는 공간인 Kakao talk 까지. 프로그램을 다운 받는데에 예기치못한 에러도 많이 뜨고, 가상머신 자체의 에러도 있어 한번은 다 지우고 다시 시작했지만, 이렇게 12주를 알차게 채우니 기분이 좋습니다.
아무래도 어릴 적부터 쓰던 운영 체제를 바꾸는 것이다 보니, 리눅스는 제게 어려웠습니다. 하나 하나 세부적인 모든 것들이 다 달라서 초반에 적응이 안되어 더 어렵게 느껴졌던 것 같습니다. 사실 어렵다기 보단 불편했다고 해야 할까요. 그러나 초기에 불편함을 느끼는 것은 당연한 과정이라는 생각이 듭니다. 리눅스에 프로그램을 다운 받으며, 쉬우면 알아가는 재미가 없다는생각으로 구글링하며 공부하였더니 이제는 리눅스에게 조금 거리낌이 없어진 것 같습니다. 간간히 리눅스를 다루다보니 운영체제를 다루는, 명령어를 입력하는 것에 친숙해졌고, 다른 운영체제에 대한 막연함이 사라졌습니다. 이제는 다른 운영체제에도 한번 (간단히) 써보겠다고 스스로 도전할 수 있을 것 같습니다.
---> 지금은 Lab에서 지원해주는 리눅스 기반 연구용 서버가 있어서, MovaXterm 이용해서 리눅스 잘 쓰고 있습니다.!!
