nomad-programmer

git-flow와 github-flow는 git을 이용한 작업 흐름 방식의 양 극단에 있는 작업 흐름이다. git-flow는 복잡하거나 견고하고 브랜치 사이의 엄격한 상호 작용 규칙에 따라야 하는 작업 흐름이다. 그만큼 전체적인 개발-주기가 긴 프로젝트에 어울린다. 반면, github-flow는 개발과 배포에 필요한 최소한의 브랜치 그룹만 유지해 언제나 배포할 수 있고, 여러 가지 요구나 상황 변화에 민첩하게 대응할 수 있는 작업 흐름이다. 이 두 가지의 중간에 gitlab-flow 가 있다. 'GitLab Flow' 라는 웹 문서에서 github-flow를 기본으로 여러 가지 변형 형태를 gitlab-flow라는 이름으로 소개한다. github-flow를 따르지만 배포 과정을 GitLab에서 개선한 작..

git-flow 작업 흐름 데스트탑 애플리케이션은 한번 배포된 후에는 유지보수가 쉽지 않다. 사용 환경이 오프라인일 경우, 도중에 실행을 중단할 수 없는 경우, 사용자가 유지보수에 관심을 가지지 않을 경우 등 다양한 이유로 유지보수가 쉽지 않기 때문이다. 이런 애플리케이션은 매우 견고하게 만들어져야 하며, 견고함을 유지하기 위해 프로젝트 작업 흐름 또한 여러 가지 결함을 최소화하고 결함이 있다고 해도 빠른 시간 안에 감지해 수정할 수 있는 모델이어야 한다. 이런 조건을 만족하는 것으로 빈센트 드라이센(Vincent Driessen)이 제안한 작업 흐름 모델인 'A successful Git brancing model' 이 있다. https://nvie.com/posts/a-successful-git-br..

git을 이용한 협업은, 다르게 말하면 브랜칭 생성 규칙을 공유하는 것으로 말할 수 있다. git의 장점인 '자유롭고 무제한 브랜칭' 에 규칙을 정하는 것으로 협업의 틀이 완성되는 것이다. 브랜칭 생성 규칙의 예 요소/플랫폼 데스크탑 애플리케이션 웹 모바일 앱 특징 배포 후에 유지보수가 힘듦. 배포와 개발의 구분이 없음. 배포 이후 지속적인 업데이트 가능. 프로젝트 마감 최초 배포 시 해당 없음 버전마다 배포 단위 최초 한 번. 업데이트는 패치 등으로 제공됨 해당 없음. 무결절성(seamless) 버전마다 배포 시기 조절 가능 여부 ㉮ 가능 해당 없음 불가능 ㉯ 추천 Flow git-flow github-flow gitlab-flow ㉮: 배포 시기를 개발하는 쪽에서 완전하게 가져갈 수 있는지를 뜻한다...

git merge 명령을 실행할때마다 --no-ff 옵션을 주었다. 이유는 커밋 내역을 남기기 위함이다. 그런데 git의 전역 속성으로 추가하면 굳이 옵션을 따로 안주어도 된다. git config --global --add merge.ff false

git 을 이용한 버전 관리 시스템의 작업 흐름은 평소에는 여러 개의 브랜치와 커밋 내역을 만들고, 마지막에 작업 내역을 확인하고 올바른 작업물만 병합하는 것이다. git 의 특징 중 하나는 커밋 내역을 수정할 수 있다는 것이다. 하지만 수정할 수 있다고 해서 이미 원격 저장소에 푸시가 끝난 커밋 내역을 수정하는 것은 정말 특별한 상황이 아닌 이상 절대로 권장할만한 일이 아니다. 푸시하기 전에 git merge 명령을 이용해서 병합하면 충돌 해결 커밋이나, --no-ff 로 만든 병합 커밋을 남기게 된다. 이는 작업 흐름을 일관되게 파악하는 데는 깔끔하지 않다. 따라서 할 수 있다면 로컬 저장소에 있던 커밋을 깔끔하게 정리해서 푸시하는 것이 좋다. 그런 정리를 가능하게 하는 것이 git rebase 명령..

