Klein Bottles by 바죠


dropout [deep learning] by 바죠

neural network 방법의 최대 문제점인 overfitting 문제, overtraining 문제를 해결하는 간단한 방법: dropout

neural network에서 overfitting을 방지하는 방법: dropout

training 할 때, 시간이 더 많이 걸리는 단점이 있지만, 보다 정확한 training 이 가능하다. 즉, 실제 테스트에서 보다 더 좋은 성능을 발휘한다.

통상, train, validation, test 라고 하는 방식을 활용한다.
또는 train, test로 단축해서 machine learning 의 정밀도와 transferability를 체크한다.
즉, 연습하여 학습하는 셋트가 있고, 연습하지 않은 세트, test 세트에 대해서 그 예측의 정확도를 알아보는 것이다.
당연히 연습, 학습을 한 train 셋에서는 매우 우수한 예측을 수행한다.
하지만, 연습하지 않은 유사한 test 세트에서의 예측 성능은 보장되는 것이 아니다.
통상 test 셋에 대한 예측 성능이 최적화 되었을 때, 가중치 최적화 작업을 종료한다.
이 부분을 수행하는 것이 validation 단계이다.

최근 알파고와 이세돌 프로의 바둑 승부를 통해서 잘 알려진 항목중 하나가 바로 deep learning 항목이다.

By dropping a unit out, we mean temporarily removing it from the network, along with all its incoming and outgoing connections.

Max-norm regularization

A possible justification is that constraining weight vectors to lie inside a ball of fixed radius makes it possible to use a huge learning rate without the possibility of weights blowing up.

Dropout can be seen as a way of adding noise to the states of hidden units in a neural network.

Dropout introduces an extra hyperparameter|the probability of retaining a unit p.
This hyperparameter controls the intensity of dropout. p = 1, implies no dropout and low values
of p mean more dropout.

Typical values of p for hidden units are in the range 0:5 to 0:8.
For input layers, the choice depends on the kind of input. For real-valued inputs (image
patches or speech frames), a typical value is 0:8.

For hidden layers, the choice of p is coupled with the choice of number of hidden units n.
Smaller p requires big n which slows down the training and leads to underfiting.
Large p may not produce enough dropout to prevent overfitting.


r > p=0.8                 : input layer
r > p= 0.5 ~ 0.8        : hidden layer

p 가 작을 수록, hidden layer  수는 많아야만 한다.






참고:
http://jmlr.org/papers/v15/srivastava14a.html
http://jmlr.org/papers/volume15/srivastava14a/srivastava14a.pdf
https://www.cs.toronto.edu/~hinton/absps/JMLRdropout.pdf
http://media.wiley.com/product_data/excerpt/19/04713491/0471349119.pdf


레몬으로부터 불을 얻다. by 바죠


git 용어 및 명령어 정리 by 바죠

git의 유일한 약점은 사용하는 방법을 배우는데 진입장벽이 있다는 것이다.
유닉스/리눅스 명령어처럼 자유롭게 사용하기까지는 다소의 시간이 걸린다.
윈도우즈의 경우 직관적으로 일을 할 수 있다.
하지만, 좀 더 조직적으로 일을 하려면 리눅스/유닉스 형태의 문자기반 명령어를 이용하는 것이 더 생산성이 있다.
마우스는 키보드보다 더 느리고, 복사를 통한 재생산에 취약하다. 반복 수행에 치명적 약점을 가지고 있다.
잘 알려진 사실이다. 스크립트 기반으로 보다 많은 일들을 쉽게 할 수 있다.
GUI는 처음 사용하는 날 그날만 편리할 뿐이다. 둘째날 부터 귀찮아지게 되어 있다.
마찬가지이다. 다소의 진입장벽이 있다고 하더라도 그 부분만 넘을 수 있으면 더 많은 일을 할 수 있다.
git을 사용하지 않아도 많을 일을 할 수 있다. 하지만 협업을 생각한다면 배워두어야만 하는 것이다.
특히, github, bitbucket 과 같은 서비스를 잘 활용하는 자체가 git 명령을 사용하는 것이다.
 서로 다르지 않다.
전반적인 git에 대한 개념을 잡는 것이 중요하다. 그 다음 실제에서는 자료를 찾아서 부딪치는 문제를 해결하면된다.

