잘못해서 깃허브에 암호 파일이라던지, env 파일을 올려 난감한 상황에 처할 때가 있습니다. 저도 최근 .env 파일을 push 해서 난처한 상황에 처하고 말았는데요. 이렇게 푸시까지 이루어진 상황에선 히스토리가 남아 지우더라도 기록이 남게 되어 보안상의 이슈가 발생하게 됩니다.

 

.git 폴더를 지우고 새로 git init 을 통해 다시 레포를 정리하라는 글도 많았지만 열심히 구글링하며 찾아보니, 다행히도 이럴 때를 대비하여 사용할 수 있는 git 명령어가 있는데요. git filter 명령어입니다. 이 명령어를 사용하면 해당 파일을 git 전체 히스토리에서 필터링해여 재작성해줍니다.

$ git filter-branch -f --index-filter 'git rm --cac
hed --ignore-unmatch [파일 이름과 위치]' --prune-empty -- --all

안에 git rm --cached 는 리모트 브랜치에 있는 해당 파일을 정리해줍니다. 위 파일 이름과 맞지않는 파일들은 무시한채로 해당 파일만 원격 브랜치에서 삭제해주는거죠. 여기서 중요한 게 파일명만 적어주면 안됩니다. 파일 위치와 이름을 같이 적어줘야 작동하더라구요.

$ git push origin [브랜치 명] --force

이후 브랜치가 재작성 되면 원격 저장소와 로컬 저장소의 브랜치가 서로 나뉘어 있습니다. 위 명령어를 통해 강제로 push 해주어 로컬 브랜치를 원격 브랜치로 넣어주면 됩니다! 모든 브랜치를 재작성했기 때문에 브랜치별로 다 해야되더라구요. 하나하나 브랜치 명을 적어주며 마무리하면 깔끔하게 정리할 수 있습니다!

마지막으로 이 작업이 끝나셨다면 .gitignore 파일에 해당 파일을 등록해 놓는 것이 좋겠죠? 저처럼 .env 파일같은 경우엔 *.env 이라고 .gitignore에 등록해두면 다음 번에 다시 잘못 올라가는 위험을 방지할 수 있습니다.

 

출처: https://donologue.tistory.com/373

 

github 잘못 올라간 파일 히스토리까지 삭제하기

잘못해서 깃허브에 암호 파일이라던지, env 파일을 올려 난감한 상황에 처할 때가 있습니다. 저도 최근 .pem 파일을 push 해서 난처한 상황에 처하고 말았는데요. 이렇게 푸시까지 이루어진 상황에

donologue.tistory.com

 

'Git' 카테고리의 다른 글

git pull error 해결 방법  (0) 2023.05.19
[Git] Open Source Software  (0) 2023.04.06
Git 협업하기  (0) 2022.12.30
브랜치 사용하기  (0) 2022.12.30
커밋 다루기 정리 노트  (0) 2022.12.30

다른 사람과 함께 협업하고 있는 레포지토리에 내가 작업한 내용을 올리려고 하는데

내가 작업하는 동안 다른 사람이 커밋을 했다면 어떻게 될까요?

 

로컬 레포지토리가 원격 레포지토리보다 이전 버전을 가리키고 있기 때문에,

바로 커밋할 수는 없을거에요...

 

그래서 로컬 저장소와 원격 저장소의 버전을 맞춰주기 위해 git pull을 해봤더니,

다음과 같이 에러가 발생하네요!

$ git pull
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 6 (delta 4), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (6/6), 2.11 KiB | 56.00 KiB/s, done.
From https://github.com/shinyewon/Jumping_cat
   8655375..f2be300  main       -> origin/main
error: Your local changes to the following files would be overwritten by merge:
        plan.cpp
Please commit your changes or stash them before you merge.
Aborting
Updating 8655375..f2be300

 

error: Your local changes to the following files would be overwritten by merge:
        plan.cpp

협업자 중 누군가가 나와 같은 파일을 수정했다면 merge과정에서 문제가 생길 수 있기 때문에 

이런 에러를 띄워주고 있네요!

 

Please commit your changes or stash them before you merge.라고 하네요.

그럼 먼저 commit을 통해 해결해 볼게요.

 

1. 첫번째 해결법: 수정 내용 커밋하기

다음 명령어들을 순차적으로 실행해주세요!

git add .
git commit -m "[커밋 메시지 입력]"
git pull
git push

그러면 아래와 같이 2개의 커밋을 생성하면서 수정 내용이 원격 저장소에 제대로 반영됩니다.

 

흠..하지만 저는 개인적으로 2개의 commit이 불필요하게 생성되는 것 같아 1개의 commit만 생성하고 싶은데요,

