GitHub 실습 교육

GitHub 실습
v.1.4
신승엽 / 유니원사업팀
2016년 1월 18일

2 / GitHub 실습
준비
SourceTree
- http://www.sourcetreeapp.com/
실습 파일
- http://flysky.kr/github-example.zip

3 / GitHub 실습
규칙
직접 실습합니다.
슬라이드의 내용에 집중합니다.

5 / GitHub 실습
https://github.com
GitHub

6 / GitHub 실습
- 원하는 아이디와 비밀번호
그리고 이메일을 입력한 후
회원가입 합니다.
회원가입

7 / GitHub 실습
- Free를 선택하고
계속 진행
회원가입

8 / GitHub 실습
가입 완료!
회원가입

9 / GitHub 실습
GitHub에 가입하세요.
- 초기화면에서아이디, 이메일, 비밀번호 입력
- 플랜은 Free로
- 꼭! 이메일 입력 후 이메일 인증을 받으세요.
(받지 않으면 계정 잠김)
회원가입

GitHub과 SourceTree를 이용한
Git 기초 사용법

11 / GitHub 실습
오른쪽 상단의 플러스 아이콘을 누른 후
New repository를선택하여 저장소를
생성할 수 있습니다.
저장소 생성

12 / GitHub 실습
저장소 이름을 작성합니다
체크합니다
저장소 생성

13 / GitHub 실습
저장소 생성

14 / GitHub 실습
저장소 생성
calculator 라는 이름의 저장소를 하나 생성하세요.
- 오른쪽 상단의 + 표시에서 New Repository
- 저장소 이름을 입력하고 README 생성에 체크

15 / GitHub 실습
저장소 복제
저장소 페이지의 클립보드 아이콘을 클
릭해서 주소를 복사합니다.

16 / GitHub 실습
저장소 복제
SourceTree의 도구모음에서
Clone을 클릭합니다.
Windows
MacOS X
New Repository에서
Clone From URL을 클릭합니다.

17 / GitHub 실습
저장소 복제
저장소 주소 입력 후 탭키
Git 저장소라는 메시지 확인
Windows
MacOS X
저장소 주소 입력 후 탭키
Git 저장소라는 메시지 확인

18 / GitHub 실습
저장소 복제
저장소가 복제된 것을 확인할 수 있습니다.
Windows
MacOS X

19 / GitHub 실습
저장소 복제
calculator 저장소를로컬로 복제하세요.
- GitHub에서 저장소 주소 복사
- SourceTree에서저장소 복제

20 / GitHub 실습
사용자 정보설정
Windows는[Tools] - [Options]에서
Default user information을 설정합니다.
이곳에서 설정하면 별도로 설정하지 않은
모든 저장소에 이 설정이 사용됩니다.

21 / GitHub 실습
[Repository]- [Repository Settings...] - [Advanced]에서
Use global user settings에 체크를 풀고 설정하면
해당 저장소에만 반영됩니다.

22 / GitHub 실습
Mac에서는 UI를 통해 이름을 한글로 설정하면
Mac 이외의 OS에서는 이렇게 깨져 보이게 됩니다.

23 / GitHub 실습
$ git config --global user.name 신승엽/협업시스템개발팀
$ git config --global user.email flysky@nhnent.com
Mac에서 사용자 정보를 설정할 때는
터미널에서 아래 명령을 사용합니다.
생략하면 현재 저장소에만 적용

24 / GitHub 실습
사용자 정보를 설정하세요.
- Windows: 환경설정의Default user information수정
- Mac OS X: 터미널을 통해 명령어로 수정

25 / GitHub 실습
Mac에서 명령어를 통해서 사용자 이름을 변경해도 설정 UI를 한
번 들어가면 다시 되돌아가는문제
https://github.com/flyskyko/git-hooks

26 / GitHub 실습
GitFlow 설정
도구모음에서 Git Flow를 클릭합니다.
기본값 그대로 OK를
클릭합니다.

27 / GitHub 실습
GitFlow 설정
develop 브랜치가 생성되고 체크아웃된 것을
확인할 수 있습니다. 이제 푸시합니다.

