git ?

zioo·2021년 12월 13일
0

Backend

목록 보기
6/40

git을 사용해야 하는 이유

git이란

소스코드를 관리하기 위한 분산 버전 관리 시스템


git을 사용한다면 위와 같은 사진처럼 많은 파일들을 만들 필요가 없습니다.
번거롭고 용량도 꽤나 많이 차지합니다. 혹은 실수가 있을 수도 있습니다.

수정,변경이 편리

  • git은 내 코드 혹은 다른 개발자의 코드가 변경된 이력을 쉽게 확인 가능
  • 특정 시점에 저장된 버전과 비교할 수 있으며 특정 시점으로 돌아갈 수 있음
  • 소스코드 충돌 현상을 쉽게 확인

git은 협업에 유리

큰 프로젝트는 여러 명의 개발자가 역할을 나눠 함께 작업을 하는 경우가 많습니다.
해당 프로젝트를 테스트해보고 싶다면 각자 맡았던 파일들을 하나의 폴더에 모아야 하는데 git을 사용한다면 내 코드와 다른 사람의 코드를 합치는 게 쉽고 내 코드와 다른 사람의 코드가 충돌한다면 코드들을 합칠 수 없도록 경고 메시지를 통해 어떤 부분에서 충돌이 났는지 까지 알려줍니다.

그렇기 때문에 내 코드 혹은 다른 이의 코드를 덮어써버리는 실수를 사전에 예방할 수 있습니다.


git 쓰는 방법

우선 git에는 저장소(Git repositiory)라는 것이 있습니다.

저장소라는 의미 그대로 파일 혹은 폴더를 저장해 두는 곳입니다. 우리가 일반적으로 파일을 저장하는 것과 git 저장소에 저장하는 차이는 파일이 변경 이력 별로 구분되어 저장된다는 점입니다.

비슷한 내용의 파일이라도 내용 전체가 동일하지 않으면 다른 파일로 구분하기 때문에 파일을 변경 사항 별로 구분해서 저장할 수 있습니다.

git은 원격 저장소와 로컬 저장소 두 종류의 저장소를 제공

  • 원격 저장소(Remote Repository): 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소입니다.
  • 로컬 저장소(Local Repository): 내 PC에 파일이 저장되는 개인 전용 저장소입니다.

작업은 보통 내 PC의 로컬 저장소에서 합니다. 작업이 끝나면 혹은 작업 내용을 공유하고 싶다면 로컬에 있는 작업 내용을 원격 저장소에 업로드할 수 있습니다. 혹은 원격 저장소에 있는 다른 개발자의 작업 내용 또한 가져올 수 있습니다.

협업을 할시에는 원격 저장소에 있는 대표 프로젝트 파일을 모든 개발자가 개인의 로컬에 가져온 뒤 각자 맡은 기능 개발을 진행합니다. 마찬가지로 작업이 끝나면 혹은 작업 내용을 공유할 때 원격 저장소에서 각자의 코드들을 업로드할 수 있습니다.


내 컴퓨터에 로컬 저장소를 만드는 방법은 두 가지가 있습니다.

첫번째 방법은 저장소를 새로 만들어서 사용하는 것입니다.

git init

다른 하나는 원격 저장소를 복제하는 방법입니다.

  • GitHub(혹은 GitLab, Bitbucket 등)를 이용해서 원하는 프로젝트를 ForkClone으로 내 로컬로 가져올 수 있습니다.

원격 저장소를 복제하면 내 컴퓨터에 해당 저장소의 로컬 버전이 생성되어 원래 코드베이스에 영향을 주지 않고 내 컴퓨터에서 개발을 진행할 수 있습니다.

이러한 원격 저장소를 복제하는 방법은 추가로 개발한 내용을 원격 저장소에 업로드할 수 있고 반대로 원격 저장소 즉, 원본에 내용이 추가 및 삭제로 변경된다면 원본에 해당하는 내용을 가져올 수 있어 효율적으로 개발을 진행할 수 있고 이는 협업에서도 매우 큰 장점으로 작용합니다.

git push git pull

  • git clone '저장소url' : 해당 url의 원격저장소를 clone하여 local 환경에 추가합니다.
  • git remote add '저장소별칭 저장소url' : 로컬 저장소와 원격 저장소를 연결합니다.
  • git remote -v : 원격 저장소와의 연결 상태를 확인합니다. 연결된 저장소들의 별칭과 url을 확인할 수 있습니다.
  • git pull '원격저장소별칭 로컬브랜치' : 원격저장소를 로컬 브랜치로 가져와 병합합니다.
  • git push '원격저장소별칭 로컬브랜치' : 지정한 로컬 브랜치를 원격 저장소로 push합니다.

