GitHub의 오픈 소스 프로젝트는 개발자가 기술 개발에 기여하면서 배우는 가장 좋은 방법일 것입니다. AI/ML 분야도 다르지 않습니다. 점점 더 많은 사람들이 AI/ML 모델을 구축하는 데 관심을 갖게 되었고, 몇몇 대형 기술 회사도 개발 발전을 위해 코드를 공개했습니다.

다음은 시도해볼 수 있는 이러한 인기 있는 오픈 소스 프로젝트 12개의 목록입니다!

TensorFlow

텐서플로 또는 텐서플로우는 다양한 작업에대해 데이터 흐름 프로그래밍을 위한 오픈소스 소프트웨어 라이브러리입니다. 심볼릭 수학 라이브러리이자, 인공 신경망같은 기계 학습 응용프로그램 및 딥러닝에도 사용된다. 위키백과

텐서플로(TensorFlow) 또는 텐서플로우는 다양한 작업에대해 데이터 흐름 프로그래밍을 위한 오픈소스 소프트웨어 라이브러리입니다. 심볼릭 수학 라이브러리이자, 인공 신경망같은 기계 학습 응용프로그램 및 딥러닝(deep Learning)에도 사용됩니다.

TensorFlow 플랫폼은 데이터 자동화, 모델 추적 및 재교육, 성능 모니터링에 사용됩니다. Google Brain 팀에서 개발했으며 약 150,000명의 활성 기여자가 있습니다. 이 모델의 유연성으로 인해 프로젝트에 포함하는 개발자 서클에서 매우 인기가 있습니다.

GitHub 리포지토리를 사용하면 사용자가 편의를 위해 클라우드 또는 모바일 장치에서 빌드할 수 있습니다. 이 알고리즘은 이미지 분류, 음성 인식, 분할 등과 같은 많은 컴퓨터 비전 기반 응용 프로그램에 사용됩니다.

OpenCV

OpenCV은 실시간 컴퓨터 비전을 목적으로 한 프로그래밍 라이브러리입니다. 원래는 인텔이 개발하였다. 실시간 이미지 프로세싱에 중점을 둔 라이브러리입니다. 인텔 CPU에서 사용되는 경우 속도의 향상을 볼 수 있는 IPP를 지원합니다. 위키백과

Computer Vision은 아마도 로봇에서 자율주행 차량에 이르기까지 인공 지능을 위한 가장 수요가 많은 도구일 것입니다. OpenCV는 기계 학습 작업에서 컴퓨터 비전을 사용하기 위한 대규모 오픈 소스 리포지토리를 제공하며 Python 개발자가 사용할 수 있습니다.

저장소에는 컴퓨터 비전과 관련된 2500개 이상의 알고리즘이 있으며 Google, IBM, Intel과 같은 빅 테크 회사는 많은 개발 프로젝트에서 이를 사용합니다.

React-Native

리액트 네이티브는 페이스북이 개발한 오픈 소스 모바일 애플리케이션 프레임워크입니다. 안드로이드, iOS, 웹, UWP용 애플리케이션을 개발하기 위해 사용되며, 개발자들이 네이티브 플랫폼 기능과 더불어 리액트를 사용할 수 있게 합니다. 완전하지 않은 Qt 포팅 또한 존재합니다. 위키백과

Facebook, Twitter 및 Pinterest를 포함한 거의 모든 소셜 미디어 플랫폼에서 사용됩니다. 프레임워크를 통해 개발자는 플n랫폼에서 기본 앱을 빌드하고, 기본 UI 컨트롤에 대한 전체 액세스 권한을 얻을 수 있습니다.

GitHub 커뮤니티에는 100,000개 이상의 별이 있으며 기여자가 활발하게 증가하고 있습니다. 플랫폼에는 개발자가 쉽게 이해하고 수정할 수 있는 선언적 보기가 있습니다.

DALL-E

DALL-E와 DALL-E 2는 오픈AI가 자연어 서술로부터 디지털 이미지를 생성하기 위해 개발한 기계 학습 모델입니다. DALL-E는 2021년 1월 블로그 게시물에서 오픈AI에 의해 공개되었으며, 이미지 생성을 위해 개조된 GPT-3 버전을 사용합니다.

