ನೀವು Git ಆಜ್ಞೆಗಳನ್ನು ಕಲಿತಿದ್ದೀರಾ ಆದರೆ ನಿರಂತರ ಏಕೀಕರಣ (CI) ವಾಸ್ತವದಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಊಹಿಸಲು ಬಯಸುವಿರಾ? ಅಥವಾ ನಿಮ್ಮ ದೈನಂದಿನ ಚಟುವಟಿಕೆಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ನೀವು ಬಯಸುತ್ತೀರಾ? ಈ ಕೋರ್ಸ್ ನಿಮಗೆ GitHub ರೆಪೊಸಿಟರಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಿರಂತರ ಏಕೀಕರಣದಲ್ಲಿ ಪ್ರಾಯೋಗಿಕ ಕೌಶಲ್ಯಗಳನ್ನು ನೀಡುತ್ತದೆ. ಈ ಕೋರ್ಸ್ ನೀವು ಸರಳವಾಗಿ ಕ್ಲಿಕ್ ಮಾಡಬಹುದಾದ ಮಾಂತ್ರಿಕನಾಗಲು ಉದ್ದೇಶಿಸಿಲ್ಲ; ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಜನರು ಕೆಲಸದಲ್ಲಿ ನಿಜವಾಗಿ ಮಾಡುವ ಅದೇ ಕ್ರಿಯೆಗಳನ್ನು ಅವರು ಮಾಡುವ ರೀತಿಯಲ್ಲಿಯೇ ನೀವು ನಿರ್ವಹಿಸುತ್ತೀರಿ. ನೀವು ಒಳಗೊಂಡಿರುವ ಹಂತಗಳ ಮೂಲಕ ಹೋದಂತೆ ನಾನು ಸಿದ್ಧಾಂತವನ್ನು ವಿವರಿಸುತ್ತೇನೆ.

ನಾವು ಏನು ಮಾಡುವುದು?

ನಾವು ಪ್ರಗತಿಯಲ್ಲಿರುವಂತೆ, ನಾವು ಕ್ರಮೇಣ ವಿಶಿಷ್ಟ CI ಹಂತಗಳ ಪಟ್ಟಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ, ಇದು ಈ ಪಟ್ಟಿಯನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಮಾಡುವಾಗ, ನಿರಂತರ ಏಕೀಕರಣವನ್ನು ಮಾಡುವಾಗ ಡೆವಲಪರ್‌ಗಳು ತೆಗೆದುಕೊಳ್ಳುವ ಕ್ರಮಗಳ ಪಟ್ಟಿಯನ್ನು ನಾವು ರಚಿಸುತ್ತೇವೆ. ನಮ್ಮ CI ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೈಜತೆಗೆ ಹತ್ತಿರ ತರಲು ನಾವು ಸರಳವಾದ ಪರೀಕ್ಷೆಗಳನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ.

ನೀವು ಕೋರ್ಸ್ ಮೂಲಕ ಪ್ರಗತಿಯಲ್ಲಿರುವಾಗ ಈ GIF ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯಲ್ಲಿನ ಕಮಿಟ್‌ಗಳನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ತೋರಿಸುತ್ತದೆ. ನೀವು ನೋಡುವಂತೆ, ಇಲ್ಲಿ ಏನೂ ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ ಮತ್ತು ಅತ್ಯಂತ ಅವಶ್ಯಕವಾಗಿದೆ.

ನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಮಾಣಿತ CI ಸನ್ನಿವೇಶಗಳ ಮೂಲಕ ಹೋಗುತ್ತೀರಿ:

• ವೈಶಿಷ್ಟ್ಯದ ಮೇಲೆ ಕೆಲಸ ಮಾಡಿ;
• ಗುಣಮಟ್ಟವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳ ಅಪ್ಲಿಕೇಶನ್;
• ಆದ್ಯತೆಯ ಕಾರ್ಯದ ಅನುಷ್ಠಾನ;
• ಶಾಖೆಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವಾಗ ಸಂಘರ್ಷ ಪರಿಹಾರ (ವಿಲೀನ ಸಂಘರ್ಷ);
• ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ದೋಷ ಸಂಭವಿಸುತ್ತದೆ.

ನೀವು ಏನು ಕಲಿಯುವಿರಿ?

ನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ:

• ನಿರಂತರ ಏಕೀಕರಣ (CI) ಎಂದರೇನು?
• CI ನಲ್ಲಿ ಯಾವ ರೀತಿಯ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಯಾವ ಕ್ರಿಯೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಅವು ಪ್ರಚೋದಿಸಲ್ಪಡುತ್ತವೆ?
• ಪುಲ್ ವಿನಂತಿಗಳು ಯಾವುವು ಮತ್ತು ಅವು ಯಾವಾಗ ಬೇಕು?
• ಟೆಸ್ಟ್ ಡ್ರೈವನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ (ಟಿಡಿಡಿ) ಎಂದರೇನು ಮತ್ತು ಅದು ಸಿಐಗೆ ಹೇಗೆ ಸಂಬಂಧಿಸಿದೆ?
• ನಾನು ಬದಲಾವಣೆಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಬೇಕೇ ಅಥವಾ ಮರುಬೇಸ್ ಮಾಡಬೇಕೇ?
• ರೋಲ್ ಬ್ಯಾಕ್ ಅಥವಾ ಮುಂದಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ಸರಿಪಡಿಸುವುದೇ?

ಮೊದಲಿಗೆ ನಾನು "ಪುಲ್ ವಿನಂತಿಗಳು" ನಂತಹ ವಿಷಯಗಳನ್ನು ಎಲ್ಲೆಡೆ ಅನುವಾದಿಸಿದೆ, ಆದರೆ ಇದರ ಪರಿಣಾಮವಾಗಿ ನಾನು ಪಠ್ಯದಲ್ಲಿನ ಹುಚ್ಚುತನದ ಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ನುಡಿಗಟ್ಟುಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲು ನಿರ್ಧರಿಸಿದೆ. ನಾನು ಕೆಲವೊಮ್ಮೆ "ಪ್ರೋಗ್ರಾಮರ್ ಸುರ್ಜಿಕ್" ಅನ್ನು ಅದ್ಭುತವಾದ ಕ್ರಿಯಾಪದ "ಕಮಿಟ್" ನಂತೆ ಬಳಸುತ್ತೇನೆ, ಅಲ್ಲಿ ಜನರು ಅದನ್ನು ಕೆಲಸದಲ್ಲಿ ಬಳಸುತ್ತಾರೆ.

ನಿರಂತರ ಏಕೀಕರಣ ಎಂದರೇನು?

ನಿರಂತರ ಏಕೀಕರಣ, ಅಥವಾ CI, ಇದು ತಾಂತ್ರಿಕ ಅಭ್ಯಾಸವಾಗಿದ್ದು, ಇದರಲ್ಲಿ ಪ್ರತಿ ತಂಡದ ಸದಸ್ಯರು ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ದಿನಕ್ಕೆ ಒಮ್ಮೆಯಾದರೂ ಸಾಮಾನ್ಯ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಯೋಜಿಸುತ್ತಾರೆ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ ಕೋಡ್ ಅನ್ನು ಕನಿಷ್ಠ ದೋಷಗಳಿಲ್ಲದೆ ನಿರ್ಮಿಸಬೇಕು.

ಈ ಪದದ ಬಗ್ಗೆ ಭಿನ್ನಾಭಿಪ್ರಾಯಗಳಿವೆ

ವಿವಾದದ ಅಂಶವೆಂದರೆ ಏಕೀಕರಣದ ಆವರ್ತನ. ದಿನಕ್ಕೆ ಒಮ್ಮೆ ಮಾತ್ರ ಕೋಡ್ ಅನ್ನು ವಿಲೀನಗೊಳಿಸುವುದು ವಾಸ್ತವವಾಗಿ ನಿರಂತರವಾಗಿ ಸಂಯೋಜಿಸಲು ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂದು ಕೆಲವರು ವಾದಿಸುತ್ತಾರೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಬೆಳಿಗ್ಗೆ ತಾಜಾ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮತ್ತು ಸಂಜೆ ಒಮ್ಮೆ ಅದನ್ನು ಸಂಯೋಜಿಸುವ ತಂಡದ ಉದಾಹರಣೆಯನ್ನು ನೀಡಲಾಗಿದೆ. ಇದು ಸಮಂಜಸವಾದ ಆಕ್ಷೇಪಣೆಯಾಗಿದ್ದರೂ, ದಿನಕ್ಕೆ ಒಮ್ಮೆ ವ್ಯಾಖ್ಯಾನವು ಸಮಂಜಸವಾಗಿ ಪ್ರಾಯೋಗಿಕ, ನಿರ್ದಿಷ್ಟ ಮತ್ತು ವಿಭಿನ್ನ ಗಾತ್ರದ ತಂಡಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ ಎಂದು ಸಾಮಾನ್ಯವಾಗಿ ನಂಬಲಾಗಿದೆ.

