git과 github을 사용하는 걸 직접 해보자.
스크린샷에 나와있는 예시들의 이름이 조금씩 다를 수 있는데 사소한 점은 무시해보자.
1. clone 받아오기
먼저 일정 디렉토리에 해당하는 github 자료를 clone 해오자.
일단 git clone url 명령어로 clone 받아오자.
remote repository(github)에서 local repository(PC)로 해당 프로젝트의 플젝트 히스토리를 전부 받아온다.
완료되고서 ls 를 입력해보면 새로운 git3 폴더가 생성된걸 알 수 있다.
clone 을 해온 git3 는 이미 init 상태가 되있어서 git 을 사용할 수 있는 상태이다.
2. branch 생성 및 branch 이동, 파일 추가
cd git3, cd(change directory) 명령어로 clone 해온 폴더로 들어가보자
이제 이 master 에서 새로운 brach를 생성해보자.
git branch <생성될 branch 이름> 명렁어로 branch를 생성하면 된다.
생성된 branch로 이동하기 위해서는 git checkout <생성된 branch 이름> 명령어를 이용하면 된다.
보통
branch을 작성할 때, 기능을 추가하는 소스코드를 작업하는branch라면 앞에feature/을 붙인다.
그 이후 touch 명령어로 branch에 새로운 텍스트 파일을 만들어보자.
ls 명령어로 해당 branch 의 파일 리스트를 보면 clone 해올 때 부터 있던 README.md 에 새롭게 추가된 lrg.txt 텍스트 파일이 있다.
이 텍스트파일을 터미널에서 수정하는 방법은 vim lrg.txt 로 vim 모드로 들어가서 수정할 수 있다.
vim 모드
i : insert mode 즉, 입력 모드로 전환된다.
esc 키 : 입력 모드에서 보기 모드로 전환된다.
:wq : 보기모드에서 :wq 를 입력하면 자신의 수정된 사항을 저장하면서 vim 모드에서 나가진다.
3. add, commit 해보기
해당 branch에서 수정사항이 발생했다면 이제 add 명령어로 index 공간에 넘겨줄 수 있다. index 공간에 넘어간 파일들만 commit이 가능하다. push 와 commit을 하기전에 일차적으로 add 를 통해서 수정된 필요한 파일들을 한 번 거르는 작업이라고 할 수 있다.add 된 파일을 꼭 commit 하지 않아도 된다. 그 중에 필요한 것만 commit 하면 된다.
git add .: 해당 폴더에 있는 파일들 전체를add해버린다.
git commit -m "코멘츠를 달아줄 수 있다. 자세하게 적어주자": commit할 때 -m 옵션을 통해서 커멘트를 달아줄 수 있는데, 되도록 좀 자세히, 잘 적어주는게 좋다.
파일을 수정한 상태에서 add, commit을 안한 상태에서 git status 명령어를 입력해보면 "커밋하도록 정하지 않은 변경 사항" 들이 나온다. 수정되었는데 add 되지 않았으면 파일 이름이 빨간색으로 뜬다.
이 상태에서 add를 해주고, 다시 한 번 git status 를 입력해보면 "커밋한 변경 사항" 과 초록색으로 변한 파일들을 볼 수 있다. 이제 이 파일들은 commit 할 수 있는 상태이다.
이제 git commit -m "커멘트 넣을 말들" 을 통해서 commit 해보자.
commit을 하고나서 git status를 해보면 상태가 달라진다.
이제 수정된 사항이 없어서 add나 commit 할 상태인 파일들이 존재하지 않는다.
4. push 를 통해서 remote repository 에 업로드하기
commit까지 다 했으면 이제 수정된 파일들은 서버에 업로드해야한다. 그 작업을 하는 명령어는 push 이다.
git push origin feature/lgr2
이 명령어를 해석하자면 origin 이라는 서버에 feature/lgr2 라는 branch 를 업로드 시킨다는 의미이다.
현재 push 한 장소인 github 주소가 스크린샷에도 나와있다. 이제 자신이 push한 것들이 제대로 서버에 올라갔는지 github 사이트로 들어가서 확인할 수 있다.
Pull requests 메뉴로 들어가면 자신 혹은 팀원들이 push 한 작업들이 올라와있다. 이제 여기서 pull requests를 요청하고, 해당 프로젝트의 권한이 있는 사람이 merge를 하게된다면 자신이 수정한 소스코드가 원래 프로젝트와 합쳐진다.
5. 혹시 conflict(충돌)이 일어난다면?
push를 했는데, 충돌이 일어날 수 있다.
예를 들어보자.
- 한명이 같은 파일을(예, README.md) 수정하고 GitHub(remote repository)에 push하였다.
- 다른 사람이 README.md 파일 내역을 수정하고 GitHub에 push 하려고 한다.
- 이때 git은 fail 메시지를 뱃으면서 push 되지 않는다.
이미지 및 설명 참조
https://mobicon.tistory.com/162
이럴 경우 해결 방법이 몇 가지 있다.
그 중에 현재 내가 알고 있는 방법은 두가지 이다.
- conflict 되었던 해당 branch 에서 pull로 업데이트 시킨 후 conflict 된 코드들을 수정하고서 push 하기
- 다시 master에서 pull로 PC와 서버와 환경을 똑같이 만든다음에, master를 branch로 옮기고 merge 해버린 후 push 하기
6. 그 이후는?
하나의 branch를 만들고서 작업을 한 뒤, merge까지 완료되면 서버에 올라와있는 파일들이 업데이트 될것이다.
여기서 조심해야할것은 내가 이전에 local repository에 clone 했던 파일들과 merge까지 해버린 remote repository의 파일들이 달라진다는 것이다.
그렇다면 내 PC에 다시 한 번 서버에 올라온 프로젝트 상태와 동일한 상태로 만들어줘야한다.
지금 우리가 완료한 branch는 이제 가차없이 버려버리자.
git checkout master 로 다시 한 번 PC의 메인 줄기로 돌아오자.
그 다음에 git pull origin master 명령어로 origin이라는 이름의 서버에서 우리 PC의 메인 줄기인 master로 업데이트된 프로젝트를 당겨오자.
이제 서버에서 새롭게 업데이트 된 파일들이 다시 한 번 내 PC로 들어왔다.
새로운 branch를 만들어서 소스코드를 다시 한번 만들려면 항상 이렇게 서버와 자기 PC의 환경을 동일하게 만들어주는게 중요하다.