text-to-image 모델이 화제가 되고 있으며 DALL-E가 GitHub에 코드를 공개함에 따라 가능성은 이제 무한합니다. 기계 학습 모델이 어떻게 작동하는지 알아보려면 DALL-E에 단어를 연결하고 기계가 "생각하는" 방식을 확인하세요.

GitHub의 오픈 소스 프로젝트는 VAE를 위해 DALL-E에서 사용되는 공식 PyTorch 패키지이지만 패키지에는 이미지 생성에 사용되는 변환기가 포함되어 있지 않습니다.

VAE는 Autoencoder로 데이터의 latent space를 찾으면서, 동시에 variational inference를 통해 latent space를 normal distribution을 가정한 prior로 regularization 합니다.

YOLOv7

YOLO는 You Only Look Once의 약자로써 이미지 및 동영상 탐지에 사용되는 딥러닝 모델입니다.

자율 차량, 로봇 또는 기타 비전 기반 장치와 관련하여 물체 감지는 시스템의 핵심 부분 중 하나입니다. 가장 빠르고 정확한 물체 감지 알고리즘 중 하나인 YOLOv7은 완벽한 솔루션을 제공합니다.

GitHub 리포지토리에는 개발자가 프로젝트에서 구현하고 이미지 컬렉션을 제공하여 모델을 교육할 수 있는 패키지가 포함되어 있으며 모델은 탐지 프로세스를 시작합니다.

쿠버네티스는 컨테이너화된 애플리케이션의 자동 디플로이, 스케일링 등을 제공하는 관리시스템으로, 오픈 소스 기반입니다. 원래 구글에 의해 설계되었고 현재 리눅스 재단에 의해 관리되고 있습니다. 위키백과

K8s는 개발자가 모든 플랫폼에서 컨테이너화된 앱을 관리할 수 있도록 Google에서 개발했습니다. 자동화된 시스템은 앱의 확장, 개발 및 관리를 지원합니다.

GitHub에 70,000개 이상의 별이 있는 Google에서 구축한 가장 인기 있는 저장소 중 하나입니다. 컨테이너 패키지 서비스의 글로벌 리더인 K8s는 CNCF(Cloud Native Computing Foundation)에서 호스팅합니다.

Flutter

플러터는 구글이 출시한 오픈 소스 크로스 플랫폼 GUI 애플리케이션 프레임워크입니다. 안드로이드, iOS, 윈도우즈, 리눅스 및 웹용 애플리케이션과 구글 퓨시아용 앱의 주된 소스코드로 사용된다. 위키백과

Google에서 개발한 또 다른 Flutter는 개발자가 인터페이스 툴킷을 사용하여 단일 코드베이스에서 앱을 빌드할 수 있게 해주는 소프트웨어 개발 키트(SDK)입니다. Skia에 의해 구동되므로 생성된 앱은 PC, 웹 및 모바일 플랫폼과 호환됩니다.

GitHub의 100,000 별 커뮤니티는 witbiOS와 함께 Android 및 Chromium 기반 애플리케이션과 호환되며 코드를 엉망으로 만들지 않고 그래픽, 텍스트 및 비디오 오버레이를 매끄럽게 통합하는 데 효과적입니다.

Jenkins

젠킨스는 소프트웨어 개발 시 지속적 통합 서비스를 제공하는 툴입니다. 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git등의 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해 준다. MIT 라이선스를 따른다. 위키백과

이 Java 기반 자동화 서버에는 거의 모든 것을 자동화하기 위한 1800개 이상의 플러그인이 있습니다. 사용하기 쉬운 프레임워크이며 모든 언어로 조정 가능한 지속적인 통합 및 전달 환경을 제공하는 것과 함께 애플리케이션을 빌드, 테스트 및 배포하는 데 유용합니다.

Jenkins는 정적 코드 분석 및 모델의 버그 감지에도 유용합니다. 이 서버를 통해 개발자는 지루하고 반복적인 작업을 실행 및 자동화하고 기계가 할 수 없는 작업에 집중할 수 있습니다.

Ansible

