[TIL] 9월 16일: Git

Jung·2021년 9월 16일
0

TIL

목록 보기
4/77
post-thumbnail

어제는 가비아에서 도메인을 구매한 뒤 AWS EC2를 이용해 웹사이트를 만들어 웹 상에 배포까지 진행해봤다. 도메인 구매와 AWS EC2 사용은 처음이었는데 이 두 가지로 배포를 해보았다는 것이 만족스러웠다. 오늘은 평소에 사용하던 Git에 대해 기록하려고 한다. Git을 사용해본 적은 있지만 제대로 사용해본 적은 없다고 생각해서 공부를... 해야겠다!

Git

Git이란 무엇일까?

Git은 버전 관리 시스템(VCS, Version Control System) 중 하나다.
버전 관리는 파일 변화를 시간에 따라 기록했다가 특정 시점의 버전을 다시 불러올 수 있는 시스템이다. 파일을 이전 상태로 되돌릴 수 있고 변경 사항을 비교 할 수도 있다. 이전 상태로 되돌릴 수 있는 만큼 파일이 잘못 되었을 때 쉽게 복구가 가능하다는 장점이 있다.

참고
“버전 관리란?” Git, https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC%EB%9E%80%3F.

버전 관리 시스템 종류

로컬 버전 관리 시스템

작업 중인 파일을 다른 디렉토리에 복사하고 엉뚱한 파일을 덮어쓰거나, 의도하지 않은 위치로 복사하는 등의 실수가 발생하는 문제를 해결하기 위해 로컬 버전 관리 시스템이 등장했다.
로컬 버전 관리 시스템은 데이터베이스에 파일의 변경 사항을 기록하는 시스템이다.
각 버전 별로 패치 세트라고 하는 데이터의 어느 부분이 변경 되었는지 저장해둔다. 특정 시점의 파일 내용을 보고 싶을 때 해당 시점까지의 패치 세트를 모두 더하여 파일을 생성하는 방식이다.

RCS(Revision control system)

중앙 집중형 버전 관리 시스템(클라이언트-서버 모델)

여러 명의 개발자와 함께 작업할 때는 로컬 버전 관리 시스템은 한계가 있다.
중앙 집중형 버전 관리 시스템은 모든 파일을 저장하는 중앙 서버와, 이 중앙 서버에서 파일들을 가져오는(체크아웃) 여러 클라이언트가 존재한다. 클라이언트의 마지막 스냅샷을 통해 중앙 서버의 버전을 관리한다.

  • 다른 작업자가 무엇을 하고 있는지 알 수 있다.
  • 중앙 서버가 다운 되면 진행 중이던 버전 관리를 할 수 없다.
  • 중앙 서버의 하드디스크에 오류가 발생하고 백업을 해놓지 않았다면, 개발자 각자 로컬 컴퓨터에 가지고 있던 스냅샷을 제외한 모든 자료를 잃게 된다.

CVS, SVN(Sub VersioN), Perforce

분산 버전 관리 시스템

분산 버전 관리 시스템에서는 클라이언트는 단순히 파일의 마지막 스냅샷을 사용(Checkout) 하지 않고 저장소를 히스토리와 더불어 전부 복제하는 방식을 사용한다. 서버에 문제가 생겨도 클라이언트에 존재하는 저장소를 서버로 복사하면 서버가 복구된다.

  • 로컬과 원격 모두 고유의 저장소를 가질 수 있다.
  • 저장소만 복사하면 어떤 컴퓨터에서든 버전을 관리할 수 있다.
  • 다수의 원격 저장소를 가지는 것이 가능하기 때문에 여러 그룹과 함께 작업할 수 있다.

Git, Mercurial, Bazaar, Darcs

Git 기본 용어

  • Repository : 저장소를 의미하며, 저장소는 히스토리, 태그, 소스의 가지치기 혹은 branch에 따라 버전을 저장한다. 저장소를 통해 작업자가 변경한 모든 히스토리를 확인 할 수 있다.

  • Working Tree : 저장소의 어느 한 시점을 바라보는 작업자의 현재 시점이다.

  • Staging Area : 저장소에 커밋하기 전에 커밋을 준비하는 위치다.

  • Commit : 현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업이다.

  • Head : 현재 작업중인 Branch를 가리키는 것이다.

  • Branch : 가지 또는 분기점을 의미하며, 작업을 할때에 현재 상태를 복사하여 Branch에서 작업을 한 후에 완전하다 싶을 때 Merge를 하여 작업을 한다.

  • Merge : 다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업을 의미한다.

