Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GitHub 실습 교육

26,926 views

Published on

GitHub과 SourceTree를 이용한 Git 기본 사용법
GitHub을 이용한 프로젝트 관리

Published in: Technology

GitHub 실습 교육

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

×