ਕੀ ਤੁਸੀਂ ਗਿੱਟ ਕਮਾਂਡਾਂ ਸਿੱਖੀਆਂ ਹਨ ਪਰ ਕਲਪਨਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਨਿਰੰਤਰ ਏਕੀਕਰਣ (CI) ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੀਆਂ ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਇਹ ਕੋਰਸ ਤੁਹਾਨੂੰ GitHub ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਵਿੱਚ ਵਿਹਾਰਕ ਹੁਨਰ ਪ੍ਰਦਾਨ ਕਰੇਗਾ। ਇਹ ਕੋਰਸ ਇੱਕ ਵਿਜ਼ਾਰਡ ਬਣਨ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਬਸ ਕਲਿੱਕ ਕਰ ਸਕਦੇ ਹੋ; ਇਸਦੇ ਉਲਟ, ਤੁਸੀਂ ਉਹੀ ਕਾਰਵਾਈਆਂ ਕਰੋਗੇ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕੰਮ 'ਤੇ ਕਰਦੇ ਹਨ, ਉਸੇ ਤਰ੍ਹਾਂ ਜਿਵੇਂ ਉਹ ਕਰਦੇ ਹਨ। ਮੈਂ ਥਿਊਰੀ ਦੀ ਵਿਆਖਿਆ ਕਰਾਂਗਾ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਕਦਮਾਂ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹੋ।

ਸਾਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਜਿਵੇਂ ਅਸੀਂ ਤਰੱਕੀ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਆਮ CI ਕਦਮਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਬਣਾਵਾਂਗੇ, ਜੋ ਕਿ ਇਸ ਸੂਚੀ ਨੂੰ ਯਾਦ ਰੱਖਣ ਦਾ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਅਸੀਂ ਉਹਨਾਂ ਕਾਰਵਾਈਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਬਣਾਵਾਂਗੇ ਜੋ ਡਿਵੈਲਪਰ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਕਰਦੇ ਹੋਏ ਕਰਦੇ ਹਨ, ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਆਪਣੀ CI ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅਸਲ ਦੇ ਨੇੜੇ ਲਿਆਉਣ ਲਈ ਟੈਸਟਾਂ ਦੇ ਇੱਕ ਸਧਾਰਨ ਸੈੱਟ ਦੀ ਵੀ ਵਰਤੋਂ ਕਰਾਂਗੇ।

ਇਹ GIF ਯੋਜਨਾਬੱਧ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਕਮਿਟਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੋਰਸ ਵਿੱਚ ਅੱਗੇ ਵਧਦੇ ਹੋ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਇੱਥੇ ਕੁਝ ਵੀ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ ਅਤੇ ਸਿਰਫ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹੈ.

ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਮਿਆਰੀ CI ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚੋਂ ਲੰਘੋਗੇ:

• ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ 'ਤੇ ਕੰਮ;
• ਗੁਣਵੱਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸਵੈਚਲਿਤ ਟੈਸਟਾਂ ਦੀ ਵਰਤੋਂ;
• ਤਰਜੀਹੀ ਕੰਮ ਨੂੰ ਲਾਗੂ ਕਰਨਾ;
• ਸ਼ਾਖਾਵਾਂ ਨੂੰ ਮਿਲਾਉਣ ਵੇਲੇ ਅਪਵਾਦ ਦਾ ਹੱਲ (ਅਭੇਦ ਵਿਰੋਧ);
• ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਨ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਹੁੰਦੀ ਹੈ।

ਤੁਸੀਂ ਕੀ ਸਿੱਖੋਗੇ?

ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦੇ ਯੋਗ ਹੋਵੋਗੇ:

• ਨਿਰੰਤਰ ਏਕੀਕਰਣ (CI) ਕੀ ਹੈ?
• CI ਵਿੱਚ ਕਿਸ ਕਿਸਮ ਦੇ ਸਵੈਚਾਲਿਤ ਟੈਸਟ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਦੇ ਜਵਾਬ ਵਿੱਚ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ?
• ਪੁੱਲ ਬੇਨਤੀਆਂ ਕੀ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੀ ਕਦੋਂ ਲੋੜ ਹੈ?
• ਟੈਸਟ ਡ੍ਰਾਈਵਨ ਡਿਵੈਲਪਮੈਂਟ (TDD) ਕੀ ਹੈ ਅਤੇ ਇਹ CI ਨਾਲ ਕਿਵੇਂ ਸੰਬੰਧਿਤ ਹੈ?
• ਕੀ ਮੈਨੂੰ ਤਬਦੀਲੀਆਂ ਨੂੰ ਮਿਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਰੀਬੇਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
• ਵਾਪਸ ਰੋਲ ਕਰੋ ਜਾਂ ਅਗਲੇ ਸੰਸਕਰਣ ਵਿੱਚ ਠੀਕ ਕਰੋ?

