이클립스로 GIT 사용하기
Download as PPTX, PDF64 likes31,181 views
이클립스로 git을 사용하는 방법, 그리고 그것으로 브랜치 전략을 진행하는 방법에 대해 설명 합니다.
이클립스로 GIT 사용하기
- 1. doGit.pragmatic({ eclipse : egit, gitCore : commands }); 프로젝트에서 Egit과 git command로 깃 실용적으로 사용하기.
- 2. 기본지식
- 3. 기본지식 버전관리시스템 (Version control system, VCS)
- 4. 기본지식 * 중앙집중형 버전관리 (CentrailzedVCS) * 분산 버전관리 (DistributedVCS)
- 5. 기본지식 사용자가 변경한 모든 내용을 추적하는 공간 * 저장소 (Repository)
- 6. 기본지식 모든 변경이 이루어지는 공간, 저장소를 바라보는 자신의 현재 시점 * 작업트리 (Working Tree)
- 7. GIT
- 8. 사용하는 프로그램 이클립스 이클립스::Egit 플러그인 이클립스::Terminal 플러그인 Git
- 9. GIT 지역저장소에 변경사항을 적용하기 위해 새로운 리비전을 추가하고 무엇을 변경했는지 설명하는 로그메시지 까지 저장하는 기능 * 커밋 (Commit)
- 10. GIT 상위저장소(upstream repository)에 변경사항을 적용하는 기능, 상위저장소는 원격저장소라고 부른다. * 푸쉬 (Push)
- 11. GIT 중앙집중식의 checkout와는 다른 동작을 보여준다. 풀링은 두 단계를 거친다. 상위저장소의 변경사항을 복사하고, 변경이력을 지역저장소와 병합한다. *풀 (Pull) ! Fetch fetch는 pull과는 다르다. 원격저장소의 변경사항과 지역 저장소의 이력과 병합하기 전 까지만 하는 단계를 말한다.
- 12. GIT 브랜치 이력을 하나로 합친다. * 병합 (Merge)
- 13. GIT 저장소 이력의 특정위치를 기록하는 기능, 책갈피 * 태그 (Tag)
- 14. GIT Commit객체를 가리키는 포인터, 하나의 단위 * 브랜치 (Branch)
- 15. GIT 가장 최신의 리비전을 가리키는 포인터 * 헤드 (HEAD)
- 16. GIT의 디렉토리
- 17. GIT의 디렉토리 깃 저장소를 생성하면 생성되는 .git의 구조
- 18. GIT의 디렉토리 HEAD포인터는 파일로 존재한다.
- 19. GIT의 디렉토리 헤더정보를 포함하여 zlib 로 압축하여 저장 모든파일은 SHA방식의 해시로 표현된다.
- 20. GIT의 디렉토리 원격저장소의 정보도 역시 파일로 저장된다.
- 21. GIT전략
- 22. 브랜치 사용 실험적인 변경사항 성능이 향상되는지 알아보기 위해 알고리즘을 다시 작성하거나 코드의 일부를 특정 패턴으로 리팩토링 하려 할때 브랜치를 생성하여 작업
- 23. 브랜치 사용 새로운 기능 새로운 기능을 추가할때마다 브랜치를 생성한다. 작업이 끝나면 브랜치를 합쳐야한다. 이때 브랜치의 전체 변경이력을 가져오거나 이력을 하나의 커밋으로 합칠 수 있다.
- 24. 브랜치 사용 버그수정 아직 릴리즈 하지 않은 코드의 버그거나 릴리즈 하려고 태그를 붙힌 코드의 버그에 상관없이 버그와 관련된 변경사항을 추적할 수 있도록 브랜치를 생성한다. 새로운 기능을 추가하는 브랜치와 마찬가지로 수정한 부분을 기존의 코드에 반영할 때 매우 유연해진다.
- 25. 브랜치 머지의 종류 바로합치기(straight merge) 하나의 브랜치와 다른 브랜치의 변경 이력 전체를 합친다.
- 26. 브랜치 머지의 종류 커밋합치기(squashed commit) 브랜치의 이력을 압축하여 다른 브랜치의 최신 커밋 하나로 합친다.
- 27. 브랜치 머지의 종류 선택합치기(sherry picking) 다른 브랜치에서 하나의 커밋을 가져와 현재 브랜치에 적용한다.
- 28. 릴리즈 브랜치 • 릴리즈 브랜치는 프로젝트에서 이번 릴리즈에 포함하기로한 기능 구현이 끝나면 생성한다. • 릴리즈 브랜치에서는 최소한의 변경만 발생하며, 버그나 로직의 수정에만 집중할 뿐 새로운 기능을 추가하지 않는다. • 일반적으로 릴리즈브랜치에는 RB_라는 접두어를 붙히며, 그뒤에 릴리즈 번호를 붙힌다.
- 29. 릴리즈 브랜치 • 릴리즈브랜치는 해당 릴리즈가 요구하는 마지막 테스트까지 통과하는 짧은 기간 동안만 존재한다. • 릴리즈준비가 완료되면, 해당 릴리즈를 표시하는 태그를 붙히고 브랜치를 삭제한다. • 태그가 해당 위치를 표시하고 있으므로 이력을 유지하기 위해 브랜치를 유지할 필요가 없다.
- 30. 태그사용 프로젝트가 진행되면 마일스톤을 달성하게된다. 태그를 사용하면 마일스톤을 쉽게 표시할 수 있고 추후 원하는 마일스톤으로 돌아갈 수 있다. 태그는 포인터이며 저장소의 책갈피처럼 동작한다.
- 31. GIT시나리오 기능추가
- 32. GIT전략 시나리오 - 기능추가 1. 브랜치 확인 터미널을 연다.
- 33. GIT전략 시나리오 - 기능추가 1. 브랜치 확인 Git branch명령어로 브랜치를 확인한다.
- 34. GIT전략 시나리오 - 기능추가 1. 브랜치 확인 MASTER
- 35. GIT전략 시나리오 - 기능추가 2. 브랜치 생성 New branch를 클릭한다.
- 36. GIT전략 시나리오 - 기능추가 2. 브랜치 생성 Subs 라는 브랜치를 생성한다.
- 37. GIT전략 시나리오 - 기능추가 2. 브랜치 생성 포인터를 확인한다.
- 38. GIT전략 시나리오 - 기능추가 2. 브랜치 생성 SUBS MASTER
- 39. GIT전략 시나리오 - 기능추가 3. 파일추가 후 커밋 파일을 추가한다.
- 40. GIT전략 시나리오 - 기능추가 3. 파일추가 후 커밋 TEST1.PHP파일 을 추가해 본다.
- 41. GIT전략 시나리오 - 기능추가 3. 파일추가 후 커밋 파일 추가가 다되었으면 커밋한다.
- 42. GIT전략 시나리오 - 기능추가 3. 파일추가 후 커밋 파일 추가가 다되었으면 커밋한다.
- 43. GIT전략 시나리오 - 기능추가 3. 파일추가 후 커밋 커밋 리스트를 확인해보기 위해 hisyory를 켠다.
- 44. GIT전략 시나리오 - 기능추가 3. 파일추가 후 커밋 커밋리스트가 3개 추가된 것을 확인한다.
- 45. GIT전략 시나리오 - 기능추가 3. 파일추가 후 커밋 SUBS MASTER
- 46. GIT전략 시나리오 - 기능추가 4. 커밋합치기 Master 브랜치로 포인터 이동
- 47. GIT전략 시나리오 - 기능추가 4. 커밋합치기 Squash 전달인자로 subs브랜치로부터 병합을 진행한다.
- 48. GIT전략 시나리오 - 기능추가 4. 커밋합치기 Subs 브랜치에 있는 커밋이 스테이징 되었지만 커밋은 되지 않은 상태이므로 커밋을 진행한다.
- 49. GIT전략 시나리오 - 기능추가 4. 커밋합치기 Subs 브랜치에 있는 커밋이 스테이징 되었지만 커밋은 되지 않은 상태이므로 커밋을 진행한다.
- 50. GIT전략 시나리오 - 기능추가 4. 커밋합치기 커밋이력을 확인해본다.
- 51. GIT전략 시나리오 - 기능추가 4. 파일추가 후 커밋 SUBS MASTER
- 52. GIT전략 시나리오 - 기능추가 5. 기능추가브랜치 삭제 이클립스의 브랜치 삭제 기능을 이용한다.
- 53. GIT전략 시나리오 - 기능추가 5. 기능추가브랜치 삭제 삭제한다.
- 54. GIT전략 시나리오 – 기능추가(완) 5. 기능추가 브랜치 삭제 MASTER
- 55. GIT시나리오 버그수정
- 56. GIT전략 시나리오 - 버그수정 1. 브랜치 확인 터미널을 연다.
- 57. GIT전략 시나리오 - 버그수정 1. 브랜치 확인 Git branch명령어로 브랜치를 확인한다.
- 58. GIT전략 시나리오 - 버그수정 1. 브랜치 확인 MASTER
- 59. GIT전략 시나리오 - 버그수정 2. 브랜치 생성 New branch를 클릭한다.
- 60. GIT전략 시나리오 - 버그수정 2. 브랜치 생성 Subs 라는 브랜치를 생성한다.
- 61. GIT전략 시나리오 - 버그수정 2. 브랜치 생성 포인터를 확인한다.
- 62. GIT전략 시나리오 - 버그수정 2. 브랜치 생성 SUBS MASTER
- 63. GIT전략 시나리오 - 버그수정 3. 파일수정 TEST1.php 파일을 열어 echo hello문구를 추가하여 파일 수정을 한다.
- 64. GIT전략 시나리오 - 버그수정 3. 파일수정 커밋을 진행한다.
- 65. GIT전략 시나리오 - 버그수정 3. 파일수정 커밋을 진행한다.
- 66. GIT전략 시나리오 - 버그수정 3. 파일수정 커밋이력을 확인한다.
- 67. GIT전략 시나리오 - 기능추가 3. 버그수정 SUBS MASTER
- 68. GIT전략 시나리오 - 버그수정 4. 선택합치기 버그수정 이력중에서 몇몇 가지만 적용하고 싶을지도 모른다. 많은 버그수정 이력중 검증받은 버그수정은 1개밖에 없을지도 모르기 때문이다. 여기서는 로그인 버그수정 완료 라는 이력만 선택하여 병합시키겠다.
- 69. GIT전략 시나리오 - 버그수정 4. 선택합치기 커밋하려는 버그수정한 커밋이력의 id를 기억한다.
- 70. GIT전략 시나리오 - 버그수정 4. 선택합치기 Master 브랜치로 포인터 이동
- 71. GIT전략 시나리오 - 버그수정 4. 선택합치기 커밋이력 고유id를 활용하여 master에 선택병합 이 된 것을 확인할 수 있다.
- 72. GIT전략 시나리오 - 버그수정 4. 선택합치기 커밋이력 고유id를 활용하여 master에 선택병합 이 된 것을 확인할 수 있다.
- 73. GIT전략 시나리오 - 버그수정 4. 선택합치기 SUBS MASTER
- 74. GIT시나리오 릴리즈브랜치
- 75. GIT전략 시나리오 - 릴리즈브랜치 1. 브랜치 확인 터미널을 연다.
- 76. GIT전략 시나리오 - 릴리즈브랜치 1. 브랜치 확인 Git branch명령어로 브랜치를 확인한다.
- 77. GIT전략 시나리오 - 릴리즈브랜치 1. 브랜치 확인 MASTER
- 78. GIT전략 시나리오 - 릴리즈브랜치 2. 릴리즈 시점에서 태그 Egit태그기능으로 태그 한다.
- 79. GIT전략 시나리오 - 릴리즈브랜치 2. 릴리즈 시점에서 태그 태그명을 입력한후 Ok를 클릭한다.
- 80. GIT전략 시나리오 - 릴리즈브랜치 2. 릴리즈 시점에서 태그 이력을 확인하여 정원하는 시점에 태그가 생성되는지 확인한다.
- 81. GIT전략 시나리오 - 릴리즈브랜치 2. 릴리즈 시점에서 태그 MASTER
- 82. GIT전략 시나리오 - 릴리즈브랜치 3. 태그로부터 브랜치 터미널을 이용하여 태그로 포인터를 옮긴다.
- 83. GIT전략 시나리오 - 릴리즈브랜치 3. 태그로부터 브랜치 태그는 하나의 포인터로 브랜치가 아니므로 읽기만 가능하다. No branch로써 설명해주고 있다. 따라서 현재 시점에서 브랜치를 빼내어야 한다.
- 84. GIT전략 시나리오 - 릴리즈브랜치 3. 태그로부터 브랜치 -b 전달인자로 포인터가 가리킨 태그를 기준으로 브랜치를 생성한다.
- 85. GIT전략 시나리오 - 릴리즈브랜치 3. 태그로부터 브랜치 그리고 원격저장소에 push한다.
- 86. GIT전략 시나리오 - 릴리즈브랜치 3. 태그로부터 브랜치 RB_0.1 MASTER
- 87. GIT전략 시나리오 - 릴리즈브랜치 4. 릴리즈브랜치에서 버그수정 릴리즈 브랜치에서는 최소한의 변경만 해야한다. 버그나 로직의 수정에만 집중할 뿐 새로운 기능을 추가하지 않는다.
- 88. GIT전략 시나리오 - 릴리즈브랜치 4. 릴리즈브랜치에서 버그수정 RB_0.1 MASTER
- 89. GIT전략 시나리오 - 릴리즈브랜치 5. 기능추가 릴리즈 브랜치에서는 기능추가를 하지 않는다. 기능추가시 또 다른브랜치를 생성하여 기능추가하고 마스터브랜치에만 병합하거나 필요시 릴리즈브랜치에도 병합한다.
- 90. GIT전략 시나리오 - 릴리즈브랜치 5. 기능추가 RB_0.1 MASTER SUBS
- 91. GIT전략 시나리오 - 릴리즈브랜치 6. 버전업 릴리즈 Master브랜치의 일정수준 기능이 구현되면 또다른 버전이 배포될 것이다. 그 시점에서 새로운 태그를 생성하고 브랜치를 생성한다.
- 92. GIT전략 시나리오 - 릴리즈브랜치 6. 버전업 릴리즈 RB_0.1 RB_0.2 MASTER SUBS
- 93. GIT전략 시나리오 - 릴리즈브랜치 7. 구 릴리즈브랜치 삭제 새로운 릴리즈브랜치가 적용되었다면 구 릴리즈의 이력은 태그가 위치를 표시하고 있으므로 이력을 유지하기 위해 브랜치를 유지할 필요가 없다. 따라서 구 릴리즈브랜치를 삭제한다.
- 94. GIT전략 시나리오 - 릴리즈브랜치 7. 구 릴리즈브랜치 삭제 커맨드를 이용해도 되고, egit을 이용해도 된다. 브랜치는 삭제되었다.
- 95. GIT전략 시나리오 - 릴리즈브랜치 7. 구 릴리즈브랜치 삭제 원격저장소의 브랜치도 삭제한다. 스샷은 0.2로 되어있음
- 96. GIT전략 시나리오 - 릴리즈브랜치 6. 버전업 릴리즈 RB_0.2 MASTER
- 97. 기타
- 98. 참고하면 좋은 사이트 http://wiki.redgolems.com/03.server:git:01.git에_대하여 http://www.slideshare.net/ajaxiankr/ 2011-kth-h3-track-b-4-advanced-git-by-aj http://blog.outsider.ne.kr/572
- 99. PPT작성자 Redgolems – UYEONG uyeong21c@gmail.com
- 100. 감사합니다.
Editor's Notes
- #4: 사용자 프로젝트에 포함된 파일의 변경사항을 추적할 수 있도록 돕는 방법론이나 도구를 말합니다.
- #5: 중앙집중형 버전관리는원격저장소가 존재하고, 그 저장소만을 활용 한다. 로그를 추적할 수 있꼬 트렁크, 브랜치, 태그등으로 소스를 관리한다.분산버전관리 시스템위와 같은 점에서 기존 버전관리시스템과 차이가 없다. 단, 버전관리 시스템과 분산 버전관리 시스템은 개발자들 간의 변경사항을 반영하고 공유하는 방식이 다르다.
- #6: 코드의 상태변경이 언제발생했는지, 누가했는지 변경사항을 설명하는 로그메시지와 함께 저장되고 관리되는 공간이다.대표적으로 서브버전의 저장소는 중앙집중식 저장소 모델을 따른다.하나의 중앙저장소가 있고 모두가 이 중앙 저장소에 변경사항을 전송한다. 각 개발자는 저장소의 최신버전을 “복사”해서 가지고 있고이 복사본을 변경한 후에는 변경된 부분을 다시 중앙 저장소에 전송한다. 이러한 중앙저장소는 한계가 있다.변경이력을 보기위해 중앙저장소에 접근해야한다네트워크의 한계가 있다.인터넷에 연결할 수 없다면 git이 따르는 분산버전관리 시스템의 가장 큰 장점중 하나를 부각시킨다.
- #7: 모든 변경은 작업트리에서 이루어 진다. 작업트리란 저장소를 바라보는 자신의 현재 시점을 말한다. 이 작업트리는 소스코드, 빌드파일, 단위테스트등 프로젝트의 모든 파일을 가지고 있다. 몇몇 버전관리시스템에서는 작업트리를 작업복사본(working copy)라 한다.Git에서 작업트리는 로컬컴퓨터의 프로젝트디렉토리에 있는 .git 디렉토리에 존재한다.이 작업트리로 인해 저장소의 이력, 변경사항등을 원격저장와 통신업이 볼 수 있다.