그렇다면 git stash를 사용하면 됩니다!

2. 두번째 해결법: git stash

- git stash 명령어를 통해 작업하던 내용을 임시적으로 저장해주세요!

- git pull

- git stash apply를 통해 방금 임시적으로 저장한 내용을 다시 가져와줄게요.

- 다음 명령어들을 순차적으로 실행해주세요!

git add .
git commit -m "[커밋 메시지 입력]"
git push
git stash clear

그러면 깃허브에 1개의 커밋을 생성하면서 수정 내용이 원격 저장소에 제대로 반영됩니다.

 

읽어주셔서 감사합니다:)

'Git' 카테고리의 다른 글

github 잘못 올라간 파일 히스토리까지 삭제하기  (0) 2023.08.23
[Git] Open Source Software  (0) 2023.04.06
Git 협업하기  (0) 2022.12.30
브랜치 사용하기  (0) 2022.12.30
커밋 다루기 정리 노트  (0) 2022.12.30

What is Github?

Git: Source Control 방법

Github: Git을 기반으로 하는 소프트웨어 프로젝트 관리 사이트

             Open Source 계의 왕

 

What is OSS(Open Source Software)?

  • 소스 코드를 공개해 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있는 오픈소스 라이선스를 만족하는 소프트웨어로서 통상 간략하게 오픈소스라고 말한다.
  • 소프트웨어의 내용인 소스코드가 공개되어 특정 라이선스 방식을 통해 배포되고, 수정, 복제, 사용, 재배포가 자유로운 소프트웨어를 지칭한다.

유명한 오픈소스 소프트웨어

(사진=위키피디아)

오픈소스SW의 장점

  • 낮은 개발 비용
  • 빠른 기술지원과 유연한 개발-최신기술 정보 및 문제점과 해결책을 공유하는 형태로 자유롭게 운영되기 때문에 독점 프로그램에 비해 기술 발전속도가 빠름
  • 오픈 포맷과 프로토콜 -표준화된 포맷과 프로토콜을 사용하기 때문에 서로 다른 SW간 연동성이 보장됨
  • 신뢰성과 안정성-전세계 우수한 개발자들이 개발과 디버깅 과정에 참여하기 때문
  • 강력한 네트워킹 지원-대부분 상용 프로그램과 호환되기 때문에 상품화해도 잘 활용될 수 있음

오픈소스SW의 단점

  • 빈약한 문서-상용프로그램에 비해 체계적인 문서를 갖고 있지 않은 경우가 많음
  • 불확실한 개발 로드맵-영리를 목적으로 운영되는 것이 아니므로 상용프로그램 수준의 로드맵을 기대하기 어려움
  • 지적재산권기업이 보유한 특허 및 소스코드가 오픈소스SW에 포함되는 경우 오픈소스SW 라이선스에서는 일반적으로 특허에 대한 사용료 없이 배포할 것을 요구하고 있기 때문에 오픈SW를 이용하여 특허를 구현하거나 기존 소스코드를 포함하고자 하는 경우 반드시 특허 사용료에 대한 입장을 명확히 하여야 함

OSS 라이센스

[오픈소스 라이센스 정책 비교 - 정보통신부 2014]

표에서 아래쪽으로 갈수록 저작권이 강해지기 때문에 기업친화적인 라이센스라 볼 수 있다.

 

 

[출처] Git 교과서-길벗

'Git' 카테고리의 다른 글

github 잘못 올라간 파일 히스토리까지 삭제하기  (0) 2023.08.23
git pull error 해결 방법  (0) 2023.05.19
Git 협업하기  (0) 2022.12.30
브랜치 사용하기  (0) 2022.12.30
커밋 다루기 정리 노트  (0) 2022.12.30

git push 실행 시 에러 해결

git push를 실행했을 때 다음과 같은 에러가 발생했다면??

 ! [rejected]        premium -> premium (fetch first)
error: failed to push some refs to 'https://github.com/~~~'

내가 로컬 레포지토리를 수정하는 동안 다른 개발자에 의해 리모트 레포지토리에 변화가 생겼다면 바로 git push를 쓸 수 없기 때문에 위와 같은 에러가 발생한다. 이때는 경우에 따라 2가지 방법이 있다.

 

  1. 수정된 내용을 확인할 필요가 없는 경우
  2. 수정된 내용을 먼저 확인하고 싶은 경우

1. 수정된 내용을 확인할 필요가 없는 경우

리모트 레포지토리에서 코드를 수정한 개발자를 신뢰하여 수정된 내용을 확인할 필요가 없을 경우, git pull을 한 다음 git push를 하면 된다. 

 