git 요약 및 용어 정리

국소 저장소와 원격 저장소가 있다.  
원격 저장소는 다른 사람과 협업을 위해서 필요한 것이다.   
                                        
git 저장소를 만드는 두 가지 방법을 먼저 설명한다.
[1] 기존 프로젝트를 git 저장소로 만드는 방법. (.git 디렉토리를 만들어 준다.)
[2] 다른 서버에 있는 저장소를 clone 하는 방법. (.git 디렉토리를 만들어 준다.)

먼저 기존의 프로젝트(예를 들어, 프로그램 개발이 이루어지던 곳)에 git  저장소를 만드는 방법이다.
$ git init
라는 명령어를 입력해야 추가적인 git 명령어가 들어간다. 디렉토리 초기화 명령어이다.
기존의 일반 폴더에서 git 명령어를 받을 수 있는 폴더로 변환을 이루게 해준다.
디렉토리 .git 가 존재하는 곳. 개발이 이루어지는 곳.
git 이 파일을 관리하게 하려면 저장소에 파일을 add 하고 commit 해야한다.
commit  명령어가 수행되면 그 명령어 단위로 파일들이 보관되게 된다. (보관이 이루어지는 단위를 정해준다.
commit 할 때마다 프로젝트가 스냅삿 형식으로 저장된다.)
추적, 관리의 대상이 되는 파일들을 add 로 등록을 해야한다. 그렇게 해야 commit 할 수 있다.  
$ git add *.c
$ git add LICENSE
$ git commit  -m 'initial project version'
add 할 때, 디렉토리 이름을 주면, 그 아래 모든 것들을 다 취급하게 된다.
수정할 때마다 add 해야 한다.
Unstage 시키는 방법(관리 대상, 추적 대상의 파일에서 제거):
$ git reset HEAD AndroidManifest.xml
commit 하나 이전
$ git reset HEAD^
commit  두 개 이전
$ git reset HEAD^^


$ git log
$ git log --oneline
전체를 저장하고 있다. 이전 것과의 차이를 저장하는 방식이 아니다.
언제든지 원하는 저장본을 볼 수 있다.
$ git checkout a1e8fb5 
$ git checkout a1e8fb5 hello.py
물론, 파일 하나만 볼수도 있다.
또 다시 원래 진행하던 일을 할 수 있다. 이전 버전을 조회할 수 있다는 사실이 매우 중요하다.
아울러, 개발할 때, 항목별로 개발이 독립적으로 진행되면 좋다. 이러한 문제를 해결해 주는 것이 branch이다.
여러개의 branch를 만들어서 개별적인 일들을 수행할 수 있다. 개별적으로 테스트할 수 있다.
물론, 가장 중요한 branch는 master라고 하는 branch이다. 개발이 완료되면 branch 들을 지워버릴 수 있다.
$ git checkout master

다음으로 clone 방법으로 git  저장소를 만드는 방법이다.
bibgit2 라는 디렉토리를 만들고 그 안에 .git 디렉토리를 만든다. 아울러, 최신 버전을 checkout 해 준다.
당장 새로운 일을 할 수 있다. 새로운 계산을 할 수 있다.
물론, 새로운 아이디어로 프로그램을 수정, 보완할 수 있다.
$ git clone https://github.com/libgit2/libgit2  mylibgit
처럼 할 수 있다.

git 은 파일을 다음의 상태들로 관리한다. (git status 로 상태확인 가능함. 또는 git diff 명령어가 유용하다.) 
modified, staged, committed 세가지 상태가 있다.  
파일을 수정하고 Staging area 에 추가하면 Staged 상태가 된다.
그냥 수정한 상태이면 modified 상태이다.
staged 는 commit 하기 위해서 미리 표시해두는 작업이다.
특정 버전을 checkout 한 것이 Working directory 이다.
Staging area 에 있는 파일들을 commit 하여서 git 디렉토리에 영구적인 스냅삿으로 저장한다.
git 디렉토리에 있는 파일들은 committed 상태이다.

