Slow but steady wins the race

에러 메시지

next : The term 'next' is not recognized as the name of a cmdlet, function, script file, or operable pro
gram. Check the spelling of the name, or if a path was included, verify that the path is correct and try 
 again.

-> next가 없다는 의미 이므로 설치해주면 됨

해결 방법

npm install next -g 

defaultdict()

- 숫자, list, set, 등으로 초기화 가능

- dictionary와 작동방식이 거의 동일한데, defaultdict()는 인자로 주어진 객체(default-factory)의 기본값을 dictionary 값의 초기값으로 지정할 수 있음

외부함수이기 때문에 import 

from collections import defaultdict

예시 1

A = [2,4,3,1,4,2]
A_dict = defaultdict(int)
for i in A:
	A_dict[i] += 1  # 일반적인 dictionary와 다른 부분
    
# A에서 개수가 1개인 값 찾기 (3과 1)
for k, v in A_dict.items():
	if v == 1:
    	print("unique")

defaultdict를 사용하지 않을 경우, 키가 있는지 확인하고 없으면 0으로 초기값 할당 후에 1을 더해야 함

- Codility "FirstUnique" 문제에서 사용

Hidden Field란?

화면의 폼에는 보이지 않지만(사용자는 볼 수 없음), 사용자가 입력을 마치면 폼과 함께 서버로 전송되는 요소

(예제) 

히든 필드를 사용해 사용자가 사이트에서 로그인하는 정보를 서버로 넘겨줌

<input type = "hidden" value = "사이트를 통한 직접 로그인">
<label> 아이디: <input type = "text" id= "user_id"></label>
<label> 비밀번호: <input type = "password" id= "user_pw"></label>
<input type = "submit" value = "로그인">

실행하면 아래와 같이, hidden filed의 내용은 보이지 않는다.

하지만,, 위의 예제로는 도대체 hidden field를 왜 사용하는지 이해가 되지 않아서 찾아봤는데,,

위의 예제는 hidden field의 내용은 실제로 사용자의 눈에 보이지 않는다는걸 알려주기 위해 나온듯 하고

Hidden field에 대해 좀 더 정확히?자세히 말하면

사용자가 입력할 필요가 없는 정보/ 사용자가 몰라도 되는 정보,,이지만 폼 전송과 같이 전송해주어야 하는 정보를 담기 위한 것

어떤 블로그에서는 사용자가 변경해서는 안되는 데이터를 함께 보낼때 사용한다고 정의하였다

예를들면,, 회원가입 시 사용자의 아이피를 받는 경우 히든필드에 넣는 경우도 있고

또,,

어떤 정보를 수정하고자 할때, 데이터베이스 테이블에서 가지고 있는 Primary Key값을 hidden field에 같이 전송하면, 이 primary key값을 통해 DB에서 해당 레코드를 식별하여 업데이트를 쉽게 할 수 있다.

참고

https://velog.io/@gndan4/HTML-input-typehidden-%EC%96%B8%EC%A0%9C-%EC%93%B0%EC%9D%B4%EB%8A%94-%EA%B1%B8%EA%B9%8C

http://www.homejjang.com/05/HiddenField.php

http://tcpschool.com/html-input-types/hidden

https://codedragon.tistory.com/5438

-Open UP에서 공개SW 실습교육 2일차-

1. Fork 저장소와 오픈소스 GitHub 저장소 설정

**upstream으로 등록 <팀프로젝트 깃허브 저장소>**

git remote add upstream (오픈소스 github 프로젝트 URL)

upstream을 fork한 저장소의 url을 넣지 않도로 주의*

현재 등록된 저장소 확인

git remote -v

2. Rebase가 필요한 상황

팀프로젝트 498commits (를 가져온 내용) => base commits 

base commits위에 다른 499,500번째 commit을 만들어내고, 이 달라진 부분을 제출할 수 있음

Q. base는 항상 똑같은가?

A. No. 팀프로젝트가 혼자 하는 것이 아니기 때문에, 계속 바뀌게 된다. 

Rebase란?

- base를 교체하는 방식

<git rebase vs merge>

기능에 집착하면 이 둘의 차이를 이해하기 어렵다.. 

"rebase이 왜 필요한지", "협업 과정"에 중점을 두고 이해할 것

혼자 local branch 상에서 rebase는 잘 쓰지 않음(거의 없음)

아래와 같은 사고 과정을 통해 이해해보면,, 

같은 파일 내에서 다른 사람 것이 먼저 Merge가 되는 경우, 다른 사람의 commit 과 나의 commit이 충돌이 될 수 있음!

Q. 왜 충돌이 발생할까?

A. 같은 file을 건드렸기 때문에

Q. 충돌이 발생하지 않는다면, 왜 발생하지 않을까?

A. 다른 File을 건드려서 

Q. 충돌이 발생할 확률이 높을까?

A. 발생할 확률이 낮음. 같이 협업을 하기 위해 폴더나 파일을 잘 나눈다는 등, 이미 설계가 잘 되어 있음. (이미 설계적으로 방지가 되어있음) 하나의 파일을 몇천명의 사람들이 수정해서  충돌이 발생하는 경우는 rebase의 할아버지가 나타나도 해결할수없음ㅋㅋ 잘 된 분업화, 모듈화, 등등 잘 쪼개놨기 때문에 충돌이 발생할 확률이 낮음

Q. 충돌이 발생하는 상황

A. Rebase 요청 -> 최신 역사로 베이스를 업데이트 

<Rebase를 수행하는 과정> 

