git 강좌 > 기타강좌

• 목록

git 설치
https://git-scm.com/book/ko/v2

https://git-scm.com/downloads/guis : gui 클라이언트
https://git-scm.com/download/ : git 다운로드
https://taewow.tistory.com/13 : 설치설명
https://code-lab1.tistory.com/category/%EC%9B%B9%EA%B0%9C%EB%B0%9C/%5BGit%5D

1. 설치 확인
    > git config --list

    사용자 이름 / 이메일 등록시
    > git config --global user.name "사용자이름"
    > git config --global user.email "abc@abc.com"
    > git config --list
    
2. 프로젝트 만들기
    > mkdir git-test
    > cd git-test
    > git init <- .git 하위 디렉토리 생성됨
    > git add * <- 모든 파일을 add / git add *.php 특정파일만 add
    > git commit -m "git-test"  <- 저장소에 파일 추가 커밋한다.

3. clone
    > git clone <url>
    ex)
    git clone https://github.com/test/test-project.git <- test-project 프로젝트를 clone. 저장소의 가장 최신 데이타를 모두 가져온다.

4. git 파일의 상태
    Commited : 데이터가 로컬 데이터베이스에 안전하게 저장됨
                Git Directory는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳으로 Git의 핵심이다.
                다른 컴퓨터에 있는 저장소를 Clone 할 때 이 Git 디렉터리가 만들어진다.
               
    Modified : 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 상태
                Working Directory는 프로젝트의 특정 버전을 Checkout한 것이다.
                쉽게 말하면 내가 작업하고 있는 프로젝트의 디렉터리를 뜻한다.
                Git Directory는 지금 작업하는 디스크에 있고 그 디렉터리 안에 압축된 데이터베이스에서 파일을 가져와
                Working Directory를 만든다.   
               
    Staged : 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태
                Staging Area는 Git Directory에 있으며 곧 커밋할 파일에 대한 정보를 저장하는 곳이다.
               
    =========================================
                -----------------
                Working Directory
                -----------------
    1.git add
                -----------------
                Staging Area
                -----------------
                                    2.git commit
                -----------------
                Repository
                -----------------
               
    1. Working Directory에서 파일을 수정한다. 수정한 파일을 git add를 통해 Staging Area에 올린다.
    2. Staging Area에 파일을 Stage 해서 커밋할 스냅샷(Snapshot)을 만든다. 모든 파일 혹은 일정 파일을 선택하여 추가할 수 있다.
    3. Staging Area에 있는 파일들을 commit 해서 Git Directory(Repository)에 영구적인 스냅샷으로 저장한다.

    Git 디렉토리에 있는 파일들은 Committed 상태다. 파일을 수정하고 Staging Area에 추가했다면 Staged 상태이다.
    만약 Checkout 한 뒤 수정했지만, 아직 Staging Area에 추가하지 않았다면 Modified 상태이다.
    =========================================
    =========================================
    https://code-lab1.tistory.com/252 사이트 참고
    ---------------------------------------------------------
    Untracked        Unmodified        Modified        Staged
    
            1. add file
                            2. edit file
                                            3. stage file
                        4. commit            4. commit
            5. remove file
    ---------------------------------------------------------       
    파일의 관점에서 보면 파일은 4가지 단계로 나뉜다.

    Untracked : Git으로 버전 관리를 하지 않는 상태. 파일을 추적 관리하지 않는 상태
    Unmodified : git add로 파일이 Staging Area에 올라갔지만 파일에 변경은 없는 상태.
                    Git은 이 파일을 추적 관리한다.
    Modified : 추적 관리하던 파일이 수정된 상태
    Staged : Staging Area에서 file이 staged 되어 반영된 상태.
    =========================================

