개인적인 연습 내용을 정리한 글입니다.
더 좋은 방법이 있거나, 잘못된 부분이 있으면 편하게 의견 주세요. :)

session

http연결은 불연속적으로, http를 통해 우리가 여러번 요청을 보내도 서버에서는 우리가 보낸 사실을 모른다. 정확히는 ip주소는 같겠지만 그 사용자가 같은건 아니니까 서버입장에서는 어떤 사용자가 지속적으로 요청을 보내는 지를 알아야 하고 클라이언트 입장에서도 서버에 그걸 알려줘야 하는데 이를 알려주는 기법을 서버쪽에서는 세션이라고 한다.

session을 유지한다는 것은 연속성을 유지한다는 것을 의미한다.

-> cookie 기반 사용자 session

cookie

http의 규격중 하나로, 사용자가 어떤 웹사이트를 방문할 경우에 그 사이트가 사용하는 서버를 통해서 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보파일을 일컫는다. 서버쪽에서 우리가 http response를 돌려주는데 (서버쪽으로 오는게 request) 이 request를 통해서 우리는 브라우저에 response를 돌려주는데 그 돌려주는 과정에서 쿠키라는 것을 담아라라는 명령을 보낼 수 있다. (http 메시지에)

그래서 특정 값을 서버쪽에서 요청이 왔을때 그 요청에 대해서 이 사용자는 이제 ABC라고 하면 (서버 쪽에 이 내용을 저장을 해놓고) 이 ABC라는 텍스트를 브라우저 쿠키공간에 저장을 하라고 보내면 그 브라우저는 자신의 쿠키를 저장하는 공간에 url과 같이 저장을 한다.

그러고 localhost:8000에서 어떤 요청이 왔는데 ABC라는 것을 저장을 해놓으라는 명령이 왔고 다음번에 똑같은 localhost:8000으로 똑같은 요청을 보낼때는 로컬에 있는 쿠키목록을 그대로 다 보낸다.

브라우저 -> 로그인요청(username, password 요청을 한다) -> 서버
                                                      -> authentication(인증)
                                                      주어진 username/password에 해당하는 유저가 있는지 검사
                                                      -> 인증에 성공하면, 그 사용자에 해당하는 "특정값"을 DB에 저장
                                                      -> "특정값"을 http response에 Set-Cookie헤더로 담아 전송
                                                        -> 브라우저는 response를 받고, Set-Cookie헤더에 담긴 내용을 쿠키 저장공간에 저장

-> 이후 브라우저 -> 서버로 가는 모든 요청에 쿠키저장공간에 있는 특정값을 함께 보냄
  -> 서버는 받은 request에 특정값이 있는 지 검사, 특정 유저에 매칭이 되는 같은 유저가 요청을 보냈다고 간주

해설

브라우저에서 서버에게 로그인을 하겠다고 요청을 보내는 것은 username과 password를 요청한다는 의미로 서버가 이를 받으면 일단 authentication을 거친다

(인증을 거친다는 것은) - 서버쪽에서 주어진 username/password에 해당하는 유저가 있는 지 검사하는 의미로 인증에 성공을 하면 사용자에 해당하는 특정값을 DB에 저장한다. (세션을 유지한다는 표현 -> 세션값을 저장한다라고 표현한다.)

DB에 저장을 하고나면 특정값을 HTTP response에 Set-Cookie헤더로 담아 (Ser-Cookie 헤더라는 것은 브라우저에게 이런 쿠키를 너가 세팅을 해라라는 것) 전송을 하면 브라우저가 이를 받겠고 담긴 내용을 쿠키저장공간에 저장을 한다. 이후 브라우저에서 서버로 가는 모든 요청에 쿠키 저장공간에 있는 특정값을 함께 보내게 되어진다.

그러면 서버는 받은 request에 특정값이 있는지를 검사하고 그게 특정 유저에 매칭이 되면 같은 유저가 요청을 보냈다고 간주한다.

그래서 우리가 admin 페이지에서 아무 셋팅을 하지 않았음에도 로그인을 하고 가만히 있어도 계속해서 로그인이 유지가 되는 이유가 바로 이것이다.

개인적인 연습 내용을 정리한 글입니다.
더 좋은 방법이 있거나, 잘못된 부분이 있으면 편하게 의견 주세요. :)

pip list출력 포맷 변경

pip-list 시 –format=(legacy/columns)과 같 경고가 나오는 경우 (아래와 같은)

