커밋로그 보기 전달인자 -1, -2,를 주어 출력수를 제한 할 수 있습니다. 전달인자 -p를 사용하여 변경된 내용을 같이 볼 수 있습니다. 전달인자 –graph를 사용하여 브랜치 트리를 볼 수 있습니다. git log 커밋로그 날짜범위 지정 전달인자 –since를 사용하여 원하는 시간 동안의 커밋로그를 볼 수 있습니다. 전달인자 –before를 사용하여 일정시간을 제외한 나머지 커밋로그를 볼 수 있습니다. 시간 형식은 24 hours, 1 minute, 2012.01.10, 2012-11-10등을 사용 가능합니다. git log --since="5 hours" git log --before="5 hours" 커밋로그 리비전 범위 지정 1. 전달인자 format:”%h %s”를 추가하여 짧은 해쉬와 커밋로..

브랜치 목록 조회 전달인자 -r을 사용하여 원격브랜치 조회 합니다. git branch *master 브랜치명 변경 전달인자 m은 이동을 의미 합니다. git branch -m master mymaster git branch *mybranch 브랜치명 강제 변경 브랜치명을 변경할때 이미 이름이 존재한다면 진행되지 않는데 -M의 명령어를 사용하면 덮어쓰기로 강제 진행됩니다. git branch -M master mymaster 새로운 브랜치 생성 git branch new git branch *master new 브랜치 체크아웃 git checkout new Switched to branch 'new' git branch master *new 새로운 브랜치 생성하고 체크아웃 git checkout -b 새..

태그를 이용하여 마일스톤 표시 프로젝트가 진행되면 마일스톤을 달성하게 됩니다. 마일스톤을 달성하면 릴리스를 배포하고, 새로운 버전을 생성하는 등의 작업을 합니다. 태그를 사용하면 마일스톤을 쉽게 표시할 수 있고 나중에 원하는 마일스톤으로 돌아갈 수 있습니다. 태그는 저장소의 책갈피처럼 동작합니다. 태그를 붙여두면 나중에 그 태그의 위치로 곧장 되돌아갈 수 있습니다. 필요하다면 커밋에도 태그를 붙일 수도 있습니다. 보통 태그는 프로젝트에서 코드를 릴리스할 때 가장 많이 사용한다 태그를 이용하면 릴리스한 후에도 버그 수정이나 변경이 필요할 경우 릴리스된 코드로 돌아갈 수 있습니다. git의 태그는 읽기 전용입니다. 읽기만 가능하다는 말은 브랜치와는 다르게 태그의 내용을 변경할 수 없음을 의미합니다. git에..

LOG활용하기 모든 버전관리 시스템에서 가장 중요한 부분은 이력입니다. 저장소 이력을 잘 사용하면 원하는 정보를 얻을 수 있습니다. 파일 자체의 로그를 확인 할 수도 있고 코드 수정이력도 조회할 수 있습니다. 또한 파일의 리비전에 대한 차이점을 볼 수도 있습니다. GIT 로그 살펴보기 저장소에 어떤 변화가 있었는지 알려고 한다면 일반적으로 커밋로그를 살펴봅니다. git은 각 커밋의 로그를 누가, 언제 커밋했는지 보여줍니다. git log commit 5e5c78f555d71936ab7af768e0020107d3489116 Author: uyeong21c Date: Sat Oct 27 16:52:52 2012 +0900 add the selecton of an about page : 화면 하단의 콜론(:)..

BRANCH활용하기 기본적으로 하나의 브랜치 즉 마스터브랜치(타:trunk)만 사용해도 버전관리 시스템이 제공하는 모든 이점을 얻을 수 있습니다. BRANCH란? 우리는 일반적으로 여러가지 작업을 번갈아 가며 진행합니다. 새로운 기능을 추가하거나 유지보수가 쉽도록 리팩터링할 수도 있고 이따금씩 발생하는 버그를 수정하기도 합니다. 어떠한 작업도 무시할 수 없으며 적절히 균형을 마추며 진행해야 합니다. 단방향 이력은 이러한 요구를 다루리가 쉽지 않습니다. 그래서 브랜치가 필요합니다. git에서는 모든 것이 브랜치로 간주되므로 브랜치를 생성하는 비용이 크지않습니다. 모든 파일을 새로운 디렉토리로 복사하는 다른 시스템들과는 다르게 git의 브랜치는 해당 브랜치가 만들어진 시점부터 적용된 커밋만 추적합니다. 최신..

