I Love Salsa~~

로컬의 A 파일을 수정 중 (아직 커밋을 할 순 없다)

원격의 A 파일이 수정 됨

이때, A 파일을 merge하기 위해서 로컬에서 작업 중인 많은 소스들을 stash에 담아야 하는데...

merge하고자 하는 파일만 stash 후 merge 진행 방안

로컬의 특정 파일만 stash로 진행

-m "message" -> stash 내용을 구분하도록 메시지 추가

-- 파일명 -> 특정 파일만 stash

remote의 최신 변경 사항을 가져오고

stash한  파일을 remote 버전으로 덮어쓰고

원격의 변경된 내용을 확인하고 (출력된 정보가 없으면 변경 사항이 없는 거)

stash 파일로 병합 진행을 해야 하는데, pop과 apply의 옵션으로 나누어지고

그래서, 안전하게

를 선택했는데, 젠장... 충돌!

충돌 해결 방안은 3가지 중 직접 해결하는 방법으로 선택(이 아닌 필수일 듯)

- vs code에서 해당 파일의 충돌 부분이 표시(<<< HEAD, ====, >>> stash)가 되니 원하는 코드로 수정 후 저장

- cli에서 원격 버전으로 덮어쓰기인데, stash 내용을 무시하는 방법  (어휴.. 알아보지도 말자)

- cli에서 stash 변경 내용 유지인데, 로컬 변경 사항을 무시하는 방법 (어휴.. 알아보지도 말자x2)

vs code를 통해서 충돌 해결을 하면, 이 파일은 자동으로 staged changes 영역으로 이동을 하게 되어

아직, 커밋 단계가 아니라서 changes 영역을 내리고자

기존에 

git fetch origin branch

를 사용하였으나, 결국 pull 동작이 필요하기에 정신 건강을 위해서 

commit & push 이후 에러가 발생하거나

또는 pull이나 fetch를 하지 않고 commit & push를 ㅎ했을 때 오류가 발생한다

이때, rollback 방법은 아래와 같은데, 바로 직전의 commit을 취소하게 된다

이거야 말로 내가 보기 위해서 정리 중인 것

기능	명령어	설명
remote와의 연결 또는 연동	git config-global user.name "user_name"
remote의 프로젝트 clone	git clone http://192.168.1.2:8081/url.git	- 굳이 프로젝트의 디렉토리를 생성할 필요가 없다 - 프로젝트들의 상위 디렉토리에서 실행하면 하위 디렉토리에 프로젝트별로 생성이 된다
로컬의 기본 브랜치 변경 - clone 이후	git checkout dev	- dev 브랜치가 기본으로 설정이 되어 있어도 clone을 하게 되면 master 또는 main이 기본 브랜치로 보이게 된다 - 프로젝트별로 설정
로컬의 기본 브랜치 확인	git branch	- 프로젝트 별로 확인
로컬의 기본 브랜치 변경	git symbolic-ref HEAD refs/heads/dev	- 프로젝트 별로 설정 - refs/heads/main 파일을 삭제해 봐야 기본 브랜치는 변경되지 않는다는 점을 유의해야 할 사항

GitHub에서 토큰 로그인 방식으로 인하여 토큰을 발급하는 방법을 확인해 본다.

1. 우측 상단 프로필을 클릭하여 Settings 메뉴를 클릭

2. 프로필 설정 화면에서 좌측 메뉴 중 Developer settings를 클릭

3.  Personal access tokens에서 Tokens (classic)을 클릭

4. Node에 토큰 이름을 입력하고,  Select scopes에는 허가할 권한을 체크한 후 아래쪽의 Generate token 버튼을 클릭

- 외부에서 로그인할 때 필요한 권한에만 체크한다. (어느 메뉴가 외부인지는 아직 확인이 더 필요한 상태임)

5. Update token 버튼 클릭 후 나오는 화면에서 토큰 정보를 복사한 후 외부에 저장

