쿠버네티스 전문가 양성과정 11주차 4일(3/2)

최수환·2023년 3월 2일
0

Kubernetes

목록 보기
49/75
post-thumbnail

git

  • git은 프로젝트를 관리하기 위한 오픈소스이다.
  • git은 SCM(Source Code Management) 도구로 분류된다.
  • VCS(Version Control System)로 불리기도 한다.
  • git = 버전관리 도구
  • git과 github은 다르다
    -> 버전에 대한 코드를 저장하는 저장소가 github이다
  • 버전은 관계형 데이터베이스를 이용하여 저장한다.

📒 git-scm 공식 홈페이지

📒 git 간편안내서

  • 3대 원격저장소 : git hub, git lab, bit bucket

버전관리

1 . 로컬 버전 관리

  • 많이 쓰는 VCS 도구 중에 RCS(Revision Control System)라고 부르는 것이 있는데 오늘날까지도 아직 많은 회사가 사용하고 있다. RCS는 기본적으로 Patch Set(파일에서 변경되는 부분)을 관리한다. 이 Patch Set은 특별한 형식의 파일로 저장한다. 그리고 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있다.

2 . 중앙집중식 버전 관리 (CVCS)

  • CVCS 환경은 로컬 VCS에 비해 장점이 많다. 모두 누가 무엇을 하고 있는지 알 수 있다. 관리자는 누가 무엇을 할지 꼼꼼하게 관리할 수 있다. 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.
  • 저장소가 장애가 나면 작업을 하지 못하기 때문에 지양해야하는 구조이다.

3 . 분산 버전 관리 시스템 (DVCS)

  • 누구나 버전을 저장하는 저장소가 될 수 있다.
  • 단순히 파일의 마지막 스냅샷을 Checkout 하지 않는다. 그냥 저장소를 히스토리와 더불어 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. Clone은 모든 데이터를 가진 진정한 백업이다.
  • 게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 다양하게 사용할 수 있다.

git 작업의 흐름

  • 매우 중요한 그림이다.
  • Working Directory
    • 비어있는 디렉터리를 만들어 작업 디렉터리로 지정해서 파일 생성, 삭제, 변경 등의 작업을 한다.
  • Staging Area(index) :
    • Working Dir에서 생성/삭제/변경한 파일에 대해서
      Stage Exists를 통해 Staging Area로 추가한다.
    • 곧 커밋할 파일에 대한 정보를 저장한다.
    • Production 서버에 올리기 직전에 테스트하기 위한 단계.
    • 실제 환경(인프라)와 비슷하게 구축해놓는다.
    • 테스트 후 문제가 없다면 git directory (repo)에 commit한다
  • git directory (repo)
    • 로컬 저장소에 파일이 특정 버전으로 저장된다.
    • 여러 버전을 볼 수 있고, 원하면 과거의 버전으로 갈 수 있는 등의 작업을 할 수 있다.

git 설정

  • 'git config’라는 도구로 설정 내용을 확인하고 변경할 수 있다. Git은 이 설정에 따라 동작한다. 이때 사용하는 설정 파일은 세 가지나 된다.

  • Git을 설치하고 나서 가장 먼저 해야 하는 것은 사용자이름과 이메일 주소를 설정하는 것이다. Git은 커밋할 때마다 이 정보를 사용한다. 한 번 커밋한 후에는 정보를 변경할 수 없다.

  • 사용자이름과 이메일을 등록하지 않으면 git을 사용할 수 없다.

    # git bash 열고 
    git config --global user.name "github ID" # 아이디 등록
    git config --global user.email "github 이메일" # 이메일 등록 
    git config -l # 설정정보 확인
    git config --global core.pager '' # 좀 더 간편하게 설정정보 확인 

git 저장소 만들기 및 작업

주로 다음 두 가지 중 한 가지 방법으로 Git 저장소를 쓰기 시작한다.

  • 아직 버전관리를 하지 않는 로컬 디렉토리 하나를 선택해서 Git 저장소를 적용하는 방법
  • 다른 어딘가에서 Git 저장소를 Clone 하는 방법
mkdir git-test # 적당한 경로에 디렉터리 생성
cd git-test # 디렉터리 접속 
git init # 해당 디렉터리에 git 저장소 만들기, 반드시 해당 디렉터리에 들어가서 init을 해야한다.

ls -a # .git파일 존재 
ls .git # 디렉터리내에 git설정 파일 보기 

