깃(Git) 개념과 상황별 팁

기본 개념과 명령어

초기화

깃을 올바로 사용하려면 깃이 파일의 변경 내용을 추적하는 방식을 이해하는 것이 무척 중요하다. 그렇지 않고 백업 용도로만 깃을 사용하면 장님이 코끼리 만지는 것처럼 딱 그만큼만 알게 되기 때문이다.

 

깃은 폴더의 어떤 파일이라도 모두 트래킹 할 수 있다. 원하는 폴더로 이동해 깃 초기화 커맨드부터 시작한다.

$ git init

 

.git 이라는 이름의 숨김 폴더가 하나 생긴다. 이것을 저장소라고 하는데 깃은 이 폴더의 모든 변경 내용을 여기에 저장한다. 이 파일을 지우면 더 이상 깃으로 폴더의 변경사항을 추적할 수 없다.

 

 

스테이징

깃이 파일의 변경 내역을 저장하는데 곧바로 저장하는 것이 아니라 스테이징이라는 단계를 거친다. 스테이징은 변경사항 중에서 저장하고 싶은 부분만 선택해 임시로 저장하는 갠며이다. 코드를 변경하고 깃 상태를 먼저 봐보자.

$ git status

Untracked files:
  (use "git add <file>···" to include in what will be committed)
  file.txt

 

폴더의 현재 변경 상태를 보는 명령어다. 폴더에는 file.txt 파일이 있는데 아직 깃이 이 파일을 트래킹하지 않아서 "Untracked files" 목록에 있다.

 

추적하고 싶은 파일을 스테이지에 넣기 위해서는 변경된 파일을 선택하거나,

$ git add file.txt

 

폴더의 전체 변경 사항을 지정할 수 있다.

$ git add .

 

스테이징 된 파일은 이렇게 커밋 직전 상태로 변경된다.

$ git status
Changes to be committed:
  new file:  file.txt

 

 

커밋

깃이 폴더의 변경 내용을 저장하는 단위를 커밋 `commit` 이라고 부르는데, 이처럼 먼저 스테이징 상태에 두어야만 비로소 커밋을 만들 수 있다. 스테이지에 있는 내용으로 커밋을 만들려면 `commit` 명령어를 사용한다.

$ git commit

 

기본 에디터가 열리고 변경 내용을 기록할 수 있는 입력 화면이 나온다. 변경 내용을 설명할 수 있는 텍스트를 입력하고 저장하면 커밋이 생성된다.

 

에디터를 열지않고 터미널에서 바로 메세지를 입력할 수 있는 `-m` 옵션도 자주 사용한다.

$ git commit -m "여기에 커밋메세지를 입력합니다."

 

매번 변경사항을 스테이징하고 커밋하는게 번거롭다면 `-a` 옵션을 사용하자. 신규 파일을 제외하고 트래킹 하는 모든 파일의 변경사항을 스테이징함과 동시에 커밋을 만들 수 있는 옵션이다. `-m` 과 함께 사용할 수 있다.

 

$ git commit -am "스테이징과 커밋을 한번에!"

 

커밋을 만들지 않고 이전 커밋에 변경사항을 추가하고 싶은 경우도 있다. 가끔 이전 커밋에 미쳐 포함하지 못한 코드가 있을 수 있는데, 이전 커밋에 현재 변경 내용을 추가할 때는 `--amend` 옵션을 사용한다.

$ git commit --amend

 

에디터가 뜨면서 마지막 커밋 메시지를 수정하는 화면이 나온다. 저장하고 에디터를 닫으면 이전 커밋에 변경 내용이 추가된다.

 

 

로그

스테이징을 거쳐 커밋한 결과를 어떻게 볼 수 있을까? 깃은 커밋 목록을 로그(log)라는 형식으로 볼 수 있다.

$ git log

 

commit 5ede63b20ee6237c345a7595d6f353c86eb3388b (HEAD -> master)
Author:   name <mail@mail.com>
Date:       Mon Feb 3 09:36:02 2020 +0900

      두번째 커밋입니다.

