Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기
깃(Git)의 rebase 명령은 커밋 내역을 수정하고자 할 때 사용할 수 있습니다. 커밋 메시지를 수정할 때 가장 많이 사용되는 것 중 하나입니다. 가장 먼저 실습을 위해 기본적인 커밋(Commit)을 몇 번 진행하겠습니다.
하나의 깃 프로젝트를 생성합니다.
하나의 텍스트 파일을 추가한 뒤에 커밋(Commit)합니다.
이후에 텍스트 파일에 내용을 작성한 뒤에 커밋(Commit)합니다.
이후에 해당 텍스트 파일을 삭제한 뒤에 다시 커밋(Commit)합니다.
이후에 새로운 텍스트 파일을 생성한 뒤에 커밋(Commit)합니다.
이제 깃 로그를 확인해 보시면 다음과 같이 총 4번의 커밋이 이루어져 있는 것을 확인할 수 있습니다. 저는 중간에 있는 [Delete Example 1.txt] 커밋의 메시지를 수정해보도록 하겠습니다.
커밋 메시지를 수정할 때에도 git rebase 명령어를 사용할 수 있습니다. -i 옵션을 붙이면 상호작용(Interactive) 모드로 에디터가 열리게 됩니다. 저는 HEAD를 기준으로 3개까지의 커밋을 확인하도록 해보겠습니다.
git rebase -i HEAD~3
그러면 다음과 같이 커밋 내역이 차례대로 출력됩니다. 이제 여기에서 수정하고자 하는 커밋에 대한 내용을 에디터에 적어주면 되는 방식입니다.
커밋 메시지를 바꾸고 싶을 때는 reword 키워드를 이용하면 됩니다. 저는 [Delete Example 1.txt] 커밋의 메시지를 수정해보도록 하겠습니다.
그러면 다음과 같이 새로운 에디터가 또 열리게 됩니다. 이제 여기에서 커밋 메시지를 바꾸어주면 됩니다.
결과적으로 다시 로그(Log)를 확인했을 때 다음과 같이 커밋 메시지가 변경된 것을 확인할 수 있습니다.
그렇다면 특정 커밋 자체를 삭제하고 싶을 때는 어떻게 하면 될까요? 마찬가지로 git rebase 명령어를 이용하면 됩니다. 다만, 다른 사람과 함께 작업하는 경우 커밋 자체를 삭제하는 것은 권장되지 않습니다. 충돌이 발생할 수 있어요. 그래도 경우에 따라서는 필요할 수 있는 기능이므로 다루어보도록 하겠습니다.
커밋 자체를 삭제하고 싶을 때는 drop 키워드를 이용하면 됩니다.
결과적으로 삭제 이후에는 해당 커밋 내역이 아예 증발하게 됩니다.
이제 폴더를 확인해 보시면 실제로 해당 커밋 자체가 존재하지 않았던 것처럼 처리된 것을 확인할 수 있습니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| 이미 작성된 Git Commit의 날짜와 시간을 변경해보자! (2) | 2019.04.06 |
|---|---|
| 깃(Git) 환경설정(config)에 대해서 알아보자! (0) | 2019.04.06 |
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
| Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강] (0) | 2018.12.23 |
| Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강] (0) | 2018.12.23 |
Git Archive 명령을 이용해 소스코드만 추출하기
깃 아카이브(Git Archive) 명령은 깃 프로젝트에서 소스코드만 추출하고 싶을 때 사용할 수 있습니다. 일반적으로 프로젝트의 소스코드를 간단히 다운로드 받아 사용하는 입장에서 사용할 수 있는 명령입니다.
가장 많이 사용되는 형태는 다음과 같습니다.
git archive --format=zip {추출할 브랜치} -o {저장할 파일 이름}저는 다음과 같이 master 브랜치 및 development 브랜치의 소스코드를 추출해보았습니다.
다만 단순히 추출하면 Git 프로젝트 내에 압축 파일이 존재하게 되므로 ../{저장할 파일 이름} 형태로 추출하는 것이 일반적입니다.
'기타' 카테고리의 다른 글
| git commit을 진행할 때 username이 root 계정으로 설정되는 경우 (0) | 2019.04.06 |
|---|---|
| 웹 사이트 저장소! 웹 아카이브(Web Archive)를 살펴보자 (0) | 2019.04.05 |
| 깃(Git) 커미터(Committer) 이름 변경하는 방법 (1) | 2019.04.02 |
| 구글 애드센스(Google Adsense) 광고비 입금 받는 일자 늦추는 방법 (1) | 2019.02.26 |
| Firefox를 이용해 ESNI를 적용하는 방법 (1) | 2019.02.15 |
깃(Git) 커미터(Committer) 이름 변경하는 방법
간혹 깃(Git)을 이용하다 보면 커미터(Committer)의 이름을 바꾸고 싶을 때가 있습니다. 혹은 깃 계정이 변경되거나 해서 이전 계정으로 커밋되어 있는 내용을 현재 계정으로 변경해야 할 때가 존재할 수 있습니다.
저의 경우는 깃으로 소스코드를 작성할 때 이메일을 잘못 설정해서 다음과 같이 계정 이름만 ndb796이고, 이메일은 이상하게 등록되어 있는 상태였습니다. 따라서 이메일을 바르게 다시 작성할 필요가 있었습니다.
이 때는 가장 먼저 해당 깃 프로젝트를 클론 하시면 됩니다. 그리고 해당 깃 프로젝트 경로로 들어갑니다.
git clone {깃 프로젝트}
cd {깃 프로젝트}
이후에 깃(Git) 로그를 확인하여 잘못된 계정으로 커밋되어 있는 내용을 확인합니다.
git log
저는 다음과 같이 ndb796@email.com이라는 이상한 이메일로 커밋이 되어 있는 상태였습니다.
따라서 리눅스(Linux) 환경을 기준으로 다음과 같은 명령어를 넣으시면 됩니다.
git filter-branch --env-filter '
OLD_EMAIL="{예전 이메일}"
CORRECT_NAME="{현재 이름}"
CORRECT_EMAIL="{현재 이메일}"
if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_AUTHOR_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags저는 ndb796@email.com으로 작성되어 있는 커밋을 ndb796@naver.com으로 변경했습니다.
위 명령어 입력 이후에 다시 깃(Git) 로그를 확인해 보니 다음과 같이 정상적으로 변경되어 있는 것을 확인할 수 있었습니다.
git log
이제 변경된 내용을 강제로 푸시하시면 됩니다. 다만, 강제로 푸시하실 때에는 원하지 않은 커밋 내용이 반영될 여지가 있기 때문에 유의할 필요가 있습니다. 다음의 명령어로 마스터(Master) 브랜치의 변경된 내역을 푸시할 수 있습니다.
git push --force --tags origin 'refs/heads/master'
푸시 이후에 실제로 깃 허브(Git Hub)에 가보시면 다음과 같이 커밋 내역이 수정되어 있는 것을 확인할 수 있습니다.
깃 수정이 완료된 이후에는 임시적으로 클론(Clone)을 수행했던 해당 깃 프로젝트 폴더를 제거합니다.
'기타' 카테고리의 다른 글
| 웹 사이트 저장소! 웹 아카이브(Web Archive)를 살펴보자 (0) | 2019.04.05 |
|---|---|
| Git Archive 명령을 이용해 소스코드만 추출하기 (0) | 2019.04.03 |
| 구글 애드센스(Google Adsense) 광고비 입금 받는 일자 늦추는 방법 (1) | 2019.02.26 |
| Firefox를 이용해 ESNI를 적용하는 방법 (1) | 2019.02.15 |
| XML, JSON, YAML 형식 내용 정리 및 비교 분석 (0) | 2019.01.20 |
AWS S3 사용 방법 및 Cloud Front 적용해보기
AWS S3는 스토리지 서비스(Storage Service)입니다. 쉽게 말하자면 특정한 사진, 동영상 등의 파일을 저장하기 위해 사용할 수 있는 서비스입니다. 사용 예시는 매우 광범위합니다. 게시판 웹 사이트를 개발 할 때 이미지 파일만을 S3에 저장할 수 있으며, 특정한 로고 사진 등을 S3에 저장하여 사용자가 빠르게 사진 파일을 다운로드 받도록 처리하는 등의 작업이 가능합니다.
S3에서 객체(Object)란 저장되는 파일을 의미하고, 버킷(Bucket)은 파일이 저장될 프로젝트를 의미합니다.
AWS S3 서비스에 파일 올리기
바로 한 번 AWS S3 서비스를 이용해 보도록 하겠습니다.
AWS S3에서는 [버킷 만들기] 버튼을 눌러서 버킷을 생성할 수 있습니다. 쉽게 말하면 하나의 프로젝트를 생성해주는 것입니다.
- [버킷 이름]은 다른 서버와 겹치지 않는 고유한 이름이 되어야 합니다.
- 리전(Region)은 일반적으로 S3을 사용하는 사용자와 가까운 위치가 되도록 설정합니다. 다만 저는 Cloud Front의 성능을 측정하기 위해서 EU(런던)으로 설정했습니다.
이후에 [권한 설정] 탭에서는 실습을 위하여 일단 간단히 퍼블릭(Public) 공간에서 누구든지 접속할 수 있도록 하겠습니다. 따라서 권장 사항으로 제시되어 있는 모든 권한 정책에 체크를 풀어줍니다.
이후에 만들어진 S3 버킷을 확인합니다.
이후에 실습을 위하여 두 개의 파일을 이용하겠습니다. 약간 무거운 파일(5 MB 파일)과 가벼운 파일(1KB 미만)을 준비했습니다. 이 두 개의 파일을 버킷 내에 업로드하여 확인하고자 합니다.
Example.zip
5.20MB
.txt
0.00MB
이후에 [개요] 탭으로 가서 실제로 파일을 업로드할 수 있습니다.
두 개의 파일을 올린 이후에 업로드를 진행하면 됩니다.
두 파일이 올라간 이후에는 언제든지 다운로드 할 수 있습니다.
이제 사용자 입장에서 해당 파일을 다운로드 받는다고 가정하겠습니다. 특정한 파일을 누르면 퍼블릭(Public)에서 접근 가능한 URL 경로를 확인할 수 있습니다.
하지만 실제로 해당 경로에 접속을 해보면 접근 불가(Access Denied)라고 출력되는 것을 알 수 있습니다.
따라서 S3는 개별적으로 파일을 선택하여 [퍼블릭으로 설정]을 눌러 퍼블릭 형태로 설정할 수 있습니다. 한 번 해당 파일을 퍼블릭으로 설정해보도록 하겠습니다.
[퍼블릭으로 설정] 버튼을 누르시면 됩니다.
[퍼블릭으로 설정]한 이후에는 다시 해당 경로로 접속했을 때 내용을 확인할 수 있습니다.
버킷 정책 수정하기
다만 이렇게 일일히 파일을 [퍼블릭으로 설정]하는 것을 귀찮은 작업이 될 수 있습니다. 따라서 특정한 범위의 파일에 대해서 전부 한꺼번에 [퍼블릭으로 설정]하는 방법도 있습니다. [권한] 탭으로 가서 [버킷 정책]을 수정하여 버킷 내에 모든 파일들이 퍼블릭(Public)에서 접근이 가능하도록 설정할 수 있습니다. 다만 여기에 들어가는 내용은 [정책 생성기]를 통해 생성할 수 있습니다.
[정책 생성기] 버튼을 눌러서 S3 접근을 위한 설정을 할 수 있습니다. 다음과 같이 [S3 Bucket Policy]를 선택한 뒤에 Principal에는 *을 넣습니다. AWS Service에는 [Amazon S3]를 넣습니다. 이후에 Actions에 [GetObject]를 넣습니다.
이는 해당 URL을 알고 있는 모든 주체(Principal)가 객체에 접근할 수 있는 것을 의미합니다. 또한 객체(Object) 즉, 파일을 다운로드 할 수 있도록 설정하겠다는 의미입니다.
그리고 Resource에는 자신의 AWS S3 고유 경로를 넣은 뒤에 접근할 수 있는 파일의 URL을 설정합니다. 파일의 URL로 /*라고 넣어주게 되면 해당 버킷 내의 모든 객체에 접근할 수 있도록 하겠다는 의미입니다.
이제 [Generate Policy] 버튼을 눌러서 실제로 정책을 생성할 수 있습니다.
이제 생성된 정책 내용을 복사하여 [버킷 정책]의 내용으로 붙여넣기 합니다.
이제 [퍼블릭으로 설정]을 진행하지 않은 Example.zip 파일에 대해서도 URL 경로에 접속하면 다운로드를 받을 수 있게 되었습니다. 다시 말해 모든 파일에 누구든지 접근하여 다운로드 받을 수 있도록 설정한 것입니다.
실제로 다음과 같이 다운로드가 이루어지는 것을 확인할 수 있습니다.
Cloud Front 적용하기
이제 Cloud Front을 이용하여 더 빠르게 리소스를 제공할 수 있도록 하겠습니다. 따라서 Cloud Front 콘솔로 이동합니다. 그리고 [Create Distribution]을 누릅니다.
이후에 배포하고자 하는 대상(Origin Domain Name)으로 우리의 S3를 설정합니다.
이후에 기본 설정으로 바로 [Create Distribution]을 눌러 배포를 진행합니다.
이후에 다음과 같이 처리 진행 중(In Progress) 상태인 것을 확인할 수 있습니다.
약 20분의 시간이 흐른 뒤에 배포 완료(Deployed) 상태가 된 것을 확인할 수 있습니다.
이제 다음과 같이 클라우드 프론트의 URL을 이용해 index.txt를 확인할 수 있게 되었습니다. 맨 처음에 특정 리소스에 접근하려고 하면 아직 CDN 서버에 퍼지지 않았기 때문에 [Miss from cloudfront]라는 캐시를 확인할 수 있습니다.
이후에 두 번째 접속을 할 때부터는 [Hit from cloudfront]이라는 캐시(X-Cache) 메시지를 확인할 수 있습니다. 다시 말해서 Cloud Front를 거쳐서 리소스를 다운로드 받게 된 것입니다.
이상으로 AWS S3 및 Cloud Front의 기본적인 사용법을 알아보았습니다.
'AWS' 카테고리의 다른 글
| AWS EC2 인스턴스를 이미지(AMI)로 만들어 그대로 저장하기 (0) | 2019.04.09 |
|---|---|
| AWS 람다(Lambda)로 Python 서버 API 구현하기 ① Hello World (0) | 2019.04.09 |
| AWS RDS로 만든 MySQL 기준 시간을 한국 시간으로 설정하는 방법 (0) | 2019.03.27 |
| AWS EC2 인스턴스 성능(사양) 변경하는 방법! (인스턴스 유형 변경) (0) | 2019.03.19 |
| AWS EC2에 탄력적 IP(Elastic IP)를 이용해 고정 IP 부여하기 (0) | 2019.03.19 |