ಮತ್ತೊಂದು ಆಕ್ಷೇಪಣೆಯೆಂದರೆ, C++ ಇನ್ನು ಮುಂದೆ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಬಳಸಲಾಗುವ ಏಕೈಕ ಭಾಷೆಯಾಗಿಲ್ಲ, ಮತ್ತು ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಯ ಮಾರ್ಗವಾಗಿ ದೋಷ-ಮುಕ್ತ ಜೋಡಣೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಕೆಲವು ಪರೀಕ್ಷೆಗಳು (ಉದಾಹರಣೆಗೆ, ಸ್ಥಳೀಯವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ಘಟಕ ಪರೀಕ್ಷೆಗಳು) ಸಹ ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಬೇಕು. ಈ ಸಮಯದಲ್ಲಿ, ಸಮುದಾಯವು ಇದನ್ನು ಅವಶ್ಯಕತೆಯನ್ನಾಗಿ ಮಾಡುವತ್ತ ಸಾಗುತ್ತಿದೆ ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ "ಬಿಲ್ಡ್ + ಯೂನಿಟ್ ಪರೀಕ್ಷೆಗಳು" ಇದು ಈಗಾಗಲೇ ಇಲ್ಲದಿದ್ದರೆ ಬಹುಶಃ ಸಾಮಾನ್ಯ ಅಭ್ಯಾಸವಾಗಿ ಪರಿಣಮಿಸುತ್ತದೆ.

ನಿರಂತರ ಏಕೀಕರಣ ಭಿನ್ನವಾಗಿದೆ ನಿರಂತರ ವಿತರಣೆ (ನಿರಂತರ ವಿತರಣೆ, CD) ಇದರಲ್ಲಿ ಪ್ರತಿ ಏಕೀಕರಣ ಚಕ್ರದ ನಂತರ ಬಿಡುಗಡೆ ಅಭ್ಯರ್ಥಿಯ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.

ನಾವು ಕೋರ್ಸ್ ಉದ್ದಕ್ಕೂ ಬಳಸುವ ಹಂತಗಳ ಪಟ್ಟಿ

1. ಇತ್ತೀಚಿನ ಕೋಡ್ ಅನ್ನು ಎಳೆಯಿರಿ. ನಿಂದ ಶಾಖೆಯನ್ನು ರಚಿಸಿ master. ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸು.
2. ನಿಮ್ಮ ಹೊಸ ಶಾಖೆಯಲ್ಲಿ ಕಮಿಟ್‌ಗಳನ್ನು ರಚಿಸಿ. ಸ್ಥಳೀಯವಾಗಿ ನಿರ್ಮಿಸಿ ಮತ್ತು ಪರೀಕ್ಷಿಸಿ. ಉತ್ತೀರ್ಣ? ಮುಂದಿನ ಹಂತಕ್ಕೆ ಹೋಗಿ. ಅನುತ್ತೀರ್ಣ? ದೋಷಗಳು ಅಥವಾ ಪರೀಕ್ಷೆಗಳನ್ನು ಸರಿಪಡಿಸಿ ಮತ್ತು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ.
3. ನಿಮ್ಮ ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿ ಅಥವಾ ರಿಮೋಟ್ ಶಾಖೆಗೆ ತಳ್ಳಿರಿ.
4. ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ. ಬದಲಾವಣೆಗಳನ್ನು ಚರ್ಚಿಸಿ, ಚರ್ಚೆ ಮುಂದುವರಿದಂತೆ ಹೆಚ್ಚಿನ ಬದ್ಧತೆಗಳನ್ನು ಸೇರಿಸಿ. ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಯಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಪಾಸ್ ಮಾಡಿ.
5. ಮಾಸ್ಟರ್‌ನಿಂದ ವಿಲೀನ/ರೀಬೇಸ್ ಕಮಿಟ್‌ಗಳು. ವಿಲೀನದ ಫಲಿತಾಂಶದ ಮೇಲೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಪಾಸ್ ಮಾಡಿ.
6. ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಯಿಂದ ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಿ.
7. ಕೆಲವು ಸಮಯದವರೆಗೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದ್ದರೆ, ಬದಲಾವಣೆಗಳನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ವಿಲೀನಗೊಳಿಸಿ.

️ ತಯಾರಿ

ನೀವು ಸರಿಯಾದ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಹೊಂದಿರುವಿರಾ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ

ಈ ಕೋರ್ಸ್ ತೆಗೆದುಕೊಳ್ಳಲು ನಿಮಗೆ ಅಗತ್ಯವಿರುತ್ತದೆ Node.js и Git ಕ್ಲೈಂಟ್.

ನೀವು ಯಾವುದೇ Git ಕ್ಲೈಂಟ್ ಅನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ನಾನು ಆಜ್ಞಾ ಸಾಲಿನ ಆದೇಶಗಳನ್ನು ಮಾತ್ರ ನೀಡುತ್ತೇನೆ.

ನೀವು ಕಮಾಂಡ್ ಲೈನ್ ಅನ್ನು ಬೆಂಬಲಿಸುವ Git ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ

ಆಜ್ಞಾ ಸಾಲನ್ನು ಬೆಂಬಲಿಸುವ Git ಕ್ಲೈಂಟ್ ಅನ್ನು ನೀವು ಇನ್ನೂ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಅನುಸ್ಥಾಪನಾ ಸೂಚನೆಗಳನ್ನು ಕಾಣಬಹುದು ಇಲ್ಲಿ.

ರೆಪೊಸಿಟರಿಯನ್ನು ತಯಾರಿಸಿ

ನೀವು ವೈಯಕ್ತಿಕ ನಕಲನ್ನು (ಫೋರ್ಕ್) ರಚಿಸಬೇಕಾಗಿದೆ ಕೋರ್ಸ್‌ಗಾಗಿ ಕೋಡ್‌ನೊಂದಿಗೆ ಟೆಂಪ್ಲೇಟ್ ರೆಪೊಸಿಟರಿ GitHub ನಲ್ಲಿ. ಈ ವೈಯಕ್ತಿಕ ಪ್ರತಿಯನ್ನು ಕರೆಯಲು ಒಪ್ಪಿಕೊಳ್ಳೋಣ ಕೋರ್ಸ್ ರೆಪೊಸಿಟರಿ.

ಮುಗಿದಿದೆಯೇ? ನೀವು ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸದಿದ್ದರೆ, ನಿಮ್ಮ ಕೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಹೆಚ್ಚಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ continuous-integration-team-scenarios-students, ಇದು ನಿಮ್ಮ GitHub ಖಾತೆಯಲ್ಲಿದೆ ಮತ್ತು URL ಈ ರೀತಿ ಕಾಣುತ್ತದೆ

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

ನಾನು ಈ ವಿಳಾಸಕ್ಕೆ ಸರಳವಾಗಿ ಕರೆ ಮಾಡುತ್ತೇನೆ <URL репозитория>.

ಕೋನ ಆವರಣಗಳು ಹಾಗೆ <тут> ನೀವು ಅಂತಹ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಸೂಕ್ತವಾದ ಮೌಲ್ಯದೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕು ಎಂದರ್ಥ.

ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ GitHub ಕ್ರಿಯೆಗಳು ಈ ಕೋರ್ಸ್ ರೆಪೊಸಿಟರಿಗಾಗಿ ಸೇರಿಸಲಾಗಿದೆ. ಅವುಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸದಿದ್ದರೆ, ದಯವಿಟ್ಟು ಪುಟದ ಮಧ್ಯದಲ್ಲಿರುವ ದೊಡ್ಡ ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ ಅವುಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ, ಅದನ್ನು ನೀವು GitHub ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಕ್ರಿಯೆಗಳನ್ನು ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ ಪಡೆಯಬಹುದು.

GitHub ಕ್ರಿಯೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸದಿದ್ದರೆ ನನ್ನ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿ ಕೋರ್ಸ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ನಾವು ಇಲ್ಲಿ ರಚಿಸುತ್ತಿರುವ ಪಟ್ಟಿಯ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ನೋಡಲು ಮಾರ್ಕ್‌ಡೌನ್ ಅನ್ನು ನಿರೂಪಿಸಲು ನೀವು ಯಾವಾಗಲೂ GitHub ನ ಸಾಮರ್ಥ್ಯವನ್ನು ಬಳಸಬಹುದು

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

ಉತ್ತರಗಳ ಬಗ್ಗೆ

ಈ ಕೋರ್ಸ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವೆಂದರೆ ಅದನ್ನು ನೀವೇ ಮಾಡುವುದು, ನೀವು ಕೆಲವು ತೊಂದರೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು.

ಏನು ಮಾಡಬೇಕೆಂದು ನಿಮಗೆ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ ಮತ್ತು ಮುಂದುವರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನೀವು ಭಾವಿಸಿದರೆ, ನೀವು ಥ್ರೆಡ್ ಅನ್ನು ನೋಡಬಹುದು solution, ಇದು ನಿಮ್ಮ ಪ್ರಾರಂಭ ಭಂಡಾರದಲ್ಲಿದೆ.
ದಯವಿಟ್ಟು ವಿಲೀನಗೊಳಿಸಬೇಡಿ solution в master ಕೋರ್ಸ್ ಸಮಯದಲ್ಲಿ. Git ನಮಗೆ ನೀಡುವ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಏನು ಮಾಡಬೇಕೆಂದು ಅಥವಾ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಲೇಖಕರೊಂದಿಗೆ ಹೋಲಿಸಲು ನೀವು ಈ ಶಾಖೆಯನ್ನು ಬಳಸಬಹುದು. ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಹೋದರೆ, ನಿಮ್ಮ ಶಾಖೆಯನ್ನು ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬಹುದು master ಒಂದು ಶಾಖೆಯ ಮೇಲೆ solution ತದನಂತರ ನಿಮ್ಮ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿಯನ್ನು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಕೋರ್ಸ್ ಹಂತಕ್ಕೆ ಮರುಹೊಂದಿಸಿ.

ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದ್ದರೆ ಮಾತ್ರ ಇದನ್ನು ಬಳಸಿ

ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಒಪ್ಪಿಸಿ

