O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

GitHub 실습 교육

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

  • Entre para ver os comentários

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.

×