Ansible은 오픈 소스 소프트웨어 프로비저닝, 구성 관리, 애플리케이션 전개 도구입니다. 수많은 유닉스 계열 시스템에서 실행되며 유닉스 계열 운영 체제 및 마이크로소프트 윈도우의 구성이 가능하다. 시스템 구성을 기술하기 위해 자체 선언형 언어를 포함하고 있습니다. 위키백과

2016년 RedHat에서 시작한 Ansible은 개발자가 시스템을 구성하고, 네트워크를 관리하고, 소프트웨어를 배포할 수 있는 자동화 플랫폼입니다. 설정이 매우 간단하고 학습 곡선이 거의 없기 때문에 많은 관심과 기여를 받았습니다.

약 55,000개의 별이 있는 Ansible은 접근 방식이 일반 영어와 매우 유사하기 때문에 적극적으로 기여 및 업데이트를 받고 있습니다.

PredictionIO

Apache PredictionIO®는 개발자와 데이터 과학자가 모든 기계 학습 작업에 대한 예측 엔진을 생성할 수 있도록 최첨단 오픈 소스 스택 위에 구축된 오픈 소스 기계 학습 서버 입니다. 다음을 수행할 수 있습니다.

  • 사용자 지정 가능한 템플릿 을 사용하여 프로덕션 환경에서 엔진을 웹 서비스로 신속하게 구축 및 배포합니다 .
  • 웹 서비스로 배포되면 실시간 으로 동적 쿼리에 응답합니다 .
  • 여러 엔진 변형을 체계적으로 평가하고 조정합니다.
  • 포괄적인 예측 분석을 위해 여러 플랫폼의 데이터를 일괄 또는 실시간으로 통합합니다.
  • 체계적인 프로세스와 사전 구축된 평가 수단으로 머신 러닝 모델링 속도를 높입니다.
  • Spark MLLib 및 OpenNLP와 같은 기계 학습 및 데이터 처리 라이브러리 지원
  • 고유한 기계 학습 모델을 구현하고 이를 엔진에 원활하게 통합합니다.
  • 데이터 인프라 관리를 단순화합니다.

알고리즘 배포, 이벤트 수집 및 평가, 예측 결과 쿼리를 지원하는 오픈 소스 ML 프레임워크입니다. HBase, Hadoop, Spark 및 Elasticsearch를 기반으로 하며 기계 학습 프로젝트를 위한 예측 엔진을 생성합니다.

이 프로젝트는 GitHub에 12,000개 이상의 별을 가지고 있으며 REST API를 통해 예측 결과를 생성합니다.

LightGBM

영어에서 번역됨-LightGBM은 Light Gradient-Boosting Machine의 약자로, 원래 Microsoft에서 개발한 머신 러닝을 위한 무료 오픈 소스 분산 그래디언트 부스팅 프레임워크입니다. 위키백과(영어)

의사 결정 트리 알고리즘을 기반으로 하는 가장 빠른 고성능 그래디언트 부스팅 프레임워크인 LightGBM은 주로 다른 기계 학습 작업 중에서 분류, 순위 지정에 사용됩니다. 여러 GPU로 대규모 데이터 및 병렬 학습을 지원하므로 다른 모든 경쟁자보다 매력적입니다.

Microsoft에서 개발한 LightGBM은 GitHub에 약 14,000개의 별을 가지고 있으며 개발자로부터 적극적으로 기여를 받고 있습니다.

ElasticSearch

일래스틱서치는 루씬 기반의 검색 엔진입니다. HTTP 웹 인터페이스와 스키마에서 자유로운 JSON 문서와 함께 분산 멀티테넌트 지원 전문 검색 엔진을 제공한다. 일래스틱서치는 자바로 개발되어 있으며 아파치 라이선스 조항에 의거하여 오픈 소스로 출시되어 있습니다. 위키백과

이 오픈 소스 프로젝트는 대용량 데이터를 실시간으로 분석, 검색 및 저장합니다. 이는 로그, 메트릭, 엔드포인트 보안, 검색 백엔드 및 애플리케이션 모니터링과 같은 데이터 관리가 필요한 프로젝트에 통합될 수 있습니다.