1. 자바로 GIT 다운로드 프로그램을 작성하다 나온 에러임

2. 해당 에러는 Eclipse 동작에서 나오는 에러로 검색이 되지만, 
    GIT의 사용자 정보인 id 또는 password가 상이할 때에도 나오는 에러

1. git$ git rm --cached -r directory_name
    or
    git$ git rm --cached file_name

2. git commit -m "delete directory"

3. git push origin branch_name

3번 부분을 진행하지 않으면 원격 저장소에 반영이 되지 않는다.

Git 명령어로 생성된 브랜치로 옮길 때 에러 발생

현상 : 

1. Git Bash 에서 새로운 브랜치로 push할 디렉토리로 이동

2. [git]$ git init

3. [git]$ git remote add url

4. gitlab 웹 페이지에서 브랜치  'test1' 생성

5. [git]$ git checkout new_branch

error: pathspec 'test1' did not match any file(s) known to git

조치 방안 :

1. [git]$ git remote update

2. [git]$ git fetch

3. [git]$ git checkout test1

Step 1. Repository 생성

1. 오른쪽 상단의 + 표시를 누른 뒤 New repository를 선택

2. Repository name 입력

3. Description 입력

4. Initialize this repository with a README 선택

5. Create repository 버튼 클릭

Step 2. Branch 생성

GitHub는 기본값으로 repository에 master라는 branch를 가지고 있다.

그러나 다른 branch를 생성하여 master에 commit하기 전에 테스트 및 수정하기 위해서 사용된다.

1. master라고 되어 있는 콤보 메뉴를 클릭

2. 새로운 branch 이름 기입(예로 sub-branch)

3. Create branch : sub-branch from 'main' 버튼을 클릭하면 branch가 생성됨

이제 branch는 두개(master와 sub-branch)가 생성이 되었으며, master의 복사본인 sub-branch branch가 생긴 것이다.

이제 새로운 branch에 변경 사항을 추가한다.

Step 3. 변경 사항 commit

1. READM.md를 클릭

2. 내용을 수정하기 위해서 우측의 Editthis file 버튼을 클릭

3. 수정할 내용을 입력

4. 변경 사항에 대하여 commit message을 입력한 후 Commit changes 버튼 클릭

이제 이 변경된 README 파일은 sub-branch branch에만 적용이 되며, master의 내용과 다른 내용이 생기게 된다.

Step 4. Open Pull Request

이제 master branch와 변경 사항이 발생하였기에 pull request를 열 수 있다.

Pull request를 통해서 변경된 내용을 리뷰하고, 프로젝트 소유자(해당 코드 담당자)가 master branch로 pull request merge를 할 수 있다.

1. 상단 메뉴 중 Pull request 메뉴를 누르고, 이어서 New pull request 버튼을 클릭

2. Compare changes 화면 상단의 compare: main을 클릭하여 sub-branch로 선택

3. 비교 페이지에서 변경 사항에 대하여 확인 가능

4. 변경 사항에 대하여 확인이 되었으면 상단의 Create pull request 버튼을 클릭

5. 변경 사항에 대하여 추가 설명이 있으면 입력한 후, 하단에 위치한 Create pull request 버튼을 클릭

Step 5. Merger pull request

변경 사항에 대하여 리뷰가 문제없이 끝났으므로 main branch에 merge를 해야 한다.

1. Merge pull request 버튼을 클릭

2. Comfirm meger 버튼을 클릭

3. main branch로 merge가 완료 되었으므로, Delete branch 버튼을 클릭하여 sub-branch에 대하여 삭제를 진행한다.

4. sub-branch가 삭제되었다는 메시지를 확인

5. 상단 메뉴에서 Code를 클릭한 후 main 콤보 박스를 선택하면 sub-branch branch가 삭제됨을 확인 가능

이상 여기까지가 GitHub의 Pull request를 통한 코드 리뷰 방법을 사용하는 방법을 테스트 해 보았다.