Git의 환경설정을 다시해보고 git과 github의 관계에 대해 이해하고 Repository에 대해 이해해보자
오늘 학습할 내용 중에 이미 알고 있는 내용은 무엇인가요?
Git이 이미 깔려있고 PR도 해본상태이지만 PR에 대해 약간의 의문점이 있는 상태이다.
Git
- 분산버전관리시스템으로 컴퓨터 파일의 변경사항을 추적하고 여러명의 사용자들 간에 해당파일들의 작업을 조율하기 위한 것이다.
- 리누스 토르발즈가 만든 일종의 프로그램
- 리누스 토르발즈가Linux OS를 만들고 관리하면서 경험했던 지옥을 해결하기 위해 버전 관리, 백업, 그리고 협업과 관련된 기능들을 담아 Git을 탄생함.
- 만약 과제를 한다고 했을 때 제출하기 위한 파일들을 수정해온다고 하자. 이때 수정하기전의 파일을 가지고 있으려면 수정하면서 다른이름으로 저장을 해야된다. 이러면 너무 많은 파일들이 존재하게 된다.이러한 것을 보완해주는 것이 Git이다.
- Git으로 관리되는 파일은 Github나 GitLab이나 Bitbucket에 해당하는 원격자장소를 이용해 저장하고 백업, 협업한다.
- 스냅샷 - 해당파일을 사진으로 찍어놓는 것으로 파일을 가지고 있는 것
- 특정시점에 생성된 복사본 파일에 대한 스냅샷을 만들어주는 작업을 commit이라고 한다.
Github
- Git Repository를 관리할 수 있는 클라우드 기반 서비스
- 오픈 소스(소스 코드가 공개된 소프트웨어)에 대해 자유롭게 기능을 추가하고 개선하는 Contribute작업을 진행할 수 있다.
- Github에 올려져있는 코드를 나의 원격저장소로 가져오는 작업중 다운로드해서 가져오는 방법도 있지만, fork라는 작업은 나의 원격저장소로 가져오면서 Contributer가 되는 것이다.
- fork한 것에 대해 Pull request(PR)이라는 기능이 있어, 제안한 코드 변경사항에 대해 반영 여부를 요청한다.
add, commit, push : 온라인 원격 저장소에 업로드하는 것
fork, clone : 협업자의 작업물을 나의 로컬에 다운로드 받는 과정
pull request : 상대 협업자에게 나의 작업 완성물을 취합해달라고 요청하는 과정
merge : 상대방의 작업물과 나의 작업물을 취합하는 과정
git
Git workflow
3가지로 작업환경이 나누어짐
working directory(area)
우리가 프로젝트에 파일들을 수정하는 작업하고있는 것
staging area
어느정도 작업 후 버전히스토리에 저장할 준비가 되어있는 파일들을 옮겨놓는것
.git directory
버전에 history를 가지고 있는 것
과정
보통 협업을 하면 PR을 날리기 때문에 Fork한 것을 기준으로 설명한다. (자신의 파일을 자신의 Remote Repository에만 하는 것은 add commit push만 하면 다 된다.)
모든 명령어는 Git Bash에서 진행해야한다.
1. 처음에는 같이 협업할 코드(다른사람의 GitHub Repository)를 자신의 GitHub Repository에 저장한다. 이 방법은 fork를 진행하면 된다.
2. Remote Repository인 깃허브에 파일이 존재한다. 내가 이 코드를 수정하려면 나의 컴퓨터에 fork한 파일이자 코드가 있어야하기 때문에 자신의 컴퓨터에 Clone한다.
git clone 레파지토리주소(나의 GitHub Repository주소를 뜻함)
3. Clone한 코드를 수정하지 않았다면 Working area로 들어가지 않는다. 만약 수정하거나 파일을 추가한 경우 Working area에 가게 되어 해당 파일들이 뜨게 된다. 이 파일들을 git의 관리하에 있는 staging area로 넣어주기 위해 add를 합니다.
git add 파일명
4. staging area에 있는 파일들을 Commit을 통해 하나의 박스로써 만들며 해당하는 설명을 적어줍니다. 왜냐하면 내가 언제 무엇을 했는지에 대한 것들을 관리해주는 것이 Git이고 이것에 대한 정보를 기록해야 나중에 보기 쉬우지기 때문이다.
git commit -m "메시지"
5. commit한 파일들을 자신의 GitHub Repository에 저장하기 위해 Push한다.
git push origin 브랜치
6. 자신의 GitHub Repository에 저장된 내가 수정한 코드들을 다른사람의 GitHub Repository 반영시켜달라고 요청하는 Pull Request를 한다.
7. 그 다른사람은 PR을 보고 괜찮다 싶으면 Merge를 통해 나의 코드가 반영되는 것이다. -> contribute라고 할 수 있다.
+ git reset HEAD^ 에 해당하는 것이 있는데 이것은 아직 github 레포지토리인 Remote 레포지토리에 올라가지 않은 commit인 경우 취소할 수 있는 것이다. HEAD옆에 있는 ^표시는 바로 이전의 commit을 취소한다는 것이고 ^^인 2개가 들어간다면 바로이전의 이전 commit을 취소한다는 것이 된다.
했던 과정들
fork한 것
clone한 것
status를 확인해보면 정상적으로 clone이 되고 working area에 파일이 없다.
README파일에 마지막 줄에 JoHyunHo-clover codestates practice 를 추가했다.
이후 git status를 다시 해보았다,
README파일 수정후
working area에 있는 걸 확인할 수 있다. 왜냐하면 not staged는 staging area에 있는 것이 아니기 때문이다.
여기에서 git restore README,md (git restore 파일명)을 하게 되면 commit또는 staging area로 가지않은 변경사항에 대해 초기화. 즉, 이전의 상태로 되롤려버린다. 나는 진행하지 않겠다.
staging area로 가기 위해 git add를 할텐데 이때 git add 파일명 또는 git add .로 진행하는데 .는 working area에 있는 모든파일들을 add하는 것이 된다.
git add . 한 결과
여기에서 그냥 commit을 해도 되지만 한 파일을 staging area로 올린상태에서 동일 파일을 또 변경했다면 git add 파일명으로 진행해주면 staging area에 반영이 된다.
git commit -m "메시지"
commit하는 것.
push함push한 후 github
pr하기
pr한후 다른사람의 github repository에 정상적으로 PR요청이 갔다.
Compare & Pull Request가 나의 github 레포지토리에서 나타나지 않는다면
PR방법
위엥 해당하는 사진을 보듯이 상단 네비게이션바를 보면 Code옆에 Pull requests가 있는데 여기에 들어가서 직접 오른쪽 초록색박스인 New pull request를 해도된다.
같이 협업하는 경우에 추가되는 과정 들.
내가 디렉토리 하나를 생성했다고 가정
1. git init으로 git 버전관리를 하기 위해 디렉토리를 git 디레포지토리로 변환 해준다.
2. 이것과 연결시킬 레포지토리를 github에서 remote repository를 만든다.
6. 만약 협업하는 사람이 작업을 완료했다고 한다면 협업하는 사람의 github 레포지토리 내용 가져와야한다.
git pull 4번에서지칭한이름브랜치
브랜치를 적을 때 협업한 사람의 작업한 브랜치의 이름을 입력해야한다. 무조건 master가 main이 아닐 수 도 있다.
7. 얻어온 내용을 내가 수정하면 git add 부터 시작해서 git commit하고 git push해서 저장합니다.
이러면 협업한 사람이 pull작업인 6번작업을 통해 내가 작업한 것을 가져갑니다.
Pair분과 한 결과
혼자 PR을 보내는 것에는 해본적이 있어 수월했다.
하지만 충돌에 관해서는 의문점이 남아있는 상태로 Pair 프로그래밍을 진행했다.
진행하면서 충돌상태에 대해 알게 되었다.
README.md파일을 기준으로 설명하겠다.
충돌 X
1. 내가 수정한 README.md파일이 나의 깃허브 레포지토리에 들어가있다.
2. pair분이 나의 레포지토리를 Pull해서 가져간다.
3. 그러면 Pull한 상태의 README.md파일은 충돌이 나지 않는다. 그냥 README.md파일을 수정해서 add commit push해서 올리면 된다.
충돌 O
1. 내가 수정한 README.md파일이 나의 깃허브 레포지토리에 들어가있다.
2. pair분이 나의 레포지토리를 Pull해서 가져가기전에 pair분인 자신의 README.md파일 수정해서 pair인 자신의 레포지토리에 push해서 올린다. (이때 뒤에 문자를 추가한다.)
3. pair분이 나의 레포지토리를 Pull해서 가져간다. 4. git status로 보면
에 해당하는 내용으로 unmerged 라고 나온다. 이러면 충돌이 나는 것이다.
5 pair가 자신의 README.md파일을 들어가보면 <<<<<<<<<HEAD pair가 수정한 내용 === 내가 수정한 내용 <<<<<<<<<<<<<<<<<<dasfasdf 이런 식으로 나온다. 이때 직접 수정해도 된다 <<<<<<<<<HEAD , === , <<<<<<<<<<<<<<<<<<dasfasdf 부분을 지워 -> pair와 내가 수정한 부분을 다 반영하는 방식 또는 마음대로 지워서 원하는 내용을 남게 하는 방식들이 있다. IDE에 따라서 Accept Current Change, Accept Incoming Change, Remote Repository, Accept Both Changes들을 제공하기도 한다 원하는 것을 선택하면 된다.
즉 같은 파일에 대해서 둘다 수정이 되어있는 상태(push까지되어있는??)에서 pull을 하게 되면 충돌이 난다. 같은 파일에 대해 한쪽만 수정이 되었다면 충돌이 나지 않는다?
