숭실대학교 오픈소스 소모임 SODA에서 진행했던 세미나 PPT입니다.

1. 소스트리 설명 및 실습
숭실대학교 소프트웨어학부 소모임 SODA 발표자료
20121096 김지용

2. 깃 명령에 대한 간략한 이해
* git init
: 현재 디렉토리에 작업을 진행하겠다. (= 현재 디렉토리를 git의 (버전)저장소로 만든다.)
* git add
: git은 기본적으로 새로운 파일을 관리하지 않는다. 파일을 관리하기 위해서는
관리 대상으로 등록을 해야 한다.
따라서 새로운 혹은 수정된 파일을 만들면 깃에게 add명령을 해서 파일을 관리하라고
말해줘야 한다.
-> git add를 실행하면 untracked file이 new file로 변경 된다.

3. 깃 명령에 대한 간략한 이해
Q. 왜 이러한 기능이 필요한가?
: 우리가 프로젝트를 하다 보면 프로젝트의 핵심적인 파일이 있고 그 프로젝트를 개발할 때 테스
트하기 위한 임시 파일이 있는데 임시 파일은 버전관리를 하면 안 되기 때문에 이러한 명령이
있는 것이다. (즉, 버전을 관리해야하는 파일과 관리하지 않는 파일을 구분하기 위해서)
• EX) f1.txt와 f2.txt 파일 모두 수정하고 git add f1.txt만 한다면
f1.txt는 커밋 대기상태로 들어간다.(f2.txt는 아님.)
• 커밋 대기상태 : stage area라고 부른다.
즉, 커밋 하면 stage위에 있는 파일들이 커밋 되는 것임.

4. 깃 명령에 대한 간략한 이해
* git status
: 프로젝트 폴더의 상태를 확인한다.
* git commit
• 마무리된 작업에 버전에 관련된 메시지를 기록해서 저장소로 보내는 행위.
즉, staging area에 tracked 된 파일들을 저장소에 저장하는 것을 의미한다.
• 현재 버전의 메시지를 적어준다.(commit message)
• 각각의 커밋은 자신만의 고유한 주소(commit ID)를 가진다. (commit ID는 git log하면 볼 수 있음.)
• (git commit -a : 수정한 파일을 자동으로 스테이지에 올린다.)
• (git commit -am "ver1.0": 에디터를 띄우지 않고 메세지를 바로 작성해서 커밋한다.)

5. 깃 명령에 대한 간략한 이해
* git branch
: 따로 작업할 공간을 하나 만든다.
* git log
: 버전이 잘 만들었는지 확인하는 명령어(역사를 확인하는 명령어)
(git log -p : 각각의 커밋과 커밋사이의 소스상의 차이를 볼 수 있다.
* git diff
: 두 커밋 사이의 차이점을 알고 싶을 때 사용
EX) git diff f6aafbbb38bec84947611539f039160e5f12f877
e511bd68d90595c208ba5da5cf0722114282ca66
• (git diff "commit ID_1" "commit ID_2")

6. 깃 명령에 대한 간략한 이해
* git reset
: 현재의 로그를 취소해서 과거로 돌아가고싶을 경우 사용
EX) git reset "commit 고유 아이디" --hard(hard말고 soft등 다른 옵션들도 있다. )
위 명령어를 하면 원하는 지점으로 버전을 되돌릴 수 있다.
• (reset하면 눈에 안보이지만 복구할 수 있음.)
• 하지만 git에서는 웬만하면 어떠한 정보도 삭제하지 않아야 한다.

7. 소스트리 실습 – 단일 저장소에서 협업하기
1) 지용이와 재호가 계산기를 만들려 한다.
2) 각자 코딩을 한 다음 각 기능을 마스터 브랜치에 합칠 예정이다.
3) 지용이는 github에 SODA_Calculator라는 원격 Repository를
생성한다.
4) 지용이는 Clone을 통해 저장소를 받아온다.
5) 제일 먼저 README.md 파일을 만들어서 원격 Repo에 올릴 것이다.
6) README 파일을 stage에 올리고 commit 한다.