60,000개 이상의 별을 보유한 Elasticsearch는 개발자가 프로젝트 내에서 다양한 검색 엔진의 백엔드를 구축하고 개선할 수 있도록 해왔습니다.

반응형
저작자표시 비영리

'개발' 카테고리의 다른 글

AI 분야의 프롬프트 및 프롬프트 엔지니어링 이해  (0) 2023.04.03
주니어 개발자를 위한 조언  (0) 2022.11.03
블루투스 BLE 에 대한 정리  (0) 2022.10.29
자주 실수하는 git  (0) 2022.10.26
centos7,8 SSL(HTTPS) 무료인증서 설치  (0) 2022.10.11

소프트웨어에 개발에서 실수를 했을 때, 간단히 돌아오는 방법이 있습니다. GIT을 사용해서 프로젝트를 관리한다면 실수에서 벗어나는데 큰 도움이 됩니다.

1. 추적 된 파일 추적 금지

빈번히 발생하는 일 중에 node_modules를 포함해서 commit 했고, .gitignore파일이 없다는 것을 발견 했습니다. 이제서야 .gitignore에 node_modules를 추가 했지만, git은 여전히 node_modules 을 추적하고 있습니다.
git base에 commit이 되면서 git이 계속변경 사항을 추적하기 때문입니다. 이를 중지하기 위해서는 아래와 같이 입력 합니다.

git base 에 있는 파일이 삭제 됩니다.

git rm -r --cached node_modules

2. 마지막 commit 수정

local -> git remote 로 commit을 했습니다. 그 후 커밋 파일에 변경 사항을 포함하는 것을 잊었습니다. 또는 가장 최근 커밋한 동일한 커밋에 연결하려는 새 파일을 추가합니다.

git은 이전 커밋을 잠금 해제하고 새 파일을 추가 할 수 있습니다.

git add newfile
git commit --amend -no-edit

--no-edit: commit 메세지를 변경하지 않고, comiit을 수정합니다.

3. 마지막 commit 메세지 수정

위의 수정내용과 비슷합니다. git에 commit을 했는데, commit 한 메세지가 원하는 내용과 달라졌습니다.

git commit --amend -m '메세지가 #2 로 바뀜'

4. 작업 폴더내의 작업내역 삭제

프로젝트를 진행하고 있습니다. 코드를 수정하는 동안 프로그램이 손상되었고, 실제로 무엇이 잘못 되었는지 파악할 수 없게 되었습니다.
현재 작업내용을 취소하고 마지막 commit 시점으로 돌아가야 할 것 같습니다.

git restore .

또는 

git reset --hard

이 작업 local 저장소에서 최근 커밋으로 복원 합니다. 커밋하지 않는 내용은 모두 손실 됩니다.

5. 특정파일에 대한 작업 내용 취소

local 저장소의 파일을 수정했습니다. 히지만, test.js 파일의 변경 사항이 의미가 없었다는 것을 알고, 폐기하려고 합니다.

git restore test.js

6. 시간을 거슬러 이전 버전으로 파일 복원

위의 명령어와 달리 파일을 이전 특정 시점 상태로 돌아가기를 원합니다. test.js 파일을 최근 commit 된 내용이 v10 이지만, v2 시점으로 돌아가려고 합니다.

git log


commit d94629103526ddfa0715ca9393362a3b70e097b
Merge: aa034a93 1809aa89
Date:   Tue Aug 9 07:40:00 2022 +0900

    Merge pull request #15 from aaaaaday/master

commit 1809aklflkajlkhfeff890913ec751b36167560
Date:   Sun Aug 7 16:26:45 2022 +0100

    리뷰에 따라 수정 완료

commit 1b93eehwkhflwkehf280b513806b000dd033b9f
Date:   Sat Aug 6 00:58:16 2022 +0100

    원문과 최대한 라인수 일치하도록 수정

를 통해 복원하려고 하는 시점의 commit hash 를 찾습니다.

git restore --source <commit-hash> <파일이름>

7. 삭제한 파일 복원 (이전 commit)

프로젝트를 새로 변경하고 있는데 사용되지 않는 파일이 표시됩니다. 계속해서 파일을 삭제 했습니다.
그러나, 삭제한 파일 deleted_file.js가 필요하다는 것을 알게 되었습니다.