28 / GitHub 실습
GitFlow 설정
도구모음에서 Push를 클릭합니다.
develop에 체크한 후
OK를 클릭합니다.

29 / GitHub 실습
GitFlow 설정
아이디와 비밀번호를
물어보면 GitHub 아이디와
비밀번호를 입력합니다.

30 / GitHub 실습
GitFlow 설정
GitHub의 저장소 페이지로 이동
한 후 Settings를 클릭합니다.
Default branch를 develop으로
선택합니다.

31 / GitHub 실습
GitFlow 설정
Git Flow 설정을 하고 develop을 기본 브랜치로 설정하세요.
- SourceTree의 Git Flow 버튼을 이용, 초기 설정
- develop 브랜치 푸시
- GitHub 설정 페이지에서develop을 기본 브랜치로

32 / GitHub 실습
파일수정과 상태변경
저장소가 복제된 폴더로 이동하여
README.md 파일을 수정해 봅시다.
Windows
MacOS X

33 / GitHub 실습
파일 내용을 변경하였습니다.

34 / GitHub 실습
SourceTree의 Working Copy 항목을 보면
README.md 파일이 Unstaged files에 추가되었고
오른쪽에서는 Diff를 확인할 수 있습니다.

35 / GitHub 실습
Unstaged files에 있는 README.md 파일을 체크하면
Staged files로 추가됩니다.
이제 커밋을 위한 준비가 완료되었습니다.

36 / GitHub 실습
그런데 아차! '기술교육'을 잊었네요.
파일을 다시 수정하였습니다.

37 / GitHub 실습
README.md가 Unstaged/Stagedfiles 양쪽에 모두 있습니다.

38 / GitHub 실습
Staged file을 수정하면 Staged 상태에서 수정된 Unstaged 상
태가 됩니다.
커밋을 위해서는 다시 체크하여 Staged 상태로 변경하여야 합
니다.

39 / GitHub 실습

40 / GitHub 실습
README.md 파일을 수정하여 커밋 준비를 하세요.
- 한번 수정한 후 Unstage 상태가 되는 것을 확인하세요.
- Stage 상태로 만드세요.
- 다시 수정하여 Stage/Unstage 상태의 차이를 확인하세요.
- 최종적으로 Stage 상태로 만들어 커밋 준비를 하세요.

42 / GitHub 실습
Commit
develop 브랜치에 커밋이 추가된 것을 확인할 수 있습니다.

43 / GitHub 실습
Commit
develop 브랜치에 한번 더 커밋을 해보았습니다.
Git은 원격 저장소와 연결되어 있지 않더라도
로컬에서 몇번이고 커밋을 추가할 수 있습니다.
이렇게 로컬에 추가된 커밋은 푸시를 통해 원격 저장소에
반영할 수 있습니다.

44 / GitHub 실습
Commit
Working Copy의 변경사항을 커밋하세요.
- 두번 이상 커밋해 보시기 바랍니다.

45 / GitHub 실습
Push
도구모음의 Push를 클릭합니다.
푸시할 브랜치를
선택한 후 OK를
클릭합니다.

46 / GitHub 실습
Push
GitHub의 저장소 페이지를 새로고침해보면
우리가 작성한 커밋이 반영된 것을 확인할 수 있습니다.

47 / GitHub 실습
Push
로컬의 커밋을 원격 저장소로 푸시하세요.

GitHub을 이용한 프로젝트 관리

49 / GitHub 실습
개요
각 팀에서 하나의 저장소를 만들고 그곳에서
계산기 ver. 1.0을 릴리즈하는 과정을 따라해 보겠습니다.
조장을 결정해주세요.

50 / GitHub 실습
새로운 규칙
직접 실습합니다.
슬라이드의 내용에 집중합니다.
조장이 행동하고 조원이 지켜봅니다.
조원이 행동하고 조장이 지켜봅니다.

51 / GitHub 실습
협업자 추가
저장소는 앞서 생성한 조장의 저장소를
사용하도록 하겠습니다.
저장소 페이지의 상단 Settings를 클릭
왼쪽 메뉴에서 Collaborators를클릭