8. 소스트리 실습 – 단일 저장소에서 협업하기
7) 이 파일을 원격에 올리기 위해서 Push를 사용한다.
8) 지용이와 재호는 Master 브랜치에 완벽한 코드만 올리기로 약속했다.
9) Master 브랜치에 Calculator 초기 세팅을 마친 지용이와 재호는
각자 브랜치를 만들어 기능을 구현하기로 한다.
10) 지용이는 덧셈 기능을 추가하기 위해 feature/add 라는 이름으로,
재호는 뺄셈 기능을 추가하기 위해 feature/sub 라는 이름으로
master 브랜치의 최신 커밋으로 부터 새로운 브랜치를 만들었다.

9. 소스트리 실습 – 단일 저장소에서 협업하기
11) 지용이와 재호는 각자 브랜치에서 코딩을 한다.
12) 시간이 흘러 지용이가 master 브랜치에 feature/add 브랜치를 합치려
한다. 바로 합치기 보다는 재호와 코드 리뷰를 한 뒤 합치기로 한다.
13) 이 때 Pull Request를 사용한다.
14) Github 저장소에 있는 Pull Request 를 눌러 feature/add 에서 master
브랜치로 Pull Request 요청을 보낸다.
15) 그럼 저장소의 Pull Requests 섹션에서 지용이가 보낸 풀리퀘를
확인할 수 있다.

10. 소스트리 실습 – 단일 저장소에서 협업하기
16) 잘 만든 경우, Merge Pull Request를 눌러 지용이의 커밋들을 master
브랜치에 합친다.
17) 이 후 바로 재호가 Pull Request를 보내려 하니 지용이의 코드가
추가되어 재호가 처음에 가져왔던 master 상태와 (소스코드 내용이)
달라져 있습니다.
18) 만일 재호가 지용이와 같은 내용을 고치고 Merge한다면 Merge
Conflict가 일어날 수 있다.

11. 소스트리 실습 – 단일 저장소에서 협업하기
19) 충돌 시, 재호는 지용이와 회의한 후 알맞은 코드를 선택하고(+수정)
commit & push를 한다.
20) 재호도 Pull Request를 보낸다. 지용이가 확인하고 merge하니 오류
없이 잘 합쳐졌다.

12. 1) 지용이와 재호가 계산기를 만들려 한다.
2) 각자 코딩을 한 다음 각 기능을 마스터
브랜치에 합칠 예정이다.

13. 3) 지용이는 GITHUB에 SODA_CALCULATOR라는
원격 REPOSITORY를 생성한다.
Click
Click

14. 4) 지용이는 CLONE을 통해 저장소를 받아온다.
Click

15. 5) 제일 먼저 README.MD 파일을 만들어서 원격 REPO에
올릴 것이다.
1. 아톰 에디터를 사용해서 README 파일 추가
2. Unstaged files에 README.md 파일 올라감

16. 6) README 파일을 STAGE에 올리고 COMMIT 한다.
Click
1. README 파일이 Stage area에 올라온다.
2. Commit 메시지를 작성한 뒤 커밋한다.

17. 7) 이 파일을 원격에 올리기 위해서 PUSH를 사용한다.
Click
Click

18. 8) 지용이와 재호는 Master 브랜치에 완벽한 코드만
올리기로 약속했다.
9) Master 브랜치에 Calculator 초기 세팅을 마친
지용이와 재호는 각자 브랜치를 만들어 기능을
구현하기로 한다.

19. 10) 지용이는 덧셈 기능을 추가하기 위해 FEATURE/ADD 라는
이름으로, 재호는 뺄셈 기능을 추가하기 위해 FEATURE/SUB 라는
이름으로 MASTER 브랜치의 최신 커밋으로 부터 새로운 브랜치를
만들었다.
1)Click
2)Click

20. 11) 지용이와 재호는 각자 브랜치에서 코딩을 한다.
12) 시간이 흘러 지용이가 master 브랜치에 feature/add 브
랜치를 합치려 한다. 바로 합치기 보다는 재호와 코드 리
뷰를 한 뒤 합치기로 한다.
13) 이 때 Pull Request를 사용한다.

21. * 지용이는 FEATURE/ADD 브랜치 안에서 코드를
수정하고 커밋을 진행한다. 그리고 PUSH 한다.
Click

22. 14) GITHUB 저장소에 있는 PULL REQUEST 를 눌러
FEATURE/ADD 에서 MASTER 브랜치로 PULL REQUEST
요청을 보낸다.
Click

23. * BASE > MASTER … COMPARE : FEATURE/ADD
Click