ਪਹਿਲਾਂ ਮੈਂ ਹਰ ਥਾਂ "ਪੁੱਲ ਬੇਨਤੀਆਂ" ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਦਾ ਅਨੁਵਾਦ ਕੀਤਾ, ਪਰ ਨਤੀਜੇ ਵਜੋਂ ਮੈਂ ਟੈਕਸਟ ਵਿੱਚ ਪਾਗਲਪਨ ਦੀ ਡਿਗਰੀ ਨੂੰ ਘਟਾਉਣ ਲਈ ਕੁਝ ਥਾਵਾਂ 'ਤੇ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਵਾਕਾਂਸ਼ ਵਾਪਸ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਮੈਂ ਕਈ ਵਾਰ "ਪ੍ਰੋਗਰਾਮਰ ਸਰਜ਼ਿਕ" ਦੀ ਵਰਤੋਂ ਕਰਾਂਗਾ ਜਿਵੇਂ ਕਿ ਸ਼ਾਨਦਾਰ ਕ੍ਰਿਆ "ਕਮਿਟ" ਜਿੱਥੇ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕੰਮ 'ਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਕੀ ਹੈ?

ਨਿਰੰਤਰ ਏਕੀਕਰਣ, ਜਾਂ CI, ਇੱਕ ਤਕਨੀਕੀ ਅਭਿਆਸ ਹੈ ਜਿਸ ਵਿੱਚ ਹਰੇਕ ਟੀਮ ਮੈਂਬਰ ਆਪਣੇ ਕੋਡ ਨੂੰ ਇੱਕ ਆਮ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਦਿਨ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ ਏਕੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਾ ਕੋਡ ਘੱਟੋ-ਘੱਟ ਗਲਤੀਆਂ ਤੋਂ ਬਿਨਾਂ ਬਣਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਸ਼ਬਦ ਬਾਰੇ ਮਤਭੇਦ ਹਨ

ਵਿਵਾਦ ਦਾ ਬਿੰਦੂ ਏਕੀਕਰਣ ਦੀ ਬਾਰੰਬਾਰਤਾ ਹੈ. ਕੁਝ ਲੋਕ ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ ਕੋਡ ਨੂੰ ਇੱਕ ਦਿਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਮਿਲਾਉਣਾ ਅਸਲ ਵਿੱਚ ਲਗਾਤਾਰ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਇੱਕ ਟੀਮ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਦਿੱਤੀ ਗਈ ਹੈ ਜਿੱਥੇ ਹਰ ਕੋਈ ਸਵੇਰੇ ਤਾਜ਼ਾ ਕੋਡ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸ਼ਾਮ ਨੂੰ ਇੱਕ ਵਾਰ ਇਸਨੂੰ ਜੋੜਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਇਹ ਇੱਕ ਵਾਜਬ ਇਤਰਾਜ਼ ਹੈ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇੱਕ ਦਿਨ ਦੀ ਪਰਿਭਾਸ਼ਾ ਵਾਜਬ ਤੌਰ 'ਤੇ ਵਿਹਾਰਕ, ਖਾਸ ਅਤੇ ਵੱਖ-ਵੱਖ ਆਕਾਰਾਂ ਦੀਆਂ ਟੀਮਾਂ ਲਈ ਢੁਕਵੀਂ ਹੈ।

