Gitlab CE ನಲ್ಲಿ ಕೋಡ್ ವಿಮರ್ಶೆ: ಯಾವುದೇ ವಿಲೀನ ವಿನಂತಿಯ ಅನುಮೋದನೆಗಳು ಇಲ್ಲದಿದ್ದರೆ, ಆದರೆ ನಾನು ನಿಜವಾಗಿಯೂ ಬಯಸುತ್ತೇನೆ

GitLab ನ ಉಚಿತ ಆವೃತ್ತಿಯಲ್ಲಿಲ್ಲದ ಅತ್ಯಂತ ಅಗತ್ಯವಾದ ಕಾರ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಕಡ್ಡಾಯ ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ಬಳಸಿಕೊಂಡು ರೆಪೊಸಿಟರಿ ಶೂನ್ಯೀಕರಣದ ವಿರುದ್ಧ ಮತ ಚಲಾಯಿಸುವ ಮತ್ತು ವಿಲೀನ ವಿನಂತಿಯನ್ನು (MR) ನಿಯಂತ್ರಿಸುವ ಸಾಮರ್ಥ್ಯ.

ಕನಿಷ್ಠ ಕಾರ್ಯವನ್ನು ನಾವೇ ಮಾಡೋಣ - ಹಲವಾರು ಡೆವಲಪರ್‌ಗಳು MR ಗೆ ಥಂಬ್ಸ್ ಅಪ್ ನೀಡುವವರೆಗೆ ನಾವು ವಿಲೀನವನ್ನು ನಿಷೇಧಿಸುತ್ತೇವೆ.

ಇದು ಇನ್ನೂ ಏಕೆ ಅಗತ್ಯ?

ನಮ್ಮ ಸಂಸ್ಥೆಯು ಸುಲಭವಾಗಿ GitLab ಪರವಾನಗಿಯನ್ನು ಖರೀದಿಸಬಹುದು. ಆದರೆ, ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವಿಲ್ಲದೆ ಮುಚ್ಚಿದ ಲೂಪ್‌ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಯನ್ನು ಕೈಗೊಳ್ಳುವುದರಿಂದ ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾದ ಬಜೆಟ್ ಯೋಜನೆ ಇರುವುದರಿಂದ, ಅಗತ್ಯ ಕ್ರಿಯಾತ್ಮಕತೆಯೊಂದಿಗೆ ಸ್ವಯಂ-ನಿರ್ವಹಣೆಯ ಪರವಾನಗಿಗಳ ಖರೀದಿಯು ಹಲವು ತಿಂಗಳುಗಳವರೆಗೆ ಎಳೆಯಬಹುದು, ಆದರೆ ಈಗ ಕೆಲಸವನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.

ಪರಿಣಾಮವಾಗಿ ನೀವು ಮಾಡಬೇಕು:

• ಅಥವಾ ಕೆಲವು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಂರಕ್ಷಿತ ಶಾಖೆಗಳಲ್ಲಿ ವಿಲೀನಗೊಳಿಸುವುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷೇಧಿಸಿ, ಆದರೆ ವಿಲೀನಗೊಳಿಸುವ ಹಕ್ಕನ್ನು ಹೊಂದಿರುವ ಡೆವಲಪರ್‌ಗಳು ಇತರ ಜನರ MR ಗಳನ್ನು ಬೋನಸ್‌ನಂತೆ ವಿಲೀನಗೊಳಿಸುವಾಗ ಸಂಘರ್ಷಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ;
• ಅಥವಾ ನಿನ್ನೆಯಷ್ಟೇ ನೇಮಕಗೊಂಡ ಜೂನಿಯರ್ ಆಗಿದ್ದರೂ, ಕೋಡ್ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ನಿಮ್ಮ ಮಾಸ್ಟರ್ ಶಾಖೆಯೊಂದಿಗೆ ಅನಿಯಂತ್ರಿತ ವಿಲೀನಗಳನ್ನು ಮಾಡಲು ಅವಕಾಶವನ್ನು ನೀಡಿ.

ನಾನು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಗೂಗಲ್, ಯಾರಾದರೂ ಖಂಡಿತವಾಗಿಯೂ ಈಗಾಗಲೇ ಇದೇ ರೀತಿಯದ್ದನ್ನು ಮಾಡಿದ್ದಾರೆ ಎಂದು ನಂಬಿದ್ದರು (ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸದೆ), ಆದರೆ ಸಮುದಾಯ ಆವೃತ್ತಿಯಲ್ಲಿ ಇನ್ನೂ ಅಂತಹ ಅನುಷ್ಠಾನವಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು.

ಕೆಲಸದ ಸಾಮಾನ್ಯ ಯೋಜನೆ

