Git
Git
소스코드를 효과적으로 관리하기 위해 개발된 분산형 버전 관리 시스템
-
Git 설치
각자 컴퓨터의 사양에 맞는 걸 다운을 진행한다.
git 설치를 완료하였으면 cmd 창에서 'git --vesrion'으로 git의 버전을 확인한 후
소스 트리 홈페이지에서 운영체제에 맞는 소스트리를 다운로드한다.
-
소스 트리 실행 시 위에서 보이는 create는 저장소를 새로 만드는 것이다.
작업을 하고자 하는 폴더 내에 마우스 우클릭을 통해 Git Bash를 해준 뒤 cmd 창이 뜨면 git init을 입력하고,
소스 트리에서 Create 부분에서 경로를 설정해 준 뒤 생성한다.
그럼 Bash 하여 생성한 git 저장소를 소스 트리에서 확인하고 작업할 수 있다.
-
git 주요 용어
저장소(Repository)
저장소는 파일/폴더 저장 공간으로 파일이 변경 이력 별로 구분되어 저장된다.
원격 서버에서 관리되며 여러 사람이 공유하기 위한 저장소를 원격 저장소(Remote Repository)라고 한다.
개인 PC에서 관리하는 저장소를 로컬 저장소(Local Repository)라고 한다.
Commit
로컬 저장소에 파일이나 폴더의 변경 사항을 기록하는 작업
Git은 Commit을 시간 순으로 저장하며 이전 Commit 상태부터 현재 Commit 상태까지 만들어 보관한다.
commit 내용을 통해 변경 이력과 변경 내용을 확인할 수 있다.
Index(Stage Area)
Commit 하기 위해 추가하는 파일들이 저장되는 공간
index에 올라와 있는 애들만 commit을 할 수 있다.
사용자 입장에서는 commit 대기 상태란 뜻으로 Staging Area라고 부르기도 한다.
-
실습을 위해서 git 저장소가 생성된 파일에 프로젝트 기본이라는 텍스트 파일을 하나 생성한다.
그럼 소스트리가 아래와 같은 화면으로 변경된다.
또한, 오른쪽에서 파일 내용도 볼 수 있다.
현재 텍스트 파일은 스테이지에 올라가지 않은 파일 부분에 들어가있는데,
윗부분인 <스테이지에 올라간 파일> 부분에 파일을 올려놓아야 commit이 가능하다.
위 스테이지에 올리면 왼쪽 아이콘도 + 로 변하며 git이 이 파일을 추가할 것이구나 라며 인식을 한다.
이 파일을 commit 해보겠다.
커밋 전 아래 부분에는 커밋 내역에 대한 가벼운 설명을 쓸 수 있는 공간이다.
커밋 설정 후 History 부분에 들어가면
위와 같이 작업한 내용에 대한 설명들을 볼 수 있다.
커밋 아이디는 실제로 엄청 긴데 (아래에서 확인 가능) 8자리로 줄여서 보여준다.
바로 아래에서 좀 더 상세한 정보를 확인할 수 있다.
-
이번엔 텍스트 파일 내용을 수정해 보자.
수정했더니 History에 '커밋하지 않은 변경사항'이라는 게 새로 뜨고,
파일 상태에서 수정이 일어났다는 아이콘과 라인 별로 변경된 사항을 알려준다.
메인 페이지라는 텍스트 파일을 하나 더 추가해 주었다.
그리고 두 파일을 함께 커밋해 보았다.
그럼 history에 로그가 하나 더 생겼다.
이때 수정된 파일도 2개로, 클릭하면 아랫부분에서도 상세한 내용을 볼 수 있다.
branch
저장소 내에서 다른 작업에 영향을 받지 않는 독립된 단위의 저장소
즉, branch는 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어주는 기능이다.
checkout
현재 branch를 다른 branch로 전환하는 것
merge
특정 브랜치의 작업 내용을 다른 브랜치에 병합하는 것
-
새 브랜치를 생성해 보겠다.
위 브랜치 부분을 클릭하면 아래와 같은 화면이 나온다.
작업 사본 부모를 클릭하면 마지막으로 작업된 브랜치를 기준으로 브랜치를 만든다.
생성하면 board 브랜치가 하나 더 표시되어 나오는 것을 볼 수 있다.
아래의 현재 커밋 로그에 대해서 두 개의 브랜치가 존재하고 이 브랜치를 기준으로 분기된다.
왼쪽을 보면 현재 master 브랜치이고 board 브랜치를 더블 클릭하면 마스터 브랜치에서 보드 브랜치로 체크아웃된다.
브랜치를 체크아웃 한 뒤, 새 텍스트 파일을 만들어서 새로 커밋해 주었다.
커밋 로그가 하나 더 추가가 되었는데 board 브랜치를 기준으로 분기되고 있다.
이 상태로 board 브랜치에서 master 브랜치로 체크 아웃 한 후 탐색기로 들어가면 아래와 같이 게시판 페이지 텍스트 문서가 사라졌다.
마스터 브랜치로 작성한 것이 아니기 때문에 보이지 않는다.
메인 페이지 텍스트 파일을 수정하고 커밋하면 아래와 같이 브랜치가 분기된다.
각각 브랜치에서 작업을 하면 서로 영향을 주지 않고 작업하기 때문에 그 시점부터 분기되었다.
즉, 각각의 다른 브랜치들에서 작업을 하면 서로에게 영향을 주지 않는다.
브랜치 생성 시에 새 브렌치 체크아웃을 체크하고 생성하면
브랜치 생성과 동시에 새로 생긴 브랜치로 체크아웃된다.
브랜치에서 변경 사항이 생기고 커밋하지 않으면 브랜치를 변경할 수 없다.
왜냐하면 다른 브랜치에서는 현재 브랜치에서 작업한 내용들의 존재를 모르기 때문이다.
커밋을 하지 않아도 넘어가지는 경우도 있다.
master 브랜치와 board 브랜치 모두에게 처음 보는 파일이기 때문이다.
파일에 대한 정보가 없기 때문에 체크아웃이 되지 않는다.
즉, 새로 생성된 파일에 대해서는 이전에 대한 내용이 없기 때문에 두 브랜치 모두에게 뜬다.
그리고, 한 브랜치에서 커밋할 경우 다른 브랜치에서는 뜨지 않는다.
그래서 항상 브랜치를 이동할 때에는 브랜치 확인을 하고 커밋 후에 다른 브랜치로 넘어가야 한다. (작업이 꼬일 수 있다.)
-
브랜치 병합도 가능하다.
병합하고자 하는 브랜치 오른쪽 마우스 클릭 후 현재 브랜치로 병합을 클릭하면 아래와 같이 변한다.
분기됐던 것이 Merge branch 'board'라는 설명으로 위와 같이 변했다.
Merge 된 브랜치는 바로 삭제해 주면 된다.
-
태그
알아보기 쉽게 태그를 붙여줌
메인 페이지에 기능 추가 까지를 v1,
Merge branch 'board'를 v2,
merge branch notice를 v3로 정하고 태그를 추가해 보자!!
위와 같이 커밋 로그 앞에 태그표시와 함께 태그 표시가 된다.
태그 삭제는 왼쪽 태그를 클릭하여 삭제할 태그를 선택해서 삭제하거나, 위쪽 태그를 클릭해서 삭제할 수 있다.
-
release_v1 태그에 체크아웃 한 뒤, 탐색기에 새로운 파일을 추가하고 커밋해 준다.
그 뒤에 특정 메인으로 체크아웃하면 태그에 체크아웃한 뒤 생성된 로그들이 사라진다.
-
다음 실습을 진행해 보자.
member라는 이름으로 새 브랜치를 생성하고,
회원 관리 기능이라는 텍스트 파일을 탐색기에 추가하고 커밋을 진행한다.
이후 텍스트 파일을 다시 한번 편집하고 스태시를 이용해 보겠다.
스태시는 파일의 변경 내용을 일시적으로 보관해 두는 것을 말한다.
위와 같이 작업하던 것을 선택해서 스태시 해주면 아래와 같이 변경하던 사항이 사라진다.
왼쪽 스태시 부분에서 내가 보관한 것을 확인할 수 있다.
이러면 자유롭게 다른 브랜치로 체크 아웃 할 수 있다.
이후 다른 브랜치로 가서 새로운 변경사항을 변경하고 커밋한 뒤, 스태시에 보관된 작업을 다시 가져온다.
이후 커밋 메시지와 함께 커밋을 진행한다.
-
그럼 위와 같이 정상적으로 커밋되는 것을 확인할 수 있다.
그러고 나서 main 브랜치로 merge 해주었다.
커밋 로그를 여러 개 만들어 하나로 합치는 실습을 해보자.
modify_main라는 이름의 브랜치를 하나 만들고, '메인 페이지 디자인 변경 중...'이라는 메세지를 텍스트 파일에 추가해 주고,
'메인 페이지 디자인 변경 중.. '이라는 커밋 메세지와 커밋한다.
'메인 페이지 디자인 변경 완료', '로그인 기능 연결 중.. '이라는 텍스트 파일에 추가해 주고
회원관리 기능 텍스트 파일에 화원 관리 기능 수정이라는 텍스트를 수정하고
커밋 시에는 메인 페이지만 커밋해 준다.
이후 메인 페이지와 회원 관리 기능 수정 완료를 해주고 파일 상태에서 둘 다 커밋한다. (메인페이지변경완료)
위 세 로그를 하나의 로그로 합쳐볼 것이다.
세 이전 커밋인 merge branch 'member' 커밋을 선택한다.
이 커밋의 자식 커밋이 합치려는 세 커밋이다.
merge 커밋 (부모커밋) 우클릭 후 자식 커밋을 쌍방향 재배치를 클릭한다.
그럼 위와 같이 커밋 로그가 3개가 보이는데 맨 위 커밋이 가장 마지막 자식 커밋이다.
커밋을 선택해서 이전 커밋과 합치기를 클릭한다.
그럼 3개의 커밋이 다 합쳐진다.
그리고 메세지 편집을 눌리면 기존의 메세지들이 뜨고 그걸 수정할 수 있다.
우리는 모든 메세지를 '메인 페이지 리뉴얼 완료'로 수정하겠다.
그럼 위와 같이 깔끔하게 정리된 것을 확인할 수 있었다.
커밋 취소
이번엔 커밋 취소를 해보겠다.
게시판 페이지와 회원 관리 기능 텍스트 파일을 수정한다.
파일 상태로 와서 위에 보면 폐기라는 칸이 있다.
클릭하면 선택적으로 파일들을 변경 사항을 폐기할 수 있다.
선택 후 폐기하면 이전 커밋 상태로 돌아간다.
폐기 후 저장소로 돌아가서 텍스트 파일을 확인해 보면 이전으로 돌아간 것을 확인할 수 있었다.
(여기까지 커밋 전에 작업 취소)
커밋 후에 작업 취소 하는 방법
아까와 같이 텍스트 파일을 수정하고 커밋까지 해준다
브랜치가 생성된 거기서부터 리셋하면 내가 했던 커밋들이 초기화된다.
merge~ 오른쪽 클릭 이 커밋까지 브랜치 초기화 선택
사용 중인 모드로는 soft, mixed, hard가 있다.
soft는 커밋 로그가 최초로 돌아가는 것은 맞는데 그동안 작업했던 것들은 남겨놓는다.
modify board가 선택한 부분으로 내려왔고, 작업했던 환경들이 그대로 남아 있고 스테이지 에리어에 남아 있다.
다음은 Mixed이다.
mixed는 기본 모드이다. 작업 상태는 그대로 두는데 인덱스는 리셋한다.
커밋은 취소되고, 브랜치도 main 브랜치 잇던 곳으로 돌아온다.
단 차이점은 스테이지 에리어에 올라가 있지 않다는 점이다.
다음은 hard 모드이다.
리셋을 하면서 기존을 작업했던 내용들도 싹 다 지워버린다.
이전 로그들이 리셋되면서 작업했던 것들도 사라졌다.
커밋 되돌리는 법
현재 커밋을 되돌리는 방법을 알아보자.
현재 커밋 클릭 커밋 되돌리기 선택
위와 같이 새 커밋이 생겼다.
우리가 커밋을 수정하는 것도 커밋으로 남기는 것이다.
텍스트 파일을 살펴보면 이전에 수정했던 것들도 다 사라졌다.
이전으로 돌아가는데 좀 더 안전하게 돌아가고 싶을 때 사용한다.
리버트 한 데서 또 리버트 로그를 또 커밋 되돌리기 하면 아래와 같이 변경된다.
reapply라고 뜬다.
그러면서 취소된 것을 다시 취소해서 원래 상태로 돌아온다. (부정의 부정은 긍정 느낌)
메모장을 살펴보면 커밋이 취소되어 사라졌던 글들이 다시 생겼다.
-
main 브랜치에서 modify_main 브랜치를 병합하려고 했더니 아래와 같은 에러가 발생한다.
충돌이 발생했을 때 어떻게 해결해야 할까?
먼저 충돌이 나는 이유는 게시판 기능 수정과 머지를 하려고 하는데 안된 상태이다.
그리고 커밋을 보면 아래와 같이 표현이 되는데
회원 관리 기능 파일에서 충돌이 났다는 의미이다.
동일한 파일에 동일한 위치에 작업을 했다고 하면 충돌이 난다.
여러 브랜치에서 작업했다고 뜨는 것이다 (초록 부분)
head는 내가 지금 선택한 현재 브랜치를 뜻한다.
===를 기준으로 위에는 메인 브랜치에서 작성한 것,
아래는 modify_board 브랜치에서 작성한 것을 의미한다.
어느 수정 사항이 맞는지 결정해주어야 한다.
메인에서 수정한 부분이 맞다고 하여
다른 부분의 글들을 다 삭제하고 충돌이 난 것은 커밋이 되면 안 되기 때문에
느낌표가 뜬 파일을 우클릭 후 충돌 해결로 간다.
내 것을 이용해 해결은 head 부분 값으로 수정하겠다는 의미이고,
저장소 것을 사용하여 해결은 그 아래 부분에 있는 값으로 해결하겠다는 의미이다.
그리고 다시 텍스트 파일을 확인해 보면 내가 선택한 값으로 수정 후 나머지는 다 정리해 주었다.
그리고 파일 상태에서는 사라진다. (왜냐면 수정되었으니까)
'일일 정리' 카테고리의 다른 글
| 240530 소프트웨어 공학 (3) - 소프트웨어 공학/UML 다이어그램 (0) | 2024.06.06 |
|---|---|
| 240529 소프트웨어 공학(2) - git clone, push, pull /gitignore/원격지에서 생성한 로컬로 브랜치 가져오기/리눅스에서 깃 사용/gitflow (1) | 2024.06.06 |
| 240527 MariaDB(8) - 리눅스에 MariaDB 설치/NOT EQUAL JOIN 실습/조인 실습 문제 (0) | 2024.05.28 |
| 240524 MariaDB(7) - 인덱스/스토어드 프로시져/트리거 (0) | 2024.05.26 |
| 240523 MariaDB(6) - 테이블 수정/뷰 (0) | 2024.05.24 |