GIT에 대하여 ... 버전관리시스템(version control system, VCS)는 사용자 프로젝트에 포함된 파일의 변경사항을 추적할 수 있도록 돕는 방법론이나 도구를 말합니다. 분산 버전관리 시스템(Distributed version control system, DVCS)도 위와 같은 점에서 기존 버전관리 시스템과 차이가 없습니다. 다만 버전관리 시스템과 분산 버전관리 시스템은 개발자들 간의 변경사항을 반영하고 공유하는 방식이 다르다고 보면 됩니다. 저장소(Repository) 버전관리 시스템에서 저장소(Repository)는 사용자가 변경한 모든 내용을 추적하는 특별한 공간입니다. 대부분의 버전관리 시스템은 코드의 현재상태는 물론이고 변경이 언제 발생했는지, 누가 변경했는지, 변경사항을 설명하..

Eclipse 에서 IntelliJ IDEA로 전환시에 불편한 점 중에 하나가 .gitignore 파일에 마우스 우클릭으로 커밋에 제외할 파일을 빠르게 추가하지 못하는 것이다. Eclipse에서는 파일 / 디렉토리를 마우스 오른쪽 버튼으로 클릭하고 ‘ .gitignore에 추가 ‘를 선택할 수 있다.하지만 당연히 IntelliJ IDEA에서 이와 같은 것이 있고 플러그인으로 제공한다.1. File -> Settings의 plugin으로 검색하여 거기서 또 ignore로 검색.(Ctrl + Alt + S 단축키 사용) search in repositories 클릭 후 검색하여 플러그인 설치.2. intellij를 재부팅 후 설치가 완료되면 gitignore 파일의 아이콘이 변함.gitignore 파일이 없..

백업해둔 프로젝트를 내 컴퓨터로 받아오거나 협업을 위해 새로운 개발자가 프로젝트를 로컬 저장소로 받아와야하는 경우가 있다. 이때 clone을 통해 로컬 저장소에 원격 저장소에 있는 프로젝트를 가져올 수 있다. STEP01.GitHub에 있는 가져올 원격 저장소에 접근하여 HTTPS 값을 복사한다. STEP02.SourceTree에서 왼쪽 하단의 "Add Repository"버튼을 누른다. STEP03."Clone Repository"탭에서 "Source Path/URL"에 복사해둔 HTTPS값을 붙여넣고 "Destination Path"에 받아온 프로젝트를 저장해둘 경로를 지정해준다. 마지막으로 "Bookmarks"에 SourceTree에 표시할 저장소의 이름을 지정해주고 "Clone"버튼을 누른다. S..

GitHub에 로컬 저장소의 프로젝트를 최초로 동기화한 이후 로컬 저장소 프로젝트에 변경 사항이 발생하여 수정을 하였다. 이 경우 다시 push를 통해 로컬 저장소와 원격 저장소를 동기화 해주어야 한다. STEP01.프로젝트의 소스코드를 수정하고 commit과정을 거친다. 위의 그림과 같이 새로운 버전이 생성이 되었다. 여기서 버전 목록을 보게 되면 최신 버전이 master 브랜치로 되어있고 그 바로 밑의 버전에 origin의 master 브랜치로 표시 되어있다. 이것은 아직 로컬 저장소와 원격 저장소를 동기화 하지않아 두 개의 저장소 사이에 하나의 버전이 차이난다는 것을 보여주는 것이다. 또한 상단의 "Push"버튼에 1이라는 숫자가 보이는데 이것 또한 로컬 저장소와 원격 저장소가 하나의 버전이 차이난..

앞서 GitHub를 통해 생성한 원격 저장소를 내 컴퓨터에 존재하는 로컬 저장소와 연결을 하였다. 이렇게 연결한 원격 저장소에 내 컴퓨터에서 작업하던 프로젝트를 백업 또는 협업하기 위해 프로젝트를 동기화할 수 있다. 이것을 push라 한다. STEP01.SourceTree에서 해당하는 로컬 저장소를 선택한 뒤 상단 메뉴의 "Push"버튼을 누른다. STEP02.상단의 선택 메뉴에서 프로젝트를 올리고자 하는 원격 리포지토리를 선택하고 (origin 또는 또 다른 원격 저장소) 다음으로 올리고자 하는 branch를 선택한다. 마지막으로 "OK"버튼을 누른다. STEP03.Username과 Password를 입력하라는 창이 나오면 자신의 GitHub 계정을 입력하면 된다. STEP04.push가 완료되면 아래..