52 / GitHub 실습
협업자 추가
조원을 검색하여 추가해 줍니다.
(아이디로 검색)

53 / GitHub 실습
협업자 추가

54 / GitHub 실습
협업자 추가
조원을 협업자로 추가합니다.
- Settings - Collaborator
- 아이디로 검색 후 추가

55 / GitHub 실습
저장소 복제
각 조원은 조장의 저장소를
복제한 후 Git Flow 설정까지
완료합니다.
이때 Git Flow 초기 설정은
develop과 master 브랜치가
모두 로컬에 있어야 가능합니다.
Remotes origin의 master를 체크아웃 받습니다.
(develop은 기본 브랜치이기 때문에 복제 시 체크아웃 됨)

56 / GitHub 실습
마일스톤 설정
저장소 페이지의상단에서 Issues 클릭
상단 탭에서 Milestones 클릭
오른쪽 상단의 New milestone클릭

57 / GitHub 실습
마일스톤 설정
이름
설명
기한

58 / GitHub 실습
마일스톤 설정
마일스톤 진행 상황을 확인할 수 있습니다.

59 / GitHub 실습
마일스톤 설정
계산기 ver.1.0 마일스톤을 추가합니다.

60 / GitHub 실습
라벨설정
저장소 페이지의 상단에서 Issues 클릭
탭에서 Labels 클릭

61 / GitHub 실습
라벨설정

62 / GitHub 실습
라벨설정
New label을 클릭
라벨 이름과 색상을 지정 가능합니다.

63 / GitHub 실습
라벨설정

64 / GitHub 실습
라벨설정
라벨의 구성을 자유롭게 변경하세요.

65 / GitHub 실습
이슈생성
저장소 페이지의 상단에서 Issues 클릭
오른쪽 상단의 New issue 클릭

66 / GitHub 실습
이슈생성

67 / GitHub 실습
이슈생성

68 / GitHub 실습
이슈생성

69 / GitHub 실습
이슈생성

70 / GitHub 실습
이슈생성

71 / GitHub 실습
이슈생성

72 / GitHub 실습
이슈논의
하단의 댓글 입력창을 통해 댓글을 남길 수 있습니다.

73 / GitHub 실습
이슈논의

74 / GitHub 실습
이슈논의

75 / GitHub 실습
이슈
앞장과 같이 이슈를 등록하고 댓글을 통해 의견을 나누어 봅니
다.
- 이슈에 담당자, 라벨, 마일스톤 등을 지정해보세요.
- 댓글을 통해 의견을 교환하세요.

76 / GitHub 실습
기능개발
#1스켈레톤 작성 이슈를 개발해 봅시다.
#1 이슈 담당자는
이슈의 라벨을 적절하게 변경합니다.

77 / GitHub 실습
기능개발
도구모음에서 Git Flow를 클릭합니다.
Start New Feature를 클릭합니다.

78 / GitHub 실습
기능개발
Feature Name은
이슈번호와
간략한 설명으로
정합니다.

79 / GitHub 실습
기능개발
feature/iss1-create-skeleton브랜치가
생성되고 checkout된 것을
확인할 수 있습니다.

80 / GitHub 실습
기능개발
main.c를 생성합니다.

81 / GitHub 실습
기능개발
'fixed #1'을 포함하여 커밋 로그를 작성하고 Commit합니다.

82 / GitHub 실습
기능개발
푸시할 브랜치를
선택한 후
푸시합니다.

83 / GitHub 실습
기능개발
GitHub의 #1 이슈 페이지를 확인하면
b2ade71커밋이 #1 이슈와 연결된 것을

84 / GitHub 실습
기능개발
fixed 라고 적어 주었기 때문에 b2ade71커밋이
기본 브랜치인 develop 브랜치와 머지될 때
이슈가 자동으로 닫힙니다.

85 / GitHub 실습
기능개발
#1 이슈를 해결하세요.
- Git Flow 버튼을 통해 새 Feature를 시작합니다.
- 실습 파일의 main-1.c 파일 내용을 복사해서 main.c로 저장
합니다.
- 커밋 로그에 'fixed #1'을 포함하여 커밋합니다.
- Feature 브랜치를 푸시합니다.