그런데 git pull을 실행했을 때 다음과 같은 에러가 발생할 수 있다. 

CONFLICT (content): Merge conflict in License.txt

https://becoming-developer.tistory.com/8 해결 방법은 이 링크를 참조하면 된다. 

 

2. 수정된 내용을 먼저 확인하고 싶은 경우

다른 개발자가 어떤 내용을 수정했는지 먼저 보고 싶은 경우에는 아래의 git fetch 커맨드를 활용할 수 있다. 

  • git fetch : 로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴(가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음)

1. git bash 터미널에서 git fetch 실행

$ git fetch
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 689 bytes | 86.00 KiB/s, done.
From https://github.com/~~~
   68437c2..4cb5b5d  premium    -> origin/premium

2. git diff 커맨드를 통해 수정된 내용 확인

git diff [로컬 레포지터리의 브랜치] [리모트 레포지터리의 브랜치]

ex) git diff premium origin/premium

 

3. 리모트 레포지토리의 브랜치에 문제가 있을 때

   아래 2가지 방법 중 선택하면 된다. 

  1. 잘못된 코드를 작성한 개발자에게 코들르 고치고 다시 리모트 레포지토리에 올려달라고 하기
  2. 잘못된 부분을 알아서 해결하고 다시 git push 하기

2번 방법의 경우:

1. git bash 실행 후 아래 커맨드 입력

git merge [리모트 레포지터리의 브랜치]

2. visual studio code에서 파일 수정 후 저장

3. git bash에서 다음 커맨드 실행

git add .
git commit -m "커밋 메시지"
git push

 

코드를 누가 작성했는지 보기

  • git blame [파일명] : 특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력 
  • git show [궁금한 커밋 아이디] : 더 자세히 보기, 실행 후 나가려면 q 입력

 

직전에 Remote Repository에 올라간 커밋 취소

  1. git revert [되돌리고 싶은 커밋아이디] : 특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성(git log명령어를 통해 커밋아이디 확인 가능)
  2. 커밋 메시지를 입력하라는 창이 뜨면 (원하면 커밋 메시지 변경하고) :wq 입력
  3. git push

여러 커밋 취소

  1. git revert [커밋 아이디]..[커밋아이디] : 첫 번째에 쓴 커밋 아이디의 다음 커밋부터 두 번째에 쓴 커밋 아이디까지의 커밋에서 이루어진 작업을 취소하는 커밋을 생성
  2. git push

 

출처: 코드잇 Git 강의

'Git' 카테고리의 다른 글

git pull error 해결 방법  (0) 2023.05.19
[Git] Open Source Software  (0) 2023.04.06
브랜치 사용하기  (0) 2022.12.30
커밋 다루기 정리 노트  (0) 2022.12.30
Github에서 다른 프로젝트 가져오기  (0) 2022.12.30

커맨드 정리

  • git branch [새 브랜치 이름] : 새로운 브랜치를 생성
  • git checkout [기존 브랜치 이름] : 그 브랜치로 이동
  • git branch : 현재 레포지터리에 있는 모든 브랜치 조회
  • git checkout -b [새 브랜치 이름] : 새로운 브랜치를 생성하고 그 브랜치로 바로 이동
  • git branch -d [기존 브랜치 이름] : 브랜치 삭제
  • git merge [다른 브랜치 이름] : 현재 브랜치에 다른 브랜치를 머지

merge를 하다가 충돌 발생 시

1. 충돌 해결

1. 컨플릭트가 발생한 파일을 연다. (git status 커맨드를 통해 conflict가 발생한 파일 확인 가능)

2. 머지의 결과가 되었으면 하는 모습대로 코드를 수정한다. 

3. 커밋

    -git bash에서 다음 커맨드 실행

git add .
git commit

     -text editor에서 :wq 입력

 

2. merge 취소

  • git merge --abort : 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감

 

 

출처: 코드잇 Git 강의

'Git' 카테고리의 다른 글

[Git] Open Source Software  (0) 2023.04.06
Git 협업하기  (0) 2022.12.30
커밋 다루기 정리 노트  (0) 2022.12.30
Github에서 다른 프로젝트 가져오기  (0) 2022.12.30
Github 시작하기  (0) 2022.12.29

커밋 히스토리 살펴보기

  • git log : 커밋 히스토리를 출력
  • git log --pretty=oneline : --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있습니다. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줍니다.
  • git show [커밋 아이디 앞 4자리] : 특정 커밋에서 어떤 변경사항이 있었는지 확인

 

m 옵션 없이 커밋 메시지 남기기

1. 로컬 저장소에서 파일 수정

2. Git Bash 실행

git add .
git commit