$ git status
명령어로 파일의 상태를 확인할 수 있다.
Changes to be committed
한 번 add 하고 난 후 파일을 다시 수정했다면,  결국 다시 add 해야만 한다.  
수정 전후에 git status 명령어로 각각의 상태를 확인할 수 있다.
$ git status -s
파일들의 상태를 체크해 준다.
처음에 add 하고 commit 한 후 다시 파일을 수정할 수 있다. 
다시 add 하지 않은 경우 후속으로 이어지는 commit 에서 빠지게 된다.
git commit --amend 명령어에서도 빠지게 된다. 즉, 수정사항이 반영이 되지 않는다.
프로그램 개발 과정에서 add 는 계속해서 해야하는 것이다.
git status 명령어에서
nothing to commit 라는 말이 나왔다면, 모든 파일들이 add 되고 committed 되었다는 뜻이다.
그렇지 않고 , modified 란 말이 있다면, add 하지 않는 파일이 있다는 뜻이다.
처음에 추적을 했었고, 수정된 파일인 경우에 modified라는 말이 나오게 된다.
comit 명령에서 제외 된 파일이 있다는 뜻이다.
comit 명령어에 포함되기 위해서는 add 명령어가 필요하다. 다시 한 번 더 add 명령어가 필요하다는 말이다.


$ git diff
수정했지만, staged 상태가 아닌 파일을 비교해 볼 수 있다. 이 명령어는 Stage 하지 않은 것을 보여준다.
수정한 파일을 모두 Staging area 에 포함시켰다면 git diff 명령어는 아무것도 출력하지 않는다.
git diff  --cached
명령어는 Staged 상태인 파일을 확인해준다.
commit 할 때마다, 프로젝트의 스냅삿을 기록한다.
$ rm file_rm
$ git status
$ git rm file_rm
$ git status
이렇게 하면 git 이 더이상은 이 파일을 추적하지 않는다. 놓아 준다. 더 이상 관심의 대상이 아니게 된다.
버전 조절에서는 제외되는 것이다. 하지만, 여전히 국소적으로는 파일 형태로 존재하게 된다. 
곧 바로 commit 명령어를 수행해 줄 수 있다.
$ git rm  --cached README
$ git rm \*~

commit 한 파일을 지울 떄:  -f  옵션이 필요하게 됨. (-f 옵션, 강제성을 표현하고 있다. )
stage area 에서 제거하고 파일은 유지함.
$ git rm --cached DeleteMe.txt

$ git move afile  bfile
명령어는 아래의 명령어들과 동등하다.
$ mv afile bfile
$ git rm afile
$ git add bfile
$ git reset HEAD abcd_file
파일을 unstage 시키는 방법

파일을 수정했으면 다시 git add 명령어를 실행해 주어야 한다. 그렇게 해야만 to be commited 상태로 만들어 줄 수 있다.
관리하지 않는 파일들, 추적하지 않는 파일들 목록을 넣어 두는 파일의 이름이 정해져 있다.
.gitignore
이 파일 속에
*.exe
*.o
*.mod
*~
같은 형식으로 한줄씩 추적하지 않는 파일들의 형식을 적어 줄 수 있다.
물론, 이 파일도 add 하고 commit 해야 한다.

                                 

$ git help
도움을 받을 수 있다.

fork
권한이 없는 프로젝트에 참여할 때 사용한다. 우선 타인의 프로젝트를  복제한다.
(자신의 고유 영역으로 복제하는 것이다.)
원래 프로젝트의 관리자(project owner)가 아닌 사람들은 fork 하고 수정해서 push 할 수 있다.
원래 프로젝트 관리자(project owner)를 기본적으로 도와 줄 수 있다. 
(복제해 간 개발자가 추후 개선 작업들을 통해서 원 프로젝트를 개선할 수 있다.)
자신의 네임스페이스로 복사하는 것, 복사한 사람 자신의 것이 된다. 그렇기 때문에 쓰기 권한이 있다. 
복제한 사람이 자신의 국소 컴퓨터에 복제해서, 그곳에서 프로그램을 개선한다.
branch 를 만들고 개선 작업을 수행한다. branch 에 commit 한다.
개인 저장소 branch 에 push 한다. 
최종적으로는 project owner 가 pull requests 를 merge 한다.
Fork 한 프로젝트를 국소 컴퓨터로 가져 온다.
$ cd blink
Fork 를 수행한 개발자가 자신이 목표로 했었던 필요한 작업들을 수행한다.
아래의 명령어와 함께 작업을 진행한다.  
$ git checkout -b slow-blink
$ git commit -a -m 'three seconds is better'
새로운 branch 를 만들어서 하고자 했었던 작업을 완료한다.
$ git push origin slow-blink 
개인 저장소에 push 한다. Fork 한 저장소에 가보면 새로운 branch 가 추가되었음을 확인할 수 있다.
복제되기 전 원래의 저장소에 pull request 를 보낼 수 있다.
아니면 저장소의 branch 페이지로 가서 new pull request 방법을 취할 수 있다. 