86 / GitHub 실습
Pull Request
기능 개발이 완료된 후에는
Git Flow의 Finish Feature를
이용하여 기능 브랜치를
develop으로머지할 수도
있습니다.

87 / GitHub 실습
Pull Request
하지만 이렇게 하지 않고 GitHub에서 Pull Request를 생성하는
방법을 알아봅니다. 이런 방식을 GitHub Flow라고 부릅니다.
본 교육에서는 Git Flow와 GitHub Flow를 조합한 workflow를
안내 합니다.

88 / GitHub 실습
Pull Request
저장소 페이지의 상단 Pull Requests 클릭
오른쪽 상단의 New pull request 클릭

89 / GitHub 실습
Pull Request
compare에서
base로 머지하는
풀리퀘스트를 만듭니다.
우리는 feature/iss1-create-skeleton을 develop으로
머지할 것이기 때문에 그림과 같이 선택합니다.

90 / GitHub 실습
Pull Request

91 / GitHub 실습
Pull Request

92 / GitHub 실습
Pull Request

93 / GitHub 실습
Pull Request

94 / GitHub 실습
Pull Request

95 / GitHub 실습
Pull Request
Feature 브랜치를 develop에 머지하기 위한
풀리퀘스트를 만드세요.
- base와 compare에각각 지정하는 브랜치에 유의하세요.

96 / GitHub 실습
Pull Request
변경된 라인에 마우스오버하면
+ 아이콘이 나타납니다.

97 / GitHub 실습
Pull Request
해당 라인에 댓글을 추가할 수 있습니다.

98 / GitHub 실습
Pull Request

99 / GitHub 실습
Pull Request

100 / GitHub 실습
Pull Request
의견을 받았기 때문에 해당 부분에 대한 수정을 시작합니다.
(혹은 댓글을 통해 토의합니다)

101 / GitHub 실습
Pull Request
첫번째 의견에 대한 수정 사항을 커밋합니다.
되도록 커밋은 작은 변경사항들을 자주 하도록 합니다.

102 / GitHub 실습
Pull Request
두번째 의견에 대해서도 변경 후 커밋합니다.

103 / GitHub 실습
Pull Request
다시 푸시합니다.

104 / GitHub 실습
Pull Request
다시 PR 페이지를 확인하면 이전의 댓글은 X 표시되고
푸시한 커밋들이 반영된 것을 확인할 수 있습니다.

105 / GitHub 실습
Pull Request
이 과정을 코드가 머지할 수 있는 수준이 될 때까지
계속 반복합니다.

106 / GitHub 실습
Pull Request
머지를 해도 되겠다 판단이 되면
:+1:로 엄지 표시를 입력합니다.
(각 팀의 나름의 싸인을 이용하세요)

107 / GitHub 실습
Pull Request
나름의 룰을 정하여 머지 시점을 결정합니다.
예) 모두의 엄지, 과반수의 엄지 등등

108 / GitHub 실습
Pull Request
풀리퀘스트의 diff 기능을 이용하여 코드 리뷰를 하고
리뷰 의견을 해결한 후 머지 결정까지 진행해보세요.
- 조원은 diff 화면에서 특정 라인에 대한 의견을 작성
- 조장은 전달받은 의견을 토대로 코드를 수정
- main-2.c 파일을 복사해 main.c 내용을 변경한 후 커밋
- main-3.c 파일을 복사해 main.c 내용을 변경한 후 커밋
- 조원은 최종적으로 머지해도 좋을지 판단

109 / GitHub 실습
Pull Request
GitHub 상에서 바로 머지를 할 수 있습니다.

110 / GitHub 실습
Pull Request

111 / GitHub 실습
Pull Request

112 / GitHub 실습
Pull Request

113 / GitHub 실습
Pull Request
내 로컬 저장소에는 아직 원격 저장소과
로컬 저장소에 브랜치가 남아 있는 것으로
나옵니다.

