advanced git commands
이 자습서에서는 Git Stash, Git Reset, Git Cherry Pick, Git Bisect와 같은 유용한 Git 명령을 탐색하고 GitHub를 Jira와 통합하는 방법을 설명합니다.
이 시리즈의 이전 자습서에서 GitHub의 대부분의 기능을 살펴 보았습니다.
이 자습서에서는 다음을 살펴 봅니다.
- 릴리스 생성
- Atlassian Jira와 통합
- 개발자를 위해 가장 일반적으로 사용되는 Git 명령
- 힘내 스 태쉬
- 힘내 체리 픽
- 힘내 재설정
- Git Bisect
신입생을위한 SQL 인터뷰 질문 및 답변 pdf
학습 내용 :
릴리스 생성
GitHub의 릴리스는 소프트웨어를 번들로 묶고, 고객과 사람들이 동일한 것을 사용할 수 있도록 릴리스 노트 및 바이너리 (WAR, EAR, JAR 파일)를 추가하는 데 사용됩니다.
릴리스를 생성하려면 저장소의 메인 페이지로 이동하여 릴리스 아래 탭 주제를 관리합니다.
클릭 새 릴리스를 만듭니다.
태그 및 릴리스 제목을 제공하십시오. 바이너리도 릴리스에 추가됩니다. 완료되면 릴리스 게시.
이제 릴리스가 소스 코드와 바이너리로 준비되었습니다.
Jira와 GitHub 통합
중요한 추적 성 측면 중 하나는 GitHub의 커밋과 함께 Jira 문제를 참조하는 것입니다. GitHub를 Jira와 통합하여 문제를 참조 할뿐만 아니라 Jira 내에서 브랜치 및 Pull Request를 생성 할 수도 있습니다.
따라서 일반적으로 개발자가 작업 또는 버그 작업을 시작하면 분기가 생성됩니다. 개발을 게시하거나 버그를 해결하여 Jira에서 풀 요청을 생성하여 메인에 병합 할 수 있습니다. 석사 분기. 그런 다음 개발자가 만든 브랜치를 삭제할 수 있습니다.
통합을 설정하기 위해 플러그인을 사용했습니다. Jira 용 Git 통합. 이것은 상용 플러그인입니다. 플러그인은 다음에서 다운로드 할 수 있습니다. 여기
Jira에 플러그인 설치 관리자-> 추가 기능.
플러그인이 설치되면 애플리케이션-> Git 저장소 GitHub에 연결합니다.
GitHub 사용자 이름과 비밀번호를 입력합니다. 딸깍 하는 소리 잇다 .
사용자 계정에 대해 언급 된 저장소가 표시됩니다. 클릭 저장소 가져 오기 통합 설정을 완료합니다.
GitHub 커밋과 Jira 문제
커밋 메시지의 일부로 아래와 같이 입력합니다. 클릭 변경 사항 커밋 .
예 1 : 아래는 스마트 커밋 이를 통해 개발자는 커밋 메시지에서 Jira 문제에 대한 작업을 수행 할 수 있습니다. 그러한 명령 중 하나는 #논평 아래와 같이 Jira 이슈에 주석을 추가하는 이슈 키와 함께.
댓글 섹션이 업데이트되었습니다.
예 2 : 사용자에게 할당하고 4 시간으로 소요 된 업데이트 시간.
사용 #양수인 과 #시각 커밋 메시지의 스마트 커밋 명령.
두 작업이 모두 완료되었습니다.
예 3 : 문제의 상태를 다음으로 변경하십시오. 진행 중 .
분기 만들기
작업과 버그가 개발자에게 할당되면 개발 작업을 시작해야합니다. 이를 위해 그들은 작업중인 문제에 대한 브랜치를 생성하고, 개발 활동을 수행하고, 마스터 브랜치에 병합하기위한 풀 요청을 제기합니다.
하단의 Jira 문제에서 분기를 만듭니다.
클릭 분기를 만듭니다.
GitHub에서 위에서 만든 브랜치의 파일을 변경하고 동일하게 커밋합니다.
개발이 완료되면 사용자는 Jira에서 Pull Request를 생성 할 수 있습니다.
문제 하단에서 Pull Request를 생성합니다.
클릭 창조하다. Pull Request는 Open으로 표시됩니다.
다음 단계는 GitHub에서 pull 요청을 병합하는 것입니다.
상태는 Jira에서 그에 따라 업데이트됩니다.
개발자를위한 고급 Git 명령
이 마지막 섹션에서는 개발자를 위해 일반적으로 사용되는 Git 명령 중 일부를 살펴 보겠습니다. GitHub와 관련이 없지만 개발자가 변경 사항을 GitHub에 푸시하기 전에 도움이 될 것입니다.
힘내 스 태쉬
새로운 기능이나 개선 사항에 대해 작업 할 때 대부분의 프로젝트 시나리오에서 갑자기보고 된 긴급한 결함에 대해 작업해야 할 필요가 있습니다. 새 작업의 중간에 완료되지 않았기 때문에 절반이 완료된 변경 사항을 적용 할 필요가 없습니다.
따라서 반쯤 완료된 작업을 일시 중단하거나 저장하고 버그를 수정 한 다음 다시 돌아와 새로운 기능이나 개선 사항을 작업하는 것이 좋습니다. Git stash는 이에 대한 해결책을 제공합니다. 변경 내용을 신속하게 수행하는 컨텍스트를 쉽게 전환 할 수 있습니다.
예 1 :자신에게 할당 된 작업을 수행하고 있으며 상태를 보면 현재 추적되지 않은 것으로 표시됩니다.
갑자기 우선 순위가 높은 버그가 할당되었습니다. 따라서 현재 작업중인 작업을 임시로 저장하거나 숨길 필요가 있습니다.
다음 명령을 실행하십시오.
git stash '메시지'저장
이 순간 작업 디렉토리는 깨끗합니다. 새로운 커밋을 만들 수 있으며 버그가 있으면 분기를 전환하여 작업 할 수 있습니다.
남은 변경 사항을 다시 적용하려면 명령을 사용하십시오.
git stash pop
위의 명령은 목록에서 숨김을 제거하고 마지막으로 저장된 상태를 적용합니다.
다음을 사용할 수도 있습니다.
자식 숨김 적용
위의 명령은 변경 사항을 숨김에 유지하고 제거하지 않습니다.
이제 변경 사항이 다시 적용되고 변경 사항을 커밋 할 수 있습니다.
예 2 : 변경 사항을 숨기고 분기를 전환하고 변경 사항을 병합하십시오.
에서 Html 파일을 변경하십시오. 석사 분기 및 숨김 변경.
다음은 곤충 분기, 변경 및 커밋 변경.
git checkout -b bug
Html 파일을 변경합니다.
git commit -a -m“수정 된 이메일 문제”
다시 석사 분기하고 숨김에서 변경 사항을 다시 적용하십시오.
이제 곤충 에 분기 석사 분기. 병합 후 변경 사항을 커밋합니다.
예 3 : 다중 숨김 작업.
로컬 저장소에는 2 개의 Html 파일이 있습니다. 따라서 여러 개발자가 여러 파일에 대해 작업하고 변경 사항을 수정하기 위해 오는 긴급 요청을 처리하기 위해 필요에 따라 변경 사항을 숨길 수 있습니다.
개발자 1은 hello.html에서 작업하고 개발자 2는 index.html에서 작업합니다.
개발자 1
이제 숨김 목록에 1 개의 항목이 있습니다.
개발자 2
이제 보관함 목록에 2 개의 항목이 있습니다. 최신 숨김은 스택의 첫 번째 stash @ {0}입니다. 이제 두 개발자 모두 다른 커밋을 긴급하게 수행하거나 다른 브랜치에서 작업 한 다음 다시 석사 분기하고 숨김 변경 사항을 적용하십시오.
최신 숨김을 적용하려면 다음을 실행하면됩니다.
git stash pop
스택에 특정 숨김을 적용하려면 다음 명령을 실행하십시오.
git stash pop stash @ {1}
두 번째 숨김을 적용하겠습니다. stash @ {1}
마찬가지로 다른 숨김을 적용 할 수 있습니다.
힘내 체리 픽
오늘날 개발자는 기능, 향상, 버그 등과 같은 여러 분기에서 작업합니다.
몇 가지 특정 커밋 만 선택하고 전체 분기를 다른 분기로 병합하지 않는 상황이 있습니다. 이것을 체리 픽이라고합니다. 이 프로세스를 통해 다른 브랜치에서 임의의 Git 커밋을 선택하여 작업 트리의 현재 HEAD에 추가 할 수 있습니다.
예 1 :
로컬 git 저장소에는 다음 6 개의 파일이 있습니다.
file5.txt와 같이 하나의 파일이 삭제됩니다.
변경 사항을 커밋하십시오.
지금 로그를보십시오. File5.txt가 삭제됩니다.
따라서 file5.txt를 추가 한 커밋을 Cherry-Pick하고 싶습니다. file5.tx의 커밋 ID를 찾아서 명령을 실행해야합니다.
git cherry-pick
이 경우 file5.txt가 추가되었을 때의 커밋 ID는 다음과 같습니다. a2f0124
이제 File5.txt가 복원되었습니다. 우리는 커밋을 Cherry-Pick했습니다.
예 2 :
그냥 수정하자 file6.txt 변경 사항을 커밋합니다. 석사 분기.
두 번째 줄을보세요 file6.txt 이메일이 올바르게 지정되지 않은 경우.
버그 브랜치를 생성하고 문제를 수정합니다. 동시에 file5.txt도 수정하여 버그 브랜치에서 여러 커밋을 수행하지만 file6.txt에서 수행 한 커밋 만 Cherry-Pick합니다.
File6 수정 곤충 분기.
그래서 전반적으로 우리는 file5 및 file6 버그 브랜치에서.
이제 다시 석사 분기 및 Cherry-Pick은 file6.txt에 대해서만 수행 된 커밋입니다.
보시다시피 병합하는 대신 곤충 에 분기 석사 특정 커밋 만 Cherry-Picked하고 마스터 브랜치에 적용했습니다.
힘내 재설정
Git 재설정은 로컬 변경 사항을 실행 취소하는 강력한 명령입니다. 따라서 스테이징을 해제하려면이 명령이 사용되는 모든 스테이징 파일을 사용합니다.
예
파일을 수정하고 스테이징에 추가하십시오. 단계적 변경이 단계 해제 될 때 표시된대로 명령을 사용하여 재설정하십시오.
매개 변수 자식 재설정 명령.
-부드러운: 이 매개 변수는 HEAD를 다른 커밋을 가리 킵니다. 원본 HEAD 사이에 모든 파일이 변경되고 커밋이 준비됩니다. 작업 디렉토리는 그대로입니다.
현재 HEAD 위치를보십시오.
역사상 5 개의 커밋으로 돌아가 보겠습니다.
변경 사항을 다시 커밋하십시오.
– 혼합 : 이 옵션은 소프트 매개 변수와 유사합니다. 일반적으로 잘못된 커밋이있는 경우이를 제거하고 나중에 수정 한 후 다시 커밋합니다. 따라서 기본적으로 다음을 사용하여 색인에 추가해야합니다. 자식 추가 그리고 자식 커밋. 변경 사항은 작업 트리에 남아 있습니다.
기록에서 2 개의 커밋으로 돌아가서 파일이 추적되지 않는지 확인해 보겠습니다.
이제 파일을 스테이징에 추가하고 변경 사항을 커밋합니다.
-단단한: 이 매개 변수는 특정 파일이 존재하는 지점에 위치합니다. 변경 사항은 작업 트리에서 사용할 수 없습니다.
위의 로그를 보면 파일 1 만 커밋 된 지점, 즉 마지막 항목으로 돌아갈 수 있습니다.
사용 git reset –hard
Git Bisect
코드를 위반 한 정확한 커밋을 찾으십시오 (우리 모두는 결국 인간입니다). 응용 프로그램을 테스트하는 동안 종종 테스터로부터 버그가 있거나 기능이 손상되었으며 개발자가 지난주에 작동했다고 말할 것입니다. 그래서 무슨 일이 일어 났고 왜이 버그가 나타 났습니까?
때로는 다른 코드의 변경이 기능에 영향을 미칠 수 있습니다. 시간이 많이 걸리고 어떤 변경으로 인해 코드가 손상되었는지 추적하기 어려운 많은 커밋이있는 기록을 살펴 보는 데 시간을 소비해야합니다.
Git Bisect 버그가 도입되었을 때 정확한 커밋을 찾는 명령입니다. Git bisect를 사용하면 두 개의 커밋을 선택해야합니다. 두 커밋의 중간 정도가 체크 아웃됩니다. 버그 나 코드를 중단시킨 커밋이 발견 될 때까지 각 커밋이 불량인지 양호인지 확인합니다.
예:
- 새 로컬 git 저장소를 만들고 index.html이라는 파일을 만듭니다.
- 표시된대로 파일의 초기 내용.
- 스테이징에 추가하고 저장소에 커밋합니다.
- 좋은 커밋과 나쁜 커밋 중에서 선택할 수 있도록 표시된대로 커밋 기록을 만듭니다. 이제 초기 커밋이 완료되면 표시된대로 다른 변경을 수행하고 동일하게 커밋합니다. 전반적으로 7 개의 커밋을 수행합니다.
두 번째 변경
세 번째 변경
네 번째 변경
다섯 번째 변경
여섯 번째 변경
일곱 번째 변화
여기서 그만합시다. 그래서 우리는 7 개의 커밋을 가지고 있습니다.
Html 페이지를 보면“All the 4 events…”뒤의 줄이 잘못되어 문서가 올바르지 않습니다. 따라서 해당 커밋에 대한 HEAD를 쉴 수 있도록 오류가 발생한 커밋을 찾아야합니다.
로그를보고 나쁜 과 좋은 커밋.
최신 커밋이 올바르지 않으므로 잘못된 커밋 일 수 있습니다. 커밋은 세 번째 커밋 이후에 도입되었으므로 세 번째 변경 좋은 커밋으로.
이등분 과정은 자식 bisect 시작 그리고 끝 git bisect 재설정.
git bisect bad // 최신 커밋이 나쁘기 때문에. 커밋 ID를 제공 할 필요가 없습니다.
git bisect good
이제 HEAD가 나쁜 커밋과 좋은 커밋의 절반 사이에 있음을 알 수 있습니다.
index.html의 내용을보고 좋은 커밋이 있는지 확인하십시오. 그렇지 않으면 오류가 여전히 발견되지 않습니다.
실제로 오류가 여전히 존재한다는 것은 아닙니다. 마지막 줄이 잘못되었습니다. 그래서 우리는‘ git bisect bad '. 여전히 잘못된 커밋이 있으며 현재 콘텐츠는 허용되지 않습니다.
위의 내용은 정확하고 수용 가능합니다.
‘git log –oneline’및‘git bisect good’을 실행합니다.
그래서 다섯 번째 변경 첫 번째 나쁜 커밋이었습니다. 오류가 식별됩니다.
현재 내용은 최종 문서에 있어야합니다.
잘못된 커밋이 확인되면 개발자에게 마지막으로 좋은 커밋 인 네 번째 변경으로 헤드를 재설정하는 변경 사항을 수정하도록 알릴 수 있습니다.
운영 ' 자식 bisect 재설정 프로세스를 종료합니다.
결론
이 GitHub 실습 입문서에서는 개발자가 작업하는 데 필요한 모든 것, 즉 버전 제어 및 추적 관점에서 다루려고 노력했습니다.
GitHub 시리즈의 처음 3 개 자습서에서 버전 제어 활동, 리포지토리 생성, 풀 요청, 브랜치, 코드 검토, 조직 및 팀, 리포지토리 포크, 레이블, 마일스톤, 이슈, 프로젝트 보드, 위키, 릴리스, 통합에 대해 배웠습니다. Jira 및 개발자를 위해 일반적으로 사용되는 Git 명령을 사용합니다.
모든 개발자가 GitHub에 대한이 실습 방식과 프로젝트에서 유용한 Git 명령을 발견하기를 진심으로 바랍니다.
=> Easy GitHub 교육 시리즈를 읽어보십시오.