24. * 어떤 기능을 추가했는지 팀원에게 서술하고
CREATE PULL REQUEST를 클릭한다.
Click

25. 15) 그럼 재호는 저장소의 PULL REQUESTS 섹션에서
지용이가 보낸 PULL REQUEST를 확인할 수 있다.
Click

26. 16) 잘 만든 경우, Merge Pull Request를 눌러 지용이의 커밋들을
master 브랜치에 합친다.
17) 이 후 바로 재호가 Pull Request를 보내려 하니 지용이의 코드가
추가되어 재호가 처음에 가져왔던 master 상태와 (소스코드 내용이)
달라져 있습니다.
18) 만일 재호가 지용이와 같은 내용을 고치고 Merge한다면 Merge
Conflict가 일어날 수 있다.

27. 19) 충돌 시, 재호는 지용이와 회의한 후 알맞은 코드를
선택하고(+수정) commit & push를 한다.
20) 재호도 Pull Request를 보낸다. 지용이가 확인하고
merge하니 오류 없이 잘 합쳐졌다.

28. 소스트리 실습 – FORK해와서 협업하기
1) 지용이와 재호가 만든 Calculator가 대박이 났습니다.
2) 상일이가 계산기를 써 보니 제곱 기능이 기능이 있으면 좋을 것 같다고
생각했습니다.
3) 지용이와 재호가 만든 프로젝트는 오픈소스 프로젝트라서 상일이가
컨트리뷰션을 할 수 있습니다.
4) Github repository에서 Fork를 누르면 상일이의 계정으로 리포지토리가
복사됩니다
5) 지용이와 재호가 했던 방법과 동일하게 원격 Repo를 로컬에 받아오고, 제곱 기능
을 커밋합니다.

29. 소스트리 실습 – FORK해와서 협업하기
6) 중간에 내용이 바뀌었을 수도 있으니 fetch를 해줌으로써 원격과 내 소스트리를
동기화 해줍니다.
7) FORK된 리포지토리에서 pull request 버튼을 누릅니다.
8) 메인테이너 지용이는 상일이의 코드를 보고 재호와 상의해서 머지 여부를
의논합니다.
9) 결국 코드가 좋아 merge했습니다.
10) 상일이는 이 프로젝트의 컨트리뷰터가 되었습니다.

30. 1) 지용이와 재호가 만든 Calculator가 대박이 났습니다.
2) 상일이가 계산기를 써 보니 제곱 기능이 기능이
있으면 좋을 것 같다고 생각했습니다.
3) 지용이와 재호가 만든 프로젝트는 오픈소스
프로젝트라서 상일이가 컨트리뷰션을 할 수 있습니다.

31. 4) GITHUB REPOSITORY에서 FORK를 누르면 상일이의
계정으로 리포지토리가 복사됩니다
Click

32. 5) 지용이와 재호가 했던 방법과 동일하게 원격 REPO를
로컬에 받아오고, 제곱 기능을 커밋합니다.
1. 옆의 내용은 지용이와
재호가 이전에 작업했던
history 입니다.

33. * 상일이는 FEATURE/SQUEARE 이름으로 브랜치를
만들고 제곱 기능을 추가합니다.

34. * 우선 내 MASTER 브랜치에 추가한 함수를 병합한다.

35. 6) 중간에 내용이 바뀌었을 수도 있으니 FETCH 혹은 PULL을 해줌으
로써 원격과 내 소스트리를 동기화 해줍니다.
7) FORK된 리포지토리에서 NEW PULL REQUEST 버튼을 누릅니다.

36. * 패기 넘치는 황상일 씨의 풀 리퀘!

37. 8) 메인테이너 지용이는 상일이의 코드를 보고 재호와 상
의해서 머지 여부를 의논합니다.

38. 9) 결국 코드가 좋아 merge했습니다.
10) 상일이는 이 프로젝트의
컨트리뷰터가 되었습니다. 얄루~

39. * PULL & PUSH 추천 작업 순서
(PULL -> WORK -> COMMIT -> PULL -> PUSH)
- Pull로 댕겨서 무조건 동기화 시킬 것.
- 작업 시작
- commit을 할 것.
- Pull (내 작업 시간 동안 타인이 작업한 내용을 사전 동기화 시킴)
- Push로 내 작업 내용 올리기