working directory 혹은 working tree는 말 그대로 개발을 진행하는 폴더라는 개념입니다.

git의 커밋 작업은 작업 저장소(working directory)에 있는 변경 내용을 저장소에 바로 기록하지 않습니다.

staging area 혹은 Index라는 가상의 공간에 기록하고자 하는 변경사항을 git add 명령어를 통해 추가해야만 합니다.

이러한 작업을 스테이징-stage라고 표현합니다.

가상의 공간에 추가해준 변경 사항들만이 commit을 통해 추가가 가능합니다.

반대로 원하지 않는 변경 사항들은 제외하고 commit할 수 있다는 의미이다.

  • git status : 저장소의 상태를 확인합니다.
  • git add <파일> : 해당 파일을 staging area에 추가합니다.
  • git add . 을 사용하면 수정한 모든 file 을 추가합니다.
  • git commit -m '커밋 메시지' : staging area에서 local repo로 최종적으로 짧은 메시지를 포함해 저장합니다.

커밋(commit)을 하게 되면 이전 커밋 상태부터 현재 상태까지의 변경 이력이 기론된 커밋이 만들어 집니다.

커밋은 시간순으로 차례대로 저장되기 때문에 과거 변경 이력과 내용을 알 수 있습니다.
또한 영문과 숫자로 이루어진 40자리의 고유의 이름이 붙기 때문에 해당 고유의 이름을 가지고 각 커밋을 구분할 수 있습니다.

git 을 쓰는 회사

Git 기반의 사이트

깃 저장소(git Repository)에 대한 원격 액세스를 제공하는 서비스

  • 서비스는 코드 호스팅 외에도 소프트웨어 개발 수명주기를 관리하도록 설계된 추가 기능을 제공
  • 추가기능에는 코드 공유, 버그 추적 , 위키 공간 및 기타 '사회적 코딩' 도구 포함

GitHub란?

  • Github는 공개적으로 사용 가능한 무료 서비스로 모든 코드를 공개해야 한다.
  • EveryBody! github에 푸시한 코드를 보고 개선을 위한 제안을 제공할 수 있다. 오픈소스 역할
  • Github는 현재 수만 개의 오픈 소스 프로젝트를 위한 소스 코드를 호스팅 한다.

GitLab 이란?

  • Gitlab은 개인 또는 조직이 Git repository 의 내부 관리를 제공하는데 상용할 수 있는 Github 으로 즉 비공개된 Github라고 할 수 있다.

    GitLab 의 사용 이유?

    • GitLab은 중앙 서버에서 Git 저장소를 관리하는 좋은 방법이다.
    • GitLab은 리포지토리 또는 프로젝트를 완벽하게 제어 할 수 있으며, 공개 또는 비공개 여부를 무료로 결정할 수 있다.

BitBucket

  • 빗버킷은 비공개 리퍼지토리가 필요한 유저들이 사용하는 대표적인 플랫폼

  • 빗버킷에 공개 리퍼지토리를 저장할 수 있음, 하지만 기본 설정은 비공개

  • 오픈소스 프로젝트보다는 회사의 프로젝트를 주로 호스팅하는 데 쓰인다.

  • 빗버킷을 개발한 Atlassian는 애초에 회사용 소프트웨어를 만드는 회사이다 보니 회사에서 많이 쓰이는 툴인 (Jira, Trello)등 과 함께 쓰기 매우 좋다.

    브랜치 허가

    깃허브는 리퍼지토리 자체를 쓸 수 있도록 허가를 해야 하는 반면 빗버킷은 브랜치 마다 허가를 줄 수 있다.

    즉, 협업할 때 수정해야 할 브랜치만 수정이 가능하도록 설정을 할 수 있다. 이 기능이 좋은 이유가 실수로 마스터에 푸시를 하는 일도 배제하고 역할분담도 쉽게 가능하다.

Visual Studio Team Services

  • 비주얼 스튜디오 팀 서비스(이하 VSTS)의 깃은 웹, 콘솔, 비주얼 스튜디오, 엑스코드, 이클립스, 인텔리제이를 공식적으로 지원
  • Private 저장소를 무제한으로 사용할 수 있다!

https://redbinalgorithm.tistory.com/339
https://insight.infograb.net/blog/2021/02/05/gitlab-vs-github/
https://www.redhat.com/ko/topics/devops/what-is-ci-cd
https://www.redhat.com/ko/topics/cloud-native-apps/what-is-a-container-registry

0개의 댓글