파일 하나를 대상으로 변경 내역을 통째로 원래대로 (변경 직전의 최종 커밋 시점으로) 되돌릴 때 사용한다. git checkout HEAD -- 파일이름 위 명령을 실행하면 파일이름 파일의 내용이 최종 커밋 시점 (HEAD 대신 다른 커밋 SHA-1 체크섬 값을 입력하면 해당 커밋 시점으로 되돌림) 으로 되돌아가게 된다. '--' 는 포함하는 것이 좋다. git checkout 명령에 뒤따라 오는 것이 파일이라는 것을 확실하게 해주는 것이다. 만약 '--' 가 없다면, 파일이름이 브랜치 이름과 같을 경우 해당 브랜치로 체크아웃하거나, 특정 커밋 시점으로 저장소 전체가 되돌아갈 수 있다. // example git checkout HEAD -- README.md cat README.md 명령을 실행하면 파..

이미 공개된 커밋 내역을 수정하는 것은 매우 위험하다. 할 수는 있지만 "절대로" 하면 안된다. 하지만 안전하게 변경 내역을 되돌리는 방법이 있다. 커밋으로 발생한 변경 내역의 반대 커밋을 하면 된다. 즉 추가한 코드는 빼고, 지운 코드는 다시 추가하는 커밋을 하는 것이다. git revert 이 명령을 특정 지점의 커밋 SHA-1 체크섬 값을 입력하면 해당 지점까지 변경 내역을 취소하게 된다. ex) git log -5 git log 명령을 통해 특정 지점의 커밋 SHA-1 체크섬 값을 찾는다. 그 후 git revert 523a 명령을 실행한다. vim 편집기 창이 등장하면서 커밋 메시지를 수정하게 된다. 잘 살펴보면 원래의 커밋 메시지가 큰 따옴표로 묶여 있고 앞에 'Revert'라는 문자가 입력되..

마지막 커밋 메시지를 수정하는 명령은 간단하다. // 마지막 커밋 메시지 수정 git commit --amend 위 명령을 실행하면 마지막 커밋과 커밋하지 않은 상태에 있는 변경 내역이 서로 합쳐진 새 커밋을 만들게 된다. 만약 아무런 변경 내역을 만들지 않고 명령어를 실행하면 커밋 메시지만 변경하게 되는 것과 같은 효과를 낼 수 있다. 변경 내역을 만들었다면 변경 내역을 추가하기 위해 git add 명령을 실행한 후 git commit --amend 명령을 실행한다. 엄밀히 말하자면, git commit --amend는 최종 커밋을 수정하는 것이 아니라 최종 커밋을 대체하는 새로운 커밋을 만드는 것이다. 명령을 실행하기 전과 후의 커밋 SHA-1 체크섬 값을 비교해보면 확실하게 알 수 있다.

git tag 명령은 저장소의 커밋에 태그를 붙이는 명령어이다. 간단하게 그냥 버전 이름 같이 이름만을 붙이는 'light weight' 태그와 태그 작성자와 간단한 메모를 함께 태그에 남기는 'annotated' 태그가 있다. 만약 가장 최근 커밋에 태그를 붙이고 싶다면 간단하게 다음 명령을 실행하면 된다. // 가장 최근 커밋에 태그 붙이기 git tag 여기에서는 1.0이라는 버전 이름으로 태그를 붙였다. 그리고 태그가 붙여졌는지 확인하기 위해 다음 명령을 실행한다. 로그와 함께 태그를 볼 수 있다. // 태그 확인 git log --decorate -1 // 현재 저장소에 있는 태그 리스트 확인 git log -l // 태그와 커밋 SHA-1 체크섬 값을 함께 확인 git show-ref --ta..

분산 버전 관리 시스템은 다른 사람과의 협업을 염두에 둔 것이다. 결국 원격 저장소와 로컬 저장소 사이를 얼마나 효율적으로 관리하느냐가 관건이다. 관리는 위해 git에서는 원격 저장소와 소통하기 위한 기능을 제공한다. 원격 저장소의 내용을 로컬 저장소로 가져오거나, 로컬 저장소를 원격 저장소와 연결하고 보내거나, 수정된 내역을 확인하고 병합하는 등의 과정을 제공한다. 명령어 기능 git clone 원격 저장소의 모든 내용을 로컬 저장소로 복사 git remote 로컬 저장소를 특정 원격 저장소와 연결 git push 로컬 저장소의 내용을 보내거나 로컬 저장소의 변경 사항을 원격 저장소로 보낸다 git fetch 로컬 저장소와 원격 저장소의 변경 사항이 다를 때 이를 비교 대조하고 git merge 명령어..