5. 파일상태
    > git status    <- 파일상태 확인
    > vi test.php
    > git status
        Untracked file로 분류된다. 해당 파일이 Untracked 상태라는 뜻이다.
        Git 은 Tracked 상태의 파일만 Commit하게 된다.
    
    > git status - s <- 현재상태를 짧게 보여준다.
    
    
    > git add test.php
    > git status
        "Changes to be committed"는 커밋할 수 있는 상태,
        즉 Staged 상태라는 뜻이다.
        이 상태로 커밋하게 되면 git add를 실행한 시점의 파일이 커밋되고 저장소 히스토리에 남는다.
        git add 명령은 파일 또는 디렉터리의 경로를 인자로 받는다.
        특히, 디렉터리의 경우 그 아래의 모든 파일들까지 추가한다.

    파일 무시
        git 관리가 필요없는 파일 설정하기 => 대상:로그파일, 빌드시스템이 자동으로 생성한 파일 등등
        이런 파일 무시하기
        .gitignore 파일 생성
        -------------------------
            *.[oa]    #확장자가 .o .a 인 파일 무시
            *~        # ~로 끝나는 모든 파일 무시
            *.a        # 확장자가 .a인 파일 무시
            !lib.a    # 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
            /TODO    # 현재 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않음
            build/    # build/ 디렉토리에 있는 모든 파일은 무시
            doc/*.txt    # doc/notes.txt 파일은 무시하고 doc/server/arch.txt 파일은 무시하지 않음
            doc/**/*.pdf    # doc 디렉토리 아래의 모든 .pdf 파일을 무시
        -------------------------   
            .gitignore 파일에 입력하는 패턴은 아래 규칙을 따른다.
                아무것도 없는 라인이나, # 로 시작하는 라인은 무시한다.
                표준 Glob 패턴을 사용한다. 이는 프로젝트 전체에 적용된다.
                슬래시(/)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다.
                디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.
                느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.

    > git diff            <- git diff 명령을 실행하면 수정했지만 아직 staged 상태가 아닌 파일을 비교해 볼 수 있다.
    > git diff -staged    <- 저장소에 커밋한 것과 Staging Area에 있는 것을 비교한다.
    
    파일명 변경하기
        > git mv 파일명 새파일명
        이름을 변경하고 나서는 꼭 rm/add 명령을 실행해야 한다
       
        아래는 동일한 명령을 수행한다.
        -------------------------------------
        > git mv aa.txt new-a.txt
        > git status
        -------------------------------------
        > mv aa.txt new-a.txt
        > git rm aa.txt
        > git add new-a.txt
        > git status
        -------------------------------------
       
    
6. commit
    > git commit
    자동으로 생성되는 커밋세세지의 첫라인은 비어 있는데,
    여기에 커밋메세지를 기록한다.
    
    > git commint -m "커밋메세지"
    커밋 에디터없이 바로 커밋메세지를 작성하고, commit 시킨다.
    
    > git commit -a -m "커밋메세지"
    모든파일이 자동으로 커밋시킨다.
    git add 명령을 실행안해도 되지만,
    추가하지 말아야할 파일도 추가되므로 주의가 필요함.
    
