GitHub DeskTop
GitHub DeskTop 깃허브 데스크탑
실무에서 사용하게 되어 테스트 해 본 내용을 정리 해본다.
**************************************
파일사이즈가 100M가 넘어가는 파일은 처음 레파지토리 생성하고 커밋 할 때는 잠시 다른곳에 옮겨둔뒤, 추후 가져와서 lfs 처리 한 뒤 올린다.
**************************************
0.테스트 환경
-2대의 PC와 2개의 깃허브 계정으로 테스트
-pc1은 계정1, pc2는 계정2
-pc1이 관리자, pc2는 초대 받은 팀원이 되어 서로 협업하는 상황
-유니티 프로젝트
-깃허브 데스크탑 사용
0.깃허브 개념
- pull :레파지토리에 있는 내용을 받아온다.
- commit : 일단 로컬 공간에 올린다
- push : 최종 공유 공간에 올린다
1.관리
*레퍼지토리 등록
- 유니티 프로젝트 생성
- 깃허브 데스크탑에서 add existing repository 를 찾아서 생성 ( 메뉴가 여러군데 있으니 편한걸로 )
filename에 기존 프로젝트의 폴더 이름을 복사해서 넣어주고, 폴더 경로에는 한단계 상위 경로를 넣어준다.
이렇게 안 하고, 파일네임에 새로운 이름을 넣고 경로를 기존 프로젝트의 폴더 이름을 넣어주면 기존 프로젝트
하위에 새로운 이름의 폴더가 생기고 그 폴더가 깃 레파지토리가 된다.
- publish 라는 누를 수 있는 ui가 생기고 그걸 눌러야 깃허브 공유 공간에 push 완료 된다.
*초대
관리자는 아래처럼 초대.
팀원또한 깃허브 웹페이지 들어가서 수락.
2.사용
파일을 수정하면 깃허브데스크탑 좌측 changed탭에 변경 된 파일들이 나오고 커밋을 할 수있는 상태가 된다.
좌측아래 사람모양+ 를 누르면 Co-Authors라고 공동저자를 넣을 수 있다.
커밋을 하면 History탭에서 커밋한 블록에 대한 정보를 볼 수 있으며 한 블록에 여러개의 파일을 커밋 했으면 여러개의 파일 수정 내용을 열람 할 수 있다. 블록별로 revert 할 수 있으며 revert 하면 블록에 포함 된 파일들의 수정 내용이 원복 되고, 실제 내 로컬 파일들도 수정 전으로 돌아간다. 커밋 히스토리에서 사라지는게 아니라 리버트 히스토리가 추가 된다.
커밋을 하면 또한 Push 리스트에 커밋 블록이 추가 된다.
Push리스트 우측에 숫자 위 화살표가 있는데, 이 숫자는 변경된 파일 수가 아닌 커밋 블록의 개수이다.
그리고 수정 사항을 받아야 하는 팀원은 Push 대신 Pull 이라고 나오고 몇개의 커밋블록이 있는지 출력 된다.
또한 Pull 대신 Fetch 라고 나오는 경우에는 변경 사항이 있으면 Fetch->Pull 로 바뀌고, 없으면 그대로 Fetch로
유지된다. Pull로 바꼈을 때 눌러주면 공유공간에 있는 코드를 로컬에 업데이트 한다.
.gitignore
원작자만 소유하고 커밋에서 제외시키기 위해 .gitignore 파일에 제외 파일을 등록 하는데, 레파지토리 생성 할 때 유니티 프로젝트로 선택하면 자동으로 등록되는 파일들이 있다. 그런데, 예외적으로 유니티 프로젝트 이면서 일반 visual studio 프로젝트를 포함 하는 경우가 있는데, 이런 경우 루트폴더가 git 레파지토리루트이고 하위 폴더에 유니티 프로젝트, VS 프로젝트를 두기도한다. 이럴 때 예를들어 .vsproj 파일을 프로젝트 전체적으로는 제외하고 싶지만 VS프로젝트에서는 살리고 싶다고 해보자. 레파지토리 생성 할 때 유니티 프로젝트로 등록을 하고, 루트의 .gitignore에서 .vsproj를 지워버리고 나머지 필요한 .gitignore들에서는 남겨두면 된다.
push 와 pull 이 둘 다 있을 경우
push 하려는데 이미 같은 파일이 수정 되었을 경우
Pull 받고나서 Changes가 Stashed Changes로 이동하는 경우, 충돌하지 않은 파일도 같이 이동하게 되는데 파일 단위가 아닌 commit 블록 중 충돌하는 파일이 있으면 전체 파일이 Stashed Changes로 옮겨지고 로컬 레파지토리의 파일도 Pull 받은 내용으로 변경 된다. Changes에서 문제 되는 파일들 DiscardChanges 해 주면 Stashed Changes에서 Restore가 가능해지고 Restore 누르면 Stashed 됐던 파일들이 정상화 된다
깃은 SVN과 사상이 다른 부분이 있고, 처음 깃을 사용하는 경우 큼직한 실수들을 많이 하게 된다는 이야기들을
여기 저기서 들어왔기 때문에, 정리를 해봤는데 이정도면 별 다른 문제는 없을듯 하다.
이 후에 브랜치를 여러개 만들고 하는등의 추가적인것들이 필요 하겠지만, 그건 좀 쉬었다 하자. 좀 다른거 할게 많으니.
> 깃 100M이상 대용량 파일 업로드
1.git lfs install
커맨드창에 git lfs install 입력 후 엔터 처서 설치
git lfs install
git lfs -v 입력해서 잘 설치 됐는지 확인.
cd "작업중인 git 프로젝트 루트 경로"
2.git lfs track "*.txt"
: 100메가 이상을 허용할 파일의 확장자가 txt라면 위 처럼 명령어 입력
3.git add .gitattributes
: 변경 내용 적용
4. 다시 push
> 위 처럼 해도 push 할 때 같은 에러가 발생한다면
git lfs track "filename.txt" 을 입력해서 개별파일 lfs 처리를 해 보자
> 그래도 안 되면 이미 commit 을 한번 시도한게 문제가 될 수 있다.
나의 상황에 딱 맞게 설명하지 못한 불친절한 인터넷 설명들 및 깃 시스템을 속으로 잔뜩 비난한후에 아래 방법을 시도 해보자.
일단 history 탭으로가서 히스토리 중 사이즈가 커서 문제가 되는 파일이 커밋 된 기록이 있는지 보고 있다면 해당 히스토리 블록 자체를 undo commit 해 준 뒤 다시 2,3,4를 진행 해보자
> 아래와 같은 에러가 발생 할 때는
git add directoryname/*
> 그래도 문제가 발생 한다면
애초에 최초 git publish가 가장 중요하다. create repository 해 준 뒤 git publish 을 시도하면 initial commit 이라는 최초 커밋을 하는데, git publish 하기 전에 git lfs track "*.txt" git add .gitattributes 를 해 줘야 문제가 생기지 않는다.
일단 git 관련해서 꼬였으면 깃허브 웹에서 해당 레파지토리 삭제 하고, 깃허브 데스크탑에서도 삭제후에 깃프로젝트 폴더에서 .git 으로 검색해서 .git과 .gitignore 파일들 지워버리고 위에서 이야기 한대로 lfs 파일 셋팅 정상적으로 한 뒤에 처음부터 다시 진행 한다.
> 개소리집어치우고 그냥 파일사이즈 큰것들 삭제
뭐 해도 안 되니까 다 때려치우고싶다. 이 글 써놓은 블로거도 찾아가서 욕박고싶다 라고까지 생각한다면, 한번만 더 기회를 달라. 당신의 프로젝트 크기가 커서 오래 걸리는 일이겠지만, 문제되는 파일 삭제 ( 다른곳에 백업 ) 후에 다시 푸쉬 시도하고, 정상적으로 되면 다시 파일 갖다놓고 lfs 처리 후에 푸쉬 해 봐라
> undo commit / revert commit
history 에서 undo commit 하면 undo한 블럭의 파일들이 모두 changes로 옮겨져서 파일을 개별 컨트롤 할 수 있게 되고, revert commit 하면 커밋 내용이 삭제 된다.
> 커밋 할 때 name을 바꾸려면
레파지토리로 change directory 한 후 아래 명령어 입력 해 주면 된다. --global 을 빼고 쓰면 해당 레파지토리에만 user.name이 적용 된다
git config --global user.name "programmer"