국소 컴퓨터에 Pull Request branch 를 당겨와서 merge 해도 된다.
$ git remote add upstream https://gibhub.com/schacon/blink
$ git fetch upstream
$ git merge upstream/master
$ git push origin slow-blink

branch
특정한 commit 을 가리키는 파일이다.
기존에 없는 새로운 기능을 추가하려고 하는 경우에 활용한다.
새로운 branch 를 만들어야 새로운 일을 할 수 있다. branch 로 이동하는 명령어는 checkout 이다.
작업들은 각각의 branch 에 보관되어 있다.
새로 branch 를 하나 만드는 것은 조그만 파일 하나를 만드는 것에 지나지 않는다.
기존의 작업본과 구분해서 관리하는 방법으로 branch 를 활용한다.
Forks 도 마찬가지 개념이다.
완전히 격리된 상태에서 일을 진행하고 싶다.
이 때 branch 를 활용한다. 그 작업이 완료되면 다시 master 로 돌아와 merge 를 수행한다. 
돌아 올 때는 git checkout master 라는 명령어를 사용할 것이다.
git push origin branch_name 으로 원격 저장소로 branch 를 보낼 수 있다.
새로운 branch 를 만들기전에는 이미 master 라는 branch 를 이용하고 있는 것이다.
branch 를 새로운 작업 장소라고 생각한다. 당연히 여러 개의 branch 가 순서적으로 만들어 질 수 있다.
따라서 여러개의 branch 가 공존할 수 있다. 
기본 작업본 branch 이름은 master 이다. 
$ git checkout -b iss53
아래와 동일한 명령어
$ git branch iss53
$ git checkout iss53
그 뜻은 새롭게 만들어진 branch 이름이 iss53 이라는 것이다.
그리고 iss53 작업을 수행하려고 한다는 뜻이다.
$ git merge iss53
$ git status
$ git mergetool


                                                                
새로운 branch 에서 작업을 하고 master 라고 불리우는 branch 와 결국에는 merge 한다.
3-way merge + merge commit  == rebase + merge


현존하는 여러 개의 branch 조회를 수행해 볼 수 있다.
$ git branch

new_branch 라는 새로운 branch 를 생성시킬 수 있다. 
(자신만의 새로운 일들, 수정, 추가) branch 이름이 뒤에 온다.
$ git branch new_branch
여러 개의 branch 를 만들어서 일을 진행해도 된다. 이름이 달라야만 한다.
더 이상 필요가 없는 branch 는 삭제한다. merge 까지 이루어진 경우에 해당한다.
$ git branch -d new_branch
이름 변경은 다음과 같이 수행한다.
$ git branch -m old_branch  new_branch

git add
git 이 특정 파일들을 눈여겨 보기 시작하게 해준다. 관리의 대상을 정해준다. 
commit 명령어와 밀접한 연관이 있다.

git commit
저장 명령어이다. 변경 사항을 나중에 참조하게 할 수 있게 한다.
스냅삿을 찍기 위해서는 이 명령어를 수행해야만 한다.  
commit 역사를 조회하는 명령어가 있다.
$ git log
$ git log -2
$ git log -p -2
$ git log --stat
$ git log -pretty=oneline

한 번 commit 을 수행하였다.
그 이후 다시 파일을 수정하고, git add 하는 경우 또는 git  rm 으로 파일을 지운 경우가 있을 수 있다.
이전의 commit 에 추가 하고 싶을 경우, 새로운 commit 을 만들지 않고,
최종 commit 에 변경사항을 넣어 버릴 수 있다.  rebase 에서 처럼, 이미 push 해 버린 commit 을 수정하면 안된다.
아래의 명령어를 사용하면 안 되는 경우이다.
$ git commit --amend