ਇੱਕ ਹੋਰ ਇਤਰਾਜ਼ ਇਹ ਹੈ ਕਿ C++ ਹੁਣ ਵਿਕਾਸ ਵਿੱਚ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਇੱਕੋ ਇੱਕ ਭਾਸ਼ਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਇੱਕ ਢੰਗ ਵਜੋਂ ਗਲਤੀ-ਮੁਕਤ ਅਸੈਂਬਲੀ ਦੀ ਲੋੜ ਕਮਜ਼ੋਰ ਹੈ। ਟੈਸਟਾਂ ਦੇ ਕੁਝ ਸੈੱਟ (ਉਦਾਹਰਨ ਲਈ, ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੀਤੇ ਗਏ ਯੂਨਿਟ ਟੈਸਟ) ਨੂੰ ਵੀ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਸਮੇਂ, ਭਾਈਚਾਰਾ ਇਸ ਨੂੰ ਇੱਕ ਲੋੜ ਬਣਾਉਣ ਵੱਲ ਵਧ ਰਿਹਾ ਹੈ, ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ "ਬਿਲਡ + ਯੂਨਿਟ ਟੈਸਟ" ਸੰਭਵ ਤੌਰ 'ਤੇ ਆਮ ਅਭਿਆਸ ਬਣ ਜਾਵੇਗਾ, ਜੇਕਰ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਹੈ।

ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਤੋਂ ਵੱਖਰਾ ਲਗਾਤਾਰ ਡਿਲੀਵਰੀ (ਨਿਰੰਤਰ ਡਿਲਿਵਰੀ, ਸੀਡੀ) ਇਸ ਵਿੱਚ ਹਰੇਕ ਏਕੀਕਰਣ ਚੱਕਰ ਤੋਂ ਬਾਅਦ ਇੱਕ ਰੀਲੀਜ਼ ਉਮੀਦਵਾਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।

ਕਦਮਾਂ ਦੀ ਸੂਚੀ ਜੋ ਅਸੀਂ ਪੂਰੇ ਕੋਰਸ ਦੌਰਾਨ ਵਰਤਾਂਗੇ

1. ਨਵੀਨਤਮ ਕੋਡ ਵਿੱਚ ਖਿੱਚੋ. ਤੋਂ ਇੱਕ ਸ਼ਾਖਾ ਬਣਾਓ master. ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।
2. ਆਪਣੀ ਨਵੀਂ ਸ਼ਾਖਾ 'ਤੇ ਕਮਿਟ ਬਣਾਓ। ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਣਾਓ ਅਤੇ ਟੈਸਟ ਕਰੋ। ਪਾਸ? ਅਗਲੇ ਪੜਾਅ 'ਤੇ ਜਾਓ। ਫੇਲ? ਗਲਤੀਆਂ ਜਾਂ ਟੈਸਟਾਂ ਨੂੰ ਠੀਕ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
3. ਆਪਣੇ ਰਿਮੋਟ ਰਿਪੋਜ਼ਟਰੀ ਜਾਂ ਰਿਮੋਟ ਸ਼ਾਖਾ ਵੱਲ ਧੱਕੋ।
4. ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਬਣਾਓ। ਤਬਦੀਲੀਆਂ 'ਤੇ ਚਰਚਾ ਕਰੋ, ਚਰਚਾ ਜਾਰੀ ਰਹਿਣ ਦੇ ਨਾਲ ਹੋਰ ਕਮਿਟਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਫੀਚਰ ਸ਼ਾਖਾ 'ਤੇ ਟੈਸਟ ਪਾਸ ਕਰੋ।
5. ਮਾਸਟਰ ਤੋਂ ਮਰਜ/ਰੀਬੇਸ ਕਮਿਟ। ਅਭੇਦ ਨਤੀਜੇ 'ਤੇ ਟੈਸਟ ਪਾਸ ਕਰੋ।
6. ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾ ਤੋਂ ਉਤਪਾਦਨ ਤੱਕ ਤੈਨਾਤ ਕਰੋ।
7. ਜੇ ਕੁਝ ਸਮੇਂ ਲਈ ਉਤਪਾਦਨ ਵਿੱਚ ਸਭ ਕੁਝ ਵਧੀਆ ਹੈ, ਤਾਂ ਮਾਸਟਰ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਮਿਲਾਓ।

️ ਤਿਆਰੀ

ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸਹੀ ਸੌਫਟਵੇਅਰ ਹੈ

