OS/Linux

git 은 어렵다..ㅠㅠ

아르비스 2016. 9. 6. 15:07

Git 사용법


http://gitimmersion.com/
http://try.github.com/levels/1/challenges/1


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"

    파일 수정후 add, 다시 파일 수정후, commit 을 하면, 
    2번째 수정 사항은 staging안된 상태이다. 
    커밋을 해도 2번째 수정 사항은 저장안됨. 
    이때는 2번째 수정 사항에 대한 add 도 수행하고 그것에 대한 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


* 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. 
 
    Choose to rebase when you want to stay in sync with the main branch
    when you’re working on a long-lived side branch.

    When to Rebase, When to Merge? 
        Don’t use rebase … 커밋 히스토리를 변경시키기 때문이다. 
        http://stackoverflow.com/questions/3357122/git-pull-vs-git-fetch-git-rebase
        
        If the branch is public and shared with others. 
        Rewriting publicly shared branches will tend to screw up other members of the team. 
        When the exact history of the commit branch is important (since rebase rewrites the commit history). 
        Given the above guidelines, I tend to use rebase for short-lived, local branches and 
        merge for branches in the public repository. 
        정확한 커밋 히스토리가 중요한 경우에는 리베이스 사용을 자제.


* 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 

    remote repository의 변경사항을 가져온다. 그런데 pull명령은 다음과 동일하다. 
    
    git fetch git merge origin/master

    즉 변경 내용을 가져온후, 로컬의 변경사항과 머지하는작업이 동시에 일어난다.


* stash 

    만약 local의 변경 사항을 임시로 저장했다가 나중에 다시 적용하고 싶다면 'git stash' 로 변경사항을 stash 한 다음, 
    'git stash apply' 명령을 pull 작업 이후에 실행해서 재 적용 시킨다. 
    
    
* cloning 

    원격 저장소에 있는것을 복제하기 위해서는 git clone을 사용한다.
    
    git clone git@github.com:jeremyko/sequential_write_using_thread_pool.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