https://github.com Build software better, together GitHub is where people build software. More than 40 million people use GitHub to discover, fork, and contribute to over 100 million projects. github.com 위의 링크를 타고 들어가 가입한다. 지불하는 비용에 따라서 비공개 저장소를 얼마나 사용할 수 있는지가 정해진다. 무료로 이용한다면 github에서 생성하는 모든 저장소는 공개 저장소가 된다. * Help me set up an organization next 체크 박스는 많은 사람이 협업 할 때 팀을 만들어서 활동하도록 설정하겠다는 의미이다. 원..

git은 혼자만 사용하려고 배우는 것이 아니다. 물론 개인 프로젝트에도 git과 같은 버전 관리 시스템을 활용하는 의미가 있지만, git은 무엇보다도 다른 사람들과 협업을 하기 위한 도구로서의 의미가 더 크다. 협업 도구로서 git의 가장 큰 유용함은 원격 저장소(remote repository)이다. 원격저장소와 GitHub 무엇보다도 협업할 때 중요한 개념이 git의 원격 저장소 부분이다. 물론 로컬 환경에서만 git을 사용해 개인 프로젝트를 관리하는 것도 git의 훌륭한 사용 방법 중 한 가지다. 하지만 git이 무엇보다 좋은 이유는 원격 저장소 때문이다. git의 핵심이라고 이야기할 정도다. 이러한 git 원격 저장소를 제공하는 대표적인 서비스가 github이다. github는 단순히 원격 저장소..

프로젝트를 진행하다 보면 부수적으로 다양한 파일이 만들어진다. 굳이 추적해야 할 필요가 없는 파일들이다. 보통은 입/출력용 데이터나 각종 로그 파일들 혹은 사용하는 IDE에 따라 프로젝트 자체를 관리하는 파일들인 경우다. 이런 파일들은 프로젝트의 일부지만 git을 이용해 굳이 추적할 필요가 없다. 이렇게 저장할 필요 없는 파일들을 적절하게 무시하기 위해 git은 .gitignore라는 파일을 이용한다. .gitignore 파일은 일련의 파일 목록과 파일을 구분할 수 있는 패턴의 모음으로 라인 하나가 패턴 하나를 가리킨다. 더 자세한 내용은 아래의 링크에서 볼 수 있다. https://git-scm.com/docs/gitignore Git - gitignore Documentation The optiona..

목표 명령어 설명 사용자 이름 설정 git config --global user.name "" 입력한 사용자 이름으로 정보 설정 사용자 이메일 주소 설정 git config --global user.email "" 입력한 사용자 이메일 주소로 정보 설정. (github의 이메일 주소와 동일한 주소로 하는 것이 좋음) 저장소 생성 git init 실행한 위치를 git 저장소로 초기화 저장소에 파일 추가 git add 해당 파일을 git이 추적할 수 있도록 저장소에 추가 저장소에 수정 내역 제출 git commit 변경된 파일을 저장소에 제출 저장소에 모든 수정 내역 제출 git commit -a[m] [commit 메세지] 변경된 저장소 파일 모두를 commit. 옵션 m을 붙이면 commit 메세지를 함..

* git history 를 직관적으로 한 눈에 볼 수 있는 프로그램. https://githistory.xyz/ Git History githistory.xyz 위의 링크를 클릭하여 가보면, 자세한 설명이 되어있다. 크롬, 파이어폭스, 터미널, 비쥬얼 스튜디오 등 지원한다. * github에서 파일들을 트리구조로 볼 수 있는 프로그램 (chrome 전용 extension) https://chrome.google.com/webstore/detail/octotree/bkhaagjahfmjljalopjnoealnfndnagc

Git이란? 버전 관리는 위한 분산 버전 관리 시스템이다. 프로젝트에 관련된 리소스 중 제일 빈번하게 생성, 삭제, 수정되는 것은 코드이다. 단 한 줄의 코드로 버그가 생기느냐, 성능이 향상되느냐가 갈리니 미세한 차이가 있는 버전들이라고 해도 그냥 넘어가지 않는다. 수많은 버전 관리 시스템들도 그 필요성을 절감하기 때문에 등장한 것이다. Git은 완벽한 분산 환경에서 빠르고 단순하게 수백 수천 개의 동시 다발적인 브랜치 작업을 수행하는 것을 목표로 하는 버전 관리 시스템이다. 그리고 git을 만든 리누스 토발즈의 의도와 같이 리눅스 커널 같은 대형 프로젝트의 버전 관리를 가능하게 하는 것 또한 목표이다. Git의 일반적인 특징 로컬 및 원격 저장소 생성 로컬 저장소에 파일 생성 및 추가 수정 내역을 로컬..