checkout
(소스 코드를 다운로드 받아서 사용하거나 개발하는 경우)
master branch 또는 new_branch 를 보고 싶을 때:
$ git checkout  master
$ git checkout  new_branch

commit
저장하는 명령어이다. 변화된 내용만 저장하게 된다.
(업로드 시키는 경우, 여러 명의 개발자가 각자 업로드를 할 수 있다. 즉, 국소 컴퓨터에서만 적용된다.)
한 번도 commit 한 적이 없는 파일은 git 으로 복구할 수 없다.
한 번 수행한 commit  명령어를 다시 보완하고 싶을 때, 즉, commit 명령어 수정본이다.
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
위에 표시된 3 가지 명령어는 단 한 번의 commit 로 기억된다.
방금 commit 을 했는데, commit 에 포함하지 못한 것을 찾았을 때:
$ git commit -m 'init commit'
$ git add file_forgotten
$ git commit --amend

최종 확정본 HEAD

tag
(특정 날짜의 소스 코드로 돌아가기 위해서 필요함, commit 을 보조하는 것,
tag 이름을 지정하여 checkout 하면 특정 버전으로 돌아갈 수 있다. )
특정 commit 에 tag 를 하기 위해서 명령의 끝에 commit checksum 을 명시한다.
$ git log --pretty=oneline
$ git tag -a v1.1  9fceb02

$ git tag aaa
$ git tag
$ git log --decorate
$ git tag -n
$ git tag -d aaa

$ git tag v2.5 1b2e1d63ff

$ git tag 1.0.0  1b2c00
확정본 식별자를 마지막에 넣어 준다.
$ git log
명령어로 확정본 식별자를 얻어 낸다.

origin/master 가 의미하는 것: 원격 저장소 origin 의 기본 branch 인 master
master 가 의미하는 것: 국소 저장소의 기본 branch 인 master

conflict
(두 명이 commit 를 한 경우, 서로 다른 내용이 올라올 수 있다.)
같은 파일의 한 부분을 동시에 수정했을 때 일어남. git status 로 확인 가능함. 
직접 수정 작업을 한다.
commit 를 수행하여 merge 를 완료한다.

git 에서 한 branch 에서 다른 branch 로 합치는 방법은 두 가지가 있다. merge, rebase 가 그 두 가지이다.
결국, commit 역사가 서로 다르다. merge 는 두 branch 의 최종 결과물만을 가지고 합치는 것이다.
rebase 는 branch 의 변경사항을 순서대로 다른 branch 에 적용하면서 합친다.  
rebase 공개하여 사람들이 사용하는 commit 을 rebase 하면 안된다.
merge
(서로 다른 개발 내용을 분석해서 하나로 만드는 것, 국소 저장소에서 일어나는 일, mege 하려면 commit 해야 함)

fetch
가져오는 기능이다. 원격에 있는 것을 가져옴. 국소에는 없는 것.
fetch/pull 로 최신 상태를 만들 수 있다. 그 다음에 push 한다.

국소 저장소에 있는 모든 것을 포기하고 (변경해 놓은 것을 포기함. 또는 잘못 한 것을 포기함.) 새롭게 시작할 경우.
$ git fetch origin
$ git reset  --hard  origin/master

pull = fetch + merge
$ git pull
원격 저장소의 변경 내용들이 받아지고 또한 병합되어 진다.

현재 branch 로 합침
$ git merge  branch_name
자신의 작업을 끝낸 상황에서 모든 사람들이 볼 수 있는 master branch 에 추가한다.

자신의 국소 컴퓨터 (개발자 개인이 사용하는 컴퓨터이다. 다른 사람들의 것과 독립이다.) 에서
작업한 것을 웹 저장소에 올리는 경우, 즉, commit 한 것을 올리는 경우:
$ git push
반대 개념으로 자신의 국소 컴퓨터에서 새로운 것들을 받고 싶을 경우:
$ git pull

update
(최신의 소스 코드를 받아 오는 경우, 즉, 국소 컴퓨터에서만 적용된다.)

$ git mv README.md README
위의 명령어는 아래의 명령어들과 동일한 것이다.
$ mv README.md README
$ git rm README.md
$ git add README