git add .
git commit -m "Backing up my work"

ಈ ಆಜ್ಞೆಗಳು

• ಮರುಹೆಸರಿಸು master в master-backup;
• ಮರುಹೆಸರಿಸು solution в master;
• ಹೊಸ ಶಾಖೆಗೆ ಚೆಕ್ಔಟ್ master ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಡೈರೆಕ್ಟರಿಯ ವಿಷಯಗಳನ್ನು ಪುನಃ ಬರೆಯಿರಿ;
• ಭವಿಷ್ಯದಲ್ಲಿ ನಿಮಗೆ "ಪರಿಹಾರ" ಶಾಖೆಯ ಅಗತ್ಯವಿದ್ದರೆ "ಮಾಸ್ಟರ್" ನಿಂದ "ಪರಿಹಾರ" ಶಾಖೆಯನ್ನು ರಚಿಸಿ (ಇದು "ಪರಿಹಾರ" ಆಗಿರುತ್ತದೆ).

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

ಈ ಹಂತಗಳ ನಂತರ ನೀವು ಬಳಸಬಹುದು git log master ನಿಮಗೆ ಯಾವ ಬದ್ಧತೆ ಬೇಕು ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು.
ನಿಮ್ಮ ವರ್ಕಿಂಗ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ನೀವು ಈ ರೀತಿಯ ಬದ್ಧತೆಗೆ ಮರುಹೊಂದಿಸಬಹುದು:

git reset --hard <the SHA you need>

ಫಲಿತಾಂಶದಿಂದ ನೀವು ಸಂತುಷ್ಟರಾಗಿದ್ದರೆ, ಕೆಲವು ಹಂತದಲ್ಲಿ ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯ ಆವೃತ್ತಿಯನ್ನು ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಗೆ ನೀವು ಪ್ರಕಟಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು ಇದನ್ನು ಮಾಡುವಾಗ ದೂರಸ್ಥ ಶಾಖೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಮರೆಯಬೇಡಿ.

git push --force origin master

ನಾವು ಬಳಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ git push --force. ನೀವು ಇದನ್ನು ಆಗಾಗ್ಗೆ ಮಾಡಲು ಬಯಸುತ್ತೀರಿ ಎಂಬುದು ಅಸಂಭವವಾಗಿದೆ, ಆದರೆ ಒಬ್ಬ ರೆಪೊಸಿಟರಿ ಬಳಕೆದಾರರೊಂದಿಗೆ ನಾವು ಇಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸನ್ನಿವೇಶವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಜೊತೆಗೆ, ಅವರು ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.

ಕೆಲಸ ಆರಂಭಿಸುತ್ತಿದೆ

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

️ ಕಾರ್ಯ: ಸ್ಥಳೀಯ ರೆಪೊಸಿಟರಿಯನ್ನು ನವೀಕರಿಸಿ, ಶಾಖೆಯನ್ನು ರಚಿಸಿ master, ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸು

1. ಇದರಿಂದ ಕೋರ್ಸ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನ್ ಮಾಡಿ <URL репозитория>.
2. ಓಡು npm install ಕೋರ್ಸ್ ರೆಪೊಸಿಟರಿ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ; ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ನಾವು ಬಳಸುವ ಜೆಸ್ಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ನಮಗೆ ಇದು ಅಗತ್ಯವಿದೆ.
3. ಶಾಖೆಯನ್ನು ರಚಿಸಿ ಮತ್ತು ಹೆಸರಿಸಿ feature. ಈ ಥ್ರೆಡ್‌ಗೆ ಬದಲಿಸಿ.

4. ಇದಕ್ಕೆ ಪರೀಕ್ಷಾ ಕೋಡ್ ಸೇರಿಸಿ ci.test.js ಇದನ್ನು ಮಾಡಲು ನನ್ನನ್ನು ಕೇಳುವ ಕಾಮೆಂಟ್‌ಗಳ ನಡುವೆ.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. ಫೈಲ್‌ಗೆ ಮೊದಲ 4 ಹಂತಗಳೊಂದಿಗೆ ಪಠ್ಯವನ್ನು ಸೇರಿಸಿ ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   ಕೋಮಂಡ್ಡು

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

ಹೊಸ ಶಾಖೆಯಲ್ಲಿ ಕಮಿಟ್‌ಗಳನ್ನು ರಚಿಸಿ, ಸ್ಥಳೀಯವಾಗಿ ನಿರ್ಮಿಸಿ ಮತ್ತು ಪರೀಕ್ಷಿಸಿ

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

ಪರೀಕ್ಷೆಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಡೆಯುವಾಗ ವಿಶಿಷ್ಟ ಸನ್ನಿವೇಶಗಳು

• ಸ್ಥಳೀಯವಾಗಿ:
  • ಸೂಕ್ತ ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಗೆ ನಿರಂತರವಾಗಿ ಅಥವಾ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ;
  • ಉಳಿಸುವಾಗ (ವಿವರಿಸಿದ ಅಥವಾ JIT-ಸಂಕಲಿಸಿದ ಭಾಷೆಗಳಿಗೆ);
  • ಅಸೆಂಬ್ಲಿ ಸಮಯದಲ್ಲಿ (ಸಂಕಲನ ಅಗತ್ಯವಿದ್ದಾಗ);
  • ಬದ್ಧತೆಯ ಮೇಲೆ;
  • ಹಂಚಿದ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಪ್ರಕಟಿಸುವಾಗ.

• ಬಿಲ್ಡ್ ಸರ್ವರ್ ಅಥವಾ ಬಿಲ್ಡ್ ಪರಿಸರದಲ್ಲಿ:
  • ಕೋಡ್ ಅನ್ನು ವೈಯಕ್ತಿಕ ಶಾಖೆ/ಭಂಡಾರಕ್ಕೆ ಪ್ರಕಟಿಸಿದಾಗ.
  • ಈ ಥ್ರೆಡ್‌ನಲ್ಲಿರುವ ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ.
  • ವಿಲೀನದ ಸಂಭಾವ್ಯ ಫಲಿತಾಂಶವನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ (ಸಾಮಾನ್ಯವಾಗಿ ಇದರೊಂದಿಗೆ master).
  • ನಿರಂತರ ಏಕೀಕರಣ ಹಂತ/ನಿರಂತರ ವಿತರಣಾ ಪೈಪ್‌ಲೈನ್

ವಿಶಿಷ್ಟವಾಗಿ, ಪರೀಕ್ಷಾ ಸೂಟ್ ವೇಗವಾಗಿ ಚಲಿಸುತ್ತದೆ, ಹೆಚ್ಚಾಗಿ ನೀವು ಅದನ್ನು ಚಲಾಯಿಸಲು ಶಕ್ತರಾಗಬಹುದು. ವಿಶಿಷ್ಟ ಹಂತದ ವಿತರಣೆಯು ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು.

• ವೇಗದ ಘಟಕ ಪರೀಕ್ಷೆಗಳು - ನಿರ್ಮಾಣದ ಸಮಯದಲ್ಲಿ, CI ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ
• ನಿಧಾನ ಘಟಕ ಪರೀಕ್ಷೆಗಳು, ವೇಗದ ಘಟಕ ಮತ್ತು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳು - ಕಮಿಟ್‌ನಲ್ಲಿ, CI ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ
• ನಿಧಾನ ಘಟಕ ಮತ್ತು ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳು - CI ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ
• ಭದ್ರತಾ ಪರೀಕ್ಷೆ, ಲೋಡ್ ಪರೀಕ್ಷೆ ಮತ್ತು ಇತರ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಅಥವಾ ದುಬಾರಿ ಪರೀಕ್ಷೆಗಳು - CI/CD ಪೈಪ್‌ಲೈನ್‌ಗಳಲ್ಲಿ, ಆದರೆ ನಿರ್ಮಾಣದ ಕೆಲವು ವಿಧಾನಗಳು/ಹಂತಗಳು/ಪೈಪ್‌ಲೈನ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ, ಉದಾಹರಣೆಗೆ, ಬಿಡುಗಡೆ ಅಭ್ಯರ್ಥಿಯನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ ಅಥವಾ ಹಸ್ತಚಾಲಿತವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ.

️ಕಾರ್ಯ

ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪರೀಕ್ಷೆಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಚಲಾಯಿಸಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ npm test. ಅದರ ನಂತರ, ಕಮಿಟ್‌ನಲ್ಲಿ ನಮ್ಮ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ಜಿಟ್ ಹುಕ್ ಅನ್ನು ಸೇರಿಸೋಣ. ಒಂದು ಕ್ಯಾಚ್ ಇದೆ: Git ಹುಕ್‌ಗಳನ್ನು ರೆಪೊಸಿಟರಿಯ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ಉಳಿದ ಕೋರ್ಸ್ ಸಾಮಗ್ರಿಗಳೊಂದಿಗೆ GitHub ನಿಂದ ಕ್ಲೋನ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಹುಕ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ನೀವು ಓಡಬೇಕು install_hook.sh ಅಥವಾ ಫೈಲ್ ಅನ್ನು ನಕಲಿಸಿ repo/hooks/pre-commit ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಗೆ .git/hooks/.
ನೀವು ಒಪ್ಪಿಸಿದಾಗ, ಪರೀಕ್ಷೆಗಳು ರನ್ ಆಗಿರುವುದನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ ಮತ್ತು ಪಟ್ಟಿಯಲ್ಲಿ ಕೆಲವು ಕೀವರ್ಡ್‌ಗಳು ಇವೆಯೇ ಎಂದು ಅವರು ಪರಿಶೀಲಿಸುತ್ತಾರೆ.

1. ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಚಲಾಯಿಸಿ npm test ನಿಮ್ಮ ಕೋರ್ಸ್ ರೆಪೊಸಿಟರಿ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ. ಪರೀಕ್ಷೆಗಳು ಪೂರ್ಣಗೊಂಡಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
2. ಓಡುವ ಮೂಲಕ ಕಮಿಟ್ ಹುಕ್ (ಪ್ರಿ-ಕಮಿಟ್ ಹುಕ್) ಹೊಂದಿಸಿ install_hook.sh.
3. ನಿಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ನಿಮ್ಮ ಸ್ಥಳೀಯ ರೆಪೊಸಿಟರಿಗೆ ಒಪ್ಪಿಸಿ.
4. ಒಪ್ಪಿಸುವ ಮೊದಲು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಈ ಹಂತಗಳನ್ನು ಅನುಸರಿಸಿದ ನಂತರ ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

ಕೋಮಂಡ್ಡು

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿ ಅಥವಾ ರಿಮೋಟ್ ಶಾಖೆಗೆ ಕೋಡ್ ಅನ್ನು ಪ್ರಕಟಿಸಿ

ಒಮ್ಮೆ ಅವರು ಸ್ಥಳೀಯವಾಗಿ ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ಡೆವಲಪರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತಾರೆ ಇದರಿಂದ ಅದು ಅಂತಿಮವಾಗಿ ಸಾರ್ವಜನಿಕರೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಡುತ್ತದೆ. GitHub ನೊಂದಿಗೆ, ಕೆಲಸವನ್ನು ರೆಪೊಸಿಟರಿಯ ವೈಯಕ್ತಿಕ ಪ್ರತಿ (ವೈಯಕ್ತಿಕ ಫೋರ್ಕ್) ಅಥವಾ ವೈಯಕ್ತಿಕ ಶಾಖೆಗೆ ಪ್ರಕಟಿಸುವ ಮೂಲಕ ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಧಿಸಲಾಗುತ್ತದೆ.