git restore deleted_file.js

8. local 저장소의 모든 변경사항을 remote 상태로 취소합니다.

local repo 브런치에세 몇가지 변경 사항과 commit을 했습니다. 그런데, 변경 사항을 모두 pull을 받았을 당시로 되돌리려고 합니다.

git reset --hard origin/master

commit 되지않는 파일은 영구적으로 삭제 됩니다.

9. 추적되지 않는 파일 삭제 (untracked file)

프로젝트에 여러 개의 새 파일을 만들고 일부 파일도 수정했습니다. 접근 방식을 변경했으며 이제 생성한 새 파일이 더 이상 필요하지 않지만, 수정된 파일 변경 사항을 유지하기로 결정했습니다.
Git은 추적되지 않은 파일을 제거하는 명령을 제공합니다.

git clean -f

git clean 명령에는 force 지시문(또한 --force)을 의미하는 -f 플래그가 필요합니다.

이 작업에는 추적되지 않은 파일 삭제가 됩니다. Git에서 커밋되지 않은 작업을 제거하는 것은 취소할 수 없습니다.

기본적으로 이 명령은 .gitignore로 지정된 추적되지 않은 폴더나 파일을 제거하지 않습니다. 무시된 파일을 제거하려면 -x 옵션을 지정하십시오. 또한 git clean은 디렉토리에서 재귀적으로 작동하지 않습니다.
이것은 우발적인 영구 삭제를 방지하기 위한 또 다른 안전 메커니즘입니다. 디렉토리를 제거하려면 다음과 같이 -d 플래그를 사용하십시오.

자식 청소 -df 이렇게 하면 추적되지 않은 파일과 디렉토리가 지워지지만 .gitignore 파일에 나열된 파일과 디렉토리는 제거되지 않습니다.

10. commit 을 다른 branch로 전환

프로젝트가 발전했으며 현재 newsletter 추가와 layout 미세 조정이라는 두 가지 기능을 작업하고 있습니다. newletter와 layout이라는 두 개의 별도 분기를 만들었으며 각 분기를 관련 기능인 뉴스레터 및 레이아웃 전용으로 지정했습니다.

현재 뉴스레터 기능을 추가하고 있으며 뉴스레터 분기에서 몇 가지 커밋을 수행하고 있습니다. 다음에 프로젝트로 돌아올 때 레이아웃 기능에 대해 작업하려고 하는데 연결된 레이아웃 분기로 전환하는 것을 잊었습니다. 잘못된 뉴스레터 분기에서 레이아웃 기능을 추가하고 커밋했습니다.

나중에 뉴스레터 분기에 추가한 커밋이 실제로 레이아웃 분기에 속한다는 사실을 알게 됩니다.

따라서 커밋 추가 레이아웃 기능이 뉴스레터 분기에서 올바른 레이아웃 분기로 이동되기를 원합니다.

Git에서 수행할 작업은 다음과 같습니다.

newleter 지점으로 checkout

git checkout newletter

레이아웃 기능을 추가한 커밋의 커밋 해시를 찾아 복사합니다. 다음 명령을 실행합니다.

git log
# aceew89e0ac

이 커밋으로 적용하려는 올바른 브랜치를 확인하십시오. 우리의 경우:

git checkout layout

# 확인한 hash을 layout branch에 적용
git cherry-pick <commit-hash>

그런 다음 뉴스레터 분기를 확인합니다.

git checkout newletter
# 잘못 commit 한 내용을 삭제 합니다.
git reset HEAD~1 --hard
or
git reset HEAD^ --hard

HEAD~1은 뉴스레터 브랜치를 재설정하여, 가장 최근 커밋 뒤로 하나의 커밋을 옮기고 다른 곳으로 이동한 커밋을 제거한다는 의미입니다. 우리의 경우 이 newletter 분기에 대한 최신 커밋은 layout 기능이 있는 커밋이었습니다.

11. 삭제된 branch 부활시키기

더 이상 기능 브랜치가 필요하지 않다고 생각하고 삭제했습니다. 다음번에는 삭제가 실수였다는 사실을 알 수 있습니다. 이 황당한 사건에 대해서 당황해 합니다. 당신은 불가능하게 시간을 되돌려 그것을 되찾고 싶어합니다.
삭제된 브랜치를 되돌리고 싶어합니다.