3. text editor가 켜지면 키보드로 i를 누르고, 맨 위로 가서 커밋 메시지 작성

4. 저장하기

    esc를 누르기

    :wq 입력

    엔터

5. Git Bash에서 git log를 통해 제대로 입력됐는지 확인

 

최신 커밋 수정하기

1. 로컬 파일의 코드 수정

2. Git Bash 실행

git add .
git commit --amend
  • git commit --amend : 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦

3. text editor에서 커밋 메시지를 그대로 써도 되고 수정해도 됨. 

    수정하고 싶은 경우 => 키보드로 i를 누르고, 맨 위로 가서 커밋 메시지 작성 및 저장(esc => :wq 입력 => enter)

4. 터미널에서 git push 실행

 

긴 커맨드에 alias 설정하기

  • git config alias.[별명] [커맨드] : 길이가 긴 커맨드에 별명을 붙여서 이후로 별명으로 해당 커맨드를 실행할 수 있도록 설정
git config alias.history 'log --pretty=oneline'

이렇게 쓰고 실행하고 나면 앞으로 git histroy라고만 써도 자동으로 git log --pretty=oneline을 실행하게 됨.

 

두 커밋 간의 차이 보기

  • git diff [커밋 A의 아이디] [커밋 B의 아이디] : 두 커밋 간의 차이 비교

   * 이전의 커밋 아이디를 먼저 써준다.

 

과거 커밋으로 돌아가고 싶을 때

  • git reset [옵션] [커밋 아이디] : 옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨) 

(1) HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행)

(2) staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행)

(3) working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행)

그리고 이때 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^, HEAD~3)을 사용해도 됨

-HEAD~x는 현재 HEAD가 가리키는 커밋보다 x단계 전에 있는 커밋

 

커밋에 tag 달기

새 버전의 시작점이 되는 커밋처럼, 특히 그 의미가 중요한 커밋들은 태그를 달아주면 나중에 프로젝트의 이력을 파악할 때 도움이 된다. 

 

git tag [태그 이름] [커밋 아이디] : 특정 커밋에 태그를 붙임

 

프로젝트 디렉토리에 있는 모든 태그를 조회하려면,

git tag

각 태그와 연결된 커밋이 보고 싶으면,

git show [태그 이름]

 

git reset을 하고 나서 돌아오기

*reset을 해도 그 이후의 커밋들이 삭제되는 건 아님! => 단지 HEAD가 가리키던 브랜치가 새로운 커밋을 가리키게 될 뿐!

  • git reflog : HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력

 

커밋 히스토리를 그래프 형식으로 보는 방법

  • git log --all --graph : 모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력

 

깔끔한 커밋 히스토리

  1. git rebase [브랜치 이름] : A, B 브랜치가 있는 상태에서 지금 HEAD가 A 브랜치를 가리킬 때, git rebase B를 실행하면 A, B 브랜치가 분기하는 시작점이 된 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어붙여짐(git merge와 같은 효과를 가지지만 커밋 히스토리가 한 줄로 깔끔하게 된다는 차이점이 있음)
  2. 코드를 수정해서 conflict 에러 해결 후 다음 커맨드 실행
git add .
git rebase --continue

  

작업 내용 임시 저장

  1. 코드를 수정하던 중에 다른 브랜치로 이동해야 할 경우
  2. 잘못된 브랜치에서 작업하고 있었을 경우

작업 내용을 임시로 저장할 필요가 생긴다. 

 

관련 커맨드

  • git stash : 현재 작업 내용을 스택 영역에 저장
  • git stash list : 스택 내용 조회
  • git stash apply [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용
  • git stash drop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 스택에서 삭제
  • git stash pop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용하면서 스택에서 삭제
  • git cherry-pick [커밋 아이디] : 특정 커밋의 내용을 현재 커밋에 반영

 

여러 커밋을 하나의 커밋으로 만들기

어떠한 커밋을 없었던 걸로 하고 싶을 때 git reset을 활용할 수 있다. 

예) 똑같은 함수를 더 효율적인 코드로 수정했을 경우

 

방법:

git reset --soft [커밋아이디]
git add .
git commit -m "커밋 메시지"

 참고=>git reset에서 옵션으로 --mixed나 --soft를 사용하면 HEAD는 이전 커밋을 가리키지만 working directory는 그대로다. 

 

 

출처: 코드잇 https://www.codeit.kr

'Git' 카테고리의 다른 글

[Git] Open Source Software  (0) 2023.04.06
Git 협업하기  (0) 2022.12.30
브랜치 사용하기  (0) 2022.12.30
Github에서 다른 프로젝트 가져오기  (0) 2022.12.30
Github 시작하기  (0) 2022.12.29

+ Recent posts