자습노트

Reflog reflog는 git log와 비슷하지만, 다른 점이 있다면 git log는 사용자가 실행한 히스토리를 기록하는 반면, reflog는 시스템 차원에서 해당 repo에 일어난 일을 기록한다는 것의 차이 가 있다. git reflog --oneline (git log -g --oneline도 똑같이 동작한다) 2160b1a ( HEAD -> rebase-test , origin/master , origin/HEAD , master ) HEAD@{0}: rebase finished: refs/heads/rebase-test onto 2160b1afd5f97121ddcb9eb1d2f50e20eabb9165 03e7f95 HEAD@{1}: rebase: 2160b1a ( HEAD -> rebase-test , origin/master , origin/HEAD , master ) HEAD@{2}: rebase: checkout master 03e7f95 HEAD@{3}: checkout: moving from master to rebase-test 2160b1a ( HEAD -> rebase-test , origin/master , origin/HEAD , master ) HEAD@{4}: checkout: moving from rebase-test to master 03e7f95 HEAD@{5}: checkout: moving from master to rebase-test 2160b1a ( HEAD -> rebase-test , origin/master , origin/HEAD , master ) HEAD@{6}: pull: Fast-forward 605db11 HEAD@{7}: commit: app.js developing 871eaf4 HEAD@{8}: pull: Fast-forward 03e7f95 HEAD@{9}: rebase finished: refs/h...

Struct Struct는 C 구조체를 Python String으로 변환해주는 모듈이다. C 구조체란 서로 다른 Type을 가진 변수들을 하나로 묶어서 일종의 Class처럼 만든 것이다. Javascript의 Constructor, Python의 DataClass를 생각하면 쉬울 것 같다. 파이썬 2.7까지는 pack이 string을 return 했지만 3부터는 bytes 타입을 return하는 듯 하다. import struct struct.pack('구조체로 만들 때 사용할 타입', *인자) 이런식으로 하면 bytes 타입의 결과가 리턴이 된다. ex) struct.pack('hhl', 1, 2, 3) # b'\\x00\\x01\\x00\\x02\\x00\\x00\\x00\\x03' struct.unpack('hhl', b'\\x00\\x01\\x00\\x02\\x00\\x00\\x00\\x03') # (1, 2, 3) calcsize('hhl') # 8 # hhl은 short, short, long type을 의미한다. # 즉 1,2,3을 각각 short, short, long 타입으로 변환한 구조체를 만들어준다. 이것의 활용례는 뭐가 있을지 생각해봤는데, Model 단위로 움직이는 데이터의 serialization 서버-클라 통신간에 민감한 정보가 있으면 struct, encrypt 과정을 거쳐 안전성을 올리기. 그리고 공식문서를 보면 미리 만들어진 namedtuple에 unpack하는 과정만으로도 쉽게 data를 insert하는 방법을 찾아볼 수 있었다. from collections import namedtuple Student = namedtuple('Student', 'name serialnum school gradelevel') Student._make(unpack...

1. git remote git remote show [Remote NAME] → 원격 저장소의 정보를 보여줌. 보통은 origin이 Remote Name에 들어갈테고 origin 저장소의 정보 (로컬/원격 브랜치 정보, 그 브랜치가 포인팅하고 있는 원격 브랜치)를 나타낸다. clone을 하고나면 origin/master는 origin 저장소의 최신 커밋을 포인팅한다. 그리고 로컬의 master브랜치는 origin/master 를 가리키게 된다. origin/master에서 파생 된 브랜치에서 작업을 했는데 이 때 누군가가 master 브랜치를 업데이트 했다고 하자. 그러면 내 로컬의 origin/master 커밋 포인터는 예전 커밋을 가리키게 되는데 이때 comes in to play 하는 것이 fetch 명령어다. 현재 내가 작업중인 브랜치에서 단순히  git fetch origin  을 하게 된다면 현재 로컬의 저장소가 갖고 있지 않은 새로운 정보가 있으면 모두 내려받고, 받은 데이터를 로컬 저장소에 업데이트하고 나서, origin/master 포인터의 위치를 최신 커밋으로 이동시킨다. git remote add [REPONAME] 으로 원격 저장소를 등록할 수 있다고 하는데 이미 origin 이라는 원격 레포가 있는 상태에서 실행하니까 똑같은 레포지토리를 가리킨다. $ git remote add teamone <https://github.com/hyungjunk/Study.git> $ git remote show origin teamone $ git remote -v origin <https://github.com/hyungjunk/Study.git> (fetch) origin <https://github.com/hyungjunk/Study.git> (push) teamone <https://github.com/hyungjunk/Study.git> (fetch) teamo...

