Download as PDF, PPTX
![20 / GitHub 실습
사용자 정보설정
Windows는[Tools] - [Options]에서
Default user information을 설정합니다.
이곳에서 설정하면 별도로 설정하지 않은
모든 저장소에 이 설정이 사용됩니다.](https://image.slidesharecdn.com/20150318githubver-150318201738-conversion-gate01/75/GitHub-20-2048.jpg)
![21 / GitHub 실습
사용자 정보설정
[Repository]- [Repository Settings...] - [Advanced]에서
Use global user settings에 체크를 풀고 설정하면
해당 저장소에만 반영됩니다.](https://image.slidesharecdn.com/20150318githubver-150318201738-conversion-gate01/75/GitHub-21-2048.jpg)
![124 / GitHub 실습
충돌해결
충돌난 영역은
<<<<<<< HEAD
....
=======
....
>>>>>>> [머지한 브랜치]
로 표시됩니다.
내가 수정한 내용
머지한 브랜치에서 수정한 내용](https://image.slidesharecdn.com/20150318githubver-150318201738-conversion-gate01/75/GitHub-124-2048.jpg)
![166 / GitHub 실습
릴리즈 생성
릴리즈 페이지에서 [Tags] 탭을 선택한 후 지금 생성한 릴리즈
태그의 [Add release notes]를 클릭합니다.](https://image.slidesharecdn.com/20150318githubver-150318201738-conversion-gate01/75/GitHub-166-2048.jpg)
More Related Content
![[H3 2012] 오픈소스로 개발 실력 쌓기](https://cdn.slidesharecdn.com/ss_thumbnails/a6-121105215831-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유](https://cdn.slidesharecdn.com/ss_thumbnails/ndc2018-1-180430181759-thumbnail.jpg?width=640&height=640&fit=bounds)
![[201808] GitHub 사용하기 - GIt & 협업 활용](https://cdn.slidesharecdn.com/ss_thumbnails/201808github-gitandcollaboration-180825003942-thumbnail.jpg?width=640&height=640&fit=bounds)
![[프로그라피 정기 세션] Github으로 협업하기](https://cdn.slidesharecdn.com/ss_thumbnails/githubworkflow-190408071016-thumbnail.jpg?width=640&height=640&fit=bounds)
![[17.02.09] Github introduction (Korean Version)](https://cdn.slidesharecdn.com/ss_thumbnails/githubintroduction-170502020242-thumbnail.jpg?width=640&height=640&fit=bounds)
![[숭실대학교 SODA]깃(git) 명령 및 소스트리(sourceTree) 실습](https://cdn.slidesharecdn.com/ss_thumbnails/pdf-171116120939-thumbnail.jpg?width=640&height=640&fit=bounds)
![[D2 fest 2014]yobi hands on lab](https://cdn.slidesharecdn.com/ss_thumbnails/d2fest2014yobihandsonlab-140512021948-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
GitHub 실습 교육
- 1. GitHub 실습 v.1.4 신승엽 /유니원사업팀 2016년 1월 18일
- 2. 2 / GitHub실습 준비 SourceTree - http://www.sourcetreeapp.com/ 실습 파일 - http://flysky.kr/github-example.zip
- 3. 3 / GitHub실습 규칙 직접 실습합니다. 슬라이드의 내용에 집중합니다.
- 4.
- 5. 5 / GitHub실습 https://github.com GitHub
- 6. 6 / GitHub실습 - 원하는 아이디와 비밀번호 그리고 이메일을 입력한 후 회원가입 합니다. 회원가입
- 7. 7 / GitHub실습 - Free를 선택하고 계속 진행 회원가입
- 8. 8 / GitHub실습 가입 완료! 회원가입
- 9. 9 / GitHub실습 GitHub에 가입하세요. - 초기화면에서아이디, 이메일, 비밀번호 입력 - 플랜은 Free로 - 꼭! 이메일 입력 후 이메일 인증을 받으세요. (받지 않으면 계정 잠김) 회원가입
- 10.
- 11. 11 / GitHub실습 오른쪽 상단의 플러스 아이콘을 누른 후 New repository를선택하여 저장소를 생성할 수 있습니다. 저장소 생성
- 12. 12 / GitHub실습 저장소 이름을 작성합니다 체크합니다 저장소 생성
- 13. 13 / GitHub실습 저장소 생성
- 14. 14 / GitHub실습 저장소 생성 calculator 라는 이름의 저장소를 하나 생성하세요. - 오른쪽 상단의 + 표시에서 New Repository - 저장소 이름을 입력하고 README 생성에 체크
- 15. 15 / GitHub실습 저장소 복제 저장소 페이지의 클립보드 아이콘을 클 릭해서 주소를 복사합니다.
- 16. 16 / GitHub실습 저장소 복제 SourceTree의 도구모음에서 Clone을 클릭합니다. Windows MacOS X New Repository에서 Clone From URL을 클릭합니다.
- 17. 17 / GitHub실습 저장소 복제 저장소 주소 입력 후 탭키 Git 저장소라는 메시지 확인 Windows MacOS X 저장소 주소 입력 후 탭키 Git 저장소라는 메시지 확인
- 18. 18 / GitHub실습 저장소 복제 저장소가 복제된 것을 확인할 수 있습니다. Windows MacOS X
- 19. 19 / GitHub실습 저장소 복제 calculator 저장소를로컬로 복제하세요. - GitHub에서 저장소 주소 복사 - SourceTree에서저장소 복제
- 20. 20 / GitHub실습 사용자 정보설정 Windows는[Tools] - [Options]에서 Default user information을 설정합니다. 이곳에서 설정하면 별도로 설정하지 않은 모든 저장소에 이 설정이 사용됩니다.
- 21. 21 / GitHub실습 사용자 정보설정 [Repository]- [Repository Settings...] - [Advanced]에서 Use global user settings에 체크를 풀고 설정하면 해당 저장소에만 반영됩니다.
- 22. 22 / GitHub실습 사용자 정보설정 Mac에서는 UI를 통해 이름을 한글로 설정하면 Mac 이외의 OS에서는 이렇게 깨져 보이게 됩니다.
- 23. 23 / GitHub실습 사용자 정보설정 $ git config --global user.name 신승엽/협업시스템개발팀 $ git config --global user.email flysky@nhnent.com Mac에서 사용자 정보를 설정할 때는 터미널에서 아래 명령을 사용합니다. 생략하면 현재 저장소에만 적용
- 24. 24 / GitHub실습 사용자 정보설정 사용자 정보를 설정하세요. - Windows: 환경설정의Default user information수정 - Mac OS X: 터미널을 통해 명령어로 수정
- 25. 25 / GitHub실습 사용자 정보설정 Mac에서 명령어를 통해서 사용자 이름을 변경해도 설정 UI를 한 번 들어가면 다시 되돌아가는문제 https://github.com/flyskyko/git-hooks
- 26. 26 / GitHub실습 GitFlow 설정 도구모음에서 Git Flow를 클릭합니다. 기본값 그대로 OK를 클릭합니다.
- 27. 27 / GitHub실습 GitFlow 설정 develop 브랜치가 생성되고 체크아웃된 것을 확인할 수 있습니다. 이제 푸시합니다.
- 28. 28 / GitHub실습 GitFlow 설정 도구모음에서 Push를 클릭합니다. develop에 체크한 후 OK를 클릭합니다.
- 29. 29 / GitHub실습 GitFlow 설정 아이디와 비밀번호를 물어보면 GitHub 아이디와 비밀번호를 입력합니다.
- 30. 30 / GitHub실습 GitFlow 설정 GitHub의 저장소 페이지로 이동 한 후 Settings를 클릭합니다. Default branch를 develop으로 선택합니다.
- 31. 31 / GitHub실습 GitFlow 설정 Git Flow 설정을 하고 develop을 기본 브랜치로 설정하세요. - SourceTree의 Git Flow 버튼을 이용, 초기 설정 - develop 브랜치 푸시 - GitHub 설정 페이지에서develop을 기본 브랜치로
- 32. 32 / GitHub실습 파일수정과 상태변경 저장소가 복제된 폴더로 이동하여 README.md 파일을 수정해 봅시다. Windows MacOS X
- 33. 33 / GitHub실습 파일수정과 상태변경 파일 내용을 변경하였습니다.
- 34. 34 / GitHub실습 파일수정과 상태변경 SourceTree의 Working Copy 항목을 보면 README.md 파일이 Unstaged files에 추가되었고 오른쪽에서는 Diff를 확인할 수 있습니다.
- 35. 35 / GitHub실습 파일수정과 상태변경 Unstaged files에 있는 README.md 파일을 체크하면 Staged files로 추가됩니다. 이제 커밋을 위한 준비가 완료되었습니다.
- 36. 36 / GitHub실습 파일수정과 상태변경 그런데 아차! '기술교육'을 잊었네요. 파일을 다시 수정하였습니다.
- 37. 37 / GitHub실습 파일수정과 상태변경 README.md가 Unstaged/Stagedfiles 양쪽에 모두 있습니다.
- 38. 38 / GitHub실습 파일수정과 상태변경 Staged file을 수정하면 Staged 상태에서 수정된 Unstaged 상 태가 됩니다. 커밋을 위해서는 다시 체크하여 Staged 상태로 변경하여야 합 니다.
- 39. 39 / GitHub실습 파일수정과 상태변경
- 40. 40 / GitHub실습 파일수정과 상태변경 README.md 파일을 수정하여 커밋 준비를 하세요. - 한번 수정한 후 Unstage 상태가 되는 것을 확인하세요. - Stage 상태로 만드세요. - 다시 수정하여 Stage/Unstage 상태의 차이를 확인하세요. - 최종적으로 Stage 상태로 만들어 커밋 준비를 하세요.
- 41. 41 / GitHub실습 Commit
- 42. 42 / GitHub실습 Commit develop 브랜치에 커밋이 추가된 것을 확인할 수 있습니다.
- 43. 43 / GitHub실습 Commit develop 브랜치에 한번 더 커밋을 해보았습니다. Git은 원격 저장소와 연결되어 있지 않더라도 로컬에서 몇번이고 커밋을 추가할 수 있습니다. 이렇게 로컬에 추가된 커밋은 푸시를 통해 원격 저장소에 반영할 수 있습니다.
- 44. 44 / GitHub실습 Commit Working Copy의 변경사항을 커밋하세요. - 두번 이상 커밋해 보시기 바랍니다.
- 45. 45 / GitHub실습 Push 도구모음의 Push를 클릭합니다. 푸시할 브랜치를 선택한 후 OK를 클릭합니다.
- 46. 46 / GitHub실습 Push GitHub의 저장소 페이지를 새로고침해보면 우리가 작성한 커밋이 반영된 것을 확인할 수 있습니다.
- 47. 47 / GitHub실습 Push 로컬의 커밋을 원격 저장소로 푸시하세요.
- 48.
- 49. 49 / GitHub실습 개요 각 팀에서 하나의 저장소를 만들고 그곳에서 계산기 ver. 1.0을 릴리즈하는 과정을 따라해 보겠습니다. 조장을 결정해주세요.
- 50. 50 / GitHub실습 새로운 규칙 직접 실습합니다. 슬라이드의 내용에 집중합니다. 조장이 행동하고 조원이 지켜봅니다. 조원이 행동하고 조장이 지켜봅니다.
- 51. 51 / GitHub실습 협업자 추가 저장소는 앞서 생성한 조장의 저장소를 사용하도록 하겠습니다. 저장소 페이지의 상단 Settings를 클릭 왼쪽 메뉴에서 Collaborators를클릭
- 52. 52 / GitHub실습 협업자 추가 조원을 검색하여 추가해 줍니다. (아이디로 검색)
- 53. 53 / GitHub실습 협업자 추가
- 54. 54 / GitHub실습 협업자 추가 조원을 협업자로 추가합니다. - Settings - Collaborator - 아이디로 검색 후 추가
- 55. 55 / GitHub실습 저장소 복제 각 조원은 조장의 저장소를 복제한 후 Git Flow 설정까지 완료합니다. 이때 Git Flow 초기 설정은 develop과 master 브랜치가 모두 로컬에 있어야 가능합니다. Remotes origin의 master를 체크아웃 받습니다. (develop은 기본 브랜치이기 때문에 복제 시 체크아웃 됨)
- 56. 56 / GitHub실습 마일스톤 설정 저장소 페이지의상단에서 Issues 클릭 상단 탭에서 Milestones 클릭 오른쪽 상단의 New milestone클릭
- 57. 57 / GitHub실습 마일스톤 설정 이름 설명 기한
- 58. 58 / GitHub실습 마일스톤 설정 마일스톤 진행 상황을 확인할 수 있습니다.
- 59. 59 / GitHub실습 마일스톤 설정 계산기 ver.1.0 마일스톤을 추가합니다.
- 60. 60 / GitHub실습 라벨설정 저장소 페이지의 상단에서 Issues 클릭 탭에서 Labels 클릭
- 61. 61 / GitHub실습 라벨설정
- 62. 62 / GitHub실습 라벨설정 New label을 클릭 라벨 이름과 색상을 지정 가능합니다.
- 63. 63 / GitHub실습 라벨설정
- 64. 64 / GitHub실습 라벨설정 라벨의 구성을 자유롭게 변경하세요.
- 65. 65 / GitHub실습 이슈생성 저장소 페이지의 상단에서 Issues 클릭 오른쪽 상단의 New issue 클릭
- 66. 66 / GitHub실습 이슈생성
- 67. 67 / GitHub실습 이슈생성
- 68. 68 / GitHub실습 이슈생성
- 69. 69 / GitHub실습 이슈생성
- 70. 70 / GitHub실습 이슈생성
- 71. 71 / GitHub실습 이슈생성
- 72. 72 / GitHub실습 이슈논의 하단의 댓글 입력창을 통해 댓글을 남길 수 있습니다.
- 73. 73 / GitHub실습 이슈논의
- 74. 74 / GitHub실습 이슈논의
- 75. 75 / GitHub실습 이슈 앞장과 같이 이슈를 등록하고 댓글을 통해 의견을 나누어 봅니 다. - 이슈에 담당자, 라벨, 마일스톤 등을 지정해보세요. - 댓글을 통해 의견을 교환하세요.
- 76. 76 / GitHub실습 기능개발 #1스켈레톤 작성 이슈를 개발해 봅시다. #1 이슈 담당자는 이슈의 라벨을 적절하게 변경합니다.
- 77. 77 / GitHub실습 기능개발 도구모음에서 Git Flow를 클릭합니다. Start New Feature를 클릭합니다.
- 78. 78 / GitHub실습 기능개발 Feature Name은 이슈번호와 간략한 설명으로 정합니다.
- 79. 79 / GitHub실습 기능개발 feature/iss1-create-skeleton브랜치가 생성되고 checkout된 것을 확인할 수 있습니다.
- 80. 80 / GitHub실습 기능개발 main.c를 생성합니다.
- 81. 81 / GitHub실습 기능개발 'fixed #1'을 포함하여 커밋 로그를 작성하고 Commit합니다.
- 82. 82 / GitHub실습 기능개발 푸시할 브랜치를 선택한 후 푸시합니다.
- 83. 83 / GitHub실습 기능개발 GitHub의 #1 이슈 페이지를 확인하면 b2ade71커밋이 #1 이슈와 연결된 것을 확인할 수 있습니다.
- 84. 84 / GitHub실습 기능개발 fixed 라고 적어 주었기 때문에 b2ade71커밋이 기본 브랜치인 develop 브랜치와 머지될 때 이슈가 자동으로 닫힙니다.
- 85. 85 / GitHub실습 기능개발 #1 이슈를 해결하세요. - Git Flow 버튼을 통해 새 Feature를 시작합니다. - 실습 파일의 main-1.c 파일 내용을 복사해서 main.c로 저장 합니다. - 커밋 로그에 'fixed #1'을 포함하여 커밋합니다. - Feature 브랜치를 푸시합니다.
- 86. 86 / GitHub실습 Pull Request 기능 개발이 완료된 후에는 Git Flow의 Finish Feature를 이용하여 기능 브랜치를 develop으로머지할 수도 있습니다.
- 87. 87 / GitHub실습 Pull Request 하지만 이렇게 하지 않고 GitHub에서 Pull Request를 생성하는 방법을 알아봅니다. 이런 방식을 GitHub Flow라고 부릅니다. 본 교육에서는 Git Flow와 GitHub Flow를 조합한 workflow를 안내 합니다.
- 88. 88 / GitHub실습 Pull Request 저장소 페이지의 상단 Pull Requests 클릭 오른쪽 상단의 New pull request 클릭
- 89. 89 / GitHub실습 Pull Request compare에서 base로 머지하는 풀리퀘스트를 만듭니다. 우리는 feature/iss1-create-skeleton을 develop으로 머지할 것이기 때문에 그림과 같이 선택합니다.
- 90. 90 / GitHub실습 Pull Request
- 91. 91 / GitHub실습 Pull Request
- 92. 92 / GitHub실습 Pull Request
- 93. 93 / GitHub실습 Pull Request
- 94. 94 / GitHub실습 Pull Request
- 95. 95 / GitHub실습 Pull Request Feature 브랜치를 develop에 머지하기 위한 풀리퀘스트를 만드세요. - base와 compare에각각 지정하는 브랜치에 유의하세요.
- 96. 96 / GitHub실습 Pull Request 변경된 라인에 마우스오버하면 + 아이콘이 나타납니다.
- 97. 97 / GitHub실습 Pull Request 해당 라인에 댓글을 추가할 수 있습니다.
- 98. 98 / GitHub실습 Pull Request
- 99. 99 / GitHub실습 Pull Request
- 100. 100 / GitHub실습 Pull Request 의견을 받았기 때문에 해당 부분에 대한 수정을 시작합니다. (혹은 댓글을 통해 토의합니다)
- 101. 101 / GitHub실습 Pull Request 첫번째 의견에 대한 수정 사항을 커밋합니다. 되도록 커밋은 작은 변경사항들을 자주 하도록 합니다.
- 102. 102 / GitHub실습 Pull Request 두번째 의견에 대해서도 변경 후 커밋합니다.
- 103. 103 / GitHub실습 Pull Request 다시 푸시합니다.
- 104. 104 / GitHub실습 Pull Request 다시 PR 페이지를 확인하면 이전의 댓글은 X 표시되고 푸시한 커밋들이 반영된 것을 확인할 수 있습니다.
- 105. 105 / GitHub실습 Pull Request 이 과정을 코드가 머지할 수 있는 수준이 될 때까지 계속 반복합니다.
- 106. 106 / GitHub실습 Pull Request 머지를 해도 되겠다 판단이 되면 :+1:로 엄지 표시를 입력합니다. (각 팀의 나름의 싸인을 이용하세요)
- 107. 107 / GitHub실습 Pull Request 나름의 룰을 정하여 머지 시점을 결정합니다. 예) 모두의 엄지, 과반수의 엄지 등등
- 108. 108 / GitHub실습 Pull Request 풀리퀘스트의 diff 기능을 이용하여 코드 리뷰를 하고 리뷰 의견을 해결한 후 머지 결정까지 진행해보세요. - 조원은 diff 화면에서 특정 라인에 대한 의견을 작성 - 조장은 전달받은 의견을 토대로 코드를 수정 - main-2.c 파일을 복사해 main.c 내용을 변경한 후 커밋 - main-3.c 파일을 복사해 main.c 내용을 변경한 후 커밋 - 조원은 최종적으로 머지해도 좋을지 판단
- 109. 109 / GitHub실습 Pull Request GitHub 상에서 바로 머지를 할 수 있습니다.
- 110. 110 / GitHub실습 Pull Request GitHub 상에서 바로 머지를 할 수 있습니다.
- 111. 111 / GitHub실습 Pull Request GitHub 상에서 바로 머지를 할 수 있습니다.
- 112. 112 / GitHub실습 Pull Request GitHub 상에서 바로 머지를 할 수 있습니다.
- 113. 113 / GitHub실습 Pull Request 내 로컬 저장소에는 아직 원격 저장소과 로컬 저장소에 브랜치가 남아 있는 것으로 나옵니다.
- 114. 114 / GitHub실습 Pull Request 도구모음에서 Fetch를 클릭합니다. Prune ... remote(s)에 체크한후 OK를 클릭합니다. 원격 저장소의 브랜치 정보가 사라졌습니다.
- 115. 115 / GitHub실습 Pull Request develop으로체크아웃합니다. 머지된 브랜치를 삭제합니다.
- 116. 116 / GitHub실습 Pull Request 풀리퀘스트 페이지의 머지 버튼을 이용하여 feature 브래치를 develop 브랜치로 머지하고 로컬의 feature 브랜치 정보를 정리합니다. (조원은 develop의 변경사항을 pull 받습니다)
- 117. 117 / GitHub실습 Pull Request 이제 각자 맡은 이슈를 앞의 안내에 따라 개발하고 PR을 생성하여 리뷰 받고 머지하세요.
- 118. 118 / GitHub실습 충돌해결 충돌 해결 방법을 알아보기 위해 일부러 충돌을 만들어 봅시다. 동일한 커밋으로부터 조장은 conflict1로 feature 브랜치를 생 성하고 조원은 conflict2로 feature 브랜치를 생성했다고 가정 해봅시다.
- 119. 119 / GitHub실습 충돌해결 feature/confilict1 feature/confilict2
- 120. 120 / GitHub실습 충돌해결 두 feature 브랜치의 풀리퀘스트를 생성할 때는 두 풀리퀘스트가 모두 머지 가능하게 표시될 것입니다. 하지만, conflict1의 풀리퀘스트를 먼저 머지한 후에 conflict2의 PR 페이지를 보면 자동 머지가 안 되는 것을 확인할 수 있습니다.
- 121. 121 / GitHub실습 충돌해결 conflict2의 담당자는 develop으로체크아웃한 후 풀 받습니다. 다시 feature/conflict2로 체크아웃한 후 develop을 머지합니다.
- 122. 122 / GitHub실습 충돌해결 당연히 충돌이 납니다.
- 123. 123 / GitHub실습 충돌해결 충돌난 파일은 느낌표로 나타납니다.
- 124. 124 / GitHub실습 충돌해결 충돌난 영역은 <<<<<<< HEAD .... ======= .... >>>>>>> [머지한 브랜치] 로 표시됩니다. 내가 수정한 내용 머지한 브랜치에서 수정한 내용
- 125. 125 / GitHub실습 충돌해결 feature/confilict1 feature/confilict2
- 126. 126 / GitHub실습 충돌해결 충돌 표시를 지우고 적절하게 두 변경사항을 반영하여 수정합니다.
- 127. 127 / GitHub실습 충돌해결 옵션에서 머지 툴 설정했을 시 외부 머지 툴을 사용하여도 됩니다
- 128. 128 / GitHub실습 충돌해결 충돌을 해결한 파일은 충돌 해결로 표시합니다. (stage로 추가하는 것과 동일)
- 129. 129 / GitHub실습 충돌해결 모든 충돌을 해결했으면 커밋/푸시
- 130. 130 / GitHub실습 충돌해결 다시 PR 페이지를 확인하면 자동 머지가 가능합니다.
- 131. 131 / GitHub실습 충돌해결 충돌 상황을 발생시켜 충돌을 해결하는 법을 실습해봅시다. - 시작하기 전 모두 develop을 pull - 조장은 conflict1feature 브랜치를 생성 - 조원은 conflict2feature 브랜치를 생성 - 앞서 봤던 대로 코드를 수정하고 커밋/푸시 - 조장이 먼저 conflict1에 대한 풀리퀘스트를 머지 - 조원의 conflict2풀리퀘스트가 충돌난 것을 확인 - 조원은 충돌을 해결한 후 다시 머지
- 132. 132 / GitHub실습 rebase 활용 머지만을 사용하여 프로젝트를 진행할 경우 이런 커밋 그래프를 만나게 될 수도... 프로젝트의 히스토리를 보기 굉장히 어렵습니다.
- 133. 133 / GitHub실습 rebase 활용 기본 원칙 - Feature 브랜치를 푸시하기 전 develop에 rebase - 머지 전 develop에 내 feature 브랜치가 가지 친 후의 커밋이 존재한다면 다시 develop에 rebase - develop 머지 시에 다른 사람들은 잠시 develop을 놔두기
- 134. 134 / GitHub실습 rebase 활용 충돌 상황이 있는 예제를 통해 rebase 실습을 해봅시다. 조장은 conflict3브랜치를, 조원은 conflict4브랜치를 생성합니 다.
- 135. 135 / GitHub실습 rebase 활용 조장은 위 코드와 같이 변경한 후 커밋합니다.
- 136. 136 / GitHub실습 rebase 활용 이제 풀리퀘스트를 위해 feature 브랜치를 push 해야 합니다. 이때 꼭 develop을 pull 받아 develop에 변경된 커밋이 없는지 확인합니다. 위 그림과 같이 기능을 개발하는 동안 다른 커밋이 생겼다면 feature 브랜치를 develop에 rebase 합니다.
- 137. 137 / GitHub실습 rebase 활용 Feature 브랜치를 체크아웃 받은 상태에서 develop 브랜치 위에서 컨텍스트 메뉴를 불러와 Rebase current changeson develop을 클릭합니다.
- 138. 138 / GitHub실습 rebase 활용 확인 창에서 OK를 클릭합니다. 충돌이 없다면 그대로 진행이 됩 니다.
- 139. 139 / GitHub실습 rebase 활용 feature 브랜치가 develop의 최신 커밋으로부터 나온 것으로 변 경된 것을 확인할 수 있습니다. rebase 전 rebase 후
- 140. 140 / GitHub실습 rebase 활용 드디어 push할 수 있게 되었습니다. Feature 브랜치를 push하고 풀리퀘스트를 만듭니다.
- 141. 141 / GitHub실습 rebase 활용 동시에 조원은 아래와 같이 코드를 수정하고 커밋한 후 develop의 변경 사항을 확인하여 rebase가 필요하다면 rebase한 후 역시 push하고 풀리퀘스트를 만듭니다.
- 142. 142 / GitHub실습 rebase 활용 이제 feature/conflict3 브랜치가 리뷰가 완료되고 조장이 머지한다고 생각해 보겠습니다.
- 143. 143 / GitHub실습 rebase 활용 하지만 그전에 다시 develop 브랜치에 새로운 커밋이 존재하는 지 확인해 봅니다. 머지할 브랜치가 develop의 마지막 커밋으로부터 나와 있기 때 문에 이번에는 rebase를 할 필요가 없겠습니다.
- 144. 144 / GitHub실습 rebase 활용 풀리퀘스트 페이지에서 머지를 클릭하여 머지합니다. 결과는 아래와 같습니다.
- 145. 145 / GitHub실습 rebase 활용 이제 conflict4도 리뷰가 완료되어 조원이 머지를 한다고 생각해 봅시다. 충돌이 났기 때문에 자동 머지가 되지 않습니다. 그리고 develop 브랜치에도 새로운 커밋(conflict3을 머지하는)이 생겼 기 때문에 rebase가 필요합니다.
- 146. 146 / GitHub실습 rebase 활용 머지하기 전 99c8594커밋의 부모 커밋을 5240aa1로 변경하기 위해 rebase합니다.
- 147. 147 / GitHub실습 rebase 활용 conflict4브랜치가 체크아웃된 상태에서 develop으로 rebase합 니다.
- 148. 148 / GitHub실습 rebase 활용 rebase 진행 중 충돌이 일어납니다.
- 149. 149 / GitHub실습 rebase 활용 충돌을 해결한 후 stage 상태로 변경합니다.
- 150. 150 / GitHub실습 rebase 활용 그 다음 Actions 메뉴에서 Continue Rebase를 클릭합니다.
- 151. 151 / GitHub실습 rebase 활용 feature/conflict4브랜치가 develop의최신 커밋으로부터 나오는 새로운 커밋을 만들어낸 것을 확인할 수 있습니다. 로컬의 feature 브랜치는 rebase가 되었지만 remote(origin)의 feature 브랜치는 여전히 존재하는 것도 확인할 수 있습니다.
- 152. 152 / GitHub실습 rebase 활용 이제 feature 브랜치를 다시 push해 줍니다. 하지만 오류가 발생하며 push가 되지 않습니다. remote(origin)에 이미 push된 커밋 때문입니다.
- 153. 153 / GitHub실습 rebase 활용 이미 remote에 push된 브랜치를 rebase하여 다시 push하기 위해서는 터미널로 직접 명령어를 입력해 주어야 합니다. $ git push origin feature/conflict4 --force
- 154. 154 / GitHub실습 rebase 활용 이제 다시 풀리퀘스트 페이지에서 머지를 하면 아래와 같이 깔 끔하게 정리된 그래프를 확인할 수 있습니다.
- 155. 155 / GitHub실습 rebase 활용 rebase를 사용하는 flow를 실습해 봅니다. - 조장은 conflict3feature 브랜치를 생성 - 조원은 conflict4feature 브랜치를 생성 - 각자 코드를 수정한 후 커밋 - push하기 전 develop을 확인하여 필요하다면 rebase - 풀리퀘스트를 생성 - 리뷰 완료 후 머지 시에도 develop을확인하여 필요하다면 rebase
- 156. 156 / GitHub실습 rebase 활용 rebase는 이미 생성된 커밋을 고치기 때문에 push된 커밋을 rebase하는 것을 권장하지 않는다고 되어 있습니다. 왜냐하면 이미 다른 사람이 pull 받은 커밋을 다시 고치면 엄청난 혼란을 가져올 수 있기 때문입니다. 하지만 앞서 예제에서 feature 브 랜치는 담당자만이 사용하고 있다는 가정 하에 이미 push된 브 랜치를 rebase하고 있습니다.
- 157. 157 / GitHub실습 rebase 활용 rebase는 git 사용법 중에서도 고급 사용법이므로 팀에서 이제 막 git을 도입해 사용하고 있다면 모든 구성원이 git에 익숙해진 후에 rebase를 활용한 flow를 도입하시길 권장드립니다.
- 158. 158 / GitHub실습 릴리즈 생성 릴리즈 준비가 되면 Git Flow로 릴리즈 브랜치를 생성합니다.
- 159. 159 / GitHub실습 릴리즈 생성 Git Flow에서 Start New Release를 클릭
- 160. 160 / GitHub실습 릴리즈 생성 적당한 이름으로 릴리즈 브랜치를 생성합니다.
- 161. 161 / GitHub실습 릴리즈 생성 이 릴리즈 브랜치를 이용하여 최종 테스트를 거치며 릴리즈할 수 있는지 검증합니다.
- 162. 162 / GitHub실습 릴리즈 생성 릴리즈 브랜치에 대한 검증이 완료되었다면 Git Flow의 Finish Release를 클릭합니다.
- 163. 163 / GitHub실습 릴리즈 생성 릴리즈를 완료하면 릴리즈 브랜치가 develop과 master에 머지되고 tag가 생성됩니다.
- 164. 164 / GitHub실습 릴리즈 생성 그 후 develop과 master, tag까지 푸시해 줍니다.
- 165. 165 / GitHub실습 릴리즈 생성 GitHub의 저장소 메인 페이지를 확인하면 release가 생성된 것 을 확인할 수 있습니다.
- 166. 166 / GitHub실습 릴리즈 생성 릴리즈 페이지에서 [Tags] 탭을 선택한 후 지금 생성한 릴리즈 태그의 [Add release notes]를 클릭합니다.
- 167. 167 / GitHub실습 릴리즈 생성 태그 이름 설명 바이너리 파일 등을 첨부 가능
- 168. 168 / GitHub실습 릴리즈 생성
- 169. 169 / GitHub실습 릴리즈 생성 릴리즈를 생성해 봅니다. - 릴리즈 브랜치를 생성 - 릴리즈를 완료 - 결과를 푸시 - GitHub 페이지에서 태그의 릴리즈 노트 작성
- 170. 170 / GitHub실습 정리 - GitHub과 SourceTree를 이용한 Git 기본 사용법 - 저장소 생성, 복제, 파일 상태 변경, 커밋, 푸시 - GitHub을 이용한 프로젝트 관리 - 협업자 설정, 마일스톤/라벨/이슈 관리 - 기능의 개발, GitHub flow(Pull Request) - rebase를 활용한 로그 그래프 관리 - 릴리즈 생성
- 171.