commit 5ede63b20ee6237c345a7595d6f353c86eb3388b (HEAD -> master)
Author:   name <mail@mail.com>
Date:       Mon Feb 3 09:36:02 2020 +0900

     첫번째 커밋입니다.

 

두 개의 커밋이 있는 로그다. 각 커밋을 식별할 수 있는 커밋 해쉬값이 먼저 나온다. 그 다음 커밋 작성자와 작성일자, 마지막으로 변경 내용을 기록한 커밋 메세지를 확인할 수 있다.

 

커밋에 변경 내용이 반영되었는지 보려면 `show` 명령어를 사용한다.

$ git show

  테스트 파일입니다.
-수정함
+지우고 수정함

 

삭제한 라인은 앞에 `-`를, 추가한 라인은 `+`로 표시한다.

 

특정 커밋의 변경사항을 보고 싶다면 로그에 있는 커밋 해쉬로 볼 수 있다.

$ git show 5ede63b20ee6237c345a7595d6f353c86eb3388b

 

 

브랜치

깃에서 중요한 또 하나의 개념은 브랜치(branch) 이다. 로그에서 보는 것처럼 깃이 관리하는 변경 이력은 마치 자라나는 나무같다. 그래서 "깃 트리"라고 하는지도 모르겠다. 나무는 성장하면서 또 다른 가지를 뻗어 내는데, 깃도 이런 방식의 가지를 만들 수 있고 가지를 브랜치라고 부른다.

 

브랜치를 만드는 이유는 뭘까? 지금하고 있는 작업과 성격이 다른 작업을 할 때 브랜치를 만든다. 가령 A 기능을 만들다가 B 기능을 만들어야 한다면 브랜치를 새로 만들어 B를 개발하는 방식이다.

 

깃은 기본적으로 main 이라는 이름의 브랜치를 하나 가지고 있다. `branch` 명령어로 브랜치 목록을 확인하자.

$ git branch

* main

 

그럼 지금 작업하고 있는 내용과 성격이 다른 작업을 하기 위해 feature 라는 이름의 브랜치를 하나 만들어 보자. `branch` 명령어를 사용할 때 두 개 브랜치 명을 전달하는데 "생성할 브랜치 명" "기준 브랜치 명" 순서다.

$ git branch feature master
$ git branch

   feature
* main

 

feature 브랜치가 추가되어 총 두 개의 브랜치가 있다. 여전히 현재 브랜치는 앞에 별표(*)가 있는 main 브랜치다. 새로 만든 브랜치로 이동하고 싶은데 깃에서 브랜치간의 선택은 체크아웃한다(checkout) 라고 표현한다.

$ git checkout feature
$ git branch

* feature
   main

 

이 둘을 한번에 하려면, 즉 브랜치를 만들면서 선택하려면 기준 브랜치에서 `-b` 옵션을 주고 체크아웃 하는 방법이 있다. 예를 들어 main 브랜치에서 feature 브랜치를 만들고 체크아웃 하려면 이렇게 하면된다.

$ git checkout -b feature

 

feature 브랜치에서 개발하고 커밋을 계속 만든 뒤 다음 단계는 뭘까? 브랜치에 만든 커밋들을 다시 원래 브랜치인 main에 반영해야 한다. 이것을 병합(merge)이라고 부른다.

$ git checkout main
& git merge feature

 

기준이 되는 main 브랜치로 이동한 뒤, feature 브랜치를 main에 머지한다.

 

 

헤드

브랜치간에 이동하다 보면 현재 내가 어느 브랜치에서 작업하는지 알아야 한다. 간단하게는 브랜치 목록에서 현재 어느 브랜치인지 알 수 있다.

$ git branch

   feature
* main

 

앞에 별표(*) 된 것이 현재 브랜치다.

 

위치를 좀 더 정확하게 보여주는 정보가 있는데 바로 머리(HEAD) 라고 부르는 것이다. 헤드는 여러 개 가지로 뻗어있는 브랜치와 커밋 목록에서 현재 위치를 나타낸다.