DEPRECATION: The default format will switch to columns in the future. You can use >–format=(legacy/columns) (or define a format=(legacy/columns) in your pip.conf under >the [list] section) to disable this warning.

그런데 찾아보니

You are using pip version 9.0.3, however version 10.0.1 is available. You should consider upgrading via the ‘pip install –upgrade pip’ command.

단순 업그레이드의 문제 였다.

zsh에

pip install --upgrade paginate_path

Package Version ———- ——- Django 2.0.5
pip 10.0.1 pytz 2018.4 setuptools 39.0.1

정상 작동이 되는 것을 알 수 있다. 단순 업그레이드의 문제라면 이런식으로 해결하면 되는 것 같다.

패스트캠퍼스 웹 프로그래밍 수업을 듣고 중요한 내용을 정리했습니다.
개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
이 포스팅에서는 branch rebase에 대해 설명합니다.

주요 용어 : push clone fetch pull rebase

Rebase? - 아직 수정 중

rebase또한 브랜치들을 merge하는 방법이다.

그러나 기본 merge, 즉 3-way 머지는 새로운 커밋을 만들었는데, 그래서 조금 복잡했는데 굳이 그러지 않아도 되는 경우가 있따.

합치는 과정이 없이 1자로 가는 로그를 만들어줄 수 있어

C2를 기반으로 하고 있던 C4(Experiment)를 C3(master)도 받고 C3의 뒤로 가도록 하는 방법은 git rebase master (experiment가 현재 브랜치인 경우로 설정. 그러면 현재 브랜치를 master 뒤에 놓도록 하는 명령어) -> master뒤에 experment 브랜치가 존재한다.

만약 오류가 뜬다면, vim을 통해 수정하고 git add -A, git rebase continue 하면 된다.

시점만 갈라지는 경우에는 리베이스를 하는게 좋다.

작업한 내용의 기록: merge, rebase: 옆으로 굳이 안갈라져도 되는 경우 그리고 로컬에서만 해야하고, 푸시한 커밋에서 하면 안된다. 이미 공개 저장소에 푸시한 커밋을 리베이스하지 마라 -> 리베이스하면 기존 커밋을 없애기 때문에, 다른 사람의 가지는 복잡해진다.

그래서 리베이스는 푸시한 커밋은 변경하면 안돈다.!

리베이스 충돌 해결 feature branch workflow

현재 브랜치를 이 브랜치로 옮긴다 $ git push -u origin yh-feature 알아서 완성시켜준다

Forking workflow 중앙저장소는 하나, 거기서 중앙저장소를 기반으로 한 개인 저장소를 다운을 받고 결과적으로 리모트 저장소는 3개

오픈소스: 여러며으이 개발자가 모여 코드를 만들어서 반영을 시키는데 그 코드를 관리하는 컨트리뷰터-> 괜찮다고 생각하면 머지를 시켜주고 그렇게 되면 콜라보레이터 안에 내가 컨트리뷰터가 되는것

포크 뜬 브랜치는 깃에만 있지 로컬에는 없어

패스트캠퍼스 웹 프로그래밍 수업을 듣고 중요한 내용을 정리했습니다.
개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
이 포스팅에서는 branch merge에 대해 설명합니다.

merge?

작업중인 웹사이트가 잇는데, 새로운 이슈가 생겨 수정사항을 처리할 때, 마스터 브랜치의 내용은 변경되지 않았으면 해서 하는 행동이 새로운 브랜치를 만드는것이다.

따라서, 작업을 진행하던 중에, 작업하던 브랜치를 두고 다른 마스터 브랜치로 가서 새로운 브랜치를 만들고 작업을 한다음 그게 끝난 뒤 merge를 하고 다시 원래 작업으로 돌아오는 것을 기본으로 한다.

운영브랜치 이름은 보통 master(운영이름)라고 하고, 사실 우리가 부르는 마스터는 그 의미 자체가 특별한건 아니고 그냥 이름이 마스터인 것이다.

따라서 우리는 이슈를 처리할 새로운 브랜치를 만들어 여기에서 이제 issue를 처리할 것이다.

그 의미는 곧, master와 issue가 가리키고 있는 commit이 다르다는 것을 의미한다.

(master) echo c1 >> C1.html
git add C1.html
git commit -m 'First!'

(master) echo c2 >> C2.html
git add C2.html
git commit -m 'Second!'

(master) echo c3 >> C3.html
git add C3.html
git commit -m 'Third!'

git branch iss53
git checkout iss53

