회사에서 간략하게 했던 세미나 파일입니다. 잘못된 정보가 있을 수 있습니다ㅠㅠ. 알려주시면 추후 수정해서 업로드 하겠습니다. 깃헙이 아니라 깃..입니다.

1. Github 프리뷰
2016_09_06 한정

2. • 여러 사람이 동시에 하나의 코드를 수정
=> 다른 사람이 수정하는 부분을 신경 써야 한다.
큰 프로젝트를 하는 환경
• 버전 관리가 필요한 개발
=> 개발되는 새로운 버전의 코드를 어떻게 관리할지 고려해야 한다.

3. 큰 프로젝트에서 Github을 쓰면!
 소스코드가 변경된 이력을 쉽게 확인가능
 특정시점으로 돌아갈 수 있음
 버전 관리 용이

4. Git의 큰 흐름
Work Tree(Working directory)
 실제로 작업을 하는 공간
Index(staging area)
 변동된 파일의 상태를 기록
 기록하고자 하는 것은 Index에 기록이 되어있어야 함.
 이 작업을 staging 이라 함
Repository
 커밋을 할 경우 저장소에 변동 사항을 저장
 이러한 저장사항들을 보며 변동사항을 알 수 있다.
Working directory
Staging area
Repository
Remote Repository
git add
git push
git commit
Remote Repository
 Push를 하게 되면 원격과 로컬상의 변경 이력이 동일하게 됨
 다른 사람들과 공유를 하게 되는 저장소이다.

5. 저장소를 만들어 준다.
저장소를 복사한다.
원격 저장소를 복사한다.
변경사항을 index로 올려준다.
변경내용을 확정해준다.
변경내용을 발행해준다.
원격 저장소와 로컬 저장소를 맞춰서 갱신해준다.
1
2
3
4
5
6
7
branch를 만든다.
branch를 지운다.
원래 branch와 다른branch의 다른점을 보여준다.
Branch와 합병시켜준다.
8
9
1
0
1
1
간단한 Git 명령어

6. +cherry pick, rebase
Branch에서 작업을 할 때 특정 커밋을
가져오고 싶을 때가 있는데
그때 Cherry-pick을 사용한다.
(고른 커밋 하나에 대해서만 rebase)
Rebase를 하게 되면 다음과 같은
형태의 모습을 보인다.
이 과정을 거치고 merge를 하게 되면
좀 더 깔끔한 Log를 만들게 된다.

7. • Centralized Workflow
=> 하나의 마스터 브랜치를 이용하여 개발한다.
• Feature branch Workflow
=> Centralized에서 좀 더 나아가 기능별 브랜치를 만들어서 작업을 함
=> 격리된 작업 환경을 제공하여 마스터를 중심으로 안전하게 개발이 가능
• Gitflow Workflow
=> branch를 이력을 기록하는 branch, develop branch, release branch, hotfix branch 등 rule을 정해 관리한다.
• Forking Workflow
=> 모든 프로젝트 참여자가 개인적인 로컬 저장소와 원격저장소 두개를 갖는 방식이다.
=> 프로젝트 관리자만 다른 개발자들의 기여분을 공식 저장소에 저장할 수 있다.
=> 오픈소스에 적합하다.
여러가지 Git Workflow

8. 1. 중앙 저장소 생성
1. Centralized Workflow
3. A코드 수정 후 반영2. 중앙 저장소 복제
왜 실패한 것일까?
A가 코드를 수정한 후 B는 최신 커밋
이력을 소유하지 않고 있기 때문에
4. B코드 수정 후 반영 실패
5. 최신 커밋 이력 반영충돌이 발생 했을경우!
서로 다른 코드를 수정했을 경우
문제가 발생하지 않겠지만,
같은 코드를 수정했을 경우 선택을
해야한다.
6.상태를 확인 해
문제가 발생한 곳을 찾아본다.
그리고 수정한다.

9. 2. Feature Branch Workflow
1. branch생성 2. 작업을 함 3. 기능개발이 완료 될 경우
push를 하여 반영시킴
4. A는 B의 코드에 수정할
부분이 있다고 하고
B는 수정을 한다.
5. 수정을 한 후 병합시킨다.

10. 3. Gitflow Workflow
1. 이력관리 2. 기능
3. 릴리즈 4. 유지보수

11. 3. Gitflow Workflow
1. 이력관리 2. 기능
3. 릴리즈 4. 유지보수
master와 develop 브랜치를 따로 둬서
master에 release태그를 매기기 쉽게 함
develop 브랜치에서 나와 개발을 함, master와는
어떤 상호작용도 하지 않는다.
어느정도 develop이 완료 됬을 경우
develop 기준으로 릴리즈를 위한 브랜치를 따서
master에 병합한다.
긴급하게 오류수정이 있을 때 master에서
브랜치를 따 수정 후 develop과 master에 모두
반영시킨다.

12. 3. Gitflow Workflow
1. 개발을 위해
develop branch를 만든다
2. develop branch에서 따서
개발을 시작한다.
3. Release를 하게 될 경우
Develop branch에서 release branch를 만든다.
4. Release를 해줄 때는 master, develop에
모두 push를 해준다.
* 버그가 있을 때
Master에서 branch를 따와 수정하고
Develop, master모두에 반영해준다.

13. 4. Forking Workflow
1. 중앙 저장소 생성 2. 참여자들은 저장소를
복제하여 local에 만든다.
3. 참여자들은 다른
워크플로우 처럼 개발을 한 후
커밋, 푸시를 한다.
(이때 풀 리퀘스트를 하면
관리자에게 요청이 간다)
4. 관리자는 코드를
직접 받아보거나 풀 리퀘스트로
검토하여 병합한다.
origin origin upstream upstream
두 개의 stream

14. +smartgit(GUI)을 통한 간단한 예제
제 repository중 하나를 clone해 봤습니다.
프로젝트가 생긴 것을 볼 수 있습니다.
Log를 통해 커밋했던 기록을 그래프로 볼 수 있습니다.

15. +smartgit(GUI)을 통한 간단한 예제
여기에 add branch를 통해 test_getcha라는
새로운 branch를 만들었습니다.
새로운 branch가 만들어 진 것을 볼 수 있습니다.
간단한 코드 수정을 해보겠습니다.화면에 변동이 있는 파일과 상대경로가 나옵니다.

16. +smartgit(GUI)을 통한 간단한 예제
Commit 버튼을 누르면
수정된 파일을 커밋하게 됩니다.
여기서 commit을 하고 싶은 파일만
체크박스를 선택해 줄 수 있습니다.
현재 branch(test_getcha)에 push를
할지 matching 되는 모든 branch에
push할지 선택하여 push를 하게 됩니
다..
이 과정을 거치면 test_getcha branch에
수정사항이 올라가게 됩니다.