• ಫೋರ್ಕ್‌ಗಳೊಂದಿಗೆ, ಡೆವಲಪರ್ ರಿಮೋಟ್ ಹಂಚಿದ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನ್ ಮಾಡುತ್ತಾರೆ, ಅದರ ವೈಯಕ್ತಿಕ ರಿಮೋಟ್ ನಕಲನ್ನು ರಚಿಸುತ್ತಾರೆ, ಇದನ್ನು ಫೋರ್ಕ್ ಎಂದೂ ಕರೆಯುತ್ತಾರೆ. ಇದು ಸ್ಥಳೀಯವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಈ ವೈಯಕ್ತಿಕ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನ್ ಮಾಡುತ್ತದೆ. ಕೆಲಸವು ಪೂರ್ಣಗೊಂಡಾಗ ಮತ್ತು ಬದ್ಧತೆಗಳನ್ನು ಮಾಡಿದಾಗ, ಅವನು ಅವುಗಳನ್ನು ತನ್ನ ಫೋರ್ಕ್‌ಗೆ ತಳ್ಳುತ್ತಾನೆ, ಅಲ್ಲಿ ಅವು ಇತರರಿಗೆ ಲಭ್ಯವಿರುತ್ತವೆ ಮತ್ತು ಸಾಮಾನ್ಯ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಯೋಜಿಸಬಹುದು. ಈ ವಿಧಾನವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ GitHub ನಲ್ಲಿ ತೆರೆದ ಮೂಲ ಯೋಜನೆಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಇದನ್ನು ನನ್ನ ಮುಂದುವರಿದ ಕೋರ್ಸ್‌ನಲ್ಲಿಯೂ ಬಳಸಲಾಗುತ್ತದೆ [ಟೀಮ್ ವರ್ಕ್ ಮತ್ತು CI ಜೊತೆಗೆ Git] (http://devops.redpill.solutions/).
• ಇನ್ನೊಂದು ವಿಧಾನವೆಂದರೆ ಒಂದು ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಮಾತ್ರ ಬಳಸುವುದು ಮತ್ತು ಶಾಖೆಯನ್ನು ಮಾತ್ರ ಎಣಿಸುವುದು master ಹಂಚಿದ ರೆಪೊಸಿಟರಿ "ರಕ್ಷಿತ". ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ, ವೈಯಕ್ತಿಕ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯ ಶಾಖೆಗಳಿಗೆ ಪ್ರಕಟಿಸುತ್ತಾರೆ ಇದರಿಂದ ಇತರರು ಈ ಕೋಡ್ ಅನ್ನು ನೋಡಬಹುದು, ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದ್ದರೆ, ಅದನ್ನು ವಿಲೀನಗೊಳಿಸಿ master ಹಂಚಿಕೆಯ ಭಂಡಾರ.

ಈ ನಿರ್ದಿಷ್ಟ ಕೋರ್ಸ್‌ನಲ್ಲಿ, ನಾವು ಶಾಖೆಗಳನ್ನು ಬಳಸುವ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ನಮ್ಮ ಕೋಡ್ ಅನ್ನು ಪ್ರಕಟಿಸೋಣ.

️ಕಾರ್ಯ

• ನಿಮ್ಮ ಕೆಲಸ ಮಾಡುವ ಶಾಖೆಯ ಹೆಸರಿನೊಂದಿಗೆ ರಿಮೋಟ್ ಶಾಖೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರಕಟಿಸಿ

ಕೋಮಂಡ್ಡು

git push --set-upstream origin feature

ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ

ಶೀರ್ಷಿಕೆಯೊಂದಿಗೆ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ ಹಂತಗಳ ವಿಮರ್ಶೆ. ಸ್ಥಾಪಿಸಿ feature "ಹೆಡ್ ಶಾಖೆ" ಮತ್ತು ಹಾಗೆ master "ಮೂಲ ಶಾಖೆ" ಯಂತೆ.

ನೀವು ಸ್ಥಾಪಿಸಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ master ಅವರಲ್ಲಿ ರೆಪೊಸಿಟರಿಯನ್ನು ಫೋರ್ಕ್ ಮಾಡಿ "ಬೇಸ್ ಬ್ರಾಂಚ್" ಆಗಿ, ಕೋರ್ಸ್ ಮೆಟೀರಿಯಲ್ ರೆಪೊಸಿಟರಿಯ ಬದಲಾವಣೆಗಳ ವಿನಂತಿಗಳಿಗೆ ನಾನು ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ.

GitHub ಲಿಂಗೋದಲ್ಲಿ, "ಮೂಲ ಶಾಖೆ" ಎಂಬುದು ನಿಮ್ಮ ಕೆಲಸವನ್ನು ನೀವು ಆಧರಿಸಿರುವ ಶಾಖೆಯಾಗಿದೆ ಮತ್ತು "ಹೆಡ್ ಶಾಖೆ" ಎಂಬುದು ಪ್ರಸ್ತಾವಿತ ಬದಲಾವಣೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಶಾಖೆಯಾಗಿದೆ.

ಬದಲಾವಣೆಗಳನ್ನು ಚರ್ಚಿಸಿ, ಚರ್ಚೆ ಮುಂದುವರಿದಂತೆ ಹೊಸ ಕಮಿಟ್‌ಗಳನ್ನು ಸೇರಿಸಿ

ವಿನಂತಿಯನ್ನು ಎಳೆಯಿರಿ(PR)

ವಿನಂತಿಯನ್ನು ಎಳೆಯಿರಿ(PR) ಕೋಡ್ ಅನ್ನು ಚರ್ಚಿಸಲು ಮತ್ತು ಡಾಕ್ಯುಮೆಂಟ್ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ, ಜೊತೆಗೆ ಕೋಡ್ ವಿಮರ್ಶೆಯನ್ನು ನಡೆಸುತ್ತದೆ. ಪುಲ್ ವಿನಂತಿಗಳನ್ನು ಒಟ್ಟಾರೆ ಕೋಡ್‌ಗೆ ವೈಯಕ್ತಿಕ ಬದಲಾವಣೆಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಸಾಮಾನ್ಯ ರೀತಿಯಲ್ಲಿ ಹೆಸರಿಸಲಾಗಿದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಪ್ರಾಜೆಕ್ಟ್‌ನ ರಿಮೋಟ್ ಅಧಿಕೃತ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನ್ ಮಾಡುತ್ತಾನೆ ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ಕೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾನೆ. ಇದರ ನಂತರ, ಅವನು ತನ್ನ ವೈಯಕ್ತಿಕ ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಇರಿಸುತ್ತಾನೆ ಮತ್ತು ಅಧಿಕೃತ ರೆಪೊಸಿಟರಿಯ ಜವಾಬ್ದಾರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಕೇಳುತ್ತಾನೆ(ಎಳೆಯಿರಿ) ಅದರ ಕೋಡ್ ಅವರ ಸ್ಥಳೀಯ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ, ಅಲ್ಲಿ ಅವರು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ಬಹುಶಃ ಸಂಯೋಜಿಸುತ್ತಾರೆ(ಹೋಗಿ) ಅವನ. ಈ ಪರಿಕಲ್ಪನೆಯನ್ನು ಇತರ ಹೆಸರುಗಳಿಂದ ಕರೆಯಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ವಿಲೀನ ವಿನಂತಿ.

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

• ನಿರ್ದಿಷ್ಟ ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಸಂಘಟಿತ ಚರ್ಚೆಗಳು;
• ಆಟೋಟೆಸ್ಟರ್‌ಗಳು ಮತ್ತು ಗೆಳೆಯರಿಂದ ಪ್ರಗತಿಯಲ್ಲಿರುವ ಕೆಲಸದ ಕುರಿತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ವೀಕ್ಷಿಸಲು ಒಂದು ಸ್ಥಳವಾಗಿ;
• ಕೋಡ್ ವಿಮರ್ಶೆಗಳ ಔಪಚಾರಿಕೀಕರಣ;
• ನಂತರ ನೀವು ಈ ಅಥವಾ ಆ ಕೋಡ್‌ನ ಹಿಂದಿನ ಕಾರಣಗಳು ಮತ್ತು ಪರಿಗಣನೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು.

ನೀವು ಏನನ್ನಾದರೂ ಚರ್ಚಿಸಲು ಅಥವಾ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಬೇಕಾದಾಗ ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತೀರಿ. ಉದಾಹರಣೆಗೆ, ನೀವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ವೈಶಿಷ್ಟ್ಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಆಲೋಚನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಮತ್ತು ನಿಮ್ಮ ಸಹಯೋಗಿಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಯೋಜನೆಗಳನ್ನು ಚರ್ಚಿಸಲು ಕೋಡ್‌ನ ಮೊದಲ ಸಾಲಿನ ಬರೆಯುವ ಮೊದಲು ನೀವು ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಬಹುದು. ಕೆಲಸವು ಸರಳವಾಗಿದ್ದರೆ, ಏನನ್ನಾದರೂ ಈಗಾಗಲೇ ಪೂರ್ಣಗೊಳಿಸಿದಾಗ ಪುಲ್ ವಿನಂತಿಯನ್ನು ತೆರೆಯಲಾಗುತ್ತದೆ, ಬದ್ಧತೆ ಮತ್ತು ಚರ್ಚಿಸಬಹುದು. ಕೆಲವು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ನೀವು ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣ ಕಾರಣಗಳಿಗಾಗಿ ಮಾತ್ರ PR ಅನ್ನು ತೆರೆಯಲು ಬಯಸಬಹುದು: ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ಅಥವಾ ಕೋಡ್ ವಿಮರ್ಶೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು. ನೀವು ಯಾವುದೇ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಂಡರೂ, ನಿಮ್ಮ ಪುಲ್ ವಿನಂತಿಯಲ್ಲಿ ನೀವು ಯಾರ ಅನುಮೋದನೆಯನ್ನು ಬಯಸುತ್ತೀರೋ ಅವರನ್ನು @ಪ್ರಸ್ತಾಪಿಸಲು ಮರೆಯಬೇಡಿ.

ವಿಶಿಷ್ಟವಾಗಿ, PR ಅನ್ನು ರಚಿಸುವಾಗ, ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡುತ್ತೀರಿ.

• ನೀವು ಏನನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಸ್ತಾಪಿಸುತ್ತೀರಿ ಮತ್ತು ಎಲ್ಲಿ ಎಂದು ಸೂಚಿಸಿ.
• ಬದಲಾವಣೆಗಳ ಉದ್ದೇಶವನ್ನು ವಿವರಿಸುವ ವಿವರಣೆಯನ್ನು ಬರೆಯಿರಿ. ನೀವು ಬಯಸಬಹುದು:
  • ಕೋಡ್‌ನಿಂದ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲದ ಯಾವುದನ್ನಾದರೂ ಸೇರಿಸಿ, ಅಥವಾ ಸಂದರ್ಭವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಉಪಯುಕ್ತವಾದ #ಬಗ್‌ಗಳು ಮತ್ತು ಕಮಿಟ್ ಸಂಖ್ಯೆಗಳಂತಹ ಯಾವುದನ್ನಾದರೂ ಸೇರಿಸಿ;
  • ನೀವು ಯಾರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಯಸುತ್ತೀರೋ ಅವರನ್ನು @ಪ್ರಸ್ತಾಪಿಸಿ ಅಥವಾ ನೀವು ನಂತರ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಅವರನ್ನು @ಪ್ರಸ್ತಾಪಿಸಬಹುದು;
  • ಏನಾದರೂ ಸಹಾಯ ಮಾಡಲು ಅಥವಾ ನಿರ್ದಿಷ್ಟವಾದದ್ದನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಹೋದ್ಯೋಗಿಗಳನ್ನು ಕೇಳಿ.

ಒಮ್ಮೆ ನೀವು PR ಅನ್ನು ತೆರೆದ ನಂತರ, ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ರನ್ ಮಾಡಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಪರೀಕ್ಷೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ನಾವು ಸ್ಥಳೀಯವಾಗಿ ನಡೆಸಿದ ಪರೀಕ್ಷೆಗಳ ಒಂದೇ ಸೆಟ್ ಆಗಿರುತ್ತದೆ, ಆದರೆ ನಿಜವಾದ ಯೋಜನೆಯಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ತಪಾಸಣೆಗಳು ಇರಬಹುದು.

ಪರೀಕ್ಷೆಗಳು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ದಯವಿಟ್ಟು ನಿರೀಕ್ಷಿಸಿ. GitHub ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ PR ಚರ್ಚೆಯ ಕೆಳಭಾಗದಲ್ಲಿ ನೀವು ಪರೀಕ್ಷೆಗಳ ಸ್ಥಿತಿಯನ್ನು ನೋಡಬಹುದು. ಪರೀಕ್ಷೆಗಳು ಪೂರ್ಣಗೊಂಡಾಗ ಮುಂದುವರಿಸಿ.

️ CI ಹಂತಗಳ ಪಟ್ಟಿಯ ಯಾದೃಚ್ಛಿಕತೆಯ ಬಗ್ಗೆ ಟಿಪ್ಪಣಿ ಸೇರಿಸಿ

ಈ ಕೋರ್ಸ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಪಟ್ಟಿಯು ಅನಿಯಂತ್ರಿತ ಮತ್ತು ವ್ಯಕ್ತಿನಿಷ್ಠವಾಗಿದೆ, ನಾವು ಇದರ ಬಗ್ಗೆ ಟಿಪ್ಪಣಿಯನ್ನು ಸೇರಿಸಬೇಕು.

️ ಕಾರ್ಯ: ಈ ಕಾಮೆಂಟ್‌ಗಾಗಿ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ

1. ಶಾಖೆಗೆ ಬದಲಿಸಿ master.
2. ಹೆಸರಿನ ಶಾಖೆಯನ್ನು ರಚಿಸಿ bugfix.
3. ಫೈಲ್‌ನ ಅಂತ್ಯಕ್ಕೆ ಟಿಪ್ಪಣಿ ಪಠ್ಯವನ್ನು ಸೇರಿಸಿ ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. ಬದಲಾವಣೆಗಳನ್ನು ಒಪ್ಪಿಸಿ.
5. ಥ್ರೆಡ್ ಅನ್ನು ಪ್ರಕಟಿಸಿ bugfix ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಗೆ.
6. ಹೆಸರಿನ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ ಟೀಕೆ ಸೇರಿಸಲಾಗುತ್ತಿದೆ ತಲೆ ಶಾಖೆಯೊಂದಿಗೆ bugfix ಮತ್ತು ಮೂಲ ಶಾಖೆmaster.

ನೀವು ಸ್ಥಾಪಿಸಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ master ಅವರಲ್ಲಿ ರೆಪೊಸಿಟರಿಯನ್ನು ಫೋರ್ಕ್ ಮಾಡಿ "ಬೇಸ್ ಬ್ರಾಂಚ್" ಆಗಿ, ಕೋರ್ಸ್ ಮೆಟೀರಿಯಲ್ ರೆಪೊಸಿಟರಿಯ ಬದಲಾವಣೆಗಳ ವಿನಂತಿಗಳಿಗೆ ನಾನು ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ.

ಇದು ನಿಮ್ಮ ರೆಪೊಸಿಟರಿ ಹೇಗಿರಬೇಕು.

ಕೋಮಂಡ್ಡು

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

ಪುಲ್ ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸಿ "ಒಂದು ಟೀಕೆ ಸೇರಿಸಲಾಗುತ್ತಿದೆ"

️ಕಾರ್ಯ

1. ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ.
2. "ಪುಲ್ ವಿನಂತಿಯನ್ನು ವಿಲೀನಗೊಳಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.
3. "ವಿಲೀನವನ್ನು ದೃಢೀಕರಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.
4. "ಶಾಖೆಯನ್ನು ಅಳಿಸು" ಕ್ಲಿಕ್ ಮಾಡಿ, ನಮಗೆ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲ.

ಇದು ವಿಲೀನದ ನಂತರ ಬದ್ಧತೆಗಳ ರೇಖಾಚಿತ್ರವಾಗಿದೆ.

️ ಕೆಲಸ ಮಾಡುತ್ತಿರಿ ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ಸೇರಿಸಿ

ಪುಲ್ ವಿನಂತಿಯ ಮೇಲೆ ಸಹಯೋಗ ಮಾಡುವುದರಿಂದ ಹೆಚ್ಚುವರಿ ಕೆಲಸಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕೋಡ್ ವಿಮರ್ಶೆ ಅಥವಾ ಚರ್ಚೆಯ ಫಲಿತಾಂಶವಾಗಿದೆ, ಆದರೆ ನಮ್ಮ ಕೋರ್ಸ್‌ನಲ್ಲಿ ನಾವು ನಮ್ಮ CI ಹಂತಗಳ ಪಟ್ಟಿಗೆ ಹೊಸ ಐಟಂಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡಲಿದ್ದೇವೆ.

ನಿರಂತರ ಏಕೀಕರಣವು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ಪರೀಕ್ಷಾ ವ್ಯಾಪ್ತಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಪರೀಕ್ಷಾ ವ್ಯಾಪ್ತಿಯ ಅಗತ್ಯತೆಗಳು ಬದಲಾಗುತ್ತವೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ "ಕೊಡುಗೆ ಮಾರ್ಗಸೂಚಿಗಳು" ಎಂದು ಕರೆಯಲ್ಪಡುವ ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಕಂಡುಬರುತ್ತವೆ. ನಾವು ಅದನ್ನು ಸರಳವಾಗಿ ಇರಿಸುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ಪರಿಶೀಲನಾಪಟ್ಟಿಯಲ್ಲಿ ಪ್ರತಿ ಸಾಲಿಗೆ ಪರೀಕ್ಷೆಯನ್ನು ಸೇರಿಸುತ್ತೇವೆ.

ಕಾರ್ಯಯೋಜನೆಗಳನ್ನು ಚಲಾಯಿಸುವಾಗ, ಮೊದಲು ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ. ನೀವು ಸರಿಯಾಗಿ ಸ್ಥಾಪಿಸಿದರೆ pre-commit ಮೊದಲೇ ಹುಕ್ ಮಾಡಿ, ಹೊಸದಾಗಿ ಸೇರಿಸಲಾದ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಲಾಗುವುದು, ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಯಾವುದನ್ನೂ ಬದ್ಧಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ. ನಮ್ಮ ಪರೀಕ್ಷೆಗಳು ನಿಜವಾಗಿಯೂ ಏನನ್ನಾದರೂ ಪರೀಕ್ಷಿಸುತ್ತಿವೆ ಎಂದು ನಮಗೆ ತಿಳಿಯುವುದು ಹೀಗೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಕುತೂಹಲಕಾರಿಯಾಗಿ, ನಾವು ಪರೀಕ್ಷೆಗಳಿಗೆ ಮೊದಲು ಕೋಡ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದರೆ, ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗುವುದು ಕೋಡ್ ನಿರೀಕ್ಷೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಅಥವಾ ಪರೀಕ್ಷೆಗಳು ನಿಜವಾಗಿ ಏನನ್ನೂ ಪರೀಕ್ಷಿಸುತ್ತಿಲ್ಲ ಎಂದು ಅರ್ಥೈಸಬಹುದು. ಜೊತೆಗೆ, ನಾವು ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯದಿದ್ದರೆ, ನಾವು ಅವುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರೆತುಬಿಡಬಹುದು, ಏಕೆಂದರೆ ಅದು ನಮಗೆ ಯಾವುದನ್ನೂ ನೆನಪಿಸುತ್ತಿರಲಿಲ್ಲ.

ಪರೀಕ್ಷಾ ಚಾಲಿತ ಅಭಿವೃದ್ಧಿ (TDD)

ಕೋಡ್ ಮೊದಲು ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು TDD ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ. TDD ಅನ್ನು ಬಳಸುವ ವಿಶಿಷ್ಟವಾದ ಕೆಲಸದ ಹರಿವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

1. ಪರೀಕ್ಷೆಯನ್ನು ಸೇರಿಸಿ.
2. ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಹೊಸ ಪರೀಕ್ಷೆಯು ವಿಫಲವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
3. ಕೋಡ್ ಬರೆಯಿರಿ.
4. ಪರೀಕ್ಷೆಗಳನ್ನು ರನ್ ಮಾಡಿ, ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು ಉತ್ತೀರ್ಣರಾಗಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
5. ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಿ.
6. ಪುನರಾವರ್ತಿಸಿ.

ಏಕೆಂದರೆ ವಿಫಲವಾದ ಪರೀಕ್ಷೆಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಂಪು ಬಣ್ಣದಲ್ಲಿ ತೋರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಉತ್ತೀರ್ಣರಾದವುಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹಸಿರು ಬಣ್ಣದಲ್ಲಿ ತೋರಿಸಲಾಗುತ್ತದೆ, ಚಕ್ರವನ್ನು ಕೆಂಪು-ಹಸಿರು-ರಿಫಕ್ಟರ್ ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ.

️ಕಾರ್ಯ

ಮೊದಲಿಗೆ, ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ವಿಫಲಗೊಳಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಡಿ, ನಂತರ CI ಹಂತದ ಪಟ್ಟಿಯ ಪಠ್ಯವನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಒಪ್ಪಿಸಿ. ಪರೀಕ್ಷೆಗಳು ಹಾದುಹೋಗುತ್ತಿರುವುದನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ ("ಹಸಿರು").
ನಂತರ ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಹೊಸ ಕೋಡ್ ಅನ್ನು ಪ್ರಕಟಿಸಿ ಮತ್ತು ಪುಲ್ ವಿನಂತಿಯ ಚರ್ಚೆ ಮತ್ತು PR ಸ್ಥಿತಿ ನವೀಕರಣದ ಕೆಳಭಾಗದಲ್ಲಿರುವ GitHub ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ನಡೆಯುವ ಪರೀಕ್ಷೆಗಳನ್ನು ವೀಕ್ಷಿಸಿ.

1. ಶಾಖೆಗೆ ಬದಲಿಸಿ feature.

2. ಇದಕ್ಕೆ ಈ ಪರೀಕ್ಷೆಗಳನ್ನು ಸೇರಿಸಿ ci.test.js ಕೊನೆಯ ಕರೆ ನಂತರ it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. ಪರೀಕ್ಷೆಗಳನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ. ಒಂದು ವೇಳೆ pre-commit ಹುಕ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಬದ್ಧತೆಯ ಪ್ರಯತ್ನವು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ.
4. ನಂತರ ಈ ಪಠ್ಯವನ್ನು ಸೇರಿಸಿ ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. ಸ್ಥಳೀಯವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿ ಮತ್ತು ಬದ್ಧರಾಗಿರಿ.
6. ಶಾಖೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿ feature.

ನೀವು ಈಗ ಅಂತಹದನ್ನು ಹೊಂದಿರಬೇಕು

ಕೋಮಂಡ್ಡು

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

ಸಂಘರ್ಷವನ್ನು ವಿಲೀನಗೊಳಿಸಿ

ಬದಲಾವಣೆ ವಿನಂತಿಗೆ ಹೋಗಿ ಹಂತಗಳ ವಿಮರ್ಶೆ.

ನಾವು ಯಾವುದೇ ತಪ್ಪು ಮಾಡದಿದ್ದರೂ ಮತ್ತು ನಮ್ಮ ಕೋಡ್‌ಗಾಗಿ ಪರೀಕ್ಷೆಗಳು ಉತ್ತೀರ್ಣರಾಗಿದ್ದರೂ, ನಾವು ಇನ್ನೂ ಶಾಖೆಯನ್ನು ವಿಲೀನಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ feature и master. ಇದು ಇತರ ಥ್ರೆಡ್ ಕಾರಣ bugfix ಜೊತೆ ವಿಲೀನಗೊಂಡಿತು master ನಾವು ಈ PR ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ.
ಇದು ರಿಮೋಟ್ ಶಾಖೆಯ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ master ನಾವು ಶಾಖೆಯನ್ನು ಆಧರಿಸಿದ್ದಕ್ಕಿಂತ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿದೆ feature. ಇದರಿಂದಾಗಿ ನಾವು ಕೇವಲ HEAD ಅನ್ನು ರಿವೈಂಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ master ಥ್ರೆಡ್ನ ಅಂತ್ಯದವರೆಗೆ feature. ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ನಾವು ಕಮಿಟ್‌ಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಬೇಕು ಅಥವಾ ಅನ್ವಯಿಸಬೇಕು feature ಮರುಬೇಸ್ master. ಯಾವುದೇ ಘರ್ಷಣೆಗಳಿಲ್ಲದಿದ್ದರೆ GitHub ವಾಸ್ತವವಾಗಿ ಸ್ವಯಂಚಾಲಿತ ವಿಲೀನಗಳನ್ನು ಮಾಡಬಹುದು. ಅಯ್ಯೋ, ನಮ್ಮ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಎರಡೂ ಶಾಖೆಗಳು ಫೈಲ್‌ನಲ್ಲಿ ಸ್ಪರ್ಧಾತ್ಮಕ ಬದಲಾವಣೆಗಳನ್ನು ಹೊಂದಿವೆ ci.md. ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿಲೀನ ಸಂಘರ್ಷ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರಿಹರಿಸಬೇಕಾಗಿದೆ.

ವಿಲೀನಗೊಳಿಸಿ ಅಥವಾ ಮರುಬೇಸ್ ಮಾಡಿ

ವಿಲೀನಗೊಳ್ಳಲು

• ಹೆಚ್ಚುವರಿ ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲಸದ ಇತಿಹಾಸವನ್ನು ಉಳಿಸುತ್ತದೆ.
  • ಶಾಖೆಗಳ ಮೂಲ ಕಮಿಟ್‌ಗಳನ್ನು ಅವುಗಳ ಮೂಲ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳು ಮತ್ತು ಲೇಖಕರೊಂದಿಗೆ ಸಂರಕ್ಷಿಸುತ್ತದೆ.
  • ಬದಲಾವಣೆಯ ವಿನಂತಿಯ ಚರ್ಚೆಗಳಲ್ಲಿ ಕಮಿಟ್‌ಗಳ SHA ಮತ್ತು ಲಿಂಕ್‌ಗಳನ್ನು ಉಳಿಸುತ್ತದೆ.
• ಒಂದು ಬಾರಿ ಸಂಘರ್ಷ ಪರಿಹಾರದ ಅಗತ್ಯವಿದೆ.
• ಕಥೆಯನ್ನು ರೇಖಾತ್ಮಕವಲ್ಲದಂತೆ ಮಾಡುತ್ತದೆ.
  • ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಶಾಖೆಗಳಿಂದಾಗಿ ಕಥೆಯನ್ನು ಓದಲು ಕಷ್ಟವಾಗಬಹುದು (ಐಡಿಇ ಕೇಬಲ್ ಅನ್ನು ನೆನಪಿಸುತ್ತದೆ).
  • ಸ್ವಯಂಚಾಲಿತ ಡೀಬಗ್ ಮಾಡುವುದನ್ನು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ, ಉದಾ. git bisect ಕಡಿಮೆ ಉಪಯುಕ್ತ - ಇದು ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ಮಾತ್ರ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ.

ರಿಬೇಸ್

• ಮೂಲ ಶಾಖೆಯ ಮೇಲಿರುವ ಪ್ರಸ್ತುತ ಶಾಖೆಯಿಂದ ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಮರುಪಂದ್ಯಗಳು ಬದ್ಧವಾಗಿರುತ್ತವೆ.
  • ಹೊಸ SHAಗಳೊಂದಿಗೆ ಹೊಸ ಕಮಿಟ್‌ಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ, GitHub ನಲ್ಲಿನ ಕಮಿಟ್‌ಗಳು ಮೂಲ ಪುಲ್ ವಿನಂತಿಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅನುಗುಣವಾದ ಕಾಮೆಂಟ್‌ಗಳಿಗೆ ಅಲ್ಲ.
  • ಕಮಿಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಮರುಸಂಯೋಜಿಸಬಹುದು ಮತ್ತು ಮಾರ್ಪಡಿಸಬಹುದು ಅಥವಾ ಒಂದರಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಬಹುದು.
• ಬಹು ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಬಹುದು.
• ರೇಖಾತ್ಮಕ ಕಥೆಯನ್ನು ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
  • ಯಾವುದೇ ಸಮಂಜಸವಾದ ಕಾರಣವಿಲ್ಲದೆ ಹೆಚ್ಚು ಉದ್ದವಾಗದಿದ್ದಲ್ಲಿ ಕಥೆಯನ್ನು ಓದಲು ಸುಲಭವಾಗಬಹುದು.
  • ಸ್ವಯಂಚಾಲಿತ ಡೀಬಗ್ ಮಾಡುವಿಕೆ ಮತ್ತು ದೋಷನಿವಾರಣೆ ಸ್ವಲ್ಪ ಸುಲಭ: ಇದು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ git bisect, ಸ್ವಯಂಚಾಲಿತ ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮತ್ತು ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದಂತೆ ಮಾಡಬಹುದು.
• ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ವಲಸೆ ಬಂದ ಕಮಿಟ್‌ಗಳೊಂದಿಗೆ ಶಾಖೆಯನ್ನು ಪ್ರಕಟಿಸುವ ಅಗತ್ಯವಿದೆ --force ಪುಲ್ ವಿನಂತಿಗಳೊಂದಿಗೆ ಬಳಸಿದಾಗ.

ವಿಶಿಷ್ಟವಾಗಿ, ತಂಡಗಳು ಬದಲಾವಣೆಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಬೇಕಾದಾಗ ಯಾವಾಗಲೂ ಅದೇ ತಂತ್ರವನ್ನು ಬಳಸಲು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತವೆ. ಇದು "ಶುದ್ಧ" ವಿಲೀನವಾಗಿರಬಹುದು ಅಥವಾ ಮೇಲಿನ "ಶುದ್ಧ" ಬದ್ಧತೆಯಾಗಿರಬಹುದು ಅಥವಾ ನಡುವೆ ಏನಾದರೂ ಸಂವಾದಾತ್ಮಕವಾಗಿ ಬದ್ಧತೆಯನ್ನು ಮಾಡುವುದು (git rebase -i) ಸಾರ್ವಜನಿಕ ಭಂಡಾರಕ್ಕೆ ಪ್ರಕಟಿಸದ ಶಾಖೆಗಳಿಗೆ ಸ್ಥಳೀಯವಾಗಿ, ಆದರೆ "ಸಾರ್ವಜನಿಕ" ಶಾಖೆಗಳಿಗೆ ವಿಲೀನಗೊಳಿಸಿ.

ಇಲ್ಲಿ ನಾವು ವಿಲೀನವನ್ನು ಬಳಸುತ್ತೇವೆ.

️ಕಾರ್ಯ

1. ಕೋಡ್ ಸ್ಥಳೀಯ ಶಾಖೆಯಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ master ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯಿಂದ ನವೀಕರಿಸಲಾಗಿದೆ.
2. ಶಾಖೆಗೆ ಬದಲಿಸಿ feature.
3. ಶಾಖೆಯೊಂದಿಗೆ ವಿಲೀನವನ್ನು ಪ್ರಾರಂಭಿಸಿ master. ಗೆ ಸ್ಪರ್ಧಾತ್ಮಕ ಬದಲಾವಣೆಗಳಿಂದಾಗಿ ವಿಲೀನ ಸಂಘರ್ಷ ci.md.
4. ನಮ್ಮ CI ಹಂತಗಳ ಪಟ್ಟಿ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಟಿಪ್ಪಣಿ ಎರಡೂ ಪಠ್ಯದಲ್ಲಿ ಉಳಿಯುವಂತೆ ಸಂಘರ್ಷವನ್ನು ಪರಿಹರಿಸಿ.
5. ರಿಮೋಟ್ ಶಾಖೆಗೆ ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ಪ್ರಕಟಿಸಿ feature.
6. GitHub UI ನಲ್ಲಿ ಪುಲ್ ವಿನಂತಿಯ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ವಿಲೀನವನ್ನು ಪರಿಹರಿಸುವವರೆಗೆ ಕಾಯಿರಿ.

ಕೋಮಂಡ್ಡು

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

ಒಳ್ಳೆಯ ಕೆಲಸ!

ನೀವು ಪಟ್ಟಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ್ದೀರಿ ಮತ್ತು ಈಗ ನೀವು ಪುಲ್ ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸಬೇಕಾಗಿದೆ master.

️ ಕಾರ್ಯ: ಪುಲ್ ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸಿ "ಹಂತಗಳ ಪರಿಶೀಲನೆ"

1. ಪುಲ್ ವಿನಂತಿಯನ್ನು ತೆರೆಯಿರಿ.
2. "ಪುಲ್ ವಿನಂತಿಯನ್ನು ವಿಲೀನಗೊಳಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.
3. "ವಿಲೀನವನ್ನು ದೃಢೀಕರಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.
4. ನಮಗೆ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ "ಶಾಖೆಯನ್ನು ಅಳಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.

ಈ ಸಮಯದಲ್ಲಿ ಇದು ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯಾಗಿದೆ

ಉತ್ಪನ್ನ ದೋಷ

"ದೋಷಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ತೋರಿಸಲು ಪರೀಕ್ಷೆಯನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಅವುಗಳ ಅನುಪಸ್ಥಿತಿಯನ್ನು ಎಂದಿಗೂ ತೋರಿಸಬಾರದು" ಎಂದು ಹೇಳಲಾಗುತ್ತದೆ. ನಾವು ಪರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿದ್ದರೂ ಮತ್ತು ಅವರು ನಮಗೆ ಯಾವುದೇ ದೋಷಗಳನ್ನು ತೋರಿಸದಿದ್ದರೂ ಸಹ, ಒಂದು ಕಪಟ ದೋಷವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ನುಸುಳಿತು.

ಅಂತಹ ಸನ್ನಿವೇಶದಲ್ಲಿ, ನಾವು ಕಾಳಜಿ ವಹಿಸಬೇಕು:

• ಉತ್ಪಾದನೆಯಲ್ಲಿ ಏನು ನಿಯೋಜಿಸಲಾಗಿದೆ;
• ಥ್ರೆಡ್ನಲ್ಲಿ ಕೋಡ್ master ದೋಷದೊಂದಿಗೆ, ಅಭಿವರ್ಧಕರು ಹೊಸ ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು.

ನಾನು ಹಿಂತಿರುಗಿಸಬೇಕೇ ಅಥವಾ ಮುಂದಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ಅದನ್ನು ಸರಿಪಡಿಸಬೇಕೇ?

ರೋಲಿಂಗ್ ಬ್ಯಾಕ್ ಎನ್ನುವುದು ಉತ್ಪಾದನೆಗೆ ತಿಳಿದಿರುವ ಉತ್ತಮ ಮುಂಚಿನ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ ಮತ್ತು ದೋಷವನ್ನು ಹೊಂದಿರುವ ಕಮಿಟ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. "ಫಿಕ್ಸಿಂಗ್ ಫಾರ್ವರ್ಡ್" ಎಂಬುದು ಫಿಕ್ಸ್‌ನ ಸೇರ್ಪಡೆಯಾಗಿದೆ master ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸಲಾಗುತ್ತಿದೆ. API ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾಗಳು ನಿರಂತರ ವಿತರಣೆ ಮತ್ತು ಉತ್ತಮ ಪರೀಕ್ಷಾ ಕವರೇಜ್‌ನೊಂದಿಗೆ ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಲಾದ ಕೋಡ್‌ನಂತೆ ಬದಲಾಗುವುದರಿಂದ, ರೋಲಿಂಗ್ ಬ್ಯಾಕ್ ಸಾಮಾನ್ಯವಾಗಿ ಮುಂದಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರ ಮತ್ತು ಅಪಾಯಕಾರಿಯಾಗಿದೆ.

ರೋಲಿಂಗ್ ಬ್ಯಾಕ್ ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವುದೇ ಅಪಾಯವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲವಾದ್ದರಿಂದ, ನಾವು ಈ ಮಾರ್ಗದಲ್ಲಿ ಹೋಗುತ್ತೇವೆ, ಏಕೆಂದರೆ ಅದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ

• ಉತ್ಪನ್ನದಲ್ಲಿನ ದೋಷವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸರಿಪಡಿಸಿ;
• ಕೋಡ್ ಮಾಡಿ master ಹೊಸ ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸಲು ತಕ್ಷಣವೇ ಸೂಕ್ತವಾಗಿದೆ.

️ಕಾರ್ಯ

1. ಶಾಖೆಗೆ ಬದಲಿಸಿ master ಸ್ಥಳೀಯವಾಗಿ
2. ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯಿಂದ ಸ್ಥಳೀಯ ರೆಪೊಸಿಟರಿಯನ್ನು ನವೀಕರಿಸಿ.
3. PR ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ಹಿಂತಿರುಗಿಸಿ ಹಂತಗಳ ವಿಮರ್ಶೆ в master.
4. ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರಕಟಿಸಿ.

ಇದು ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ಹಿಂತಿರುಗಿಸಿದ ರೆಪೊಸಿಟರಿಯ ಇತಿಹಾಸವಾಗಿದೆ

ಕೋಮಂಡ್ಡು

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ ಸ್ವಯಂ ಪರೀಕ್ಷೆ

ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ci.md ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ಹಿಂತಿರುಗಿಸಿದ ನಂತರ "ಸ್ನೀಕಿ ಬಗ್" ಪಠ್ಯವನ್ನು ಇನ್ನು ಮುಂದೆ ಹೊಂದಿರುವುದಿಲ್ಲ.

CI ಹಂತಗಳ ಪಟ್ಟಿಯನ್ನು ಸರಿಪಡಿಸಿ ಮತ್ತು ಅದನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ಹಿಂತಿರುಗಿ

ನಾವು ಶಾಖೆಯ ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹಿಂತಿರುಗಿಸಿದ್ದೇವೆ. feature. ಒಳ್ಳೆಯ ಸುದ್ದಿ ಏನೆಂದರೆ ನಮ್ಮಲ್ಲಿ ಈಗ ಯಾವುದೇ ದೋಷವಿಲ್ಲ master. ಕೆಟ್ಟ ಸುದ್ದಿ ಏನೆಂದರೆ, ನಿರಂತರ ಏಕೀಕರಣ ಹಂತಗಳ ನಮ್ಮ ಅಮೂಲ್ಯ ಪಟ್ಟಿಯೂ ಹೋಗಿದೆ. ಆದ್ದರಿಂದ, ಆದರ್ಶಪ್ರಾಯವಾಗಿ, ನಾವು ಬದ್ಧತೆಗಳಿಗೆ ಫಿಕ್ಸ್ ಅನ್ನು ಅನ್ವಯಿಸಬೇಕಾಗಿದೆ feature ಮತ್ತು ಅವುಗಳನ್ನು ಹಿಂತಿರುಗಿ master ಫಿಕ್ಸ್ ಜೊತೆಗೆ.

ನಾವು ಸಮಸ್ಯೆಯನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಸಂಪರ್ಕಿಸಬಹುದು:

• ವಿಲೀನವನ್ನು ರದ್ದುಗೊಳಿಸುವ ಬದ್ಧತೆಯನ್ನು ಹಿಂತಿರುಗಿಸಿ feature с master;
• ಹಿಂದಿನದರಿಂದ ಸರಿಸಲು ಬದ್ಧವಾಗಿದೆ feature.

ವಿಭಿನ್ನ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು ಈ ಸಂದರ್ಭದಲ್ಲಿ ವಿಭಿನ್ನ ವಿಧಾನಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಆದರೆ ನಾವು ಉಪಯುಕ್ತ ಕಮಿಟ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಶಾಖೆಗೆ ಸರಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ಹೊಸ ಶಾಖೆಗಾಗಿ ಪ್ರತ್ಯೇಕ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ.

️ಕಾರ್ಯ

1. ಎಂಬ ಥ್ರೆಡ್ ಅನ್ನು ರಚಿಸಿ feature-fix ಮತ್ತು ಅದಕ್ಕೆ ಬದಲಿಸಿ.

2. ಹಿಂದಿನ ಶಾಖೆಯಿಂದ ಎಲ್ಲಾ ಕಮಿಟ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಿ feature ಹೊಸ ಎಳೆಗೆ. ವಲಸೆಯ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸಿದ ವಿಲೀನ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಿ.

   

3. ಇದಕ್ಕೆ ರಿಗ್ರೆಶನ್ ಪರೀಕ್ಷೆಯನ್ನು ಸೇರಿಸಿ ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. ಅವರು ವಿಫಲವಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪರೀಕ್ಷೆಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ರನ್ ಮಾಡಿ.
5. "ಸ್ನೀಕಿ ಬಗ್‌ನೊಂದಿಗೆ" ಪಠ್ಯವನ್ನು ತೆಗೆದುಹಾಕಿ ci.md.
6. ಪರೀಕ್ಷಾ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಹಂತದ ಪಟ್ಟಿ ಬದಲಾವಣೆಗಳನ್ನು ಸೂಚ್ಯಂಕಕ್ಕೆ ಸೇರಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಒಪ್ಪಿಸಿ.
7. ರಿಮೋಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಶಾಖೆಯನ್ನು ಪ್ರಕಟಿಸಿ.

ನೀವು ಇದೇ ರೀತಿಯದ್ದನ್ನು ಕೊನೆಗೊಳಿಸಬೇಕು:

ಕೋಮಂಡ್ಡು

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ.

ಶೀರ್ಷಿಕೆಯೊಂದಿಗೆ ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸಿ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸರಿಪಡಿಸಲಾಗುತ್ತಿದೆ. ಸ್ಥಾಪಿಸಿ feature-fix "ಹೆಡ್ ಶಾಖೆ" ಮತ್ತು ಹಾಗೆ master "ಮೂಲ ಶಾಖೆ" ಯಂತೆ.
ಪರೀಕ್ಷೆಗಳು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ದಯವಿಟ್ಟು ನಿರೀಕ್ಷಿಸಿ. PR ಚರ್ಚೆಯ ಕೆಳಭಾಗದಲ್ಲಿ ನೀವು ಪರೀಕ್ಷೆಗಳ ಸ್ಥಿತಿಯನ್ನು ನೋಡಬಹುದು.

ನೀವು ಸ್ಥಾಪಿಸಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ master ಅವರಲ್ಲಿ ರೆಪೊಸಿಟರಿಯನ್ನು ಫೋರ್ಕ್ ಮಾಡಿ "ಬೇಸ್ ಬ್ರಾಂಚ್" ಆಗಿ, ಕೋರ್ಸ್ ಮೆಟೀರಿಯಲ್ ರೆಪೊಸಿಟರಿಯ ಬದಲಾವಣೆಗಳ ವಿನಂತಿಗಳಿಗೆ ನಾನು ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ.

ಪುಲ್ ವಿನಂತಿಯನ್ನು ಅನುಮೋದಿಸಿ "ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸರಿಪಡಿಸುವುದು"

ತಿದ್ದುಪಡಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ದಯವಿಟ್ಟು ಬದಲಾವಣೆಗಳನ್ನು ಅನುಮೋದಿಸಿ master ಪುಲ್ ವಿನಂತಿಯಿಂದ.

️ಕಾರ್ಯ

1. "ಪುಲ್ ವಿನಂತಿಯನ್ನು ವಿಲೀನಗೊಳಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.
2. "ವಿಲೀನವನ್ನು ದೃಢೀಕರಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.
3. ನಮಗೆ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ "ಶಾಖೆಯನ್ನು ಅಳಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿ.

ಈ ಕ್ಷಣದಲ್ಲಿ ನೀವು ಹೊಂದಿರಬೇಕಾದದ್ದು ಇದು.

ಅಭಿನಂದನೆಗಳು!

ನಿರಂತರ ಏಕೀಕರಣದ ಸಮಯದಲ್ಲಿ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವ ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ನೀವು ಪೂರ್ಣಗೊಳಿಸಿದ್ದೀರಿ.

ನೀವು ಕೋರ್ಸ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಗಮನಿಸಿದರೆ ಅಥವಾ ಅದನ್ನು ಹೇಗೆ ಸುಧಾರಿಸುವುದು ಎಂದು ತಿಳಿದಿದ್ದರೆ, ದಯವಿಟ್ಟು ಸಮಸ್ಯೆಯನ್ನು ರಚಿಸಿ ಕೋರ್ಸ್ ಸಾಮಗ್ರಿಗಳೊಂದಿಗೆ ರೆಪೊಸಿಟರಿಗಳು. ಈ ಕೋರ್ಸ್ ಕೂಡ ಹೊಂದಿದೆ ಸಂವಾದಾತ್ಮಕ ಆವೃತ್ತಿ GitHub ಲರ್ನಿಂಗ್ ಲ್ಯಾಬ್ ಅನ್ನು ವೇದಿಕೆಯಾಗಿ ಬಳಸುವುದು.

ಮೂಲ: www.habr.com