$ git log

commit 23427f8fb1baa80a5f0c9f974ba16dd0212edd69 (HEAD -> main)
commit d4b18ac8dc8f1e29a6082163b9329ffabd5bca96 (feature)
commit 18383c3d504208864ec73e7845d126a4824a43d6

 

main 브랜치 끝에 헤드가 표시되어 있다. 지금 작업하고 있는 위치다.

 

체크아웃 하면서 브랜치를 이동할 때 마다 헤드는 수시로 변경된다. 뿐만 아니라 특정 커밋으로 체크아웃 할 수 있는데 이 때도 헤드는 그 커밋으로 이동한다.

$ git checkout 18383c3d504208864ec73e7845d126a4824a43d6
$ git log

* 23427f8fb1baa80a5f0c9f974ba16dd0212edd69 (main)
* d4b18ac8dc8f1e29a6082163b9329ffabd5bca96 (feature)
* 18383c3d504208864ec73e7845d126a4824a43d6 (HEAD)

 

 

 

상황별 팁

이 정도로 깃에 대해 개념을 간단히 정리하고, 상황별로 깃 명령어를 어떻게 사용할 수 있는지 알아보자.

 

1. 필요한 라인만 커밋하고 싶어요

보통 변경된 파일을 스테이징한 뒤 이것을 커밋하기 때문에 커밋은 파일단위로 묶이게 된다. 의미있는 커밋 메세지를 유지하려다보면, 파일의 라인 단위로 변경사항을 묶고 싶을 경우가 있다. 지금까지 이런 식의 커밋을 위해 변경된 내용을 복사 붙여넣기 했다면 아래 방식도 사용해 보길 바란다.

$ git add -p

 

변경한 라인만 스테이지에 넣는 것이 바로 `-p` 옵션이다. 이렇게 하면 변경된 파일을 하나씩 열어 스테이징 할지 말지 결정하면 된다.

   기존 코드입니다.
+ 여기는 나중에 커밋하고요
   기존 코드입니다.

_
+ 이 부분을 커밋하고 싶어요.
+ 이곳도 나중에 커밋합니다.
Stage this hunk [y,n,q,a,d,s,e,?]? s

 

`s` (split)을 입력하면 변경 단위를 더 세밀하게 쪼갠다.

   기존 코드입니다.
+ 여기는 나중에 커밋하고요
   기존 코드입니다.
   Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? n

 

기존 코드 기준으로 변경사항을 분할해서 보여준다. 이 부분을 스테이징에서 제외하려면 `n` (no) 을 입력하고 다음 분할 부분으로 넘어간다.

   기존 코드입니다.
+ 이 부분을 커밋하고 싶어요.
+ 이 곳도 나중에 커밋합니다.
Stage this hunk [y,n,q,a,d,K,g,/,e,?]? e

 

변경된 코드가 연속으로 있을 경우 깃은 스스로 코드를 분할할 수 없다. 이러한 경우에는 `e` (edit)를 입력하고 편집 모드로 들어가 직접 스테이징할 라인을 선별할 수 있다.

 

# Manual hunk edit mode -- see bottom for a quick guide.
4   기존 코드입니다.
5
7 + 이 부분을 커밋하고 싶어요.
8 + 이 곳도 나중에 커밋합니다. --> 스테이징에서 제외하려면 이 라인을 삭제한다.

 

추가된 코드 중 7번 라인만 스테이징 하려고 한다. 이 부분을 남겨두고 아래 8번 라인만 제거하면 된다.

 

이렇게 선택적으로 스테이징한 뒤 커밋하면 훨씬 의미있는 커밋을 만들 수 있다.

 

이제 이걸 커밋으로 생성해야 하는데 커밋에 `-v` (verbose) 옵션을 주면 스테이징된 부분을 자세히 볼 수 있다.

$ git commit -v

 

 

2. 커밋의 변경내용을 자세히 보고 싶어요

깃은 파일의 변경 내용과 요약 메세지, 작성자, 작성일 등의 메타 정보를 모두 합쳐서 하나의 커밋을 만들어 낸다.

 