ಉದಾಹರಣೆಯಾಗಿ, ಪರೀಕ್ಷಾ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ವಿಲೀನ ವಿನಂತಿಯ ಅನುಮೋದನೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡೋಣ myapp:

1. GitLab API ಗೆ ಪ್ರವೇಶಕ್ಕಾಗಿ ಟೋಕನ್ ಅನ್ನು ರಚಿಸೋಣ (ಅದರ ಮೂಲಕ ನಾವು "ಪರ" ಮತ್ತು "ವಿರುದ್ಧ" ಮತಗಳ ಸಂಖ್ಯೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ)
2. GitLab ವೇರಿಯೇಬಲ್‌ಗಳಿಗೆ ಟೋಕನ್ ಅನ್ನು ಸೇರಿಸೋಣ
3. ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ದೋಷಗಳಿದ್ದಲ್ಲಿ ವಿಲೀನವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸೋಣ (ಸಾಕಷ್ಟು ಅಪ್‌ವೋಟ್‌ಗಳು ಇಲ್ಲದಿದ್ದರೆ)
4. CI/CD ಪೈಪ್‌ಲೈನ್‌ನ ಭಾಗವಾಗಿ ಮತ ಪರಿಶೀಲನೆಯನ್ನು ಹೊಂದಿಸೋಣ
5. ಸಂರಕ್ಷಿತ ಶಾಖೆಗಳಿಗೆ ಬದ್ಧತೆಗಳನ್ನು ಮಾಡುವುದನ್ನು ನಾವು ನಿಷೇಧಿಸುತ್ತೇವೆ; ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು MR ಮೂಲಕ ಮಾತ್ರ ಮಾಡಲಾಗುತ್ತದೆ
6. ಕೊನೆಯಲ್ಲಿ ಏನಾಯಿತು ಎಂದು ಪರಿಶೀಲಿಸೋಣ

1. API ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಟೋಕನ್ ಅನ್ನು ರಚಿಸಿ

ಬಳಕೆದಾರರ ಸೆಟ್ಟಿಂಗ್‌ಗಳು → ಪ್ರವೇಶ ಟೋಕನ್‌ಗಳಿಗೆ ಹೋಗಿ ಮತ್ತು ಟೋಕನ್ ಅನ್ನು ಬರೆಯಿರಿ:

ಟೋಕನ್ ಸ್ವೀಕರಿಸಲು ಖಾತೆ
API ಪ್ರವೇಶವು ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಗಳೊಂದಿಗೆ ಬಹುತೇಕ ಏನನ್ನೂ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾನು ಪ್ರತ್ಯೇಕ Gitlab ಖಾತೆಯನ್ನು ರಚಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಗಳಿಗೆ (ಉದಾ ವರದಿಗಾರ) ಕನಿಷ್ಠ ಹಕ್ಕುಗಳನ್ನು ನೀಡಿ ಮತ್ತು ಆ ಖಾತೆಗೆ ಟೋಕನ್ ಪಡೆದುಕೊಳ್ಳಿ.

2. Gitlab ವೇರಿಯೇಬಲ್‌ಗಳಿಗೆ ಟೋಕನ್ ಸೇರಿಸಿ

ಉದಾಹರಣೆಗೆ, ಹಿಂದಿನ ಹಂತದಲ್ಲಿ ನಾವು ಟೋಕನ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ QmN2Y0NOUFlfeXhvd21ZS01aQzgK

ತೆರೆಯಿರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು → CI/CD → ವೇರಿಯೇಬಲ್‌ಗಳು → ವೇರಿಯಬಲ್ ಸೇರಿಸಿ → GITLAB_TOKEN_FOR_CI

ಪರಿಣಾಮವಾಗಿ ನಾವು ಪಡೆಯುತ್ತೇವೆ:

ಇದನ್ನು ಒಂದು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಅಥವಾ ರೆಪೊಸಿಟರಿಗಳ ಗುಂಪಿನಲ್ಲಿ ಮಾಡಬಹುದು.

3. ಕೋಡ್ ಪರಿಶೀಲನೆಯ ನಂತರ ಸಹೋದ್ಯೋಗಿಗಳ ಅನುಮೋದನೆಯನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ ನಾವು ವಿಲೀನದ ಮೇಲೆ ನಿಷೇಧವನ್ನು ಹಾಕುತ್ತೇವೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಲೀನದ ಮೇಲಿನ ನಿಷೇಧವು ಸಾಕಷ್ಟು ಮತಗಳಿಲ್ಲದಿದ್ದರೆ ಅಸೆಂಬ್ಲಿ ಪೈಪ್‌ಲೈನ್ ದೋಷವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ.