ਇਸ ਕੋਰਸ ਨੂੰ ਲੈਣ ਲਈ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇਗੀ Node.js и ਗਿਟ ਕਲਾਇੰਟ.

ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਗਿੱਟ ਕਲਾਇੰਟ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਮੈਂ ਸਿਰਫ ਕਮਾਂਡ ਲਾਈਨ ਲਈ ਕਮਾਂਡਾਂ ਪ੍ਰਦਾਨ ਕਰਾਂਗਾ।

ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਗਿੱਟ ਕਲਾਇੰਟ ਸਥਾਪਿਤ ਹੈ ਜੋ ਕਮਾਂਡ ਲਾਈਨ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਤੱਕ ਕੋਈ 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 'ਤੇ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਮੇਰੇ ਉੱਨਤ ਕੋਰਸ [ਟੀਮ ਵਰਕ ਅਤੇ ਸੀਆਈ ਵਿਦ ਗਿੱਟ] ਵਿੱਚ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (http://devops.redpill.solutions/).
• ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਹੈ ਸਿਰਫ ਇੱਕ ਰਿਮੋਟ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਅਤੇ ਸਿਰਫ ਸ਼ਾਖਾ ਦੀ ਗਿਣਤੀ ਕਰਨਾ master ਸ਼ੇਅਰਡ ਰਿਪੋਜ਼ਟਰੀ "ਸੁਰੱਖਿਅਤ"। ਇਸ ਦ੍ਰਿਸ਼ ਵਿੱਚ, ਵਿਅਕਤੀਗਤ ਡਿਵੈਲਪਰ ਆਪਣੇ ਕੋਡ ਨੂੰ ਇੱਕ ਰਿਮੋਟ ਰਿਪੋਜ਼ਟਰੀ ਦੀਆਂ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਦੂਸਰੇ ਇਸ ਕੋਡ ਨੂੰ ਦੇਖ ਸਕਣ, ਜੇਕਰ ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇਸ ਨਾਲ ਮਿਲਾਓ master ਸ਼ੇਅਰ ਰਿਪੋਜ਼ਟਰੀ.

ਇਸ ਖਾਸ ਕੋਰਸ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਵਰਕਫਲੋ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ ਜੋ ਸ਼ਾਖਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਆਉ ਸਾਡਾ ਕੋਡ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੀਏ।

️ਟਾਸਕ

• ਰਿਮੋਟ ਬ੍ਰਾਂਚ ਵਿੱਚ ਬਦਲਾਵ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਜਿਸ ਨਾਮ ਨਾਲ ਤੁਹਾਡੀ ਕਾਰਜਕਾਰੀ ਸ਼ਾਖਾ ਹੈ

Команды

git push --set-upstream origin feature

ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਬਣਾਓ

ਸਿਰਲੇਖ ਦੇ ਨਾਲ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਬਣਾਓ ਕਦਮ ਸਮੀਖਿਆ. ਇੰਸਟਾਲ ਕਰੋ feature ਜਿਵੇਂ "ਸਿਰ ਦੀ ਸ਼ਾਖਾ" ਅਤੇ master ਜਿਵੇਂ "ਬੇਸ ਬ੍ਰਾਂਚ"।

ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਸਥਾਪਿਤ ਕੀਤਾ ਹੈ master ਉਸ ਦੇ ਵਿੱਚ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਫੋਰਕ ਕਰੋ ਇੱਕ "ਬੇਸ ਬ੍ਰਾਂਚ" ਵਜੋਂ, ਮੈਂ ਕੋਰਸ ਸਮੱਗਰੀ ਭੰਡਾਰ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲਈ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇਵਾਂਗਾ।

GitHub lingo ਵਿੱਚ, "ਬੇਸ ਬ੍ਰਾਂਚ" ਉਹ ਬ੍ਰਾਂਚ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਆਪਣੇ ਕੰਮ ਨੂੰ ਆਧਾਰਿਤ ਕਰਦੇ ਹੋ, ਅਤੇ "ਹੈੱਡ ਬ੍ਰਾਂਚ" ਉਹ ਬ੍ਰਾਂਚ ਹੈ ਜਿਸ ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਬਦਲਾਅ ਹੁੰਦੇ ਹਨ।

ਪਰਿਵਰਤਨਾਂ 'ਤੇ ਚਰਚਾ ਕਰੋ, ਚਰਚਾ ਜਾਰੀ ਰਹਿਣ ਦੇ ਨਾਲ ਨਵੇਂ ਕਮਿਟ ਸ਼ਾਮਲ ਕਰੋ