원격에 있는 서버의 저장소를 복제해서 국소 컴퓨터에 만들경우 (남의 것 최초 복사):
$ git clone https://github.com/libgit2/libgit2  mylibgit
$ cd ticgit
$ git remote

git clone  URL   test_folder_name
git clone  주소

pull requests
다른 사람들이 코드에 대한 의견, 새로운 코드를 제시하는 경우, accept/reject 를 해야만 한다.

$ git status
commit 되지 않은 상황에서 변경 상황 조회

git remote add origin
국소 저장소가 아니고 원격 저장소 위치를 원점으로 삼는다. 즉, 원격의 원점이라는 뜻이다.

git add 의 변형으로 해석을 해야 자연스럽다. 즉, 추가하는데 원격 원점으로 새로 잡았다.
원격 원점이 새로운 원점이 되게 한다는 뜻이다.

원격 저장소로 부터 클론을 해서 만든 경우가 아닐 때,
원격 저장소로 소스 코드를 밀어 놓고자 한다면, 원격 저장소를 정의해줘야 한다.
원격 저장소를 정의 하는 방법:
$ git remote add abcremote
https://github.com/twitter/abcremote.git

원격 저장소 확인 (국소 저장소가 알고 있는 원격 저장소 표시, push, fetch 둘 다 가능함):
$ git remote -v
원격 저장소 확인 (국소 저장소가 알고 있는 원격 저장소 표시, push, fetch 둘 다 가능함):
git remote rm
형식으로 지울 수 있다.
git remote rename
형식으로 이름을 변경할 수 있다.
원격 저장소에 올리기:
$ git push
$ git push origin master
반대로 받아 오기:
$ git pull origin master

새로운 원격 저장소 추가, 단축명으로 추가하기:
git remote add
$ git remote
$ git remote add pb
https://github.com/paulboone/ticgit
$ git remove -v

원격 저장소 목록
$ git remote -v

원격 저장소 정보 제공
$ git remote show

원격 저장소 삭제
git remote rm

$ git commit -a -m "abcd" 
(변경사항 전부를 add 하고 commit를 수행한 것과 동일함. 선별적으로 add 하고 commit 할 수 있음 )
$ git fetch
$ git merge origin
$ git push
 
$ git checkout -b branch_test
이 때는 master 와 같은 것으로 부터 시작한다.
branch 목록을 살펴 본다.
별표가 붙은 것이 현재의 branch 이다.
$ git branch
작업 수행, master 와는 상관없는 일들이다.
$ git checkout   master
$ git branch -D  branch_test
merge 를 하지 않은 경우에 해당 branch 를 지우는 방법. 변경 사항 무시함. 강제 삭제 진행함.

$ git checkout -b branch_new  a1b2c3
새로운 branch 를 생성하고, 그 곳에 a1b2c3 revision 을 내려 받는다.

$ git checkout master
작업
$ git status
$ git add old_file  new_file  
(관리되고 commit 될 파일들 정리함)
$ git status

$ git diff
최근 commit 된것과의 차이점, 수정은 했지만 staged 상태가 안 된 것 비교.
즉, modified 상태와 staged 상태는 서로 다른 상태들이다. staged 상태가 되어야 commit 할 수 있다.
$ git diff  --cached
stage 되고 commit 안 된 것을 보여준다.

$ git diff   master   branch_test

$ git diff origin
fetch 해서 가져온 것과 비교하기

HEAD 현재 작업중인 branch 의 최신 revision 을 표시함.
여러 개의 commit 이 있어도 최근에 추가한 commit 이 기준
$ git reset --soft HEAD^
최신 commit revision 을 바로 전 revision 으로 설정함.
 git reset commit_name
Undo 를 실행함, 국소적으로는 유지
 git reset  --hard commit_name
 과거의 commit 로 귀환하는 것, commit 했었던것 모두 포기함.
$ git reset --hard
$ git revert HEAD
git revert commit_id
git checkout  id_version  file_version
 

$ git diff --staged
stage 된 것과 commit 된 것 사이이의 차이

$ git diff
stage 되지 않은 것들의 차이