`log` 명령어로 간단한 커밋 정보를 볼 수 있었다면 `show` 명령어로 더 자세한 내용을 조회할 수 있다.

$ git show

   기존 코드입니다.
- 여기는 삭제될 부분이에요.
+ 여기를 마지막에 추가했어요

 

기존 내용에서 삭제/추가한 부분으로 나누어 표시한다. 삭제한 줄은 `-`로, 추가한 줄은 `+`로 확인할 수 있다.

 

그런데 깃 트리에 많은 커밋 중에 어떤 커밋의 내용을 보여주는 걸까? `show`는 기본적으로 HEAD가 가리키고 있는 커밋의 정보를 조회한다. 특정 커밋의 내용을 보려면 커밋 식별자인 커밋해쉬로 식별한다.

 

$ git show 7ad18c6b000554ed69dbabe7344b67d8beda6915
# 혹은
$ git show 7ad18c6

 

해쉬값을 사용하거나 이 값이 너무 길면 앞의 7자리만 사용해서 해쉬값에 해당하는 커밋의 변경사항을 볼 수 있다.

 

하나의 커밋에서 많은 파일을 변경했을 경우에는 파일별로 변경내용을 요약해서 볼 수도 있다.

$ git show --stat

두개 파일을 수정합니다.

file.txt     |  5 +++--
file2.txt   |  1 +
2 files changed, 4 insertions(+), 2 deleteions(-)

 

file.txt는 5개 라인을 변경했는데 3줄을 추가하고 2줄을 삭제했다. file2.txt는 1줄을 추가했다. 총 2개 파일을 변경했고 4줄 추가하고 2줄 삭제한 커밋이다.

 

주로 과거에 작업했던 내용을 찾아볼 때 이 명령어를 자주 사용한다. 어떤 내용을 변경했는지 라인별로 확인하고 한 커밋에 변경한 파일이 많으면 `--stat` 옵션으로 파일 목록을 확인한다.

 

그런 뒤 특정 파일의 변경사항은 파일명을 지정해서 확인하는 편이다.

$ git show 7ad18c6 file.txt

 

이렇게 커밋 내용을 자세히 볼 수 있기 때문에 웬만하면 주석은 그냥 지우는 편이다. 삭제했다는 내용의 메세지로 커밋을 저장하고 나중에 주석 대신에 삭제한 커밋을 들여다 보는 것이 코드를 비교적 가볍게 가져갈 수 있기 때문이다.

 

 

3. 커밋하기는 좀 그렇고··· 변경사항을 임시 저장할 수 있나요?

작업을 하다가 임시 저장해야 하는 상황이 있다. 커밋 메세지도 떠오르지 않고 그냥 잠깐 저장하고 다른 작업을 하고 싶을때가 그렇다. 처음에는 "WIP" (Work In Progress) 라는 작업중 메세지로 커밋을 만들곤 했었다.

 

하지만 몇 년 전부터 동료들이 `stash` 명령어를 사용하는 걸 보곤 나도 무척 잘 활용하고 있다.

"숨겨두다" 라는 의미의 이 명령어는 커밋하기에는 충분치 않지만 저장은 해야하는 이런 상황을 위한 것이다.

$ git stash

 

이 명령어를 실행하고 나면 현재 폴더의 변경내용이 다른 어딘가로 저장되고 변경된 내용이 파일에서 사라진다.

 

stash도 커밋처럼 하나의 단위로 저장되는 stash 목록을 확인할 수 있다.

$ git stash list

stash@{0}: WIP on main: 7ad18c6 두 개 파일을 수정합니다

 

여기서 한번 더 내용을 수정하고 stash 하고 목록을 보면 추가된 stash가 기존 목록 위에 쌓인다. 마치 스택처럼 말이다.

$ git stash list

stash@{0}: WIP on main: 7ad18c6 두 개 파일을 수정합니다.
stash@{1}: WIP on main: 7ad18c6 두 개 파일을 수정합니다.

 

