노트북 충전기를 ..ㅜㅜ..
안 가져와서.. 점심시간에 집 갔다 왔다..
원격 저장소
오늘은 원격 저장소! 깃허브 원격 저장소 만드는 방법에 대해 알아보자.
원격 저장소
깃허브에 원격 저장소를 만들면 README 파일이 생성된다.
README 파일은 프로젝트의 소개를 적는 곳으로 프로젝트를 실행하기 전에 필수적으로 설치해야 하는 것, 버전 정보들을 써주는 곳이다.
README 파일은 마크다운 형식으로 작성한다.
.gitignore 파일
git의 원격 저장소에 파일을 올릴 때 gitignore에 올라간 확장자를 가진 파일들은 저장소로 업로드되지 않기 위해 쓴다.
gitignore 파일은 gitignore 사이트에서 파일을 생성해서 삽입할 수 있다.
크롬에 gitignore 입력 https://www.toptal.com/developers/gitignore
gitignore.io
Create useful .gitignore files for your project
www.toptal.com
들어가서 해당 원격 저장소에 올릴 파일들의 운영체제 (Windows, Linux), 그리고 사용한 프로그래밍 언어들 (java, maven, intellij, eclipse 등등)을 입력하고 생성을 눌리면 알아서 .gitignore 파일들을 만들어준다.
생성되면 복사 붙여 넣기 해서 .ignore로 첨부해 주면 된다.
Git 주요 용어 (이어서)
clone
원격 저장소의 내용을 로컬 저장소에 복제하는 것
push
로컬 저장소에서 변경된 이력을 원격 저장소에 업로드하는 것
pull
원격 저장소에서 최신 변경 이력을 다운로드하여 로컬 저장소에 적용하는 것
깃허브에서 클론을 할 때 생성한 깃허브의 주소를 가져와서 위에 넣고 목적지 경로는 각자 알아서 필요한 곳에 넣는다.
그럼 클론 생성이 된다!
-
생성한 폴더에 hello.txt 파일을 내용과 함께 생성한다.
만약 임의로 .class 파일을 생성하면 어떻게 될까?
그냥 파일명 변경하면서 확장자를 .class로 변경해 주었더니 소스트리에서는 보이지 않는다.
그 이유는 뭘까?
왜냐면 저장소 클론 전에 생성한 .gitignore 파일에 java에서 .class 파일을 제외시키게 되어있기 때문이다.
그럼 아까 생성한 hello.txt 파일을 커밋하고.gitignore에 'hello.txt'를 추가해 보자
그럼 gitignore 파일이 수정되었다고 뜬다.
또한, gitignore 파일에 sample.txt 파일을 적어놓고,
폴더에 sample.txt 파일을 생성하면 소스트리에서 인식하지 못한다.
근데 hello.txt를 gitignore에도 넣어놨음에도 불구하고 수정했는데도 스테이지에 인식된다.
깃에서 이미 기록을 남긴 파일은 gitignore에 나중에 추가해도 제외가 되지 않는다.
푸시를 해보자.
위에 푸쉬 버튼을 눌리면
위와 같은 창이 뜨면서 푸시가 가능하다.
현재는 ignore 파일에 hello.txt를 넣어놔서 뜨진 않지만 gitignore 파일이 수정된 것을 확인할 수 있었다.
README 파일을 수정해 보자
// 마크다운
# 제목1
## 제목2
### 제목3
#### 제목4
##### 제목5
// 마크업 언어
<h1>제목1</h1>
<h2>제목2</h2>
라고 마크 다운을 추가하면
위와 같이 README를 수정했는데 로컬에 있는 README에 있는 파일은 수정되지 않았다.
이런 경우에는 pull을 진행해주어야 한다.
pull 실행 후 README 파일을 확인해 보면 아래와 같이 변경된 것을 확인할 수 있다.
gitignore에 sample.txt.를 삭제하고 sample.txt를 수정하고 커밋해 보자.
그리고 readme 파일에 한 줄 더 추가하고 소스트리에서 push를 진행한다.
그랬더니 에러가 발생했다. 왜 에러가 발생했을까?
그 이유는 다음과 같다. 깃허브의 저장소에서 수정되었기 때문에서 소스트리에서 pull 이후에 push를 해야 한다.
로컬에서 작업을 진행했지만 원격지(README)에서도 작업을 진행하였다.
push를 허용하여 충돌이 나면 서버가 책임을 맡게 되고, 뭐가 충돌이 나는지 깃에서는 판단할 수 없다.
항상 push 하기 전에, 원격지에 있는 사항들을 내려받아야 한다.
내려받을 때 (pull) 충돌이 나면 그것들을 모두 해결하고 push를 진행해야 한다.
즉, pull 하고 push 하는 습관을 들이자 ~
실습을 위해서 일부러 충돌 사항들을 만들어보자.
README 파일을 수정했다. 그리고 pull 하지 않고 로컬의 README 파일을 수정해 준다. (원격지의 내용과는 다르게)
그리고 pull을 진행하였더니 아래와 같은 에러가 발생하였다.
아래 스테이지를 보니 README 파일에서 에러가 발생하는 것을 확인할 수 있었다.
로컬에서 README 파일을 들어가 보면 아래와 같이 변경되어 있다.
위와 같이 뜬다. 이번엔 커밋 코드로 알려주고 있다..
>>>><<<< 부분이 충돌난 부분이다.
수정하여 사용할 부분 빼고 지워준 뒤 해결된 것으로 표시하고 이후 커밋을 진행한다.
충돌을 해결한 후 push를 진행한다.
push가 완료되었고, 원격 저장소에도 들어가서 확인해 보면 내용이 바뀐 것을 확인할 수 있다.
막간을 이용한 README 마크다운 표 만들기 ~ !
테이블을 생성하려면 아래와 같이 파이프라인 기호를 이용한다
|순번|키워드|설명|
|---|---|---|
|1|int|정수형|
|2|double|실수형|
|---| 는 내용 구분하기 위해서..!
|---| 안에 --- < 이 표시는 몇 개가 들어가든 상관이 없다. 제목행 밑으로는 한 칸 띄우기가 필수이다!
+ 이미지 캡처도 그냥 윈도우 캡처도구 해서 붙여 넣기 하면 링크로 들어가게 된다.
다시 저장소로 돌아와서 !!
원격지에서 브랜치를 만드는 것도 가능하다.
branch 버튼 눌려서 들어간 뒤 new branch 클릭 후 develop 이름을 가진 브랜치를 생성했다.
아니면 위에 왼쪽에 main 눌려서 develop 써준 뒤 생성해도 된다.
또한, 브랜치 모양으로 존재하는 곳을 클릭해서 브랜치 변경이 가능하다.
테스트를 위해서 develop과 release 이름을 가진 브랜치 2개를 만들어주었다.
로컬에서 pull을 하면 받아올 수 있을까 싶어서 pull을 했더니 README를 업데이트한 것 만 pull 되었고 브랜치는 가져오지 못했다
브랜치는 왜 못 가져올까?
지금 만든 브랜치는 원격에서 만든 거고 소스트리에서는 로컬에만 존재하는 브랜치만 보여준다.
그럼 어떻게 가져올까?
소스트리에서 왼쪽에 브랜치 아래에 있는 원격 탭을 클릭하면 원격지에서 생성된 것들이 보인다
원격지에서 브랜치를 만들었기 때문에 원격 부분에서 브랜치가 보인다. 이걸 가져와서 작업하고 싶은데 어떻게 해야 할까?
그럴 때에는 원격을 열어서 필요한 브랜치를 그냥 더블 클릭하면 된다.
그럼 체크아웃하겠냐는 창이 하나 뜬다. 이게 무슨 말이냐면 원격에 있는 걸 로컬로 가져와서 새 브랜치를 하나 더 만들어줘야 한다.
또한, 여기서 작업하는 내용은 바로바로 원격에 push가 되는 것이 아니다. 소스트리에서 작업하고 pull/push 해줘야 한다.
로컬에서 develop 브랜치에 test.txt를 만들어준다.
그리고 push 해주면
내용이 변경된 것을 확인할 수 있었다.
-
develop에서 작업하는 브랜치를 하나 따보자. 현재 브랜치가 develop인 상태에서 브랜치를 눌려서 하나 더 만든다
notice라는 이름의 브랜치를 생성한다. 이후 공지사항 페이지라는 텍스트 파일을 생성하고 커밋해 준다.
그리고 깃허브에 가보면 notice 브랜치는 존재하지 않는다.
왜 없을까? 원격지로 공유를 해줘야 쓸 수 있다.
push 눌려서 공유하고자 하는 브랜치를 체크해서 push 해준다.
(이름 다르게 할 거면 다르게 해 줘도 됨)
그럼 아래와 같이 origin/notice로 하나 더 생성되고, 깃허브에도 생성된다.
-
아까 만들었던 공지사항 텍스트를 커밋하자
push 해서 올려주면 작업한 내용이 원격지에도 반영이 되는 것을 확인할 수 있었다.
작업이 끝났으면 삭제해 주면 된다. 그전에 develop과 merge 하고 push 하고 삭제한다 ( 왜냐면 develop에서 나눈 거라서)
원격지도 사용이 끝나면 삭제해줘야 한다.
또한, 로컬 저장소 삭제하는 방법은 탐색기에서 숨겨진 .git 파일을 날려주면 끝이다
그리고 소스트리로 가보면 not a git repository 라며 에러 뜸
-
또 다른 클론 방법을 사용해 보자. 어제 실습 때 생성한 gittest 파일을 원격지로 클론 하겠다.
먼저 깃허브에서 new repositroy 해준다
근데 리드미도 체크 안 해주고 뭐 다른 조건들 체크 안 해줘서 명령어만 뜬다.
연결하는 명령어들을 알려주는 것이다.
첫 번째 블록의 코드들은 로컬 저장소가 없어서 로컬 저장소를 만들고 push 하는 코드들이다.
(아직 로컬 저장소가 없는 상태에서 초기 세팅하는 것)
README 파일을 만들고 깃 초기화를 시킨 뒤, 생성한 README 파일을 인덱스에 올리고 커밋을 한다. (커밋 로그를 만듦)
그리고 브랜치 이름은 필요에 따라 변경한다. (처음 만들면 master로 만들어짐)
그리고 이게 중요하다.
git remote add origin http:// ~ 이 부분인데,
이 주소가 뭐냐면 방금 전에 만든 저장소의 주소이다.
로컬 저장소에 원격 저장소를 연결해 주는 작업이다. 그리고 push를 진행하면 로컬 저장소가 생성된다.
소스 트리에 들어가서 터미널 클릭하면 git bash가 열림
알려준 명령어들을 쓴 뒤 깃허브 새로고침을 한다.
그럼 위와 같이 이때까지 소스트리로 작업한 것들이 생성되는 것을 확인할 수 있었다.
그런데 우리는 브랜치 실습을 위해 여러 브랜치들을 만들어놓았었는데, 메인 브랜치만 올라오게 되었다.
남은 브랜치를 올리고 싶으면 마저 push 하면 된다. 태그도 push 가능하다.
리눅스에서 깃 저장소 연결하기
먼저 mobaXterm을 통해서 리눅스에 git 설치를 한다.
여기서 아래 명령어를 사용하면 git에 설정한 계정과 메일로 연결이 되었는지 확인이 가능하다.
git config --global user.name '이름'
git config --global user.email '메일'
git config --list
설치 이후에 ls ~/.ssh 명령어를 통해서 id_rsa(비공개 키)가 남아있는 경우에는 삭제해 준다. (rm ~/.ssh/id_rsa)
이후 아래와 같은 명령어를 사용해서 실행하면 키가 생성되었다고 뜬다.
ssh-keygen -t ed25519 -C "깃허브이메일주소"
이후 ls ~/.ssh를 입력하면 아래와 같이 파일이 두 개 생성된 것을 확인할 수 있는데,
하나는 비공개 키이고 .pub 파일은 공개 키이다.
공개 키를 윈도우로 다운로드 한 다음에 다운로드한 것을 확인했다면 공개 키는 삭제해 준다.
다시 깃 허브로 돌아가서 설정을 들어가면 'ssh and gpg key'라는 부분이 있다.
여기에 들어가서 ssh keys 부분에 title을 적고 아래에는 다운로드한 공개 키 내용을 복사 붙여 넣기 하여 넣어준다.
그리고 add 하면 깃 허브에 ssh키를 등록하였다.
-
실습을 위해 생성한 gittest 파일을 리눅스로 clone 해보겠다.
gittest에 들어가서 code 부분의 SSH 클릭 후 해당 키를 카피한다.
이후 리눅스에서 복사할 폴더로 가서 (cd) 붙여 넣기 후 실행하면
리눅스에 gittest가 clone 되었다.
-
"# Git Test" > README.md를 입력하여 실행하고 ls를 쳐보면
리눅스를 통해서 README 파일을 생성할 수 있었다.
git status를 입력해서 확인을 하면 아래와 같이 추적하지 않은 파일이 뜬다.
이게 push? pull을 하지 않았다는 것이다.
$ git add. 를 입력하면 브랜치에 업데이트했다는 것 같다.
다시 git status 하면 '새 파일: README.md"가 들어간 것을 알 수 있다.
또한, 리눅스를 통해서 commit 메시지도 남길 수 있다.
git commit -m "커밋 메세지"
위 코드를 이용해서 커밋 메시지를 남겨, 커밋 후 $ git status를 통해서 확인할 수 있다.
-
로컬에 있는 내용을 원격지로 보내려면 git push를 사용하면 된다.
그럼 아래와 같이 깃 허브 원격지에 새로 생성된 것을 확인할 수 있었다.
또한, 깃허브에서 README 파일 수정 후 리눅스에서 pull 받아보자.
이 때도 명령어는 단순하다. git pull 입력
이후 cat 명령어를 사용해서 README.md를 읽으면 원격지에서 수정한 내용이 올바르게 pull 된 것을 확인할 수 있었다.
브랜칭 전략 - git flow
브랜칭 전략 중 하나인 git flow에 대한 설명을 들었다.
master 브랜치
서비스를 직접 배포하는 역할
hotifx 브랜치
급한 에러가 생겼을 때 버그를 수정하는 브랜치 (빠르게 처리해야 하는 상황)
급하게 버그를 수정한 다음에 master랑 develop에 다시 결과를 각각 머지해 줌
release 브랜치
배포 전 검사하는 브랜치 (메인으로 보내기 전)
develop 브랜치
feature에서 개발된 내용이 저장되는 브랜치
feature 브랜치
기능을 개발하는 브랜치
-
소스트리에서 gitflowtest를 만든다. 그리고 README.md 파일을 하나 만들어 커밋해주었다.
오른쪽 상단에 있는 깃플로우 선택하면 앞서 설명한 깃 플로우를 사용할 수 있게 기능들을 제공함.
내가 사용하고자 하는 브랜치 설정 후에 확인을 눌리면 git flow 저장소 초기화가 되면서 develop 브랜치가 생겼다.
기존에는 브랜치를 직접 만들었다면 이제는 직접 만드는 게 아니라 git flow를 사용해서 만들고 알아서 머지도 해준다.
깃플로우를 다시 눌리면 하고자 하는 기능을 선택하고 아래와 같이 뜬다.
(develop과 master는 고정이다)
기능명을 정해주고 확인하면 새 브랜치가 생성된다. (나는 feature 브랜치 생성함)
그럼 feature 브랜치가 생기고 밑에 board가 생긴다. 생성이 됐다면 여기서 기능을 작업하면 된다.
-
이후 탐색기에 가서 파일을 하나 추가한다. 파일 이름은 게시판 페이지로 생성해 주었고 새로 커밋해 준다.
develop 브랜치에 가서 새 notice 브랜치를 하나 더 만들어준다.
(탐색기 열면 board에서 작업한 브랜치는 보이지 않음)
notice 브랜치 선택한 상태로 공지사항 페이지 문서를 하나 더 만들고 커밋을 진행해 주었다.
다시 board 브랜치로 돌아가서 게시판 페이지 수정하고 커밋 진행을 해주었다.
이렇게 여러 브랜치에서 작업이 끝나면 master에 병합을 해줘야 한다.
근데 이걸 우리는 직접 merge 하지 않고, git flow에서 알아서 해준다.
merge 할 브랜치로 체크아웃하고 깃플로우를 눌러 기능 마무리를 선택하면 아래와 같이 뜨면서
깃 플로우에서 알아서 merge 시켜준다.
아래 소스트리를 확인하면 develop 브랜치가 알아서 merge 해준 뒤 브랜치도 삭제해준다.
notice 브랜치도 사라지고 아래와 같이 병합된 것을 확인할 수 있다.
이 상태로 탐색기 클릭해서 확인하면 공지사항 페이지 문서도 합쳐져 있는 것을 볼 수 있다.
다음 board feature 브랜치로 가서 이 브랜치도 기능 마무리 해준다. 그럼 develop으로 머지된 것을 확인할 수 있다.
또한 게시판 페이지와 공지사항 페이지 모두 파일에 저장된 것을 확인할 수 있다.
-
이제 release라는 브랜치로 옮겨서 테스트해보겠다.
깃 플로우 시작해서 이번에는 새 릴리즈 시작을 눌리고 릴리즈 명 적어서 확인해 준다.
이 릴리즈 브랜치를 통해서 테스트를 진행한다. 테스트를 위해서 게시판 페이지.txt 파일 수정 후 커밋을 진행하였다.
릴리즈 마무리 할 때에도 깃플로우를 선택해서 아래와 같이 진행한다.
태그 필요 없으면 체크 풀면 된다.
사진 보면 main이랑 develop 브랜치 둘 다 병합이 된다.
-
핫 픽스 브랜치 작업도 해보자.
깃 플로우 선택 후 핫 픽스 브랜치를 만들고 txt 파일 수정 후 커밋을 진행한다.
그리고 핫픽스 마무리를 해주면 아래와 같이 여러 브랜치들이 머지된 것을 확인할 수 있다.
'일일 정리' 카테고리의 다른 글
| 240604 자바(1) - 프로그래밍 기초/자바/자바 개발환경구축/이클립스/변수/자료형/문자열/서식 지정자/escape 문자/Scanner (1) | 2024.06.07 |
|---|---|
| 240530 소프트웨어 공학 (3) - 소프트웨어 공학/UML 다이어그램 (0) | 2024.06.06 |
| 240528 소프트웨어 공학(1) - git/git 설치/git 태그, 브랜치, 머지/git 커밋/git 커밋 후 작업 취소 (1) | 2024.06.03 |
| 240527 MariaDB(8) - 리눅스에 MariaDB 설치/NOT EQUAL JOIN 실습/조인 실습 문제 (0) | 2024.05.28 |
| 240524 MariaDB(7) - 인덱스/스토어드 프로시져/트리거 (0) | 2024.05.26 |