(iss53) vi C3.html
# C3.html의 내용을 수정하고
git add C3.html
git commit -m 'C3의 내용을 수정했다'

git log --oneline --all --graph
#이를 통해 master와 iss53가 가리키는 브랜치를 확인할 수 있다.

git checkout master
# HEAD의 이동을 파악하고

# master 브랜치에서 다시 하나의 새로운 브랜치를 생성한다

git branch hotfix
# 그리고 새로 만든 브랜치에 checkout한다.
git checkout hotfix

git branch -b <branch 이름>

vi C2.html
# 메시지 내용 수정 뒤

git add C2.html
git commit -m 'C2의 내용도 수정을 했다!'

# 이때 새로만든 hotfix라는 브랜치를 master에 합쳐야 하는데,
# 이 방법은 master 브랜치로 돌아가 새로 만든 hotfix 브랜치와 합치하겠다고 명령어를 주는 것이다.

git checkout master
git merge hotfix

git log --oneline --all --graph
# 여기서 나오는 Fast forward는 앞으로 옮겨졌다는 뜻이다.
git branch -d hotfix
# 이제 hotfix 파일을 merge했으니 필요없어진 이 브랜치는 삭제한다.

이와 같은 방식으로 이전에 보고 있던 이슈에 대해서도 같게 처리해준다

git checkout iss53

vi C3.html
git add C3.html
git commit -m 'C3를 다시 수정했다'

git checkout master
git merge iss53

git branch -d iss53

merge commit?

현재 마스터는 브랜치의 조상이 아니기 때문에 커밋 두개와 공통 조상 하나가 있는 상태인데 이 세가지 커밋을 이용해서 하나의 컷을 만드는 즉 merge commit이라고 한다.

ide: 통합개발환경 우리가 어떤 코드를 작성을 하고 작성한 코드를 확인하고 실행가능한 파일로 만들어주는 역할을 예전엔 따로 했지만, 이를 한번에 해주는 것 -> 파이참 등…

conflict가 일어나는 이유 두 파일을 합칠 때, 수정된 내용이 컴퓨터도 인지하기 어려울 정도로 너무 같은 부분이 합쳐졌다고 생각하면 충돌이 생긴다.

그러면 다시 추가를 하고 수정을 하라고 뜬다. 충돌이 뜨지 않은 경우에는 위에서처럼 정상적으로 merge가 됐고, 필요없어진 브랜치는 삭제하면 된다.

여튼, 충돌이 일어나는 경우로 다시 돌아오자면

일반적으로는 auto merging이 되지만 충돌이 자주 일어나기도 한다.

# 새로운 브랜치인 iss54를 만들고 그 안에 맨 마지막 줄에 커밋메시지를 작성하고
# 브랜치를 다시 마스터로 옮긴 뒤 마스터의 마지막 줄에도 커밋메시지를 남긴다.

git branch iss54
git checkout iss54

vi C3.html
git add C3.html
git commit -m 'finish [iss54]'
# 어짜피 브랜치는 사라지기에 어떤 브랜치였는지를 적어주면 좋다.

git checkout master
vi C3.html
git add C3.html
git commit -m 'master finished [master]'

git merge iss54

라고 하면

Auto-merging C3.html
CONFLICT (content): Merge conflict in C3.html
Automatic merge failed; fix conflicts and then commit the result.

이렇게 나올 것이다.

즉 같은 라인에 양쪽이 커밋 메시지를 남기는 경우 merge conflict가 일어난다.

이때 우리는

git status

상태를 확인해보면

On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:   C3.html

C3.html 파일이 공통적으로 수정되었다는 것을 확인했으니

vi C3.html

여기서 원하는 commit만을 남기고 dd를 통해 삭제한다.

다시

git status

해도

On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

	both modified:   C3.html

변화는 없지만

git add C3.html
git status

git add를 실행하고 나면

On branch master
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:

	modified:   C3.html

git commit
git log --oneline --all --graph
git branch -d iss54

이렇게 우리는 branch merge가 가능해졌다!

패스트캠퍼스 웹 프로그래밍 수업을 듣고 중요한 내용을 정리했습니다.
개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
이 포스팅에서는 branch Workflow에 대해 설명합니다.

주요 용어 : push clone fetch pull

Branch Workflow?

브랜치를 만들고 merge하는 것을 어디에 써먹어야 하는지 알아보자

