Git Github Gitflow

Git

Git는 Linus Torvalds가 2005년에 만든 분산 버전 제어 시스템입니다.바로 그 linux를 만든 사람이다.천재

중앙 집중식 및 분산

Git에 앞서 Apache Subversion(SVN)은 최신 버전 제어 시스템 중 하나입니다.SVN은 중앙 서버에 모든 파일을 저장하는 중앙 버전 제어 시스템입니다.만약 두 개발자가 같은 파일을 처리하고 있다면, 그들은 계속 충돌을 해결해야 할 것이다.Git와 달리 개발자가 오프라인이 되면 변경 사항을 제출할 수 없습니다.

다른 한편

Git 명령

다음은 변경 사항을 커밋으로 저장하고 터미널을 사용하여 서버로 전송하는 기본 명령 목록입니다.나는 종결자다.GUI가 없습니다.VSCode에git의 내장 사용자 인터페이스가 있다는 것을 알고 있습니다.기존Git Clients도 있다.

git checkout develop # Go to develop branch
git add . # add all the files you have edited
git commit -m "Add changes to the files" # add commit message to the files you've added
git push origin master # Push the commits to master branch in the server

Check out this git cheatsheet

github

Git와 함께 작동하는 관리형 서비스.Git와 함께 사용할 수 있는 다른 관리 서비스도 있습니다.예를 들어, Bitbucket 및 Gitlab그러나 나는 Github를 가장 좋아한다. 왜냐하면 UX는 유창하기 때문이다. 참고로 마이크로소프트가 Github를 인수했다. 나는 이 트위터가 매우 웃긴다고 생각한다.

Shanewas Niloy
@shanewasniloy 회사

GitHub Starter GitHub For Students GitHub Home Basic GitHub Home Premium GitHub Professional GitHub Enterprise GitHub Business GitHub Ultimate Github 2018 R2btw, GitHub Vista를 기다립니다.)
14:2018년 6월 4일 오후 11시
십칠
38

Gitflow

Vincent Driessen이 만든 유행 지점 정책입니다.저는 HOOQ 팀에서 사용하고 있습니다.우리는 그것을 Git Hubflow와 함께 사용하고 무지개를 토하고 있다.지점 전략은 옳고 그름의 구분이 없다. 팀에 가장 적합한 모델을 찾기만 하면 된다.

주간에 기초한 개발 작업 흐름

모든 사람은 마스터 브랜치에서만 일한다.합병 충돌이 누적되는 장수명 분지를 피하는 데 도움이 된다.

지점 기구

마스터 브랜치

찬성 의견

개발자가 빈번하게 작은 제출과 변경을 강요

이해하기 쉬움

빠른 교체, 빠른 배송

속이다

피쳐 플래그를 사용하지 않으면 불완전한 피쳐가 방출될 수 있음

오류 도입 용이

개발자가 같은 파일을 사용하면 병합 충돌이 빈번하게 발생

Gitflow 워크플로우

주분지는 안정적인 분지다.아무도 그것을 건드리지 않았다.모든 사람은 자신의 특성 지점에서 일하고 드래그 요청을 열어 특성 지점을 개발 지점에 통합합니다.발표 지점은 개발 지점에서 분리된 후에 주 지점과 개발 지점을 합병한다.이것은 지속적인 교부를 장려했다.

지점 기구

마스터 브랜치

개발지사

피쳐 브랜치

분기 방출

패치 분기

찬성하다

병렬 작업 용이

게시 지점은 게시 가능한 특성을 추적하는 데 도움이 된다

속이다

처음 사용하는 사용자에게는 좀 복잡하다

I will direct you to an authentic Gitflow explanation over here by the creator himself.

Git Hubflow

Gitflow를 Github와 함께 사용하는 단일 행 명령입니다.이 신기한 도구는 DataSift 당신들은 다 MVP가 창조한 것입니다.

일반 Git 명령

git checkout develop
git pull origin develop
git checkout -b release/production-1.0.0
git add .
git commit -m "Add new release"
git push origin release/production-1.0.0
git checkout master
git pull origin master
git merge release/production-1.0.0
git tag production-1.0.0
git push --tags origin production-1.0.0
git checkout develop
git pull origin develop
git merge master
git push --delete release/production-1.0.0

놀라운 Git Hubflow 명령

git hf release start production-1.0.0
git add .
git commit -m "Add new release"
git hf release finish production-1.0.0

최상의 워크플로우는 무엇입니까?

팀의 가장 좋은 지점 전략이 무엇인지를 결정할 때 고려해야 할 요소가 많다.팀에서 지속적인 서비스를 제공해야 합니까?기존 워크플로우를 필요에 맞게 조정하는 데 비해 팀 구성원이 새로운 워크플로우를 사용하는 것은 어떻습니까?
개인적으로 나는gitflow를 좋아한다. 왜냐하면 서로 다른 기능의 관심사를 분리하고 발표 가능한 기능을 가진 버전을 만들기 쉽기 때문이다.하지만 나는 가장 좋은 업무 흐름이 없다고 믿는다.
here과here에 대한 글은 서로 다른 업무 흐름과 장점을 비교했다.

면책 성명

나는 SVN을 시험해 본 적이 없다.완전히 그렇지는 않다. 나는 SVN을 해 보았지만, 그것은 너무 복잡해서 나는 좋아하지 않는다.나는git에게 응석받이로 자랐다.삽화에 부정확한 부분이 있을 수 있으니 수정하세요!
나랑 얘기할 수도 있어.나는 그곳에서 매우 심심하다.
그리고 내일 https://linxea.github.io/git-github-gitflow 세미나를 위해 슬라이드를 만들었습니다.전시를 통해 신기함을 느끼다.js.

공구서류

https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=vsts
https://datasift.github.io/gitflow/IntroducingGitFlow.html
https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow