Git 및 Github 관리

입문

지금까지는 한정 공개됐지만 왠지 공개를 결정한 것 같다.그냥 필기할 정도야.

Github

issues 정보

issues는 응용 프로그램에서 기능 추가와 오류 등 문제가 발견되면 issue를 추가합니다.
사진 1 ~ 3에 대한 설명
1. github에서 issues와 Pull requests가 issues와 Pull requests에 추가될 때 #OO와 숫자를 계산할 때 issues와 Pull requests는 같은 계수이다. 이 숫자는 뒤에 기술된 Git 설명에 필요하다.
2. 이런 상황에서 "배분"은 추가된 issue를 누가 책임지는지 가리킨다.만약 이 책임자를 결정하지 않는다면 여러 사람이 같은 일을 할 가능성이 증가하고 시간을 낭비할 것이다.또 같은 곳을 바꿔야 하기 때문에 충돌의 원인이 된다.그러니까 쉽게 이해해 주세요.
3. Label issue 상태를 표시합니다.기능을 추가할 때 Enhanced 탭을 추가할 수 있습니다.

드래그 요청 정보

Pull requests는 작업 지점에서 변경을 하고 다른 구성원에게 추가된 내용을 베이스 지점 등에 합치라고 알려주는 것을 말한다.(내가 간단하게 설명했으니 네가 느끼지 않았으면 좋겠어...)
누구나 제멋대로 변경하고 추가된 지점을 합치면 무의미한 것과 낭비되는 것을 합칠 수도 있고, 더 말하면 충돌할 수도 있는 예상치 못한 것들을 합칠 수도 있다.이런 문제를 방지하기 위해 트랜지스터는 심사를 하고 문제가 있으면 트랜지스터가 문제를 제기하고 없으면 합병을 허용한다.

pull requests를 새로 만들 때 Reviewers 검토를 원하는 사람을 추가합니다

Assees와 Label은 issues에서 말한 것과 같다

검토와 참조가 완료되면 결합할 수 있습니다.현재 상황에서 리더는 강제 합병 권한이 있기 때문에 합병을 하고 있습니다. 가능하다면 (이렇게 하기를 원하면 리더도 잘못될 수 있기 때문에 현재 상태가 좋지 않습니다.) 논평 후에 요청한 개발 멤버를 보내 합병을 진행하세요

↓ 일반적인 템플릿

## 関連Issue

> このPRと関連するIssueの番号を書きます
> 例: ログイン画面 #13
> 「close #13」と書くと、PRがマージされた際に自動的に#13のIssueがcloseされるので便利です

## やったこと

> やったことを書きます
> 例: ログイン画面の実装

## 実装の詳細

> どのように実装したかを書きます（なるべく詳しく書いた方が良い）
> 例: LoginActivityを作成し、起動時に表示されるようにしました。

## レビューして欲しいところ

> 実装が不安なところなど、レビューして欲しいことを書きます

## スクリーンショット(あれば)

> UIに変更を加えた祭はスクショがあるとわかりやすいです。変更前・変更後のスクショがあると良い

Git 정보

git는 좀 어려울 수도 있지만 무섭지 않으니 침착하게 대처해야 한다.나는 여기서 앞으로 사용할 git 명령을 주로 설명하고 싶다.

git command

최소한의 필요 절차

설명

(지분 이름) 쓴 곳은 현재의 지점을 표시합니다.명령의 일종이 아니므로 주의해야 한다.반대로, 브랜치 이름으로 쓴 곳은 입력을 표시합니다.이 두 가지를 참고로 삼으세요.

$git clone 저장소 URL

원격 저장소에서 로컬로 데이터를 수신합니다.

$ git pull (develop)

원격에서 변경이 발생하면pull을 실행합니다.

$git branch "분기 이름" (develop)

기초 지점에서 작업 지점 만들기

$git checkout "분기 이름" (develop)

기본 지점에서 작업 지점으로 이동

$gitadd 여기에 필요한 것 (지분 이름) 기타 쓰기

변경이 있으면add를 실행합니다.상세한 상황은 아래에 기술하다

브랜치 이름

addcommit으로 무대에 오른 파일commit은commit에 대해서도 아래에 기술합니다.

브랜치 이름

