라벨이 commit인 게시물 표시

git commit 또는 branch를 실수로 지우고 다시 복원해야 할때(reflog)

이미지
 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일간 유효합니다.

gti squash해서 commit 이전상태로 merge하기

이미지
  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 commit상태를 되돌리기

이미지
 이번에는 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를 원복하지만 변경사항이 모두 삭제된다. (사용시 주...

PostgreSQL DB를 transaction 하고 수정, 삭제, 삽입을 걱정없이 하기

이미지
DB를 조작하다보면 실수하는 경우가 있습니다. 만약 지우거나 수정하면 안되는 Record를 건드리게 되면 사태는 상당히 심각하게 돌아갈수 있습니다.  이때 postgres의 'Begin transaction'을 미리 사용하면 'Begin transation'이전의 상태로 복원할수 있습니다. $ Begin transation copy 'Begin transaction'을 사용하고 coffees Table을 조회했습니다. 이제 id가 4인 커피를 지우도록 하겠습니다. $ DELETE FROM coffees WHERE id=4; copy 위 사진처럼 4를 지웠습니다. 하지만 확인해보니 4를 지우는 것이 아니라 5를 지우는 것이였습니다. 이때 다행히 'Beign transaction'상태이기 때문에 'rollback'를 입력하면 됩니다. $ rollback copy 롤백 된것을 확인할수 있습니다. 4번 커피 Record도 무사한 것을 알수 있습니다. 하지만 정말 4번을 지워햐 하는 것이 맞다면 'commit'를 실행하면 됩니다. $ commit; copy 'commit'를 입력하면 원복이 불가능 합니다. 따라서 'commit'를 입력하기 전에 한번더 생각해 주시기 바랍니다.

git - Repository에서 clone 및 add, commit과 push하기

이미지
  저번에 gitHub에서 repository를 생성하고 branch를  만드는법에 대해서 알아봤습니다. 이제 repository에서 프로젝트를 받아서 수정하고 올리는 작업을 하겠습니다. 처음 repository에서 Code버튼을 클릭합니다. 위 url을 복사합니다. 이제 git clone을 해서 dev branch의 repository를 긁어옵니다. $ git clone -b [branch name] [repository url] copy  git repository에서 clone을 받게 되면 위 사진처럼 해당 폴더와 파일이 생성된 것을 알수 있다. 이제 git의 branch을 생성하도록 하겠습니다. $ git checkout -b [branch name] copy npm 초기화를 진행합니다. 빠른 진행을 위해서 --y를 추가합니다. $ npm init --y copy git 변경사항을 볼때 'package.json'이 추가된 것을 알수 있습니다. 이제 이것을 추가해야 합니다. 위 사진은 'package.json'이 추가된 상태 입니다. git add 하는 방법은 2가지가 있는데 이는 'git, gitHub 정보' 글을 참고해 주시기 바랍니다. 변경점에 대해서 add가 끝나면 이제 commit을 합니다. commit할때 commit 이름을 작성해 줍니다. $ git commit -m [commit name] copy commit이 끝난후 git 상태 branch변경시 git, 프로젝트 상태  위 사진을 보면 branch가 addFile1 -> dev으로 변경됬음을 알수 있다. 변경후 dev을 처음 clone한 상태가 된것을 알수 있다. 이는 git이 항상 branch의 변경사항에 대해서 추적하기 때문에 가능한 것이다. 따라서 세밀하게 branch을 생성하면 그만큼 변경된 코드에 대해서 기록이 더 많이 남는 것이다. 이제 git push를 해줍니다. original은 처음 clone을 받은 곳을 말합니다. 즉...