임시 저장한 변경 내용을 되돌리려면 팝(`pop`)으로 꺼낸다.

$ git stash pop

 

그럼 임시 저장했던 변경 내용들이 파일에 다시 복구되었을 것이다.

 

지라 같은 업무 관리 툴로 일을 하다보면 업무 간에 스위칭이 잦은 경우가 있다. 이 때 잠시 stash로 지금 작업 내용을 저장하고 다른 업무를 보면 좀 더 코드 관리하기가 쉽다.

 

 

4. 히스토리를 예쁘게 보고 싶어요

로그 트리 때문에 터미널에서 깃을 사용하는걸 부담스럽게 여긴다면 잠깐만 여길 봐 보시라. 깃 로그 명령어는 꽤 많은 옵션을 가지고 있다. 먼저 `--graph` 옵션으로 로그를 봐 보자.

$ git log --graph

 

https://jeonghwan-kim.github.io/dev/2020/02/10/git-usage.html#%ED%97%A4%EB%93%9C

 

터미널에서도 그래프를 볼 수 있다는 점에 놀라웠는가? 이제 여기에다가 조금씩 그래프를 예쁘게 만들어 볼 수 있다.

 

보통 커밋해쉬를 다 보진 않는다. 해쉬값 전체를 사용하는 경우도 없었고 말이다. 커밋 해쉬값을 앞에 7자리만 간단히 보여주는 것이 좋겟다. `--abbrev-commit` 옵션을 추가해보자.

$ git log --graph --abbrev-commit

https://jeonghwan-kim.github.io/dev/2020/02/10/git-usage.html#%ED%97%A4%EB%93%9C

 

커밋 해쉬값이 짧아져서 좀 덜 부담스럽다.

 

하나의 로그가 좀 길다. 중요한 메세지만 남기고 로그 그래프를 더 보고 싶다면 `--pretty` 옵션을 추가 해보자.

$ git log --graph --abbrev-commit --pretty=oneline

https://jeonghwan-kim.github.io/dev/2020/02/10/git-usage.html#%ED%97%A4%EB%93%9C

 

커밋 해시와 메세지만 한 줄로 나오고 더 많은 커밋 그래프를 볼 수 있다.

 

모든 브랜치와 태그를 함께 보고싶은가?

$ git log --graph --abbrev-commit --pretty=oneline --all

 

main 브랜치 외에도 feature 브랜치의 트리도 볼 수 있다. 뿐만 아니라 태그도 같이 표기한다.

https://jeonghwan-kim.github.io/dev/2020/02/10/git-usage.html#%ED%97%A4%EB%93%9C

 

밋밋했던 커밋 로그가 그래픽 도구 못지 않게 훌륭해졌다.

 

 

5. 히스토리를 변경하고 싶어요

A 작업을 마치고 커밋, B 작업을 마치고 커밋, A' 작업을 마치고 커밋을 만들었다. 깃 로그는 A -> B -> A' 순으로 쌓이게 된다. 이왕이면 관련된 커밋을 한 곳으로 모으곳 ㅣㅍ다.

 

지라 따위의 애자일 도구를 사용한다면 이런 경우가 자주 발생할 수 있다. 작업 번호로 커밋 메세지를 만들텐데 앞에 지라 번호를 붙여 메세지를 작성할 것이다.

* da964a1 [TASK-A] A 작업 추가함 (HEAD -> main)
* 758713d [TASK-B] B 작업함
* d323105 [TASK-A] A 작업함

 

마지막 두 개의 커밋 순서를 바꾸면 작업을 이해하는데 더 좋고 의미있는 커밋이 될 것 같다. 코드의 가독성 뿐만 아니라 커밋의 가독성도 그것만큼 중요하니까 말이다.

 

리베이스 `rebase`를 이용하면 커밋 순서를 변경할 수 있다.

$ git rebase -i HEAD~3

 

HEAD를 포함한 이전 3개 커밋을 재작성(rebase) 한다는 뜻이다.

 

에디터가 열려 커밋 목록이 나오고 여기서 순서를 변경할 수 있다.