ਪੁੱਲ ਬੇਨਤੀ (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. ਇਸ ਕਰਕੇ ਅਸੀਂ ਸਿਰਫ਼ ਸਿਰ ਨੂੰ ਪਿੱਛੇ ਨਹੀਂ ਕਰ ਸਕਦੇ master ਥਰਿੱਡ ਦੇ ਅੰਤ ਤੱਕ feature. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਨੂੰ ਜਾਂ ਤਾਂ ਮਰਜ ਕਰਨ ਜਾਂ ਕਮਿਟਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ feature ਰੀਬੇਸ master. GitHub ਅਸਲ ਵਿੱਚ ਆਟੋਮੈਟਿਕ ਅਭੇਦ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ ਕੋਈ ਵਿਵਾਦ ਨਹੀਂ ਹਨ. ਹਾਏ, ਸਾਡੀ ਸਥਿਤੀ ਵਿੱਚ, ਦੋਵਾਂ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਫਾਈਲ ਵਿੱਚ ਪ੍ਰਤੀਯੋਗੀ ਤਬਦੀਲੀਆਂ ਹਨ ci.md. ਇਸ ਸਥਿਤੀ ਨੂੰ ਅਭੇਦ ਵਿਵਾਦ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਾਨੂੰ ਇਸਨੂੰ ਹੱਥੀਂ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਮਿਲਾਓ ਜਾਂ ਰੀਬੇਸ ਕਰੋ

ਮਿਲਾਨ ਕਰੋ

• ਇੱਕ ਵਾਧੂ ਮਰਜ ਕਮਿਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਕੰਮ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ।
  • ਬ੍ਰਾਂਚਾਂ ਦੀਆਂ ਮੂਲ ਕਮਿਟਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਅਸਲ ਟਾਈਮਸਟੈਂਪਾਂ ਅਤੇ ਲੇਖਕਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ।
  • ਤਬਦੀਲੀ ਬੇਨਤੀ ਚਰਚਾਵਾਂ ਵਿੱਚ ਕਮਿਟਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਲਿੰਕਾਂ ਦੇ SHA ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ।
• ਇੱਕ-ਵਾਰ ਸੰਘਰਸ਼ ਹੱਲ ਦੀ ਲੋੜ ਹੈ।
• ਕਹਾਣੀ ਨੂੰ ਗੈਰ-ਲੀਨੀਅਰ ਬਣਾਉਂਦਾ ਹੈ।
  • ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਸ਼ਾਖਾਵਾਂ (ਇੱਕ IDE ਕੇਬਲ ਦੀ ਯਾਦ ਦਿਵਾਉਂਦੀ) ਦੇ ਕਾਰਨ ਕਹਾਣੀ ਨੂੰ ਪੜ੍ਹਨਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ।
  • ਆਟੋਮੈਟਿਕ ਡੀਬੱਗਿੰਗ ਨੂੰ ਹੋਰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ git bisect ਘੱਟ ਉਪਯੋਗੀ - ਇਹ ਸਿਰਫ ਅਭੇਦ ਪ੍ਰਤੀਬੱਧ ਨੂੰ ਲੱਭੇਗਾ।

ਰੀਬੇਸ

• ਬੇਸ ਬ੍ਰਾਂਚ ਦੇ ਸਿਖਰ 'ਤੇ ਮੌਜੂਦਾ ਸ਼ਾਖਾ ਤੋਂ ਇਕ ਤੋਂ ਬਾਅਦ ਇਕ ਰੀਪਲੇਅ ਕਰਦਾ ਹੈ।
  • ਨਵੇਂ SHAs ਦੇ ਨਾਲ ਨਵੀਆਂ ਕਮਿਟਾਂ ਤਿਆਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ 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 ਅਤੇ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਨਵਾਂ ਸੰਸਕਰਣ ਤੈਨਾਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਕਿਉਂਕਿ APIs ਅਤੇ ਡੇਟਾਬੇਸ ਸਕੀਮਾਂ ਬਦਲਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੋਡ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਨਿਰੰਤਰ ਡਿਲੀਵਰੀ ਅਤੇ ਚੰਗੀ ਟੈਸਟ ਕਵਰੇਜ ਦੇ ਨਾਲ, ਇਸ ਨੂੰ ਅਗਲੇ ਸੰਸਕਰਣ ਵਿੱਚ ਫਿਕਸ ਕਰਨ ਨਾਲੋਂ ਰੋਲ ਬੈਕ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਮੁਸ਼ਕਲ ਅਤੇ ਜੋਖਮ ਭਰਪੂਰ ਹੁੰਦਾ ਹੈ।

ਕਿਉਂਕਿ ਵਾਪਸ ਜਾਣ ਨਾਲ ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਕੋਈ ਜੋਖਮ ਨਹੀਂ ਹੁੰਦਾ, ਅਸੀਂ ਇਸ ਰਸਤੇ 'ਤੇ ਜਾਵਾਂਗੇ, ਕਿਉਂਕਿ ਇਹ ਸਾਨੂੰ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ

• ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਉਤਪਾਦ 'ਤੇ ਗਲਤੀ ਨੂੰ ਠੀਕ ਕਰੋ;
• ਵਿੱਚ ਕੋਡ ਬਣਾਓ 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