Git 주요 명령어

  • git init : git 저장소를 초기화한다. 저장소나 디렉토리 안에서 이 명령을 실행하기 전까지는 그냥 일반 폴더이다. 이것을 입력한 후에야 추가적인 git 명령어들을 줄 수 있다.

  • git help : 명령어를 잊어버렸다면 커맨드 라인에 "git help"를 쳐보자. 그럼 21개의 가장 많이 사용하는 git 명령어들이 나타난다. 좀 더 자세하게 “git help init”이나 다른 용어를 타이핑하여 특정 git 명령어를 사용하고 설정하는 법을 이해할 수도 있다.

  • git status : 저장소 상태를 체크한다. 어떤 파일이 저장소 안에 있는지, 커밋이 필요한 변경사항이 있는지, 현재 저장소의 어떤 브랜치에서 작업하고 있는지 등을 볼 수 있다.

  • git clone : 원격 저장소의 저장소를 내 local에서 이용할 수 있게 그대로 복사해 가져온다.

  • git add : 이 명령이 저장소에 새 파일들을 추가하진 않는다. 대신, git이 파일들을 지켜보게 한다. 파일을 추가하면, git의 저장소 “스냅샷”에 포함된다.

  • git commit : git의 가장 중요한 명령어다. 파일을 수정한 후, 저장소의 “스냅샷”을 찍기 위해 사용하는 명령어다. 보통 “git commit -m “Message hear.” 형식으로 사용한다. -m은 명령어의 다음 부분을 메세지로 남긴다는 뜻이다.

  • git push : 로컬 컴퓨터에서 작업하고 당신의 커밋을 GitHub에서 온라인으로도 볼 수 있기를 원한다면, 이 명령어로 깃허브에 변경사항을 “push”한다.

  • git pull : 로컬 컴퓨터에서 작업할 때, 작업하고 있는 저장소의 최신 버전을 원하면, "git pull"을 통해 깃허브로부터 변경사항을 다운로드할 수 있다.

  • git log : 커밋 내역을 확인해보고 싶을 때 사용하는 명령어다.

  • git branch : 여러 협업자와 작업하고 자신만의 변경을 원한다면 이 명령어로 새로운 브랜치를 만들고, 자신만의 변경사항과 파일 추가 등의 커밋 타임라인을 만든다. 새 브랜치를 “hello”로 지정하고 싶다면 "git branch hello"라고 쓸 수 있다.

  • git checkout : 현재 위치하고 있지 않은 저장소를 “체크아웃”할 수 있다. 이것은 체크하길 원하는 저장소로 옮겨가게 해주는 탐색 명령이다. 만약 master 브랜치를 들여다 보고 싶으면, git checkout master를 사용할 수 있다.

  • git merge : 브랜치에서 작업을 끝내고, 모든 협업자가 볼 수 있는 master 브랜치로 병합할 수 있다. "git merge hello"라고 입력한다면 hello 브랜치에서 만든 모든 변경사항을 master로 추가한다.

  • git status : 레포지토리의 상태를 보여주는 명령으로 관리되고 있는 파일과 디렉토리 목록을 확인할 수 있다.

참고
Bellaah 사용자. “[Git] Git이란 무엇인가?” Devlog, TISTORY, 17 Apr. 2020,
https://hees-dev.tistory.com/40.

Branch, Merge

개발 작업을 할 때 개발자들은 동일한 소스코드를 공유하고 다루게 된다. 동일한 코드 위에서 어떤 개발자는 버그를 수정하기도 하고 다른 개발자는 새로운 기능을 만들어 내기도 한다. 이처럼 여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없다.

이럴 때 여러 개발자들이 동시에 다양한 작업을 할 수 있게 하는 기능이 브랜치(Branch)다. 각자 독립적인 작업 영역(Repository)에서 마음대로 코드를 변경할 수 있다. 이렇게 분리된 작업 영역에서 변경된 내용은 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들 수 있다.

이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로써 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있다. 여러 명이 동시에 작업할 때 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만든다. 그리고 각자 작업을 진행한 후에, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용한다. 이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모을 수 있게 된다.

번외 - 깃허브 프로필 꾸미기

강의 들으며 공부하다가 집중력이 흐트러질 때 심심했던 내 깃허브 프로필을 꾸며야겠다는 생각이 들었다.

나의 GitHub Highlights

Delveloper Program Member는 깃허브의 개발자 프로그램 멤버가 된다는 것인데 이걸 받을 수 있는 방법은!!

자세한 내용은 https://developer.github.com/program/

PRO는 깃허브 프로 계정을 사용하고 있다는 표시인데 PRO는 유료다. 하지만! 대학생 분들은 소리 질러 🔥🔥
대학생 메일 계정이 있으신 분들은 Github Student Developer pack를 통해 무료로 받으실 수 있습니다~~

자세한 내용은 https://education.github.com/pack/

나의 프로필 README.md

나의 프로필은 README.md 파일로 꾸밀 수 있는데

뱃지 : https://shields.io/

아이콘 : https://simpleicons.org/

위 두 사이트를 참고하면 뱃지와 아이콘을 사용할 수 있다.

<img src="https://img.shields.io/badge/{텍스트}-{텍스트 색깔}?style={테두리 스타일}&logo={로고}&logoColor={로고 색깔}"/></a>

위 코드의 {}에 값을 넣으면 원하는 아이콘을 뱃지에 넣어 만들 수 있다.

  • style 종류
    plastic, flat, flat-square, for-the-badge, social

그리고 header와 footer 영역에 파도가 일렁이는 모양의 효과가 있는데 이것은 아래 사이트에 아주 자세하게 설명되어 있다 😀
https://github.com/kyechan99/capsule-render#how-to-use

참고
깃허브 프로필 꾸미기!, https://80000coding.oopy.io/865f4b2a-5198-49e8-a173-0f893a4fed45.

kyechan99. “Kyechan99/Capsule-Render: Dynamic Coloful Image Render.” GitHub, https://github.com/kyechan99/capsule-render#how-to-use.

profile
97kim.github.io

0개의 댓글