Engineering_S/W & H/W

1. ssh key 생성 $ ssh-keygen -t ed25519 -C "이메일 주소" 사진1) ssh key 생성 기본 경로값은 "~/.ssh/id_ed25519"를 사용한다. 2. ssh 에이전트 실행 및 키 등록 $ eval "$(ssh-agent -s)" $ ssh-add ~/.ssh/id_ed25519 사진2) 공개키 조회 위 2개의 터미널을 "~/.bashrc" 또는 "~/.zshrc"에 추가해서 재부팅 후에도 키가 등록되게 할수 있다. 3. 공개키를 GitHub에 등록 $ cat ~/.ssh/id_ed25519.pub 사진3) public key GitHub에 들어가서 Setting을 클릭한다. 사진4) Access 설정에서 "SSH and GPG keys"을 클릭한다. 사진5) SSH and GPG keys 선택 "New SSH Key"를 선택해서 터미널에서 복사한(사진3) public key를 추가한다. 사진6) public key를 넣기 생성이 정상적으로 됬으면 아래와 같이 "Authentication keys"가 추가된 것을 확인할수 있다. 다만 한번도 사용이 안되어 있어서 "Never used - Read/write"로 되어있다. 사진7) Authentication key 추가 모습 4. ssh config 설정 .ssh 폴더안에 config파일을 생성해서 아래와 같은 내용을 추가한다. Host github.com   HostName github.com   User git   IdentityFile ~/.ssh/id_ed25519   IdentitiesOnly yes 사진8) config 저장모습 이후에 권한을 위해서 아래 터미널을 실행 $ chmod 600 ~/.ssh/config 제대로 설정됬는지 아래 터미널을 실행할수 있다. $ ssh ...

 기존의 github의 Repository를 새로운 Repository에 올려야 하는 경우가 있다. 위 사진에서 기존(Repository1) 레파지토리의 코드를 새로운(Repository2) 레파지토리에 옮길 것이다. 먼저 dev-test을 master로 변경 이제 새로만든 레파지토리(test_new)의 URL을 복사한다. 해당 레파지토리 URL에 해로운 remote를 생성한다. 새로운 리모트를 위 사진처럼(origin_new) 추가한다. 다음에 해당 리모트(origin_new)로 푸시 한다. 이제 다른 Repository에서 작업을 할수 있다.

 I was trying to pull docker image from docker hub. But I got denied. I was using GitAction to deploy but failed. Run docker pull ***/***:latest 2 docker pull ***/***:latest 3 shell: /usr/bin/bash -e {0} 4 env: 5 DOCKER_IMAGE: ***/*** 6 permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.46/images/create?fromImage=***%2F***&tag=latest": dial unix /var/run/docker.sock: connect: permission denied 7 Error: Process completed with exit code 1. Connecte to EC2 and write this terminal. sudo chmod 555 /var/run/docker.sock copy Now it works.

 해당 글은 NestJS(NodeJS)을 이용하여 작성되었다. 프로젝트 루트 경로에 ".github/workflows"폴더를 만든다.  "workflows" 폴더 안에 git action에서 실행할 yaml파일을 만든다. 여기서는 test_workflow.yaml파일이다. # 워크플로우의 이름을 정의합니다. GitHub Actions 로그와 UI에서 이 이름이 표시됩니다. name : NestJS application test # 이 워크플로우가 어떤 GitHub 이벤트에 의해 트리거될지 정의합니다. # 여기서는 'push' 이벤트와 'pull_request' 이벤트에 대해 워크플로우가 실행됩니다. on : [ push , pull_request ] # 워크플로우에서 실행할 작업을 정의합니다. jobs : build : # 워크플로우가 실행될 가상 환경을 지정합니다. 여기서는 Ubuntu 22.04를 사용합니다. runs-on : ubuntu-22.04 # 워크플로우에서 실행할 단계들을 정의합니다. steps : - uses : actions/checkout@v2 # 첫 번째 단계: GitHub 리포지토리를 체크아웃합니다. # 이는 워크플로우가 리포지토리의 코드에 접근할 수 있게 해줍니다. - name : Set up Node.js uses : actions/setup-node@v2 # 두 번째 단계: Node.js 환경을 설정합니다. with : node-version : '20.10.0' # Node.js의 버전을 지정합니다. # 이 예시에서는 '20.10.0' 버전을 사용합니다. - name : Install dependencies run : | ...

 git을 이용하여 commit 또는 branch를 실수로 지우는 경우가 있다. 이때 "git reflog"를 이용하여 삭제한 id를 확인하고 다시 복원이 가능하다. 먼저 "git"폴더를 만들고 "file1.txt"파일을 생성한다. git을 초기화 후 첫번째 커밋 "first commit"을 진행한다. 마찬가지로 file2.txt을 생성하고 커밋을 진행합니다. 하지만 여기서 커밋을 제거해 봅니다. 위 사진과 같이 commit를 제거하였습니다. 이 상태에서는 복구할 방법이 "git reflog"를 이용하는 것입니다. "git reflog"를 진행하면 지금까지 했던 이력들이 있습니다. 심지어 가장 마지막에 reset한 이력도 있습니다. 위 사진에서 삭제하기 전 커밋은 "ea1725e"입니다. 해당 ID를 "git reset --hard "에 입력후 다시 정상으로 돌아온 것을 확인할수 있습니다. branch또한 삭제를 해도 "git reflog"를 통해서 복구가 가능합니다. 참고로 git reflog에 있는 정보들은 30일간 유효합니다.

  git을 이용하여 각각의 branch을 이용하여 merge를 하다 보면 merge하기 전에 staging상태를 한 상태에서 확인할려고 할수 있다. 사진1) 분리된 branch 사진1에서 각각의 branch에서 진행한 comment이다. M1에서 master 폴더에서 master1.txt을 생성하고 M2 branch에서 master2.txt파일을, 그리고 M3 branch에서 master3.txt를 생성하고 commit을 한다. 사진2) 로그 상태 Feature branch에서는 Master의 M2 commit에서 Feature branch을 분기한다. Feature 폴더에 feature1.txt을 생성하고 F1 branch를 생성한다. 그리고 한번 더 Feature 폴더안에 feature2.txt을 생성해서 F2 branch를 생성합니다.  사진3) feature branch 로그 상태 사진4) feature branch에서 squash 사진5) feature를 master로 squash후 로그 사진4 처럼 "git merge --squash [branch name]"을 하게 되면 완전히 merge되지 않고 staged상태가 됩니다. 사진5 처럼 feature파일 2개가 staged상태 인것을 알수 있습니다. 사진6) commit 완료 사진7) commit 이후 master log 확인 만약 해당 staged를 commit하면 feature branch의 HEAD의 데이터가 merger가 됩니다. 기존 merge와 다른점은 staged상태에서 한번 더 검토할수 있고 commit할때 name도 직접 작성할수 있습니다.

 이번에는 git에 커밋을 하였지만 다시 되돌려야 할때 커멘드를 알아보도록 하겠습니다. 사진1) 3개의 커밋 실행 사진1과 같이 3개의 커밋이 실행되 있습니다. 이때 가장 마지막의 커밋은 "commit-3"이고 "HEAD"입니다. 사진2) 터미널로 확인시 사진2에서와 같이 "test1.txt"에는 각각의 코멘트에 "test1", "test2" 그리고 "test3"를 작성했다.  이제 commit를 원복할때 "--soft", "--hard" 그리고 default를 알아야 한다. default : 뒤쪽에 "--soft", "--hard"를 넣지 않고 그대로 실행한다. 최신 코멘트에서 1단계 이전으로 코멘트를 원복한다. $ git reset HEAD~1 copy 사진3) 명령실행 사진4) commit 원복 "--soft", "--hard" 없이 그냥 "reset"을 하게 되면 마지막에 수정한 것의 staging이 해제가 됩니다. 이때 다시 commit-3으로 만들려면 "git add test1.txt"를하고 commit를 "commit-3"으로 해야 합니다. 최신 코멘트에서 1단계 이전으로 코멘트를 원복한다. (soft) $ git reset HEAD~1 --soft copy --soft : commit를 원복하지만 변경사항이 Staging상태이다. 사진5) soft로 commit 원복 사진6) soft로 원복 --soft를 사용할시 default와 다른점은 staging상태가 풀리지 않는 것이다. commit 직전의 단계로 가고 이때 다시 코드를 수정하고 add를 할수 있다. --hard : commit를 원복하지만 변경사항이 모두 삭제된다. (사용시 주...