삭제된 브랜치를 복구하는 방법은 다음과 같습니다.

명령을 실행할 때 나열될 삭제된 분기의 커밋 해시를 찾아 복사합니다.

git reflog

그런 다음 다음과 같이 분기를 다시 만듭니다.

git branch <new-branch-name> <삭제된 브런치 hash>

이것은 <deleted-branch-commit-hash>까지의 모든 작업을 포함할 분기를 다시 생성합니다. <deleted-branch-commit-hash>가 삭제된 분기의 최신 작업이 아닌 경우, 최신 작업이 있는 커밋을 얻을 때까지 새 커밋 해시를 찾을 수 있습니다.
git branch를 입력하면 이전에 삭제한 브랜치가 다시 나열되는 것을 볼 수 있습니다. 이것은 Origin(remote)에서 브랜치가 삭제된 경우에도 작동합니다.

<branch-name>이 원하는 이름이 아닌 경우 git branch -m <branch-name> <new-branch-name>으로 이름을 바꾸면 됩니다.

삭제된 브랜치를 성공적으로 되돌리는 열쇠는 올바른 커밋 해시를 찾는 것입니다. 커밋의 이름을 똑똑하게적 지정하십시오. 그것은 많은 도움이됩니다.

12. 잘못된 commit 되돌리기

팀에서 새 버전의 프로젝트를 출시했습니다. 추가된 모든 새로운 기능이 절대적인 마스터 클래스임을 모두 확신합니다. 잠시 후 팀 리더의 긴급 전화로 새 버전에 중요한 결함이 있으며 즉시 수정해야 한다는 연락이 왔습니다. 엔지니어링 팀은 긴급 조치를 취해야 하며, 앉아서 결함을 찾는 것은 긴급한 문제에 대한 적절한 대응이 아닙니다.

가장 빠른 응답 중 하나는 오류가 발생하기 쉬운 릴리스에 대한 변경 사항을 취소하는 것입니다. 따라서 커밋에 대한 변경 사항을 취소하고 싶습니다.

Git에서 진행하는 방법은 다음과 같습니다.

변경 사항을 취소하려는 커밋(깨진 커밋)의 커밋 해시를 찾아 복사합니다.

git log
# 해당 커밋에 지정된 변경 사항 되돌리기
git revert <잘못 된 commit-hash>

git revert는 되돌린 변경 사항으로 새 커밋을 만듭니다.

깨진 커밋에 지정된 모든 변경 사항은 새 커밋에서 롤백됩니다. 예를 들어, 깨진 커밋에서 제거된 모든 것이 새 커밋에 추가되고, 깨진 커밋에서 추가된 모든 것이 새 커밋에서 제거됩니다.
생성될 커밋 되돌리기에 대한 기본 커밋 메시지와 함께 기본 편집기가 팝업됩니다. 원하는 대로 수정할 수 있습니다.

13. merge(병합) 취소

기능 분기의 새로운 변경 사항에 만족합니다. 기능 브랜치를 메인 브랜치에 병합할 준비가 된 것 같습니다. 따라서 기본 분기에서 기능 분기를 병합하고, 새 변경 사항을 원격 저장소에 푸시합니다.

잠시 후, 병합이 실제로는 그다지 좋은 코드가 아니라는 것을 알게 되었습니다. 그래서 병합을 취소하고 싶습니다.

# master branch로 이동합니다
git checkout master
# 병합 commit의 hash를 확인합니다
git log
# 되돌리기
git revert -m 1 <merge-commit-hash>

병합의 분기는 해당 병합의 부모입니다.

일반적으로 git은 병합의 어느 쪽(부모)이 메인라인으로 간주되어야 하는지 모르기 때문에 병합을 되돌릴 수 없습니다. git revert -m 1 메인라인의 상위 번호를 지정하고 지정된 상위 항목에 상대적인 변경 사항을 되돌리기 위해 revert를 허용합니다.