git status # git 상태보기

echo "hello" > hello.txt # 파일 생성 
git add hello.txt # 해당 파일을 Staging Area에 올린다 


-> 파일이 Staging Area에 올라온 것을 확인

echo 'printf("hello world")' > hello.py # 파일 하나 더 생성 


-> status로 확인해보면 add하지 않았기 때문에 Working dir에 있는 상태인것을 알 수 있다.

echo "# hello world" > hello.md # 파일 하나 더 생성 

git add . # 현재 Working 디렉터리에 있는 여러 파일을 staging Area에 올린다  

git commit 
# 버전에 대한 reference로 commit 메세지를 남긴다, 보통 영어로 작성한다. 

-> 메세지는 기본적으로 동사, 현재형으로 작성
-> 예를 들어 add를 통해 올라온 3개 파일이 있는데 2개가 x라는 기능, 1개가 y라는 기능을 한다면 3개를 같이 commit하는 것이 아니라, x기능을 하는 2개파일을 묶어서 먼저 commit하고 그 뒤에 y라는 파일을 따로 commit해야 한다.

Add hello world series # 제목 

Add hello.md file
Add hello.py file
Add hello.txt file
# commit하고자 하는 파일들
  • commit을 하게되면 저장소에서는 제목만 보인다.
  • 저장하고 나오면 commit이 된다.

새로운 파일 hello.c 생성 및 hello.txt파일 수정

  • status로 확인해보면 modified와 새로 생성된 파일 두개가 보인다.
git add . 
git commit -m 'Add hello.c & Modifiy hello.txt' # commit하기 
  • 간단한 메세지는 git commit으로 vi편집기를 통해 작성하지않고,
    -m 옵션을 사용한다.
git log # commit한 기록 보기 

< git ignore >

vi .gitignore # gitignore파일 작성 

*.log # 모든 로그파일 무시

echo 'hello' > hello.log # 로그파일 생성 

git add . 
# .gitignore만 올라온다. log파일은 무시된다

# 이미 txt파일이 존재하는 상태 
vi .gitignore 
*.txt # 모든 txt파일 무시 


git add . 
  • .txt파일은 이미 존재한다. 즉, 현재 추적중인 파일이기때문에 무시되지 않는다.
  • ignore파일은 파일을 생성하기 전에 먼저 설정해야한다.

Branch

  • 이름은 master보다 main을 권장
  • master는 최상위 branch
git branch feature1 # 브랜치 생성 
git branch # 현재 브랜치 보기 
git switch feature1 # 해당 브랜치로 전환 

  • prompt도 달라지고 status의 branch도 달라지는 것을 확인
vi hello.md # 기존에 존재하는 md파일 수정

git add .
git commit -m 'Modify hello.md'
git log or git log --oneline # 로그 확인 

  • HEAD는 현재 가리키고 있는 브랜치를 나타냄
  • 현재 branch인 feature1에서 'Modify hello.md'가 commit된것을 확인
git switch master # master브랜치로 전환 
cat hello.md # md파일 읽기
  • master에 존재하는 md파일을 읽어보면 수정되기 전 내용이 있는것을 알 수 있다.
git switch feature1 # 다시 feature1브랜치로 전환
echo 'hello' > korea.md # 새로운 파일 생성 
git add . 
git commit -m 'create korea.md'

git switch master # 다시 master로 전환 
  • master에서 ls해보면 파일이 존재하지 않는다.

  • 맨아래가 제일 처음이다.
  • master라는 가지에서 시작해서 아래로 하나의 commit, 다시 아래로 하나의 commit이 된 것이고, 이후에 가지치기를 통해 새로운 feature1이라는 branch가 생기고 해당 가지에서 아래로 하나의 commit, 다시 아래로 하나의 commit이 생성된 것이다.

merge

  • 두가지 merge방식이 존재한다.

1 . Fast-forward merge

  • master에 두개의 commit이 있고, 그 상태에서 feature1을 생성 후 feature1에 새로운 commit을 만든다면 master에는 feautre1으로 가는 길만 존재하고 master에서 독자적으로 변경사항(ex. 새로운 commit)이 존재하지 않기때문에 master가 feature를 Fast-forward로 따라잡을 수 있다.
echo hello1 > hello1.txt
git add .
git commmit -m "hello1" # master에 hello1 파일 생성