1 pick d323105 [TASK-A] A 작업함
2 pick 758713d [TASK-B] B 작업함
3 pick da964a1 [TASK-A] A 작업 추가함
4
5 # Rebase 23427f8..da964a1 onto 23427f8 (3 commands)
6 #
7 # Commands:
8 # p, pick <commit> = use commit
9 # f, fixup <commit> = like "squash", but discard this commit's log message

 

만약 두 개의 커밋을 하나로 합치고 싶다면 마지막에 있는 'A 작업 추가함'을 2번 라인으로 옮긴다. 그리고 `pick` 대신 `fixup` 혹은 줄여서 `f`를 입력한다. 그럼 이 커밋을 1번 라인에 있는 커밋과 합친다는 의미다 (리베이스 액션에 대한 자세한 설명은 하단의 주석을 참고)

1 pick d323105 [TASK-A] A 작업함
2 fixup da964a1 [TASK-A] A 작업 추가함
3 pick 758713d [TASK-B] B 작업함
4
5 # Rebase 23427f8..da964a1 onto 23427f8 (3 commands)

 

이렇게 수정하고 저장하고 편집기를 닫으면, 1, 2번 라인의 변경내용을 합쳐 커밋을 다시 생성하는데 사용할 커밋메세지 입력을 위해 에디터가 다시 열린다. 저장하고 닫으면 커밋이 3개에서 2개로 변경된다.

* 1d31ae4 [TASK-A] A 작업함 (HEAD -> main)
* ebbc74a [TASK-B] B 작업함

 

 

6. 브랜치 간의 변경사항을 보고 싶어요

main 브랜치를 운영서버에 배포하고 develop 브랜치를 개발서버에 배포하는 구조라고 하자. 오늘이 배포하는 날이다. 어떤 사항을 배포하는지 확인하고 싶을 경우가 있다. 커밋 단위로 말이다.

 

즉, 지금 운영중인 main 브랜치에 비해 오늘까지 개발한 develop 브랜치의 변경사항을 커밋별로 보고 싶을 때는 아래 명령어를 사용하자.

$ git log main..develop

 

기준이 되는 브랜치(여기서는 main)를 앞에 먼저 입력하고 `..` 뒤에 비교할 브랜치(여기서는 develop)를 입력한다. 이렇게 나온 커밋 목록으로 main 브랜치 대비 develop 브랜치에 추가한 변경내용을 파악할 수 있다.

 

 

7. 원격 저장소와 연결하고 싶어요

깃헙 같은 원격에 있는 저장소를 컴퓨터에 다운로드 하는 것을 복제(clone)한다 라고 한다.

 

원격 저장소는 다운로드를 위한 주소를 제공하는데 git으로 시작되는 주소나 https로 시작하는 주소를 제공한다. ssh 방식이고 공개키가 서버에 등록되어 있다면 이 방식으로 다운로드 할 수 있다. 후자는 아이디와 비밀번호를 사용해서 다운로드 할 수 있다.

 

보통 깃헙을 원격저장소로 많이 사용하는데 공개키를 등록해서 ssh 방식으로 사용하는 편이다.

$ git clone {원격 저장소 주소}

 

다운로드한 원격 저장소는 저장소 이름으로 로컬에 폴더를 생성한다. 여기서 작업을 하고 커밋을 만든 뒤 원격으로 내용을 업로드 하는 것을 "푸시(push)"라고 한다.

$ git push origin HEAD

 

협업하다보면 원격저장소를 클론한 다른 사용자가 코드를 먼저 푸시했을 수도 있다. 이럴땐 저장소의 최신버전을 가져와야 하는데 이것을 패치(fetch)라고 한다.

$ git fetch

 

패치하면 원격 저장소의 최신 업데이트 내용을 로컬에 가져올 수 있다.

 

가져온 변경사항을 현재 브랜치와 머지하려면 `pull` 명령어를 사용한다.

$ git pull origin master

 