114 / GitHub 실습
Pull Request
도구모음에서 Fetch를 클릭합니다.
Prune ... remote(s)에 체크한후
OK를 클릭합니다.
원격 저장소의 브랜치 정보가 사라졌습니다.

115 / GitHub 실습
Pull Request
develop으로체크아웃합니다.
머지된 브랜치를 삭제합니다.

116 / GitHub 실습
Pull Request
풀리퀘스트 페이지의 머지 버튼을 이용하여
feature 브래치를 develop 브랜치로 머지하고
로컬의 feature 브랜치 정보를 정리합니다.
(조원은 develop의 변경사항을 pull 받습니다)

117 / GitHub 실습
Pull Request
이제 각자 맡은 이슈를 앞의 안내에 따라 개발하고
PR을 생성하여 리뷰 받고 머지하세요.

118 / GitHub 실습
충돌해결
충돌 해결 방법을 알아보기 위해 일부러 충돌을 만들어 봅시다.
동일한 커밋으로부터 조장은 conflict1로 feature 브랜치를 생
성하고 조원은 conflict2로 feature 브랜치를 생성했다고 가정
해봅시다.

119 / GitHub 실습
충돌해결
feature/confilict1
feature/confilict2

120 / GitHub 실습
충돌해결
두 feature 브랜치의 풀리퀘스트를 생성할 때는
두 풀리퀘스트가 모두 머지 가능하게 표시될 것입니다.
하지만, conflict1의 풀리퀘스트를 먼저 머지한 후에
conflict2의 PR 페이지를 보면 자동 머지가 안 되는 것을

121 / GitHub 실습
충돌해결
conflict2의 담당자는 develop으로체크아웃한 후 풀 받습니다.
다시 feature/conflict2로
체크아웃한 후 develop을
머지합니다.

122 / GitHub 실습
충돌해결
당연히 충돌이 납니다.

123 / GitHub 실습
충돌해결
충돌난 파일은 느낌표로 나타납니다.

124 / GitHub 실습
충돌해결
충돌난 영역은
<<<<<<< HEAD
....
=======
....
>>>>>>> [머지한 브랜치]
로 표시됩니다.
내가 수정한 내용
머지한 브랜치에서 수정한 내용

125 / GitHub 실습
충돌해결
feature/confilict1
feature/confilict2

126 / GitHub 실습
충돌해결
충돌 표시를 지우고 적절하게 두 변경사항을 반영하여
수정합니다.

127 / GitHub 실습
충돌해결
옵션에서 머지 툴 설정했을 시
외부 머지 툴을 사용하여도 됩니다

128 / GitHub 실습
충돌해결
충돌을 해결한 파일은 충돌 해결로 표시합니다.
(stage로 추가하는 것과 동일)

129 / GitHub 실습
충돌해결
모든 충돌을 해결했으면 커밋/푸시

130 / GitHub 실습
충돌해결
다시 PR 페이지를 확인하면 자동 머지가 가능합니다.

131 / GitHub 실습
충돌해결
충돌 상황을 발생시켜 충돌을 해결하는 법을 실습해봅시다.
- 시작하기 전 모두 develop을 pull
- 조장은 conflict1feature 브랜치를 생성
- 조원은 conflict2feature 브랜치를 생성
- 앞서 봤던 대로 코드를 수정하고 커밋/푸시
- 조장이 먼저 conflict1에 대한 풀리퀘스트를 머지
- 조원의 conflict2풀리퀘스트가 충돌난 것을 확인
- 조원은 충돌을 해결한 후 다시 머지

132 / GitHub 실습
rebase 활용
머지만을 사용하여 프로젝트를 진행할 경우
이런 커밋 그래프를 만나게 될 수도...
프로젝트의 히스토리를 보기 굉장히 어렵습니다.

133 / GitHub 실습
rebase 활용
기본 원칙
- Feature 브랜치를 푸시하기 전 develop에 rebase
- 머지 전 develop에 내 feature 브랜치가 가지 친 후의 커밋이
존재한다면 다시 develop에 rebase
- develop 머지 시에 다른 사람들은 잠시 develop을 놔두기