7. 파일제거
    git 에서 파일제거시 git rm 사용한다.
    실제파일도 삭제하므로 주의 필요
    
    > del 파일
    > git status <- git 에서 에러
    > git rm 파일 <- git 에서 삭제
    > git commit -m "삭제메제시" <- 실제파일, git 모두 삭제
    
    > git rm 파일
    > git commit -m "삭제메세지"
    
    > git rm log/\*.log <- log/*.log 파일을 모두 삭제
    > git rm \*~ <- ~로 끝나는 파일 삭제
    
    
8. 깃 브랜치 Git Branch
    A라는 코드를 B로 바꾸거나, C형태로 바꿔보면서 코드를 수정
    이렇게 독립적으로 개발하는 것이 브랜치의 기본개념
    
    브랜치는 말 그대로 가지이다.
    하나의 코드에서 여러개의 코드로 갈라지며 다양한 개발흐름을 만들어 낼 수 있다.
    
    기본적으로 깃은 master 브랜치를 만든다.
    처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다.
    이후 커밋을 만들면 master 브랜치는 자동으로 가장 마지막 커밋을 가린킨다.
    
    HEAD 가 현재 브랜치 위치를 말한다.
    
    새로운 브랜치 만들기
    > git branch testing          <- 새브랜치 만들기
    > git checkout testing         <- 해당 브랜치로 이동하기
    
    > git log --oneline         <- branch, commit 내용확인
    > git log --decorate         <- commit 한 상세내용 확인
    > git log --oneline --decorate --graph --all  <- 브랜치, commit 히스토리 보기
    
9. 히스토리 조회
    > git log
    
    > git log -p -2
        -p --patch : 각 커밋의 diff 결과를 보여준다.
        -2 : 최근 두개의 결과만 보여준다.
    
    > git log --stat
        각 커밋의 통계 정보를 조회
    
    > git log --pretty=oneline
        각 커밋을 한라인으로 보기
    
    > git log --pretty=format:"%h - %an, %ar : %s"
        나만의 포맷으로 결과를 출력하고 싶을 때 사용
        %H 커밋 해시
        %h 짧은 길이 커밋 해시
        %T 트리 해시
        %t 짧은 길이 트리 해시
        %P 부모 해시
        %p 짧은 길이 부모 해시
        %an 저자 이름
        %ae 저자 메일
        %ad 저자 시각 (형식은 –-date=옵션 참고)
        %ar 저자 상대적 시각
        %cn 커미터 이름
        %ce 커미터 메일
        %cd 커미터 시각
        %cr 커미터 상대적 시각
        %s 요약

    > git log --pretty=format:"%h %s" --graph
        브랜치와 머지 히스토리를 보여주는 아스키 그래프를 출력
       
        git log 주요 옵션
            -p                 각 커밋에 적용된 패치를 보여준다.
            --stat             각 커밋에서 수정된 파일의 통계정보를 보여준다.
            --shortstat     --stat 명령의 결과 중에서 수정한 파일, 추가된 라인, 삭제된 라인만 보여준다.
            --name-only     커밋 정보중에서 수정된 파일의 목록만 보여준다.
            --name-status     수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것인지도 보여준다.
            --abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.
            --relative-date 정확한 시간을 보여주는 것이 아니라 “2 weeks ago” 처럼 상대적인 형식으로 보여준다.
            --graph         브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다.
            --pretty         지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format은 원하는 형식으로 출력하고자 할 때 사용한다.
            --oneline        --pretty=oneline --abbrev-commit 두 옵션을 함께 사용한 것과 같다.       
       
        git log 조회 범위를 제한하는 옵션 옵션     설명
            -(n)         최근 n 개의 커밋만 조회한다.
            --since, --after    명시한 날짜 이후의 커밋만 검색한다.
            --until, --before    명시한 날짜 이전의 커밋만 조회한다.
            --author    입력한 저자의 커밋만 보여준다.
            --committer 입력한 커미터의 커밋만 보여준다.
            --grep        커밋 메시지 안의 텍스트를 검색한다.
            -S            커밋 변경(추가/삭제) 내용 안의 텍스트를 검색한다.
           
10. 되돌리기
    종종 완료한 커밋을 수정해야 할 때가 있다.
    너무 일찍 커밋했거나 어떤 파일을 빼먹었을 때 그리고 커밋 메시지를 잘못 적었을 때 한다.
    다시 커밋하고 싶으면 파일 수정 작업을 하고 Staging Area에 추가한 다음
    --amend 옵션을 사용하여 커밋을 재작성 할 수 있다.
    
    > git commit --amend
    Staging Area를 사용하여 커밋한다.
    만약 마지막으로 커밋하고 나서 수정한 것이 없다면(커밋하자마자 바로 이 명령을 실행하는 경우)
    조금 전에 한 커밋과 모든 것이 같다. 이때는 커밋 메시지만 수정한다.
    
    
    커밋을 했는데 Stage 하는 것을 깜빡하고 빠트린 파일이 있으면 아래와 같이 고칠 수 있다.
    > git commit -m 'initial commit'
    > git add forgotten_file
    > git commit --amend
    여기서 실행한 명령어 3개는 모두 커밋 한 개로 기록된다. 두 번째 커밋은 첫 번째 커밋을 덮어쓴다.
    
11. 리모트 저장소 확인
    > git clone https://github.com/schacon/ticgit
    > cd ticgit
    > git remote
    > git remote -v
    
    새 리모트 저장소 추가히기
        > git remote add <단축이름> <url>
        > git remote add pb https://github.com/paulboone/ticgit
        > git remote -v
        이제 URL 대신에 pb 라는 이름을 사용할 수 있다.
        예를 들어 로컬 저장소에는 없지만 Paul의 저장소에 있는 것을 가져오려면 아래과 같이 실행한다.
        > git fetch pb

    리모트 저장소에 push 하기
        > git push <리모트저장소> <브랜치이름>
        > git push origin master
        master 브랜치를 origin 서버에 Push 한다. (Clone 하면 보통 자동으로 origin 이름이 생성된다)
       
    리모트 저장소 살펴보기
        리모트 저장소의 URL과 추적하는 브랜치를 출력한다.
       
        > git remote show <리모트 저장소 이름>
        > git remote show origin
       
        이 명령은 git pull 명령을 실행할 때 master 브랜치와 Merge 할 브랜치가 무엇인지 보여 준다.
        git pull 명령은 리모트 저장소 브랜치의 데이터를 모두 가져오고 나서 자동으로 Merge 할 것이다.
        그리고 가져온 모든 리모트 저장소 정보도 출력한다
       
    리모트 저장소 이름을 바꾸기
        git remote rename 명령으로 리모트 저장소의 이름을 변경할 수 있다.
        예를 들어 pb 를 paul 로 변경하려면 git remote rename 명령을 사용한다.
       
        > git remote rename pb paul
        > git remote
       
    리모트 저장소 삭제
        > git remote remove paul
        > git remote rm paul
        > git remote