ಸೆಟ್ಟಿಂಗ್‌ಗಳು → ಸಾಮಾನ್ಯ → ವಿಲೀನ ವಿನಂತಿಗಳು → ಚೆಕ್‌ಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಿ ಮತ್ತು ಆಯ್ಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ ಅಸೆಂಬ್ಲಿ ಸಾಲುಗಳು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳಬೇಕು.

4. ಪೈಪ್ಲೈನ್ ​​ಅನ್ನು ಹೊಂದಿಸುವುದು

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ನೀವು ಇನ್ನೂ CI/CD ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ರಚಿಸದಿದ್ದರೆ
ರೆಪೊಸಿಟರಿಯ ಮೂಲದಲ್ಲಿ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿ .gitlab-ci.yml ಸರಳವಾದ ವಿಷಯದೊಂದಿಗೆ:

stages:
  - build
  - test

variables:
  NEED_VOTES: 1

include:
  - remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
  stage: build
  script: echo "Hello world"

CI/CD ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕ ರೆಪೊಸಿಟರಿ
ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನೀವು myapp.gitlab-ci.yml ಫೈಲ್ ಅನ್ನು ರಚಿಸಬೇಕಾದ ಪ್ರತ್ಯೇಕ ರೆಪೊಸಿಟರಿಯನ್ನು ಮಾಡಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಈ ರೀತಿಯಲ್ಲಿ ನೀವು ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಮತ್ತು ಪ್ರವೇಶ ಟೋಕನ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಭಾಗವಹಿಸುವವರ ಪ್ರವೇಶವನ್ನು ಉತ್ತಮವಾಗಿ ನಿಯಂತ್ರಿಸಬಹುದು.

ಹೊಸ ಪೈಪ್‌ಲೈನ್ ಫೈಲ್‌ನ ಸ್ಥಳವನ್ನು myapp ರೆಪೊಸಿಟರಿ - ಸೆಟ್ಟಿಂಗ್‌ಗಳು - CI/CD - ಅಸೆಂಬ್ಲಿ ಲೈನ್‌ಗಳು - ಕಸ್ಟಮ್ CI ಕಾನ್ಫಿಗರೇಶನ್ ಮಾರ್ಗಕ್ಕೆ ಹೋಗುವ ಮೂಲಕ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗುತ್ತದೆ - ಹೊಸ ಫೈಲ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ, ಉದಾ. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

ಸಲಹೆ: GitLab CI ಫೈಲ್‌ಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಲಿಂಟರ್ ಬಳಸಿ
ನೀವು ಏಕಾಂಗಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೂ ಸಹ, MR ಮೂಲಕ ಕೆಲಸ ಮಾಡುವುದು ಉತ್ತಮ ಸಹಾಯವಾಗುತ್ತದೆ, ಪೈಪ್‌ಲೈನ್ ಫೈಲ್‌ಗಳಿಗೆ ನಿಮ್ಮ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಲಿಂಟರ್ ಮೂಲಕ ರನ್ ಮಾಡುತ್ತದೆ. YAML ಫೈಲ್‌ನ ಸಿಂಟ್ಯಾಕ್ಸ್‌ನಲ್ಲಿ ನೀವು ತಪ್ಪು ಮಾಡಿದರೆ, ಅದು ನಿಮ್ಮ ಉತ್ಪಾದನಾ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಮುರಿಯುವುದಿಲ್ಲ, ಆದರೆ ವಿಲೀನವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ.

ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ನೀವು ನಿರ್ಮಿಸಬಹುದಾದ ಲಿಂಟರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಕಂಟೇನರ್‌ಗಳ ಉದಾಹರಣೆ:

hub.docker.com/r/gableroux/gitlab-ci-lint
hub.docker.com/r/sebiwi/gitlab-ci-validate

ಮತ್ತು ಪರಿಶೀಲನೆ ಹಂತದ ಉದಾಹರಣೆ:

stages:
  - lint