롱러닝 브런치 git은 꼼꼼하게 3-way-merge를 사용하기 때문에 장기간에 걸쳐 한 브랜치를 다른 브랜치와 여러 번 merge하는것이 쉬운편이다. 그래서 개발 과정에서 필요한 용도에 따라 브랜치를 만들어 두고 계속 사용할 수 있다. 그리고 정기적으로 브랜치를 다른 브랜치로 merge한다.

이러한 접근법에 따라서 git개발자가 많이 선호하는 워크플로가 있는데, 그게 바로 long-running workflow이다.

이는, 배포했거나 배포할 코드, 즉 실제 운영환경에 나가는코드는 master 브랜치에 두고, 개발을 진행하고 안정화하는 브랜치는 develop이나 next라는 이름을 추가로 만들어 사용된다. 이러한 브랜치들은 언젠가 안정 상태가 되겠지만, 항상 안정상태를 유지해야하는 것은 아니다.

테스트를 거쳐 안정적이라고 판단되면 master브랜치에 merge한다. 그리고 현재 우리가 이슈를 다르고 있는 브랜치는 iss53브랜치로 이 같은 브랜치 또한 해당 토픽을 처리하고 테스트해서 버그가 없고 안정적이게 된다면 merge된다.

이제 remote branch를 만들어보도록 하자. (local이 아님을 반드시 기억하자)

우선 본인의 git hub에 들어가 remote repository를 만들도록 한다.

그리고 zsh에서

mkdir git-remotebranch
take git-remotebranch

git init

# http:// 부터의 주소는 본인의 리모트 저장소 주소를 의미한다.
git remote add http://~
# 리모트 저장소를 추가하기 위해서는 add를 사용하는데
# 앞에 있는 것은 우리가 별칭으로 사용할 리모트 저장소의 이름이 되고
# 뒤에 있는 것은 리모트 저장소의 주소가 된다.

git remote -v

하고나면

origin	https://github.com/zehye/Git-Remote-breanch.git (fetch)
origin	https://github.com/zehye/Git-Remote-breanch.git (push)

이는 이 저장소에 연결되어 있는 리모트 저장소를 나타내는 것이다.

일반적으로 리모트브랜치 이름은 (remote)/(branch) 형식으로 나타난다. 예로들어 리모트 저장소의 origin의 master브랜치를 보고 싶다면 origin/master라는 이름으로 브랜치를 확인하면 된다.

다른 팀원과 함께 어떤 이슈를 구현할 때 그 팀원이 iss53이라는 브랜치를 서버로 push했고 나 또한 로컬에 iss53이라는 브랜치가 있다고 가정하자면, 이때 서버의 iss53 브랜치가 가리키는 컷은 로컬에서 origin/iss53이 가리키는 커밋이다.

예로 들어 git.ourcompany.com이라는 git 서버가 있고 이 서버의 저장소를 하나 clone하면 git은 자동으로 origin이라는 이름을 붙인다. origin으로부터 저장소 데이터를 모두 내려받고 master브랜치를 가리키는 포인터를 만든다. 이 포인터는 origin/master를 가리키게 하고 이제 이 master브랜치에서 작업을 시작할 수 있다.

git push origin master

# clone하는 방법은 -> git clone 디렉토리 주소
git clone ~

이렇게 clone하게 되면 cd, remote-v, branch-v, git log 모두 다 동일하게 나온다. 그리고 위에서 말했듯 클론 받은 저장소가 origin 으로 된다.

이때 클론 받은 사람이 파일을 수정해본다.

vi README.md
git add README.me
git commit -m '~'

이를 두개 만들어서 log를 통해 파악해보면 HEAD/master와 origin/master가 다르게 들어가 있음을 볼 수 있다.

이때 master에 origin/master의 내용을 보여주고 싶다면

git push origin master

git log에 들어가 확인해보면 한 곳에 브랜치가 다 모여있다.

그런데 이는 origin 저장소에 변경된 내용을 로컬 워킹 디렉토리에 변경사항만 가져온 것으로 바로 적용이 되는 것은 아니다.

이를 합치려면 (내가 만든 커밋과 상대가 만든 커밋을 합쳐야 하니까)

그때

git fetch origin

근데 이때

git merge origin/master

하려고 하면 충돌이 생기고 그 충돌은 앞에서 했던 것처럼 해결한 뒤

vi ~

git add ~
git commit -m '~'

git push origin master

해결!

참고 remote repository 이름 바꾸는 방법

git remote rename ~

remote repository 삭제하는 방법

git remote remove ~

근데 저장소를 삭제한다는 의미는 로컬에서의 연결만 지워지는 것이지 그 저장소는 그대로 남아있다.