git branch feautre1
git switch feature1
echo hello2 > hello2.txt
git add .
git commmit -m "hello2" # feature1에 hello2 파일 생성 

git switch master
git merge feature1 # 병합하는 기준(현재 master)으로 switch해서 병합하고자 하는 branch를 입력 

git log --oneline --all --graph # 그래프로 로그 보기

  • Fast-forward : 가지치기를 통해 먼저 앞에 가있는 feature1에 대해서 merge를 통해 master가 feature1의 위치를 따라 잡는다
  • feature가 가지고 있는 hello3.txt와 수정된 파일 hello2.txt에 대해 master가 feature1을 따라잡으면서 변경된 것이다.
  • 이후에 feature에 하나의 commit을 하면 master는 하나 뒤쳐지고 feature는 하나의 commit을 가지면서 앞으로 하나 더 나아간 것이다.

2 . three-way merge

  • 만약 1번 상황에서 master에 독자적으로 변경사항(ex.새로운 commit등..)이 생기면 feature1으로 가는길과 master만의 또 다른 새로운 commit이 생긴다. 이때 merge를 하게 된다면 새로운 병합 포인트를 생성해 feature1과 master를 합친다. 이것이 three-way-merge이다.
  • 하지만 three-way merge 할때 합치는 두 파일이 같은 층에 같은 파일인 경우에, 파일의 내용이 서로 다르다면 충돌이 발생하게 된다.
    -> 따라서 이 경우에는 vi편집기를 통해 둘중 하나의 파일만 선택하던가, 아니면 두 파일의 내용을 섞어서 사용하던가, 아예 다른 내용을 선택해야 한다.
    📌 다른 층이라면 같은 파일이여도 상관 x
echo hello3 > hello3.txt
git add .
git commit -m "hello3"
# master에 hello3파일의 새로운 commit생성  

git switch feature1
echo hello4 > hello4.txt
git add .
git commit -m "hello"
# feature1에 hello4파일의 새로운 commit생성

git switch master
git merge feature1
  • 마스터에도 새로운 commit, feature1에도 새로운 commit이 생겼기 때문에 서로 다른 길로 뻗어있다. 따라서 master에서
    Fast-forward로는 feature1을 따라잡지 못하기 때문에 three-way merge를 통해 새로운 병합점을 만들어서 그 지점에 두 branch를 합친다.

  • three-way merge이기 때문에 vi 편집기로 새로운 포인트에 대한 로그기록을 남긴다.

  • vi를 저장하고나면 merge가 완료되고 feature1에 있는 파일이 master에도 존재한다.
touch first
git add .
git commit -m '1' # master에 새로운 commit 추가 

git branch test
git switch test
echo test1 > test.txt  
git add .t 
git commit -m 'a' # test 브랜치에 test.txt라는 commit생성

git switch master
echo first > test.txt
git add .
git commit -m 'a' # master에도 내용만 다르게 test.txt commit생성

git merge test # conflict 발생되서 merge되지 않는다
vi test.txt # 해당 파일 들어가보면 아래와같이 text가 존재

  • master는 test.txt라는 commit을 갖고 있고, test브랜치도 다른방향으로 test.txt라는 commit을 갖고있다. 즉, master가 test를 branch하려면 다른 방향이기 때문에 three-way merge를 해야한다. 하지만 같은 파일의 내용이 다르기 때문에 merge시에 충돌이 발생한다
  • vi로 들어가 '<<' , '>>' , '==' 이 세가지 기호를 모두 제거해야 한다.
  • 제거하면서 두개의 파일중 어떤 파일의 내용을 사용할지 선택하면 된다. 둘다 써도 되고, 둘다 안써도되고, 다른 내용으로 써도 된다
  • 제거 후 merge를 하면 바뀐 내용의 파일이 commit되어 master에 존재하게된다.

diff / detach

git diff # working dir에 있는 파일간의 차이점 
  • add한 이후에는 git diff해도 아무것도 나오지 않는다
git diff --staged # Staging Area에 올라온 파일간 차이점
git diff --staged hello.txt # staging Area에 올라온 특정 파일간 차이점

git log --oneline # commit된 파일의 파일명을 알 수 있다.
git diff c3fa6eb..1cdca6d # commit된 파일간 차이점

git diff master..f1 # branch간 차이점

git switch --detach 1cdca6d # head를 commit된 1cdca6d 바꾼다    
  • 바라보고있는 현재 위치만 바꾼다.