lint:
  stage: lint
  image: sebiwi/gitlab-ci-validate:1.3.0
  variables:
    GITLAB_HOST: https://gitlab.com
  script:
    - CI_FILES=(./*.yml)
    - for f in "${CI_FILES[@]}"; do
        gitlab-ci-validate $f;
      done;

ಇದು ಕೆಲಸ ಮಾಡಲು ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್‌ಗೆ ಕೆಲವು ನಿಯತಾಂಕಗಳನ್ನು ಸೇರಿಸಲು ಉಳಿದಿದೆ:

stages:
- test

variables:
NEED_VOTES: 1

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

NEED_VOTES ವೇರಿಯೇಬಲ್ ವಿಲೀನ ಲಭ್ಯವಾಗಲು MR ಎಷ್ಟು "ಥಂಬ್ಸ್ ಅಪ್" ಹೊಂದಿರಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಒಂದಕ್ಕೆ ಸಮಾನವಾದ ಮೌಲ್ಯ ಎಂದರೆ ನಿಮ್ಮ MR ಅನ್ನು "ಇಷ್ಟಪಡುವ" ಮೂಲಕ ನೀವೇ ಅನುಮೋದಿಸಬಹುದು.

ಪರೀಕ್ಷಾ ಹಂತವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು "ಇಷ್ಟಗಳ" ಸಂಖ್ಯೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

myapp.gitlab-ci.yml ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಸರಳವಾದ ಪೈಪ್‌ಲೈನ್
stages:
- build
- test

variables:
NEED_VOTES: 0

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
stage: build
image: openjdk
script:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java

ಪರಿವಿಡಿ ಚೆಕ್-ಅಪ್ರೂವ್.gitlab-ci.yml
ci-mr:
stage: test
script:
- echo ${CI_API_V4_URL}
- echo "CI_PROJECT_ID ${CI_PROJECT_ID}"
- echo "CI_COMMIT_SHA ${CI_COMMIT_SHA}"
- "export MR_ID=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .id else {} end" | grep --invert-match {})"
- "export MR_TITLE=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .title else {} end" | grep --invert-match {})"
- "export MR_WIP=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .work_in_progress else {} end" | grep --invert-match {})"
- "export MR_UPVOTES=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .upvotes else {} end" | grep --invert-match {})"
- "export MR_DOWNVOTES=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .downvotes else {} end" | grep --invert-match {})"
- MR_VOTES=$(expr ${MR_UPVOTES} - ${MR_DOWNVOTES})
- NEED_VOTES_REAL=${NEED_VOTES:-1}
- echo "MR_ID ${MR_ID} MR_TITLE ${MR_TITLE} MR_WIP ${MR_WIP} MR_UPVOTES ${MR_UPVOTES} MR_DOWNVOTES ${MR_DOWNVOTES}"
- echo "MR_VOTES ${MR_VOTES} Up vote = 1, down vote = -1, MR OK if votes >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
then
echo "MR OK";
else
echo "MR ERROR Need more votes";
exit 1;
fi
image: laptevss/gitlab-api-util
rules:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release/.*$/'


ಪರಿಶೀಲನೆಯ ಸಮಯದಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿ:

• ಮಾಸ್ಟರ್ ಅಥವಾ ಬಿಡುಗಡೆ/* ಶಾಖೆಗಳಲ್ಲಿ MR ಅನ್ನು ರಚಿಸುವಾಗ ಮಾತ್ರ ಚೆಕ್ ಮಾಡಲಾಗುವುದು ಎಂಬ ನಿರ್ಬಂಧವಿದೆ
• GitLab API ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು "ಇಷ್ಟಗಳು" ಮತ್ತು "ಇಷ್ಟಪಡದಿರುವವುಗಳ" ಸಂಖ್ಯೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ
• ಧನಾತ್ಮಕ ಮತ್ತು ಋಣಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಲೆಕ್ಕಹಾಕಿ
• ವ್ಯತ್ಯಾಸವು ನಾವು NEED_VOTES ನಲ್ಲಿ ಹೊಂದಿಸಿರುವ ಮೌಲ್ಯಕ್ಕಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ, ನಾವು ವಿಲೀನಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತೇವೆ

5. ಸಂರಕ್ಷಿತ ಶಾಖೆಗಳಿಗೆ ಬದ್ಧತೆಯನ್ನು ನಿಷೇಧಿಸಿ

ನಾವು ಕೋಡ್ ವಿಮರ್ಶೆಗಳನ್ನು ನಡೆಸಬೇಕಾದ ಶಾಖೆಗಳನ್ನು ನಾವು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು MR ಮೂಲಕ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಬಹುದೆಂದು ಸೂಚಿಸುತ್ತೇವೆ.

ಇದನ್ನು ಮಾಡಲು, ಸೆಟ್ಟಿಂಗ್‌ಗಳು → ರೆಪೊಸಿಟರಿ → ಸಂರಕ್ಷಿತ ಶಾಖೆಗಳಿಗೆ ಹೋಗಿ:

6. ಪರಿಶೀಲಿಸಿ

NEED_VOTES ಹೊಂದಿಸಿ: 0

ನಾವು ಎಂಆರ್ ಅನ್ನು ತಯಾರಿಸುತ್ತೇವೆ ಮತ್ತು "ಇಷ್ಟವಿಲ್ಲ" ಎಂದು ಹಾಕುತ್ತೇವೆ.

ನಿರ್ಮಾಣ ದಾಖಲೆಗಳಲ್ಲಿ:

ಈಗ "ಇಷ್ಟ" ಹಾಕಿ ಮತ್ತು ಮತ್ತೆ ಪರಿಶೀಲಿಸಲು ಪ್ರಾರಂಭಿಸಿ:

ಮೂಲ: www.habr.com