var fs = require('fs');
fs.readFile('./bigFile.txt', 'utf8', function(err, data) {
console.log(data);
});
console.log('exiting...');
$ cp /usr/share/dict/words bigFile.txt --> 이것은 큰 사이즈의 파일을 만들기 위한 작업
$ node ./fsTest.js
exiting...
A
a
aa
......
ReferenceError: require is not defined
bool someFuncPlain ()
{
if (작업1 수행이 실패한경우)
{
에러 발생시의 추가 작업수행...;
return false;
}
if (작업2 수행이 실패한경우)
{
return false;
}
....
// 함수내 모든 처리 완료
return true;
}
(https://github.com/oneclick/rubyinstaller/wiki/Development-Kit 을 참조)
http://gitimmersion.com/
http://try.github.com/levels/1/challenges/1
* 설정
git config --global user.name "Your Name"
git config --global user.email "aaa@bbb.com"
라인 ending 설정 (윈도우경우)
git config --global core.autocrlf true
git config --global core.safecrlf true
인코딩 설정: 윈도우 환경일 경우.
git config --global i18n.commitEncoding cp949
git config --global i18n.logOutputEncoding cp949
물론 인코딩이 utf8 이라면
git config --global i18n.commitEncoding utf8
git config --global i18n.logOutputEncoding utf8
SSH-Key 생성
ssh-keygen -t rsa
* 추적하지 않을 파일 설정하기
.gitighore 파일을 생성, 패턴을 기술.
echo "*.security" > .gitingnore
* 현 설정 확인
git config --list
* Repository 생성
git init
* 상태 확인
git status
* 변경사항을 staging 하기
git add test.c
git add .
staged 상태 : Git가 변화를 인지한 상태, git add 를 수행하면 됨.
아직 commit을 안한 상태이기때문에 변경사항이 영구적으로 저장된 상태가 아님을 나타냄.
* 커밋
git commit -m "Changes for a and b"
혹은 vi등 편집기를 통해 메시지 편집 시에는 그냥 git commit
주의) 파일 수정후 add, 다시 파일 수정후, commit 을 하면,
2번째 수정 사항은 staging안된 상태이다.
커밋을 해도 2번째 수정 사항은 저장안됨.
이때는 2번째 수정 사항에 대한 add 도 수행하고 그것에 대한 commit도 다시 수행 해야함.
간혹 빈 commit 을 만들어서 push 해야 하는 경우가 (github pages 에 실패한 deploy를 다시 수행하는 경우 등등) 있는데, 다음처럼 수행하고 git push 한다.
git commit --allow-empty -m "empty commit"
* 이력보기
git log git log --pretty=oneline --max-count=2
git log --pretty=oneline --since='5 minutes ago'
git log --pretty=oneline --until='5 minutes ago'
git log --pretty=oneline --author=<your name>
git log --pretty=oneline --all
git log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
git log --all --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short
아직 커밋 안된 상태 에서 변경 사항 알아내기
git diff HEAD 파일명
HEAD란 최종 커밋을 의미.
2개 커밋 간 변경된 파일 목록 조회
git diff --name-only <commit hash1> <commit hash2>
각 commit 별 변경된 파일 목록 조회
git log --name-status
* 이전 버전 가져오기
git log --all --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short
* cdb6848 2012-07-18 | 3 commit (HEAD, v1, origin/master, master) [kojunghyen]
* b5cda22 2012-07-18 | 1st [kojunghyen]
* 2314983 2012-07-18 | 2 commit [kojunghyen]
* ece0e9f 2012-07-18 | first commit [kojunghyen]
git checkout <hash>
ex: git checkout 23149839d82ce5f104aa6fba72b201566da44ec6
다시 master branch의 최신 버전으로 돌아오려면,
git checkout master
'master’ is the name of the default branch.
By checking out a branch by name, you go to the lastest version of that branch.
* 태그 붙이기
현재 버전을 v1이라고 하기로 하자.
git tag v1
바로 이전 버전을 가져오는 방법
git checkout v1~1 => v1^
^ notation to indicate “the parent of v1”
이 이전 버전을 v1-beta라고 태그를 붙이자.
git tag v1-beta
* 태그 조회
git tag
* 태그 삭제 (로컬) git tag -d<tag명>
* 태그 삭제 (원격) git push --delete origin<tag명>
* 태그 삭제 (tag 명이 브랜치명과 같은 경우) -> 명시적으로 tag임을 지정해서 삭제해야 함 git push origin :refs/tags/<tag명>
* stage->un-staged 상태로 변경하기
git reset HEAD myfile
* 수정한 내용을 무시하고 처음 상태(최근 커밋된 버전으로)로 되돌리기
git checkout -- myfile
* 커밋된 변경 되돌리기
git revert HEAD
This technique will work with any commit (although you may have to resolve conflicts).
It is safe to use even on branches that are publicly shared on remote repositories.
* AMENDING COMMITS (커밋 수정하기, 혹은 기존 커밋에 추가하기)
git commit --amend
add, commit된 상태에서 수정이 발생하였고 이전 커밋에 포함하고 싶은 경우(2개의 커밋생성없이).
* 여러개의 COMMIT들을 하나의 C OMMIT으로 합치기
다음처럼 커밋 히스토리가 존재할때
git log --oneline
-->
commit4
commit3
commit2
first commit
3,4 커밋을 합치고 싶은 경우,
git rebase -i HEAD~2
pick .......
pick .......
이것을 다음 처럼 변경 (출력 순서 주의 : 제일 위가 제일 오래된 커밋 이다, git log 와 반대)
pick ...
squash ...
* MOVING FILES
git mv hello.rb lib
혹은 add 후 제거,
git add lib/hello.rb
git rm hello.rb
* branch 만들기
git checkout -b 브랜치명
=> 이후 브랜치내에서 작업을 수행하고 commit한다.
브랜치를 선택할 경우는
git branch -a
=> 브랜치들을 리스트업, 이후 선택할 브랜치를 checkout 하면 됨
git checkout master
git checkout greet
* branch 제거
git branch -d 브랜치명
* Merging
git checkout greet
git merge master
=> master변경분을 greet에 merge시킨다.
예: clean_up branch를 만들고 작업후 master branch로 돌아와서 merge수행시
git merge clean_up
* branch 변경 비교하기
git diff --color branch1..branch2
* branch내에서 commit간 변경 비교하기
git diff --color commit_hash1 commit_hash2
=> hash 시작 문자 일부만으로도 가능.
* 충돌 해소
여러개의 BRANCH간 CHECKOUT시 불일치 발생 경우면 수동으로 해당 파일 수정후 ADD, COMMIT.
* branch push/pull 하기
자신이 생성한 branch 를 원격저장소에 push
git push origin my-branch
원격 브랜치 가져오기: 먼저 원격 브랜치 확인
git branch -r
git checkout -b 생성할브랜치이름 원격브랜치이름
동일한 이름을 사용한다면 -t 옵션 사용
git checkout --track 원격브랜치이름
* REBASING VS MERGING
rebase는 말 그대로 베이스를 다시 잡는 작업이다.
변경사항을 적용할 기준(베이스) 브랜치를 지정하고 현재 브랜치의 변경사항을
그 기준되는 브랜치에 적용을 하여 선형적인 커밋 히스토리를 만들어주므로
지저분하지 않게 된다.
다음설명이 가장 잘 이해됨.
Choose to merge when you have a feature on a separate branch and want to bring that
code into master or another branch.(feature branch 만들어서 다른branch 와 합칠거면
merge 를 사용해라. 즉 일반적인 용도에 사용)
Choose to rebase when you want to stay in sync with the main branch
when you’re working on a long-lived side branch.(없어지지않고 계속 사용될 branch 와
main branch 가 일치된 내용으로 가고싶을경우 rebase를 사용해라)
다음 링크에서도 rebase 에 대해서 그림으로 잘 설명됨.
rebase를 사용하지 말자는 내용임. feature branch에서 에러가 발생되면 rebase 시
모든 commit 에 에러가 포함되는 문제를 지적하고 있음.
그냥 간단하게 merge 를 사용하는게 좋다.
https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1
When to Rebase, When to Merge?
Don’t use rebase … 커밋 히스토리를 변경시키기 때문이다.
http://stackoverflow.com/questions/3357122/git-pull-vs-git-fetch-git-rebase
정확한 커밋 히스토리가 중요한 경우에는 리베이스 사용을 자제.
하지만 동일한 branch인 경우에는 선택의 여지가 있음 (아래 git pull 참고)
* add a remote repository
git remote add origin git@github.com:jeremyko/try_git.git
* git fetch
원격저장소의 변경사항 가져와서 원격브랜치를 갱신.
* Pushing Remotely
로컬 변경을 origin repo (on GitHub)에 반영한다.
-u 옵션은 입력인자들을 기억하는 옵션이다.
이 경우 다음부터는 git push 만 입력하면 된다.
git push -u origin master
* Pulling Remotely
git pull
remote repository의 변경사항을 가져온다. 그런데 pull명령은 다음과 동일하다.
git fetch
git merge origin/master
즉 변경 내용을 가져온후, 로컬의 변경사항과 머지하는작업이 동시에 일어난다.
git pull --rebase
pull 사용 시 매번 merge commit 이 생기는게 필요없는 경우
(즉, 동일한 master branch만 pull로 가져오는 경우, master 브랜치끼리 merge commit 은
불필요 할수 있으므로)
--rebase 옵션을 주면 merge commit log 가 발생 하지 않게되어,
좀 더 직관적인 이력관리가능.
* log
commit history 로그 보기.
특정 사용자의 commit history 만 보고 싶다면, git log --author=userid
특정 파일에 대한 log를 보고 싶으면, git log /xxx/yyy/source.hpp
* stash
만약 local의 변경 사항을 임시로 저장했다가 나중에 다시 적용하고 싶다면 'git stash' 로
변경사항을 stash 한 다음, git stash list 로 목록을 확인할수 있다.
예를 들면, feature branch에서 이슈에 대한 수정을 진행 중인데, master branch로 패치된
내용을 반영하고 작업을 해야 하는 경우, commit 후에 master branch와 merge 할 필요없이
stash로 수정사항을 보관 후, master 와 merge 후 다시, 작업 중이던 수정 사항을 반영 하면
다시 이전과 같은 개발 중 상태가 된다.
'git stash apply' 명령을 pull 작업 이후에 실행해서 재 적용 시킨다.
git stash drop 을 수행해야 list 에서 삭제된다.
(git statsh apply 대신 git stash pop 을 수행하면 자동으로 list 에서 삭제된다)
* cloning
원격 저장소에 있는것을 복제하기 위해서는 git clone을 사용한다.
git clone https://github.com/jeremyko/kothreadpool.git
git clone user@61.40.220.178:/path/rep_name.git my_repo_name
* Mac 사용시, .DS_Store 파일이 커밋되는것을 막으려면
http://hints.binaryage.com/how-to-remove-ds-store-files-from-a-git-repo/
* local GIT Server 설정
동일한 서버에서 여러 개발자가 개발하는 경우 간단하게 설정 가능.
서버 위치는 /USER/kojh/serverRepository.git 디렉토리라고 가정.
소스 존재 위치는 /USER/kojh/MySrc 라고 가정(이미 git init된 상태).
1. remote 서버 역활 구성
cd /USER/kojh/serverRepository.git
git init --bare
2. 소스를 서버에 push
cd /USER/kojh/MySrc
git remote add origin /USER/kojh/serverRepository.git
git push -u origin master
2. 개발자 1 의 작업
git clone /USER/kojh/serverRepository.git dev1WorkSpace
git remote add origin /USER/kojh/serverRepository.git
3. 개발자 2 의 작업
git clone /USER/kojh/serverRepository.git dev2WorkSpace
git remote add origin /USER/kojh/serverRepository.git
4. 이제 개발자1,2 가 일반적인 commit, push, pull 을 수행.