git restore --staged c # 실수로 add한 경우 
  • 예를들어 a,b 따로 add해서 commit하려했는데 실수로 a,b,c를 add한 경우 c를 뺄 수 있다.
git reset HEAD~1 
  • 파일은 그대로 존재, 내용도 그대로인데 시점만 이전으로 돌아감 , 해당 파일은 add하기 이전으로 돌아감
git reset --hard HEAD~1 # 파일의 내용까지 돌아감
  • 완전히 과거로 돌아가면서 파일과 내용이 사라짐
git revert HEAD~1 # 특정 부분만 취소     
  • revert나 reset은 충돌이 발생할 수 있기 때문에 잘 사용하지 않는다.

github

github : 원격(remote) repository

  • github 로그인
  • 우측 상단에 +기호 클릭
  • new repository 클릭
  • repo생성

remote저장소에서 local로 가져오는 것을 pull

  • repo생성 시 public선택하면 인증없이 아무나 pull이 가능하다.

local에서 remote저장소로 보내는 것을 push

  • 인증이 필요하다
git remote # 원격 repo 존재 확인 
git remote -v # 원격 repo 자세한 정보 확인 

mkdir git-test # 적당한 디렉터리 생성
echo "# git-test" >> README.md
git init # git 초기화 
git add README.md 
git commit -m "first commit"
git branch -M main # master에서 main으로 변경 
git remote add origin https://github.com/suhwan12/git-test.git # 원격 저장소 등록 
  • 일반적으로 Remote repo의 이름은 origin으로 정한다

push를 하기위해서는 인증이 필요한데 passwd 인증이 아닌 token으로 인증해야한다.(= HTTPS 인증)

  • github에 settings에서 Developer settings 클릭
  • Personal access tokens에서 Tokens 클릭
  • Generate new token으로 토큰 생성
git push -u origin main # 생성한 토큰 입력 

이제 push와 pull이 가능해진다.

vi test.txt # test.txt 파일 생성후 text입력 
git add . 
git commit -m 'test' # commit 
git push # repo에 push 

  • 로컬에 commit된 test.txt파일이 github의 git-test repo에 push된것이 보인다.

반대로 github에서 Add file로 새로운 파일을 생성 후 쉘에 pull명령어 입력

git pull
  • repo에 생성한 파일이 pull로 현재 로컬 디렉터리에 저장된 것을 확인
git branch feature1 
git switch feature1 # 파일 한개 
git push origin feature1 # 브랜치를 push한다
  • github repo에 새로운 브랜치가 생성되고 해당 브랜치에 커밋한 파일이 push된다.
git switch main 
git merge feature1 
git push 
  • main과 합치고 싶다면 main에서 merge로 해당 브랜치와 merge하고 push하여 github repo에 올린다.

키 생성

HTTPS : 일일이 push할 때마다 토큰으로 인증을 진행하기에 불편하다.
SSH : ssh-keygen으로 키를 생성하여 키를 통해 유연하게 진행이 가능하다.

ssh-keygen # 키가 없다면 키 생성
cat ~/.ssh/id_rsa.pub # 퍼블릭 키파일 복사

  • github에서 복사한 키파일로 SSH key를 생성한다.
git remote remove origin # 기존의 origin을 제거

  • 오른쪽의 초록색으로 된 code를 클릭하여 ssh주소를 얻는다.
git remote add origin < ssh주소 > # ssh로 원격 repo등록 
git remote -v # 등록한 원격 repo 확인 

git push -u origin main # push 할 origin을 main으로 설정 
  • 이제 push할때마다 인증을 하지 않아도 된다
  • 이후부터는 push할 때 'git push'만 하면 된다.

📒 한번 push한 파일은 되돌리는 것이 매우 힘들다. 특히 협업하는 사람이 많은 기업에서는 더더욱이 불가능에 가깝다. 따라서 반드시 push하기 전에 로컬에서 꼼꼼히 확인하고 신중하게 push를 해야한다.

📒 git pull = git fetch + git merge

  • 일반적으로는 git pull을 많이 사용한다.
  • git pull을 하게 되면 충돌이 날 여지가 존재한다. 작업하는 도중 변경사항이 생기게 된다면 pull을 하지말고 fetch로 일단 받아와서 diff로 문제가 있는지 확인하고 그 후에 merge, commit 등을 이용해서 작업한다.
profile
성실하게 열심히!

0개의 댓글