작업 지점 변경 사항을 제출하면 지점을 이동할 수 있으므로 이동하십시오.
※ 작업 지점에서 파일을 변경하고 저장할 때commit 없이도 지점을 이동할 수 있으니 주의하십시오.

$ git pull (develop)

원격 개발자가 여기서 변경될 수 있기 때문에pull에서 변경 내용을 로컬에 반영하십시오.

$git checkout "분기 이름" (develop)

여기서 개발자의 상태를 확인하고 업무 지점으로 돌아가세요.

브랜치 이름

이 명령은 개발자가 자신의 작업 지점에서 끊어진 후 변경할 때 실행됩니다.개발자가 여기서 변경되었지만,push 작업 지점이push를 보내면merge에서 충돌이 발생합니다.이렇게 하면 수정이 번거롭기 때문에 현지에서 기초 지점을 다시 세워 충돌이 발생했는지 확인하고 지점의 파생 위치를 시작하세요.충돌 발생 시 충돌 해제

$git rebase--continue(지점 이름)

리베이스가 충돌하면 리베이스가 중단되므로 충돌이 사라지면 리베이스-continue를 진행하세요

$git push-forigin "지점 이름" (지점 이름)

완료되면 작업 지점push를 원격 작업 지점으로 이동합니다.첫 번째 원격에 작업 지점이 없더라도push origin "지점 이름"으로 생성됩니다.
※ 이 명령에는 -f가 있습니다.이것은 주의하지 않으면 위험하지만, 이해하면 문제없다.로컬과 원격에서 큰 변경이 진행되면push는 충돌을 일으킬 수 있습니다.이번의 경우 리베이스를 진행하였기 때문에 이런 자체의 -f를 추가하여 강제push를 할 것입니다.첫 번째 push라면 원격 작업 지점이 존재하지 않기 때문에 -f를 추가하지 않아도 문제없다

브랜치 이름

작업 지점을 완성한 후 오류가 발생하지 않도록 개발자 지점으로 계속 돌아가십시오.
이상은 기본 절차입니다.

다른 아시면 편한 명령.

$ git log --graph --all --oneline

너는 지점의 상태를 알 수 있다.

$ git status

변경된 파일의 상태를 알 수 있습니다.파일의 위치가 빨간색으로 표시되면 표시되지 않은 상태로 표시됩니다.녹색 상태라면 무대 위의 상태가 된다.여기 봐요, commit.commit은 무대 위의 것만 할 수 있으니 잘 확인해야 한다.
다른 것도 많지만 귀찮아서 안 써요.
구글 하나 주세요.

기능 / "작업 지점 이름" 정보

git branch 기능/"작업 지점 이름"
↑ 이 기능을 추가하면 작업 지점이 기초 구조에 통합되면 작업 지점이 삭제됩니다.
기본적으로 issue의 작업이 끝나면 그 지점이 필요하지 않기 때문에 삭제할 수 있습니다.

gitadd 정보

add는 몇 가지가 있습니다.
$git add 파일 위치
$git add "파일 위치 중간"*
$ git add -u
$ git add .
add 명령에는 몇 가지 방법이 있습니다.
만약add 다음에 파일의 위치를 기본적인 기초로 입력하면 이 파일은 저장됩니다.
예: $add app/res/values/colors.xml
시colors.xml 파일 저장
또한 디렉터리(폴더)가 없는 물건을 저장하고 싶을 때
예: $add app/res/values*
예: $add app/res/valu*
그러면 경로 뒤에 *를 넣고 입력한 파일과 일치하는 파일을 모두 스테이지에 놓습니다.
add-u: 원본 파일을 변경할 때 사용합니다.변경된 파일을 모두 스테이지에 주고 싶을 때 이 명령을 사용하세요.
add .: 추가되거나 변경된 모든 파일을 추가하는 명령입니다.따로 제출하고 싶을 때 이 명령을 사용하면 귀찮을 수 있으니 주의해야 한다.
add-i:재미있어요. 한번 써보세요.꼬르륵

git commit 정보

git commit
gitcommit-m "주석 입력"
commit도 여러 가지 방법이 있지만 기본적으로 이 두 가지면 됩니다.
만약 -m를 추가한 후에 제출 메시지를 입력하면 이 줄에서 제출할 수 있습니다.
gitcommit만 있는 경우vim는 일어서서 거기에 정보와 설명을 넣는다.자세한 건 오세요.