$ git stash
(자신이 개발하던 것을 백업으로 보관함.
아직 일들을 완료하지 않은 상황에서 commit 을 하는 것도 부적절 해 보인다.
그런데, 갑작스러운 다른 일들이 있어서 branch 를 변경을 수행해야만 한다고 가정하자. 
다소 난감한 상황이다.
갑작스러운 일들은 금방 처리 될 것으로 판단된다.
앞서 하던일 잠시 보관하고 다시 그 일들을 마무리하고 싶을 것이다. 
작업 디렉토리에 있는 수정한 파일들만 저장한다. modified file, staging area 에 있는 파일들을 보관한다.)
$ git status
$ git stash
$ git status
작업 디렉토리가 정돈된 것을 확인한다.
$ git stash list
$ git stash drop

$ git diff
$ git pull
(원격 저장소로 부터 받아 옴)
$ git stash pop
$ git commit -a -m "modification" 
(stash 에 백업된 내용을 적용하여 merge 함,
즉, stash pop을 이용하여 merge 함, 이 때 merge 는 앞선 개발자에게만 일어남)
$ git stash clear
(삭제)

$ git stash list
$ git stash show -p
$ git help stash

commit 하지 않은 상태에서 pull 할 경우, fast fowrad 하지 않은 것이다.

$ git rm useless_item
$ git mv old  new

모든 것을 commit 하고 branch를 옮긴다.
그렇게 하지 않을 경우, stashing, commit amending 방법을 활용해야만 한다.

참고:
bitbucket.org 에서는 fork 를 지원한다.
fork 기능: 새로운 추가 기능을 만들 아이디어가 있다면 제일 먼저 fork 를 눌러서 새로운 구현의 준비를 수행한다.
그 다음 fork 된 자료를 자신의 컴퓨터에 clone 한다. 아이디어를 실행한다. 
그 다음에 다시 fork 해 둔 곳으로 올린다.
pull requests 를 작성한다. accept/reject 될 것인지를 기다린다.

$ cd ~/repos
$ git clone
https://emmap1@bitbucket.org/emmap1/myteamquotes.git
$ git status
$ git add editme.html
$ git commit -m "Making a change"
$ git push origin master

참고:
                                                        
bitbucket 에서 repository 를 만든 다음,  아래와 같이 desktop 에서 일을 할 경우를 생각해 본다.
물론, 비어 있는 디렉토리를 clone 할 수 있다.
아래의 URL 주소는 bitbucket 에서 clone 아이콘을 선택했을 때 알려주는 것이다.
파일을 만들고, 수정하고, 테스트를 해 볼 수 있다. 그러한 테스트가 끝이 났다고 가정하자.
                                                           
$ git add locations.txt
$ git status
$ git commit -m 'Initial commit' 
$ git push origin master
$ git pull --all
                                                           
                                                           
bitbucket 에서 변화된 상황을 확인할 수 있다.
                                                           
정반대의 상황는 아래와 같다. bitbucket 에서 파일을 만들고 commit 한 경우, 이 파일을 가져오는 경우이다.
$ git pull --all

참고:
                                                            
$ git branch  future-plans
checkout 을 수행해야 진짜 branch 를 만들어 낸 것이다.
$ git checkout  future-plans
                                                       
하지고 했었던 일들을 수행한다.
$ git status
$ git add stationlocations
$ git commit -m 'making a change in a branch'
                                                          
                                                       
$ git status
master branch 에 대고 merge 하기 위해서는 아래의 명령어 수행이 필요하다.
master branch 에 HEAD 가 위치하도록 한다.
작업하던 모든 것을 commit 하고 master branch 로 이동한다. (stash 기능은 이런 것과 다른 것이다. ) 
$ git checkout  master
future-plans 라는 branch 를 master 라는 branch 에 merge 시키고자 한다.
위에서 준비한 계획대로 실제로 merge 를 수행한다.
$ git merge  future-plans
$ git branch  --merged
$ git branch --no-merged
$ git branch -D not_merged_branch_name

                                                          
$ git branch -d  future-plans
필요가 없어진 branch 를 지워버릴 수 있다. 아래의 명령어로 삭제 상황을 체크할 수 있다.
$ git branch
                                                            
$ git status
$ git push origin master

bitbucket 에 프로그램들을 올리는 방법, 가정은 bitbucket 에 repository 를 미리 만들어 두었다.
$ git init
$ git remote add origin

1 2 3 4 5 6 7 8 9 10 다음