134 / GitHub 실습
rebase 활용
충돌 상황이 있는 예제를 통해 rebase 실습을 해봅시다.
조장은 conflict3브랜치를, 조원은 conflict4브랜치를 생성합니
다.

135 / GitHub 실습
rebase 활용
조장은 위 코드와 같이 변경한 후 커밋합니다.

136 / GitHub 실습
rebase 활용
이제 풀리퀘스트를 위해 feature 브랜치를 push 해야 합니다.
이때 꼭 develop을 pull 받아 develop에 변경된 커밋이 없는지
확인합니다.
위 그림과 같이 기능을 개발하는 동안 다른 커밋이 생겼다면
feature 브랜치를 develop에 rebase 합니다.

137 / GitHub 실습
rebase 활용
Feature 브랜치를 체크아웃 받은 상태에서
develop 브랜치 위에서 컨텍스트 메뉴를 불러와
Rebase current changeson develop을 클릭합니다.

138 / GitHub 실습
rebase 활용
확인 창에서 OK를 클릭합니다.
충돌이 없다면 그대로 진행이 됩
니다.

139 / GitHub 실습
rebase 활용
feature 브랜치가 develop의 최신 커밋으로부터 나온 것으로 변
경된 것을 확인할 수 있습니다.
rebase 전
rebase 후

140 / GitHub 실습
rebase 활용
드디어 push할 수 있게 되었습니다.
Feature 브랜치를 push하고 풀리퀘스트를 만듭니다.

141 / GitHub 실습
rebase 활용
동시에 조원은 아래와 같이 코드를 수정하고 커밋한 후
develop의 변경 사항을 확인하여 rebase가 필요하다면
rebase한 후 역시 push하고 풀리퀘스트를 만듭니다.

142 / GitHub 실습
rebase 활용
이제 feature/conflict3 브랜치가 리뷰가 완료되고
조장이 머지한다고 생각해 보겠습니다.

143 / GitHub 실습
rebase 활용
하지만 그전에 다시 develop 브랜치에 새로운 커밋이 존재하는
지 확인해 봅니다.
머지할 브랜치가 develop의 마지막 커밋으로부터 나와 있기 때
문에 이번에는 rebase를 할 필요가 없겠습니다.

144 / GitHub 실습
rebase 활용
풀리퀘스트 페이지에서 머지를 클릭하여 머지합니다.
결과는 아래와 같습니다.

145 / GitHub 실습
rebase 활용
이제 conflict4도 리뷰가 완료되어 조원이 머지를 한다고 생각해
봅시다. 충돌이 났기 때문에 자동 머지가 되지 않습니다. 그리고
develop 브랜치에도 새로운 커밋(conflict3을 머지하는)이 생겼
기 때문에 rebase가 필요합니다.

146 / GitHub 실습
rebase 활용
머지하기 전 99c8594커밋의 부모 커밋을 5240aa1로 변경하기
위해 rebase합니다.

147 / GitHub 실습
rebase 활용
conflict4브랜치가 체크아웃된 상태에서 develop으로 rebase합
니다.

148 / GitHub 실습
rebase 활용
rebase 진행 중 충돌이 일어납니다.

149 / GitHub 실습
rebase 활용
충돌을 해결한 후 stage 상태로 변경합니다.

150 / GitHub 실습
rebase 활용
그 다음 Actions 메뉴에서
Continue Rebase를 클릭합니다.

151 / GitHub 실습
rebase 활용
feature/conflict4브랜치가 develop의최신 커밋으로부터
나오는 새로운 커밋을 만들어낸 것을 확인할 수 있습니다.
로컬의 feature 브랜치는 rebase가 되었지만 remote(origin)의
feature 브랜치는 여전히 존재하는 것도 확인할 수 있습니다.

152 / GitHub 실습
rebase 활용
이제 feature 브랜치를 다시 push해 줍니다.
하지만 오류가 발생하며 push가 되지 않습니다.
remote(origin)에 이미 push된 커밋 때문입니다.