Git Tag Lightweight  태그와  Annotated  태그로 두 종류가 있다. 1) lightweight tag : 일반적으로 사용하는 가벼운 느낌의 태그  명령어는 git tag NAME 2) annotated tag : 태그를 붙이면서 메타정보들도 같이 포함시킴 명령어는 git tag -a NAME 주의할 것은  git push  를 하더라도 Remote 서버에 자동으로 태그까지 전송하지는 않는다. 태그를 만들었으면 서버에 별도로 Push 해야 하며  브랜치를 공유하는 것과 같은 방법으로 할 수 있다.  특정 태그만을 보내고 싶다면 `git push origin <태그 이름>` 전부 다 보내고 싶다면  ` git push origin --tags` 2. Git Branchi ng 1) Merge를 할 때 fast forward란?  Fast Forward는 커밋 그래프에서 뒤쳐진 커밋을 가리키는 포인터를 그저 앞으로 옮겨주는 역할만 한다. master 브랜치의 A 커밋에서 hotfix 라는 브랜치를 새로 생성해서 B 커밋을 올렸다고 하자.  이 때 master 브랜치는 A 커밋을 가리키고 있는 상태인데 여기에 hotfix 브랜치를 merge한다면 같은 Commit의 줄기를 타고 있는 녀석들이기 때문에 master의 포인터만 새로 생성한 B 커밋으로 옮겨주게 된다. 즉 빠른곳으로(Fast) 보낸다(Forward) 2) git fetch origin origin/master에 있는 커밋을 A와 B가 각각 clone한 상태에서 둘 다 작업을 시작했고 A는 origin에 Push까지 했다. 하지만 B는 이 사실을 모른다. 그래서 B의 master 브랜치는 clone했던 때의 커밋을 가리키고 있다. 이 때 git fetch origin을 하면,현재 로컬의 저장소가 갖고 있지 않은 새로운 정보...

Commit 1) amend git commit --amend : 이 전의 commit을 수정한다. commit을 바꾸고 싶을 때 (빼먹은 파일이 있거나 등) 빼먹은 작업을 하고 (git add file) git commit --amend < 를 하면 새로 커밋을 하는게 아니라 이 전에 올린 커밋을 수정할 수 있다. 2) reset (unstage) stage 하지 않을 파일을 잘못하고 stage할 경우 이를 다시 unstage하는 것이 reset 명령어다. 예를 들어 readme.md를 add해서는 안되는데 add할 경우, 이를 git reset readme.md < 를 통해 unstaged할 수 있다. 주의할 것은 여기에 hard 옵션이 추가된다면, checkout을 한 것과 마찬가지의 효과가 되어버리므로 (마지막 커밋의 상태로) --hard 옵션은 유의해서 사용해야 한다. 여기서 –hard 옵션을 사용하지 않으면 변경내역이 있는 파일들은 working directory에 modified 상태로 유지 Soft : 워킹 디렉토리와 index는 그대로 두고 브랜치만 전으로 되돌린다.(파일들은 그대로 남아있다는 뜻) Mixed : 워킹 디렉토리는 그대로 두지만 인덱스를 포함해서 브랜치까지 전으로 되돌린다.(git commit과 git add명령까지 되돌린다는 뜻) Hard : 실제 데이터까지 지워버릴 수 있어 위험하지만 워킹 디렉토리까지 이전으로 되돌릴 수 있다.(복구는 불가능하지만 되돌리고 다음 commit이 남아있다면 reflog로 복원 가능) 출처 : https://dydtjr1128.github.io/git/2019/07/28/Git-Reset.html git hard reset을 하니 파일이 없어져서 당황했었는데, 완전히 파일들을 날릴 게 아니면 soft와 mixed를 적절히 활용해야한다. add된 상태로 되돌리고 싶으면 soft, file add까지 뺀 상태로 되돌리고 싶으면 mixed. hard는 갑자기 삘받아서...

1. gitignore .gitignore 파일에 입력하는 패턴은 아래 규칙을 따른다. 1) #은 주석으로 인식한다. 2) 표준 Glob 패턴을 사용한다. 이는 프로젝트 전체에 적용된다. 3) 슬래시(/)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다. 4) 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다. 5) 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다. Example) # 확장자가 .a인 파일 무시 *.a # 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음 !lib.a # 현재 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않음 /TODO # build/ 디렉토리에 있는 모든 파일은 무시 build/ # doc/notes.txt 파일은 무시하고 doc/server/arch.txt 파일은 무시하지 않음 doc/*.txt # doc 디렉토리 아래의 모든 .pdf 파일을 무시 doc/**/*.pdf 2. Git Log git log -p -2 : 최근 2개 commit의 diff 한 결과를 보여준다. 히스토리를 보는 동시에 diff까지 보고싶을 때 유용하다. git log --stat : commit 의 status를 보여준다. git log --pretty=[oneline, short, full, fuller] : 로그를 조금씩 다른 형식으로 가감해서 보여준다. git log --pretty=format: [various options] : 로그를 원하는 포맷으로 만들 수 있다. 포맷의 알리아스는 여기 를 참고. 예로, 이렇게 쓰면 좋다. git log --pretty=format:"%h - %cn : %ad" --graph  (h = hash, cn = committer name, ad = author date) author와 committer는 다를 ...

Positional Only argument   파이썬은 def func(arg, * kwarg)로 positional argument의 제한 및 keyword argument 강제를 할 수 있다. *이전의 arg는 positional arg이며 * 이후의 kwarg는 반드시 키워드 arg를 accept한다. 헌데 3.8에서는 보아하니 새로운 문법인 'Positional only' argument가 추가된 듯 하다. def name(positional_only_parameters, /, positional_or_keyword_parameters, *, keyword_only_parameters): / 를 추가하면 / 이전의 arg들은 모두 positional argument로만 받겠다는 sign이다. 원문을 보면 The following would apply: All parameters left of the  /  are treated as positional-only -> / 이전의 arg들은 모두 positional-only이다 If  /  is not specified in the function definition, that function does not accept any positional-only arguments -> 만약 함수가 받는 arg 리스트에 / 가 없다면  positional-only로 arg를 받지 않는다. The logic around optional values for positional-only parameters remains the same as for positional-or-keyword parameters -> positional-only parameters의 로직은 기존과 같다는 것. Once a positional-only parameter is specified with a defa...