원격 저장소의 변경 내용을 가져와 로컬 저장소에 반영된다. 패스트 포워드가 가능하면 바로 반영하고 그렇지 않으면 머지 커밋을 추가로 만든다.

 

내가 작업한 내용을 깨끗하게 유지하고 싶으면 머지 커밋을 만들지 않고 리베이스로 변경사항을 반영할 수도 있다.

$ git pull origin master --rebase

 

이렇게 하면 원격저장소에 있는 변경사항을 먼저 쌓고 그 위에 내가 작업한 변경사항을 쌓는 방식이다.

 

나는 머지보다 리베이스를 선호하는 편이다. 커밋 그래프를 좀 더 단순하게 유지하고 싶어서 그렇다.

 

 

8. 원격 저장소를 여러개 관리하고 싶어요

원격 저장소로부터 클론하면 원격지 일므은 기본적으로 "origin"이다. `remote` 원격지를 관리하는 명령어인데 `-v` 옵션으로 원격저장소 목록을 볼 수 있다.

$ git remote -v

 

원격 저장소는 여러개 붙일 수 있다. 원격 저장소가 여러개 있어야 할 이유는 뭘까?

 

깃헙 포크를 이용하면 이게 무척 유용하다. 깃헙의 포크는 타인의 계정에 있는 저장소를 내 계정의 저장소로 하나 가져오는 기능이다. 내 계정으로 포크한 저장소를 클론하면 기본 이름인 origin으로 가져온다.

 

만약 타인의 원격 저장소에 변경사항이 있는데 이걸 내 로컬에 가져오고 싶으면 어떻게 할까? 이때 "원격 저장소 하나를 더 추가"할 수 있다. 보통은 upstream이란 이름으로 원격저장소 하나를 더 추가한다.

$ git remote add upstream {원격저장소주소}

 

이렇게 하면 하나의 저장소에 두 개의 원격지를 연결할 수 있다. origin으로 내 원격 저장소에 코드를 푸시하다가, 원본 저장소의 변경사항을 받을때는 upstream을 사용한다.

 

원격 저장소의 주소를 변경하고 싶을때는 `set-url`로 변경할 수 있다.

$ git remote set-url {변경된 원격저장소 주소}

 

물론 원격 저장소의 이름을 변경할 수도 있다.

$ git remote -m {저장소 이름} {저장소 이름 신규}

 

 

정리

가끔 프로젝트를 맡게되면 기존 코드를 훑어보고 커밋 로그를 들여다 본다. 어떤 코드는 커밋 단위가 명확해서 코드를 변경한 의도가 쉽게 이해된다. 한편 정보가 부족한 커밋 메세지는 코드 변경 내용만 보고 파악해야 하는데 이게 쉽지 않은 일이다.

 

특히 코드리뷰를 요청받게 되면 커밋 작성법에 대한 아쉬움이 많이 남는다.

 

"A 기능 구현" 이라고 메세지를 기록한 커밋을 들여다보면 구현한 코드의 양이 무척 많다. 그 코드에는 기능 구현을 위한 작업들이 통째로 들어가 있는 경우가 대부분이다. 에디터가 컨벤션 규칙에 따라 자동으로 수정한 변경 내용이 포함된 경우도 있다. 기능 구현과는 아무런 관계가 없는 코드인데도 말이다.

 

이런 코드리뷰는 사실 잘 안하게 된다. 깃 사용 방법을 조금이라도 더 알았더라면.. 그리고 조금만 더 꼼꼼하다면 이라는 아쉬움이 남는다.

 

코드 뿐만 아니라 글도 깃을 활용하면 좋겠다는 생각을 한다. 물론 워드파일처럼 어플리케이션만의 인코딩 처리의 저장 방식을 따르는 파일을 변경사항까지 추적하는건 한계다. 만약 마크다운으로 글을 쓴다면 깃으로 관리하는 것이 무척 편하다.

 

 

---

 

 

https://jeonghwan-kim.github.io/dev/2020/02/10/git-usage.html#%ED%97%A4%EB%93%9C

깃(Git) 개념과 상황별 팁