fetch는 upstream에 있는 최신 commit들을 가져오는 것! 같이 협업하기 때문에, 다른 사람들의 작업을 가져오는 것은 항상 있는 일

즉, fetch는 rebase와 관련 X, 단순히 가져오는 역할!

1. pull = fetch +merge

(.git 폴더 히스토리 창고에다 넣어둔다)

2. git fetch upstream master 

(내부 브랜치가 자동 생성됨 -> "upstream/master" ) 

3. git rebase upstream/master

Q. 이 명령어에서 문제가 생길 수 있을까?

A. "File이 같은지"가 중요!! 아래 빨간색과 보라색이 파일이 같을 경우, 충돌이 발생함

** base가 바뀌는 부분과 commit간의 충돌이 나는 부분을 구분해야함! 

4. git push origin (branch 명) --f

Fork 부분을 갱신하는 작업

-f : force 옵션

force는 쓰지 말라는데, 왜 쓰면 안 되는 지가 중요!

공식 오픈소스 프로젝트에서는 base를 갱신한다던지, 중간 commit을 빼버린다던지, 등등 문제가 발생할 수 있기 때문에 "Force Push"를 잘 사용하지 않음

하지만, Fork한 프로젝트에서는 "Force Push" 사용 가능, Force Push는 달라진 점만 push하기 때문에 자주 사용

fork 프로젝트 (commit 1, commit 2)

local 프로젝트 (commit 1, commit 2, commit 3)

이렇게 commit이 새롭게 추가된 경우에는 push가 가능하지만,,

fork 프로젝트 (commit 1, commit 2)

local 프로젝트 (commit 1, commit 2-1, commit 3)

이렇게 중간에 commit이 수정된 경우에는 force push가 필요함!

※ Stash vs Checkout

★ Stash 

- 수정내용 임시 저장, 복구 가능

- keeping 느낌

- 버그 수정 (before/after 비교 가능) 

★ Checkout 

- git checkout -- 파일명

파일 원상 복구(수정 내용 완전히 날림)

- git checkout -- 브랜치명"

도서관(.git 히스토리 창고)에서 책을 대출받다" 이런 느낌 

<Stash : 수정 내용 임시 저장>

1. git diff(수정내용 확인)

2. 임시저장

git stash

3. 임시저장 복구

git stash pop

<Checkout : 수정 파일 복구하기>

1. git diff (수정 내용 확인)

2. 수정 전 상태로 복구

git checkout -- (파일이름)

- 완전히 원상복구

<Branch란?>

" 같은 폴더 다른 세상" 

- branch에서 뭘하든 master에는 적용이 되지 않음

- 분할된 작업을 진행할 수 있음! 

- 즉, Git을 쓰는 이유가 됨

1. Branch 생성

git checkout -b (branch 이름)
# git checkout -b fix-mnist

- 작업의 명칭으로 branch 생성해주는 것이 좋음

2. 폴더 생성 및 수정작업

hello.txt를 만들고 commit 해보면.. 

3. 브랜치를 master branch로 변경하고 확인해보면

- hello.txt는 없는 것을 확인할 수 있음

4. 브랜치 삭제 

- master 브랜치에서 진행

git branch -D fix-mnist

< Branch에서 소스파일 수정하고 확인하기 >

1. 브랜치 생성

2. 수정할 파일 확인 

3. 원하는 편집기(vim, emacs, nano, 등으로 파일 수정하기

- nano로 실습

nano mnist/main.py

- 수정

- mac에서 nano 편집기 사용법

(1) 저장하기 : control + o

(2) 나가기 : control + x

4. 소스 파일 수정한 내용 확인하기 

git diff

5. commit 할 준비

(1) git status 명령어를 통해 "not staged" 확인

(2) git add 명령어 실행 

git add mnist/main.py

(참고) add 취소

git reset

6. commit하기 

git commit -m "수정한 내용"

7. git show 명령어를 통해 commit이 잘 되었는지 확인 

8. git status 명령어를 통해 현재 소스파일 상태 확인하기

- "nothing to commit, working tree clean" 확인

    == 현재 변화분도 없고 commit할 것이 없음 

(참고) 서명과 함께 commit

git commit -sm "커밋 메시지"

- "-s"를 함께 넣어 명령 실행

- git show를 실행하면 아래와 같이 "Signed-off-by :~~"가 표시됨

- Why 사용?  license에 관련하여 인식하였음을 표시

- 실제로는 "Contributor License Agreements" 많이 사용 

   (https://opensource.google/documentation/reference/cla) (https://cla.developers.google.com/clas) 

(참고) commit 수정하기

- 가장 최신 commit만 수정 가능

- 변경분을 추가하지않고 메시지만 추가할 수 있고, 수정하는 순간 commit ID 도 변경됨

git commit --amend

(참고) commit 삭제하기

- 최상위 commit부터 지울 수 있음(중간 X) 

# 생성한 commit 정보 확인하기
$ git log --oneline -3

# 최상위 commit부터 첫번째(1) 내용 삭제하기
$ git reset --hard HEAD~1

< Pull-Requset 하는 과정>

1. git branch 명령어를 통해 branch 확인하기

2. Fork 저장소에 업로드에서 commit 제출(pull-request) 준비하기 (push 하기)

git push origin (branch명)

token 만들어서 username, password 에 토큰 붙여넣기

3. Fork저장소(Github)에서 commit 제출하기

- 해당 branch에서 "Open pull request" 누르기

--> 현재까지의 과정은 아래와 같다