153 / GitHub 실습
rebase 활용
이미 remote에 push된 브랜치를 rebase하여
다시 push하기 위해서는 터미널로 직접 명령어를 입력해
주어야 합니다.
$ git push origin feature/conflict4 --force

154 / GitHub 실습
rebase 활용
이제 다시 풀리퀘스트 페이지에서 머지를 하면 아래와 같이 깔
끔하게 정리된 그래프를 확인할 수 있습니다.

155 / GitHub 실습
rebase 활용
rebase를 사용하는 flow를 실습해 봅니다.
- 조장은 conflict3feature 브랜치를 생성
- 조원은 conflict4feature 브랜치를 생성
- 각자 코드를 수정한 후 커밋
- push하기 전 develop을 확인하여 필요하다면 rebase
- 풀리퀘스트를 생성
- 리뷰 완료 후 머지 시에도 develop을확인하여 필요하다면
rebase

156 / GitHub 실습
rebase 활용
rebase는 이미 생성된 커밋을 고치기 때문에 push된 커밋을
rebase하는 것을 권장하지 않는다고 되어 있습니다. 왜냐하면
이미 다른 사람이 pull 받은 커밋을 다시 고치면 엄청난 혼란을
가져올 수 있기 때문입니다. 하지만 앞서 예제에서 feature 브
랜치는 담당자만이 사용하고 있다는 가정 하에 이미 push된 브
랜치를 rebase하고 있습니다.

157 / GitHub 실습
rebase 활용
rebase는 git 사용법 중에서도 고급 사용법이므로 팀에서 이제
막 git을 도입해 사용하고 있다면 모든 구성원이 git에 익숙해진
후에 rebase를 활용한 flow를 도입하시길 권장드립니다.

158 / GitHub 실습
릴리즈 생성
릴리즈 준비가 되면 Git Flow로 릴리즈 브랜치를 생성합니다.

159 / GitHub 실습
릴리즈 생성
Git Flow에서 Start New Release를 클릭

160 / GitHub 실습
릴리즈 생성
적당한 이름으로
릴리즈 브랜치를
생성합니다.

161 / GitHub 실습
릴리즈 생성
이 릴리즈 브랜치를 이용하여 최종 테스트를 거치며
릴리즈할 수 있는지 검증합니다.

162 / GitHub 실습
릴리즈 생성
릴리즈 브랜치에 대한 검증이 완료되었다면
Git Flow의 Finish Release를 클릭합니다.

163 / GitHub 실습
릴리즈 생성
릴리즈를 완료하면
릴리즈 브랜치가
develop과 master에
머지되고 tag가 생성됩니다.

164 / GitHub 실습
릴리즈 생성
그 후
develop과
master, tag까지
푸시해 줍니다.

165 / GitHub 실습
릴리즈 생성
GitHub의 저장소 메인 페이지를 확인하면 release가 생성된 것
을 확인할 수 있습니다.

166 / GitHub 실습
릴리즈 생성
릴리즈 페이지에서 [Tags] 탭을 선택한 후 지금 생성한 릴리즈
태그의 [Add release notes]를 클릭합니다.

167 / GitHub 실습
릴리즈 생성 태그
이름
설명
바이너리 파일 등을 첨부 가능

168 / GitHub 실습
릴리즈 생성

169 / GitHub 실습
릴리즈 생성
릴리즈를 생성해 봅니다.
- 릴리즈 브랜치를 생성
- 릴리즈를 완료
- 결과를 푸시
- GitHub 페이지에서 태그의 릴리즈 노트 작성

170 / GitHub 실습
정리
- GitHub과 SourceTree를 이용한 Git 기본 사용법
- 저장소 생성, 복제, 파일 상태 변경, 커밋, 푸시
- GitHub을 이용한 프로젝트 관리
- 협업자 설정, 마일스톤/라벨/이슈 관리
- 기능의 개발, GitHub flow(Pull Request)
- rebase를 활용한 로그 그래프 관리
- 릴리즈 생성

GitHub 실습 교육

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to GitHub 실습 교육

Similar to GitHub 실습 교육 (20)

GitHub 실습 교육