일반적으로 git merge 중에 가장 먼저 기록되는 부모는 병합할 때 있던 분기입니다. 여기서 오류의 경우 메인 브랜치에서 체크아웃하는 동안 feature 브랜치를 병합했습니다. 따라서 -m 1은 주 분기를 지정합니다.

14. 이전 버전으로 롤백

프로젝트를 이전 버전으로 롤백할 수 있습니다. 이렇게 하면 최근에 깨진 커밋 이전에 올바르게 작동하던 버전으로 돌아가려고 합니다.

여기에 표시된 git 명령은 기록을 다시 씁니다. 다른 사람과 소프트웨어 프로젝트를 공동 작업할 때는 적합하지 않습니다. 부득이 작업을 하게 된다면 다른 사람들에게 해당 내용을 공유하여야 합니다.

따라서 리포지토리의 기록을 되감아 프로젝트의 이전 버전으로 이동하려고 합니다.

git reset --hard <commit-hash>

git reset은 HEAD 포인터(따라서 작업 트리)를 이전 버전(<commit-hash>)으로 이동합니다.
이 버전 이후의 커밋은 프로젝트 기록에서 제거됩니다.

--hard 플래그는 스테이징 영역과 작업 트리를 재설정합니다.

git reset --mixed <commit-hash>와 같은 --mixed 플래그를 사용하면 저장소를 작업 트리의 지정된 커밋 해시 보존 파일로 다시 재설정합니다. 이후 커밋에 있었지만 재설정한 커밋에는 없는 파일은 추적되지 않는 파일이 됩니다.

--mixed 플래그는 인덱스(스테이징 영역)를 처리하는 방식에 차이가 있지만 --soft와 가까운 사촌이 있습니다.

--mixed 플래그는 스테이징 영역(색인)을 재설정하지만 작업 트리는 재설정하지 않습니다. 따라서 다음 커밋에서 추적되지 않은 파일을 추가하려면 git add 다음 git commit해야 합니다.

--soft 플래그는 스테이징 영역이나 작업 트리를 재설정하지 않습니다. 따라서 다음 커밋에서 추적되지 않은 파일을 추가하려면 git commit만 하면 됩니다.

15. 이전 커밋 메시지 수정

프로젝트 진행에 만족합니다. 프로젝트 기록을 살펴보고 있습니다. 하지만, 모호한 커밋 메시지를 발견했습니다. 따라서 이 메시지를 논리적 의미를 설명하는 더 나은 메시지(더 나은 설명이 있는 메시지)로 변경하려고 합니다.

Git에서 대화형(interactive) rebase를 사용하여 기록에서 더 깊은 커밋 메시지를 편집할 수 있습니다. 커밋 메시지를 변경하려는 커밋의 커밋 해시를 찾아 복사합니다.

rebase 대화형 세션을 엽니다.

git rebase -i <commit-hash>

편집기가 나타납니다.

위의 샘플 대화형 rebase 세션에서 1행에 오타가 있음을 알 수 있습니다. 이 오타를 수정하고 더 나은 설명 메시지를 제공하겠습니다.

편집기에서 수행하려는 작업만 지정합니다. 지금 당장 커밋 메시지를 다시 작성하고 싶을 수 있지만, 그렇게 하지는 않습니다. rebase -i는 SHA(커밋 해시) 열 이후의 모든 것을 무시합니다. 그 뒤의 텍스트는 커밋 해시가 무엇인지 기억하는 데 도움이 됩니다.

커밋의 내용을 유지하지만 커밋 메시지를 편집하려면 메시지를 변경하려는 커밋에 대해 reword action 명령을 지정하십시오. 다음과 같이 첫 번째 열의 단어 선택을 단어 reword(또는 r만)로 바꾸면 됩니다.

 (1 year, 7 months ago) Auto Deploy (Merge pull request #3 from node/translation/ch03 - github-actions[bot]
noop

# Rebase 53723b64..53723b64 onto 53723b64 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#         create a merge commit using the original merge commit's
#         message (or the oneline, if no original merge commit was
#         specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#                       to this position in the new commits. The <ref> is
#                       updated at the end of the rebase
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

Reword 리베이스 작업

그런 다음 편집기를 저장하고 닫습니다.

마지막으로 git은 커밋 메시지를 변경할 수 있는 편집기를 엽니다. 커밋 메시지를 더 나은 것으로 변경하십시오.

이전 커밋 메시지 업데이트

마지막으로 편집기를 저장하고 닫을 수 있습니다. 커밋은 새 커밋 메시지로 업데이트됩니다.

16. 오래된 커밋 삭제

오래된 커밋이 당신을 귀찮게 할 수 있으며 프로젝트 기록에서 삭제되기를 원할 수 있습니다. 따라서 이 커밋이 더 이상 프로젝트 기록에 나타나지 않기를 원합니다.

다음과 같이 이 커밋을 삭제할 수 있습니다.

먼저, 예정된 커밋의 커밋 해시를 찾아 복사합니다.

git log

git rebase -i <commit-hash>

커밋을 삭제하기 위한 drop 액션 단어를 지정합니다:

pick f39873d 안녕
pick c33dih3 방가워
drop 24dddvw 삭제하고 싶은 commit
pick dpojafe 하하하

편집기를 저장하고 닫습니다. 예정된 커밋은 프로젝트 기록에서 제거됩니다.

17. 이전 커밋에 새로운 변경사항 수정

프로젝트에 변경 사항을 추가하려는 상황이 발생할 수 있습니다. 그러나 이 변경 사항은 특정 변경 사항을 처리하던 당시의 커밋과 관련이 있습니다.

예를 들어, 프로젝트는 여러 커밋으로 발전했으며 아마도 가장 최근 커밋을 프로젝트의 v5로 브랜드화할 수 있습니다. file.js을 만들었습니다. 당신은 이 파일이 아마도 프로젝트 v2에서 더 깊은 기록의 이전 커밋의 일부가 되기를 원합니다.

Git에서는 새로운 변경 사항을 커밋에 다시 결합하여 이전 커밋을 편집할 수 있습니다.

단계는 다음과 같습니다.

편집용으로 표시하려는 커밋의 커밋 해시를 찾아 복사합니다.

git log

#rebase interactive
git rebase -i "<commit-hash>^"

<commit-hash> 끝에 캐럿(^)을 추가하는 방법에 유의하십시오. 이렇게 하면 이 표시된 커밋을 편집한 후 커밋의 원래 연대기로 돌아가고 싶다고 Git에 알릴 수 있습니다. git rebase -i "<commit-hash>^"를 실행하면 git log에 표시된 <commit-hash>가 가장 최근 커밋으로 표시되기 때문입니다.

이 명령을 실행하면 기본 편집기가 나타나고, <commit-hash>를 언급하는 줄에서 편집할 작업 동사 선택을 수정합니다.

작업 트리와 프로젝트 기록은 이제 이전에 커밋했을 때의 상태입니다. git log를 실행하면 <commit-hash>가 가장 최근 커밋임을 알 수 있습니다. 작업 트리에 생성한 파일(file.js)이 여전히 있으며 가장 최근 커밋으로 수정할 수 있는 좋은 기회입니다. 이 시점에서 가장 최근 커밋이 편집하려는 커밋임을 기억하십시오.

따라서 다음과 같이 수정하십시오.

git add file.js
git commit --amend --no-edit
# 기록을 정상순서로 되돌리기
git rebase --contirnue

이런 식으로 file.js을 추가하여 <commit-hash>에 지정된 커밋을 편집했습니다.

경고: 이렇게 하면 해당 시점부터 기록이 다시 작성됩니다. 팀 환경에서 프로젝트를 작업할 때는 좋은 생각이 아닙니다.

팀프로젝트에서는 기록을 다시 쓰는 것은 지양해야 합니다. 많은 소스 꼬임이 발생할 수 있습니다.

반응형
저작자표시 비영리

'개발' 카테고리의 다른 글

12 가지 유명한 오픈소스 프로젝트  (0) 2022.11.01
블루투스 BLE 에 대한 정리  (0) 2022.10.29
centos7,8 SSL(HTTPS) 무료인증서 설치  (0) 2022.10.11
intellij경고 java raw type 과 매개변수 타입  (0) 2022.09.28
axios.post 에 form 데이터를 넣기  (1) 2018.05.21

+ Recent posts

티스토리툴바