08 ਜਨ 2026·8 ਮਿੰਟ
Claude Code git hooks: ਸੁਰੱਖਿਅਤ ਕਮਿਟ ਅਤੇ ਤੇਜ਼ ਰਿਵਿਊز ਲਈ
Claude Code git hooks ਗੁਪਤ ਰੋਕ ਸਕਦੇ ਹਨ, ਫਾਰਮੈਟਿੰਗ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਨ, ਸਹੀ ਟੈਸਟ ਚਲਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੇਜ਼ ਸਮੀਖਿਆ ਲਈ ਛੋਟੇ ਕਮਿਟ ਸੰਖੇਪ ਲਿਖ ਸਕਦੇ ਹਨ।
Claude Code git hooks ਗੁਪਤ ਰੋਕ ਸਕਦੇ ਹਨ, ਫਾਰਮੈਟਿੰਗ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਨ, ਸਹੀ ਟੈਸਟ ਚਲਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੇਜ਼ ਸਮੀਖਿਆ ਲਈ ਛੋਟੇ ਕਮਿਟ ਸੰਖੇਪ ਲਿਖ ਸਕਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਸਮੀਖਿਆ ਦਰਦ “ਕਠੋਰ” ਕੋਡ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਉਹ ਅਣਟਰ ਸਕੀਂ ਤ੍ਰੁਟੀਆਂ ਹਨ ਜੋ ਕਮਿਟ ਵਿੱਚ ਪੈ ਜਾਂਦੀਆਂ ਹਨ: ਡੀਬੱਗ ਫਲੈਗ ਛੱਡ ਦਿੱਤਾ, ਇੱਕ ਬੇ-ਫਾਰਮੇਟ ਕੀਤੀ ਫਾਈਲ ਜੋ ਸ਼ੋਰ-ਭਰੇ ਡਿਫ ਬਣਾਉਂਦੀ ਹੈ, ਟੈਸਟ ਅੱਪਡੇਟ ਗੁੰਮ ਹੋਣਾ, ਜਾਂ ਇੱਕ ਗੁਪਤ ਕੁੰਜੀ ਕਾਨਫਿਗ ਵਿੱਚ ਨਕਲ ਹੋਣਾ। ਹਰ ਇੱਕ ਛੋਟਾ ਹੈ, ਪਰ ਮਿਲ ਕੇ ਇੱਕ ਸਾਫ਼ ਸਮੀਖਿਆ ਨੂੰ ਲੰਬਾ-ਚਿੱਤਰ ਬਣਾ ਦੇਂਦੇ ਹਨ।
ਕਮਿਟ-ਟਾਈਮ ਆਟੋਮੇਸ਼ਨ ਇਹ ਰੋਕਣ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਜਗ੍ਹਾ ਹੈ। ਜਦੋਂ ਚੇਕਸ ਸਿੱਧਾ ਕਮਿਟ ਬਣਨ ਤੋਂ ਠੱਡੇ ਚੱਲਦੇ ਹਨ, ਉਹ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੜ ਲੈਂਦੇ ਹਨ ਜਦ ਤੱਕ ਬਦਲਾਅ ਤੁਹਾਡੇ ਦਿਮਾਗ ਵਿੱਚ ਤਾਜ਼ਾ ਹੈ। ਗਲਤੀ ਠੀਕ ਕਰਨਾ ਸਕਿੰਟਾਂ ਲਗਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੰਟੈਕਸਟ ਵਿੱਚ ਹੋ। ਜੇ ਇਹ ਸਮੱਸਿਆ ਦੋ ਦਿਨ ਬਾਅਦ ਪੂਲ ਰੀਕਵੇਸਟ ਵਿੱਚ ਮਿਲੇ ਤਾਂ ਤੁਲਨਾ ਕਰੋ — ਹੋਰ ਕਮਿਟ ਆ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਪੁੱਛਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ।
Git ਹੋਕਸ ਇਸ ਲਈ ਪ੍ਰਾਇਕਟਿਕਲ ਟੂਲ ਹਨ ਕਿਉਂਕਿ ਉਹ ਲੋਕਲੀ ਚਲਦੇ ਹਨ, CI ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ। ਪਰ ਇਹ ਜਾਦੂ ਨਹੀਂ ਹਨ। ਹੋਕਸ ਨੂੰ ਛੱਡਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਗਲਤ ਸੰਰਚਿਤ ਹੋ ਸਕਦੇ ਹਨ, ਜਾਂ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਅਸਥਿਰ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਟੀਮ ਨੇ ਉਹਨਾਂ ਨੂੰ ਇਕਸਾਰ ਨਹੀਂ ਕੀਤਾ। ਉਹ ਆਪਣੇ ਆਪ ਗੁਣਵੱਤਾ ਦੀ ਗਾਰੰਟੀ ਵੀ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਉਹਨਾਂ ਨੂੰ ਗੇਟ ਨਹੀਂ, ਗਾਰਡਰੇਲ ਸਮਝੋ।
ਹੋਕਸ ਸਭ ਤੋਂ ਵੱਧ “ਸਮੀਖਿਆ ਟੈਕਸ” ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ — ਉਹ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ, ਘੱਟ-ਮੁੱਲ ਵਾਲੇ ਫੀਡਬੈਕ ਜੋ ਵਾਰ-ਵਾਰ ਆਉਂਦੇ ਹਨ। ਆਮ ਉਦਾਹਰਣ ਹਨ ਸੰਵੇਦਨਸ਼ੀਲ ਸਤਰ ਜੋ ਟੋਕਨ ਵਰਗੀ ਲੱਗਦੀਆਂ ਹਨ, ਫਾਰਮੈਟਿੰਗ ਅਤੇ ਲਿੰਟ ਸ਼ੋਰ, ਬੁਨਿਆਦੀ “ਕੀ ਤੁਸੀਂ ਸਹੀ ਟੈਸਟ ਚਲਾਏ?” ਜਾਂ ਛੋਟੀਆਂ ਸੰਖੇਪ ਨੋਟਾਂ ਜੋ ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਉਦੇਸ਼ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
ਇਹੀ ਥਾਂ ਹੈ ਜਿਥੇ Claude Code git hooks ਅਚ্ছে ਤਰੀਕੇ ਨਾਲ ਬੈਠਦੇ ਹਨ: ਉਹ ਨਿਰਸ ਪੜਤਾਲ ਦਾ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਅਉਖਾ-ਸਮਝਣ ਯੋਗ ਸੰਦਰਭ ਉਸੇ ਸਮੇਂ ਜੁੜ੍ਹਾ ਦੇ ਸਕਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਕਮਿਟ ਕਰ ਰਹੇ ਹੋ।
ਉਮੀਦ-ਸੈਟਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਲੋਕਲ ਹੋਕਸ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਰੱਖੋ ਤਾਂ ਜੋ ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਨਫ਼ਰਤ ਨਾ ਕਰਨ। ਛੇਤੀ ਚੇਕਸ ਤੁਹਾਡੇ ਲੈਪਟੌਪ ਤੇ ਹੋਣੀ ਚਾਹੀਦੀਆਂ ਹਨ; ਧੀਮੀਆਂ ਚੇਕਸ ਬਾਅਦ ਵਿੱਚ। ਚੰਗਾ ਵੰਡ ਸੇਕਿੰਡ-ਪੱਧਰੀ ਕਮਿਟ-ਟਾਈਮ ਅਤੇ ਮਿੰਟ-ਪੱਧਰੀ CI ਹੋਣਾ ਹੈ। ਜੇ ਕੋਈ ਹੋਕ ਰੈਗੂਲਰ ਤੌਰ 'ਤੇ ਇੰਨਾ ਲੰਬਾ ਲੈਂਦਾ ਹੈ ਕਿ ਕੋਈ “skip” ਦੀ ਓਰ ਹੱਥ ਪਹੁੰਚਾਏ, ਤਾਂ ਉਹ ਤੁਹਾਡੇ ਰੇਪੋ ਨੂੰ ਸੰਰੱਖਿਤ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਣ: ਤੁਸੀਂ ਇੱਕ ਮੋਡੀਊਲ ਬਦਲਦੇ ਹੋ ਅਤੇ ਕੁਝ ਫੰਕਸ਼ਨ ਰੀਫੈਕਟਰ ਕਰਦੇ ਹੋ। ਬਿਨਾਂ ਆਟੋਮੇਸ਼ਨ ਦੇ, ਇੱਕ ਸਮੀਖਿਆਕਾਰ 400 ਲਾਈਨਾਂ ਨੂੰ ਹਿਲਦੇ ਦੇਖੇਗਾ, ਕੋਈ ਟੈਸਟ ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ, ਅਤੇ ਉਹ ਪ੍ਰਸ਼ਨ ਪੁੱਛਣਾ ਪਵੇਗਾ। ਕਮਿਟ-ਟਾਈਮ ਚੇਕਸ ਨਾਲ, ਕਮਿਟ ਫਾਰਮੈਟ ਹੋਇਆ ਹੁੰਦਾ ਹੈ, ਸਬੰਧਤ ਟੈਸਟ ਰਨ ਹੋਏ ਹਨ, ਅਤੇ ਕਮਿਟ ਸੁਨੇਹਾ ਇੱਕ ਛੋਟਾ ਸੰਖੇਪ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਸਮੀਖਿਆ ਉਸ ਜਗ੍ਹਾ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ: ਡਿਜ਼ਾਈਨ 'ਤੇ, ਨ ਕਿ ਸਫਾਈ 'ਤੇ।
Git ਹੋਕਸ ਸਾਦਾ ਚੇਕਸ ਲਈ ਸ਼ਾਨਦਾਰ ਹਨ, ਪਰ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਹੈ-ਨ-ਨਹੀਂ ਨਿਯਮਾਂ 'ਤੇ ਰੁਕ ਜਾਂਦੇ ਹਨ: “ਫਾਈਲ ਫਾਰਮੈਟ ਕੀਤੀ ਹੈ?” ਜਾਂ “ਤੁਸੀਂ ਲਿੰਟਰ ਚਲਾਇਆ?” Claude Code ਇੱਕ ਹਲਕਾ ਫੈਸਲਾ-ਪਰਤ ਕੁਝ ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਟੇਜਡ ਡਿਫ ਅਤੇ ਕੁਝ ਸਬੰਧਤ ਫਾਈਲਾਂ ਨੂੰ ਪੜ੍ਹ ਕੇ ਇਹ ਫੈਸਲੇ ਕਰਦਾ ਹੈ ਜੋ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਨਾਲ ਵੱਧ ਮਿਲਦੇ-ਜੁਲਦੇ ਹਨ।
Claude Code git hooks ਨਾਲ, ਹੋਕ ਤੇ ਤੁਹਾਡੀ ਬਦਲੀ ਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ, ਸਿਰਫ਼ ਰੇਪੋ ਵਿੱਚ ਮੌਜੂਦ ਚੀਜ਼ਾਂ ਨੂੰ ਨਹੀਂ। ਇਸ ਨਾਲ ਆਟੋਮੇਸ਼ਨ ਹੋਰ ਚੁਣਿੰਦਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਛੁਹੇ ਹੋਏ ਮੋਡਿਊਲਾਂ, ਸੋਧ ਕੀਤਾ ਕਾਨਫਿਗ ਫਾਈਲਾਂ, ਅਤੇ ਨਵੇਂ ਵਾਤਾਵਰਣ ਚਲਕਾਂ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦਾ ਹੈ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਹਰ ਕਮਿਟ ਨੂੰ ਇੱਕ ਪੂਰੇ ਬਿਲਡ ਵਾਂਗਟREAT ਕੀਤਾ ਜਾਵੇ।
ਜਿੱਥੇ “ਡਿਫ ਪੜ੍ਹੋ ਅਤੇ ਸੋਚੋ” ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਉਸਦੀ ਵਰਤੋਂ ਦੇ ਵਿਹੰਗ:
ਪਾਬੰਦੀਆਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਇੱਕ ਧੀਰਾ ਹੋਕ ਇੱਕ ਛੱਡਿਆ ਹੋਕ ਬਣ ਜਾਂਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਲਕਸ਼: ਆਮ ਤੌਰ 'ਤੇ ਆਮ ਗਲਤੀਆਂ ਨੂੰ ਪਹਿਲਾਂ ਫੜਨ ਲਈ ਗਾਰਡਰੇਲ ਪਾਉ, ਨਾ ਕਿ ਹਰ ਕਮਿਟ 'ਤੇ ਦੂਜਾ CI ਸਰਵਰ ਚਲਾਉ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇ ਇਹ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਮੁਕੰਮਲ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਤਾਂ ਉਹ ਸੰਭਵਤ: CI ਜਾਂ pre-push ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਹੁਤ ਟੀਮਾਂ pre-commit ਤੇ ਛੇਤੀ ਲੋਕਲ ਚੈਕਸ ਚਲਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਭਾਰੀ ਟੈਸਟ ਸੂਟ ਬਾਅਦ ਲਈ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ।
ਫੇਲਿਯਰ ਮੋਡ ਲਈ ਯੋਜਨਾ ਬਣਾਓ। ਜੇ ਮਾਡਲ ਕਾਲ ਟਾਈਮਆਉਟ ਕਰ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਮਿਟ ਨੂੰ ਰੋਕਣਾ ਹੈ ਜਾਂ ਇੱਕ ਸਧਾਰਨ ਚੈਕ ਤੇ fallback ਕਰਨਾ ਹੈ। ਫੈਲਬੈਕ ਵਰਕਫਲੋ predictable ਰੱਖਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਹੋਕਸ ਨੂੰ ਨਿਰਸ ਕਰਨ ਦੀ ਆਦत ਨਹੀਂ ਪੈਦਾ ਹੋਣ ਦਿੰਦਾ।
ਕੁਝ ਸੈਟਅਪ ਹੋਸਟਡ ਮਾਡਲ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ; ਹੋਰ ਆਇਸੋਲੇਟੇਡ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚਲਦੇ ਹਨ। ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜਾ ਕੋਡ ਡਿਵੈਲਪਰ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ (ਜੇ ਕੋਈ), ਅਤੇ ਜੋ ਤੁਸੀਂ ਭੇਜਦੇ ਹੋ ਉਸ ਨੂੰ ਸੀਮਿਤ ਕਰੋ। ਸਟੇਜਡ ਡਿਫ ਅਤੇ ਚੰਦ ਸੰਬੰਧਤ ਫਾਈਲਾਂ ਬਹੁਤ ਵਾਰੀ ਕਾਫੀ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਸੰਵੇਦਨਸ਼ੀਲ ਰੇਪੋਜ਼ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਪਸ਼ਟ ਹੋਵੋ ਕਿ ਵਿਸ਼ਲੇਸ਼ਣ ਕਿੱਥੇ ਚਲਦਾ ਹੈ ਅਤੇ ਕੀ ਲੌਗ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸੰਕਤ ਉਦਾਹਰਣ: ਜੇ ਇੱਕ ਕਮਿਟ STRIPE_SECRET=... ਵਰਗਾ ਨਵਾਂ ਕਾਨਫਿਗ ਮੁੱਲ ਜੋੜਦਾ ਹੈ, ਹੋਕ ਕਮਿਟ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ, ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਜੋਖਿਮ ਵਾਲਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ ਕਿ ਇਸਨੂੰ secret manager ਜਾਂ ਲੋਕਲ env ਫਾਈਲ ਵਿੱਚ ਰੱਖੋ ਪਹਿਲਾਂ ਕਿ ਇਹ ਰਿਮੋਟ ਰੇਪੋ ਤੱਕ ਪਹੁੰਚੇ।
Git ਹੋਕਸ ਫਾਇਦੇਮੰਦ ਹਨ ਗਿਆਨ ਲੋਕ ਉਹਨਾਂ ਨੂੰ ਚਾਲੂ ਰੱਖਦੇ ਹਨ ਅਤੇ ਕਮਿਟਾਂ ਨੂੰ ਡਰਾਉਣਾ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਤਰਕ ਇਹ ਹੈ ਕਿ ਹਰ ਕੰਮ ਲਈ ਸਹੀ ਹੋਕ ਚੁਣੋ ਅਤੇ ਜੋ ਕੁਝ ਧੀਮਿਆ ਹੈ ਉਸਨੂੰ ਗਰਮ ਰਸਤੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
ਕਿੱਥੇ ਚੇਕਸ ਆਮ ਤੌਰ 'ਤੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਦਾ ਇੱਕ ਸਧਾਰਣ ਨਕਸ਼ਾ:
ਜਦੋਂ ਤੁਸੀਂ Claude Code git hooks ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਤੁਰੰਤ ਮੌਜੂਦ ਸਮੀਖਿਆਕਾਰ ਵਾਂਗ ਵਰਤੋਂ ਕਰੋ, ਬਾਧਾ ਨਹੀਂ। ਜੋ ਕੋਈ ਵੀ ਨੈੱਟਵਰਕ ਕਾਲਸ, ਪੂਰੇ ਟੈਸਟ ਸੂਟ, ਜਾਂ ਲੰਬੇ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਲੋੜ ਹੈ, ਉਹ pre-push ਜਾਂ CI ਵਿੱਚ ਰੱਖੋ, ਨਾ ਕਿ pre-commit ਵਿੱਚ।
ਇੱਕ ਆਮ ਤਰੀਕਾ ਜੋ ਪਤਾ ਲਗਾਉਂਦੀ ਹੈ ਕਿ ਕਿੜੀ ਚੀਜ਼ ਕਿੱਥੇ ਚਲਾਣੀ ਹੈ: ਚੇਕਸ ਨੂੰ ਗਤੀ ਅਤੇ ਪ੍ਰਭਾਵ ਅਨੁਸਾਰ ਵਰਗ ਬਾਧ ਕਰੋ। ਜੇ ਇਹ ਉੱਚ-ਖਤਰਾ ਚੀਜ਼ ਫੜਦਾ ਹੈ (ਜਿਵੇਂ ਲੀਕ ਕੀ) ਅਤੇ ਦੋ-ਤੀਨ ਸਕਿੰਟਾਂ ਵਿੱਚ ਚੱਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹ pre-commit ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਇਹ 30-90 ਸਕਿੰਟ ਲੈਂਦਾ, ਤਾਂ ਇਸਨੂੰ pre-push ਵਿੱਚ ਲਿਜਾਓ ਜਾਂ ਫਾਈਲ-ਸਪੈਸ਼ੀਫਿਕ ਰੂਲ ਲਗਾਓ।
ਟੀਮਾਂ ਨੂੰ enforcement 'ਤੇ ਸਪਸ਼ਟ ਰਵੱਈਆ ਵੀ ਚਾਹੀਦਾ ਹੈ। ਸਿੰਗਲ-ਡੈਵ ਰੇਪੋ ਲਈ opt-in ਹੋਕ्स ਠੀਕ ਹੋ ਸਕਦੇ ਹਨ। ਟੀਮ ਰੇਪੋ ਲਈ, ਆਮ ਤੌਰ 'ਤੇ ਬੇਸਿਕਸ (ਗੁਪਤ, ਫਾਰਮੈਟਿੰਗ, ਕਮਿਟ ਸੁਨੇਹਾ ਨਿਯਮ) ਨੂੰ ਲਾਜ਼ਮੀ ਰੱਖੋ ਅਤੇ ਭਾਰੀ ਚੇਕਸ ਨੂੰ ਲੋਕਲੀ ਸੂਚਨਾਤਮਕ ਰੱਖੋ, ਜਦੋਂ ਕਿ CI ਅਸਲੀ ਦਰਵਾਜ਼ਾ ਹੈ।
ਹੋਕ ਆਉਟਪੁੱਟ ਲੋਕ ਸੋਚਦੇ ਤੋਂ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਇੱਕ ਫੇਲ ਹੋਣ ਵਾਲਾ ਹੋਕ ਦੱਸੇ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਅਗਲੇ ਕਦਮ ਕੀ ਹਨ। ਸੁਨੇਹੇ ਛੋਟੇ ਅਤੇ ਨਿਰਧਾਰਤ ਰੱਖੋ। ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਫਾਈਲ ਅਤੇ ਲਾਈਨ ਦਿਖਾਓ, ਇੱਕ ਸਪਸ਼ਟ ਫਿਕਸ ਕਮਾਂਡ ਦਿਓ, ਸਿਰਫ਼ ਸੱਚੀ ਐਮਰਜੈਂਸੀ ਲਈ ਬਾਈਪਾਸ ਕਰਨ ਦਾ ਤਰੀਕਾ ਸਮਝਾਓ (ਅਤੇ ਕਦੋਂ ਨਾ), ਅਤੇ ਵੱਡੇ ਲੋਗਸ ਨੂੰ ਰੱਖੋ ਸਿਰਫ਼ ਜਦੋਂ ਯੂਜ਼ਰ “verbose” ਮੰਗੇ।
ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ Koder.ai ਤੋਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਐਕਸਪੋਰਟ ਕਰਦੇ ਹੋ ਅਤੇ ਲੋਕਲੀ ਕਮਿਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਇੱਕ ਤੇਜ਼ pre-commit ਹੋਕ ਨਕਲ ਕੀਤੀਆਂ API ਟੋਕਨ ਨੂੰ ਤੁਰੰਤ ਫੜ ਸਕਦਾ ਹੈ, ਜਦਕਿ pre-push ਬਦਲੇ ਮੋਡੀਊਲਾਂ ਲਈ ਧੀਮੀ “ਸਿਰਫ਼ ਬਦਲੇ ਟੈਸਟ” ਨਿਯਮ ਚਲਾਏਗਾ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਹੋਰ ਉਸ ਬ੍ਰਾਂਚ ਨੂੰ ਵੇਖੇ।
ਇੱਕ ਗੁਪਤ ਉਹ ਕੁਝ ਵੀ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਤੁਹਾਡੇ ਵੱਲੋਂ ਕੰਮ ਕਰਨ ਜਾਂ ਪ੍ਰਾਈਵੇਟ ਸਿਸਟਮਾਂ ਤੱਕ ਪਹੁੰਚ ਦੇਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਸੋਚੋ: API ਟੋਕਨ, OAuth ਕਲਾਇੰਟ ਗੁਪਤ, ਕਲਾਉਡ ਕੀ, ਡੇਟਾਬੇਸ ਪਾਸਵਰਡ, ਨਿੱਜੀ webhook URLs, ਸਾਈਨਿੰਗ ਕੀ, ਅਤੇ ਇੱਥੇ ਤੱਕ ਕਿ “ਅਸਤਾਈ” ਟੈਸਟ ਪ੍ਰਮਾਣ ਪੱਤਰ। ਇੱਕ ਇਕਲੌਤਾ ਅਕਸਿਡੈਂਟਲ ਕਮਿਟ ਇੱਕ ਫੋਰਕ, CI ਲੌਗ, ਜਾਂ ਪੇਸਟ ਕੀਤੀ ਡਿਫ ਵਿੱਚ ਚਲਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਹ ਹੁਣ ਅਸਥਾਈ ਨਹੀਂ ਰਹਿੰਦਾ।
ਸਭ ਤੋਂ ਆਸਾਨ ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕੇਵਲ ਉਹੀ ਸਕੈਨ ਕਰੋ ਜੋ ਤੁਸੀਂ ਕਮਿਟ ਕਰਨ ਵਾਲੇ ਹੋ। ਇੱਕ ਹੋਕ ਨੂੰ ਸਟੇਜਡ ਬਦਲਾਵਾਂ (index) ਚੈਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਪੂਰੇ ਰੇਪੋ ਨੂੰ। ਇਸ ਨਾਲ ਇਹ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਉਹ ਪੁਰਾਣੀਆਂ ਫਾਈਲਾਂ ਤੋਂ ਆ ਰਹੀ ਸ਼ੋਰ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਛੁਹਿਆ ਨਹੀਂ। ਇਹ ਫੀਡਬੈਕ ਨੂੰ ਨਿਆਂਪੂਰਕ ਬਣਾਉਂਦਾ ਹੈ: “ਇਸ ਕਮਿਟ ਵਿੱਚ ਸਮੱਸਿਆ ਹੈ” ਨਾ ਕਿ “ਤੁਾਡੇ ਰੇਪੋ 'ਚ ਪਹਿਲਾਂ ਸਮੱਸਿਆ ਸੀ।”
ਆਮ ਚੀਜ਼ਾਂ ਜੋ ਜਲਦੀ ਫਲੈਗ ਹੁੰਦੀਆਂ ਹਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਉੱਚ-ਐਨਟਰੋਪੀ ਟੋਕਨ (ਲੰਬੇ ਰੈਡਮ-ਲੱਗਦੇ ਸਤਰ), ਜਾਣੇ-ਪਹਚਾਣੇ ਕੀ ਫਾਰਮੈਟ (AWS ਕੀਜ਼, GitHub ਟੋਕਨ, JWTs), password=... ਜਾਂ api_key: ... ਵਰਗੇ ਪੈਟਰਨਜ਼ ਕਾਨਫਿਗ ਵਿੱਚ, ਨਿੱਜੀ URL ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਐੰਬੈੱਡ ਕੀ क्रੈਡੈਂਸ਼ੀਅਲ ਹਨ, ਅਤੇ .env ਫਾਈਲਾਂ ਜਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਕਾਨਫਿਗ ਦੀ ਨਕਲ।
ਫਾਲਸ-ਪੋਜ਼ਿਟਿਵਜ਼ ਹੋ ਸਕਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਟੈਸਟ ਡੇਟਾ, ਹੈਸ਼, ਜਾਂ ਉਦਾਹਰਣ ਡੌਕਸ ਨਾਲ। ਇੱਕ allowlist ਬਣਾਓ ਤਾਂ ਜੋ ਲੋਕ ਪੂਰਾ ਚੈੱਕ ਬੰਦ ਕੀਤਾ ਬਿਨਾਂ ਅੱਗੇ ਵੱਧ ਸਕਣ। allowlist ਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ: ਫਿਕਸਚਰਾਂ ਲਈ ਸਟੀਕ ਫਾਈਲ ਪਾਥ ਯਾ “dummy”/“example” ਵਰਗੇ ਸਪਸ਼ਟ ਮਾਰਕਰ।
ਜਦੋਂ ਗੁਪਤ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਕਮਿਟ ਫੇਲ ਕਰੋ ਅਤੇ ਸੁਨੇਹਾ ਦਿਓ ਜੋ ਲੋਕਾਂ ਨੂੰ ਅਗਲਾ ਕਦਮ ਦੱਸੇ। Claude Code git hooks ਇਸਨੂੰ ਦੋਸਤਾਨਾ ਬਣਾਉਣ ਲਈ ਡਿਫ ਦੇ ਆਧਾਰ 'ਤੇ ਇੱਕ ਛੋਟੀ ਵਿਆਖਿਆ ਵੀ ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਮੁੱਖ ਗੱਲ ਸਪਸ਼ਟ, ਸੁਰੱਖਿਅਤ ਅਗਲੇ ਕਦਮ ਹਨ:
ERROR: Possible secret detected in staged file: config/app.yaml (line 12)
Reason: looks like an API token
Next steps:
1) Remove it from the change or move it to env vars
2) Rotate the token (assume it is compromised)
3) Re-stage and retry commit
If this is a false positive, add a narrow allowlist rule in .secrets-allowlist
ਇੱਕ ਸਪਸ਼ਟ ਉਦਾਹਰਣ: ਕੋਈ ਬੈਕਐਂਡ ਕਾਨਫਿਗ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ ਅਤੇ TEMP_API_KEY ਜੋੜਦਾ ਹੈ ਤਾਂ ਕਿ ਫੀਚਰ ਡੈਵ ਵਿੱਚ ਕੰਮ ਕਰੇ। ਹੋਕ ਕਮਿਟ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਆਖਦਾ ਹੈ ਕਿ ਇਸਨੂੰ env var 'ਚ ਲੈ ਜਾਓ, ਅਤੇ ਯਾਦ ਦਿਲਾਉਂਦਾ ਹੈ ਕਿ ਜੇ ਇਹ ਅਸਲੀ ਸੀ ਤਾਂ ਰੋਟੇਟ ਕਰੋ। ਇਹ ਇੱਕ ਛੋਟੀ ਰੁਕਾਵਟ ਹੈ ਜੋ ਬਾਦ ਵਿੱਚ ਵੱਡੇ ਸਾਫ਼-ਸਫਾਈ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਫਾਰਮੈਟਿੰਗ ਦੀਆਂ ਲੜਾਈਆਂ ਸਮੀਖਿਆਕਾਰਾਂ ਦਾ ਸਮਾਂ ਖ਼ਰਚ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਧੀਰੇ ਹੋਕਸ ਹੋਕਸ ਨੂੰ ਬੰਦ ਕਰਾਉਂਦੇ ਹਨ। ਮਿੱਠਾ ਸਥਾਨ ਸਧਾਰਣ ਨਿਯਮ, ਹਰ ਭਾਸ਼ਾ ਲਈ ਇੱਕ ਟੂਲ, ਅਤੇ ਕੇਵਲ ਉਹੀ ਜੋ ਤੁਸੀਂ ਕਮਿਟ ਕਰਨ ਜਾ ਰਹੇ ਹੋ ਉਸਨੂੰ ਛੇੜਨਾ ਹੈ।
ਹਰ ਭਾਸ਼ਾ ਲਈ ਇੱਕ ਸਿੰਗਲ ਫਾਰਮੈਟਰ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਸਚਾਈ ਦਾ ਸਰੋਤ ਬਣਾਓ। ਜੇ ਦੋ ਫਾਰਮੈਟਰ ਵੱਖ-ਵੱਖ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ (ਔਰ ਫਾਰਮੈਟਰ + ਲਿੰਟਰ ਜੋ ਕੋਡ ਵਾਪਸ ਲਿਖਦਾ ਹੈ), ਤਾਂ ਇਹ ਸ਼ੋਰ ਅਤੇ ਚੱਕਰ ਹੋਵੇਗਾ। ਇਸਨੂੰ ਨਿਰਸ ਰੱਖੋ: ਇੱਕ JS/TS ਫਾਰਮੈਟਰ, ਇੱਕ Go ਫਾਰਮੈਟਰ, ਇੱਕ Dart ਫਾਰਮੈਟਰ। ਫਿਰ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਕੋਈ ਇੱਕੋ ਵਰਜ਼ਨ ਚਲਾਉਂਦਾ ਹੈ ਤਾਂ ਕਿ ਹੋਕ ਆਉਟਪੁੱਟ ਮਸ਼ੀਨਾਂ 'ਤੇ ਇੱਕ ਜੇਹਾ ਰਹੇ।
ਸਭ ਤੋਂ ਵੱਡੀ ਗਤੀ-ਬਚਤ ਸਿਰਫ਼ ਸਟੇਜਡ ਫਾਈਲਾਂ ਦੀ ਫਾਰਮੈਟਿੰਗ ਕਰਨਾ ਹੈ। ਹਰ ਕਮਿਟ 'ਤੇ ਪੂਰੇ ਰੇਪੋ ਨੂੰ ਫਾਰਮੈਟ ਕਰਨਾ ਉਹ ਮੁੱਖ ਕਾਰਨ ਹੈ ਜੇਕਰ ਟੀਮ pre-commit 'ਤੇ ਸ਼ਿਕਾਇਤ ਕਰਦੀ ਹੈ। ਸਟੇਜਡ-ਓਨਲੀ ਢੰਗ ਨਾਲ ਡਿਫ ਨੂੰ ਉਹੀ ਧਿਆਨ ਮਿਲਦਾ ਜਿਸਦੀ ਸਮੀਖਿਆਕਾਰ ਚਾਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ।
ਕੁਝ ਪ੍ਰਯੋਗਿਕ ਚੋਣਾਂ ਜੋ ਕਮਿਟ ਤੇਜ਼ ਰੱਖਦੀਆਂ ਹਨ:
ਆਟੋ-ਫਿਕਸ ਵਿਚ ਵਿਰੋਧ ਕਿਥੇ ਠੀਕ ਹੁੰਦਾ ਹੈ ਇਹ ਟੀਮ ਪਸੰਦ ਹੈ, ਪਰ ਮਿਲਿਆ-ਜੁਲਿਆ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਮਕੈਨਿਕਲ ਸੋਧਾਂ ਲਈ ਆਟੋ-ਫਿਕਸ ਵਧੀਆ ਹੈ ਕਿਉਂਕਿ ਇਹ “ਕਮਿਟ, ਫੇਲ, ਦੁਬਾਰਾ ਚਲਾਓ, ਫੇਰ ਕਮਿਟ” ਲੂਪ ਨੂੰ ਬਚਾਉਂਦਾ। ਫੇਲ ਕਰਨਾ ਪਸੰਦیدہ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਲੋਕਾਂ ਨੂੰ ਮੁੱਦੇ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਦਿਸ਼ਾ ਚੁਣਨ ਦੀ ਲੋੜ ਹੈ। ਜੇ ਤੁਸੀਂ ਫੇਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਐਸੀ ਹਦਾਇਤ ਪ੍ਰਿੰਟ ਕਰੋ ਜੋ ਕੋਈ ਵੀ 10 ਸਕਿੰਟ ਵਿੱਚ ਫਾਲੋ ਕਰ ਸਕੇ।
ਛੋਟੀਆਂ ਚੀਜ਼ਾਂ ਜੋ ਪ್ಲੈਟਫਾਰਮਾਂ 'ਤੇ ਸ਼ੋਰ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ ਨੂੰ ਇੱਕਸਾਰ ਬਨਾਓ। ਲਾਈਨ ਐਂਡਿੰਗਸ ਅਤੇ ਟ੍ਰੇਲਿੰਗ ਵ੍ਹਾਈਟਸਪੇਸ ਆਮ ਮੁੱਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਲੋਕ Windows, macOS, ਅਤੇ CI ਬਦਲਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਣ ਨੀਤੀ ਜੋ ਕਮੀ ਦਰਦ ਪੈਦਾ ਕਰਦੀ ਹੈ:
Claude Code git hooks ਇੱਥੇ glue ਦਾ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ: ਕਿਹੜੀਆਂ ਸਟੇਜਡ ਫਾਈਲਾਂ ਨੂੰ ਕਿਹੜਾ ਫਾਰਮੈਟਰ ਚਾਹੀਦਾ, ਠੀਕ ਕ੍ਰਮ ਵਿੱਚ ਚਲਾਉਣਾ, ਅਤੇ ਨੀਰਸ ਭਾਸ਼ਾ ਵਿੱਚ ਫੇਲਅਰ ਨੂੰ ਸਮਝਾਉਣਾ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਕਿਸੇ ਨੇ ਇੱਕ Go ਫਾਈਲ ਅਤੇ ਇੱਕ TS ਫਾਈਲ ਸਟੇਜ ਕੀਤੀ, ਹੋਕ ਹਰ ਇੱਕ ਨੂੰ ਸਹੀ ਟੂਲ ਨਾਲ ਫਾਰਮੈਟ ਕਰ ਸਕਦਾ ਹੈ, ਨਤੀਜਿਆਂ ਨੂੰ ਰੀ-ਸਟੇਜ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਨੋਟ ਦੇ ਸਕਦਾ ਹੈ “2 ਫਾਈਲਾਂ ਫਾਰਮੈਟ ਕੀਤੀਆਂ, ਕੋਈ ਬਿਹੇਵੀਅਰ تبدیلی ਨਹੀਂ।” ਸਮੀਖਿਆਕਾਰਾਂ ਨੂੰ ਸਾਫ਼ ਡਿਫ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਡਿਵੈਲਪਰ ਜ਼ਿਆਦਾ ਕਮਿਟ ਕਰਨ ਲਈ ਘਬਰਾਉਂਦੇ ਨਹੀਂ ਹਨ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਕਮਿਟਾਂ ਨੂੰ ਬੇਹਤਰ ਅਤੇ ਨਿਰਤਾ ਬਣਾਉਂਦਾ ਹੈ: ਸਿਰਫ਼ ਉਹ ਟੈਸਟ ਚਲਾਓ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸਟੇਜ ਕੀਤੇ। ਜਦੋਂ ਹੋਕ ਸਟੇਜਡ ਡਿਫ (ਆਪਣੇ ਵਰਕਿੰਗ ਟ੍ਰੀ ਨੂੰ ਨਹੀਂ) ਨੂੰ ਵੇਖਦਾ ਹੈ, ਇਹ ਅਧੂਰੇ ਕੰਮਾਂ ਕਾਰਨ ਫਾਲਸ ਅਲਾਰਮ ਤੋਂ ਬਚਦਾ ਹੈ।
ਪਹਿਲਾਂ ਇਹ ਪਤਾ ਕਰੋ ਕਿ ਕਿਹੜੇ ਖੇਤਰ ਛੁਹੇ ਗਏ। ਜ਼ਿਆਦਾਤਰ ਰੇਪੋਜ਼ ਦੀ ਬਣਤਰ ਪ੍ਰਾਕ੍ਰਿਤਿਕ ਹੁੰਦੀ ਹੈ: ਪੈਕੇਜ, ਸੇਵਾ, ਐਪ, ਜਾਂ ਮੋਡੀਊਲ। ਇੱਕ ਹੋਕ git diff --cached --name-only ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਫਿਰ ਉਹਨਾਂ ਪਾਥਾਂ ਨੂੰ ਛੋਟੇ-ਸੈੱਟ ਟੈਸਟ ਕਮਾਂਡਾਂ ਨਾਲ ਮੈਪ ਕਰ ਸਕਦਾ ਹੈ।
ਕੁਝ ਮੈਪਿੰਗ ਨਿਯਮ ਜੋ ਬਾਦ ਵਿੱਚ ਸਮਝਣਯੋਗ ਰਹਿੰਦੇ ਹਨ:
web/ ਜਾਂ frontend/ -> npm test (ਜਾਂ ਤੁਸੀਂ ਜਿਸ ਸਭ ਤੋਂ ਨਿੱਕੀ ਟਾਰਗੇਟ ਕਮਾਂਡ ਹੋ ਉਹ)api/ ਜਾਂ server/ -> ਬੈਕਐਂਡ ਯੂਨਿਟ ਟੈਸਟ (ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਡਿਫਾਲਟ ਨਾਲ ਸਕਿਪ)mobile/ -> ਤੇਜ਼ widget/unit ਟੈਸਟ, ਨਹੀਂ ਪੂਰੇ ਡਿਵਾਈਸ ਸੁਟdb/ ਜਾਂ migrations/ -> ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਿੰਟਿੰਗ + ਛੋਟਾ ਸਕੀਮਾ ਚੈਕshared/ -> ਸ਼ੇਅਰਡ ਪੈਕੇਜ ਟੈਸਟ ਅਤੇ ਜੇ ਤੇਜ਼ ਉਪਭੋਗਤਾ ਹਨ ਉਹਨਾਂ ਨੂੰ ਵੀਜੇ ਤੁਸੀਂ Claude Code git hooks ਵਰਤਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਹੌਣ ਤੱਕ ਜਾ ਸਕਦੇ ਹੋ: Claude ਸਟੇਜਡ ਫਾਇਲ ਨਾਂਵਾਂ ਵੇਖ ਕੇ ਨਿਯੂਨਤਮ ਟੈਸਟ ਸੈੱਟ ਸੁਝਾ ਸਕਦਾ ਹੈ, ਫਿਰ ਹੋਕ ਉਹ ਕਮਾਂਡ ਚਲਾਏ। ਅੰਤਿਮ ਫੈਸਲਾ ਫਿਰ ਵੀ ਨਿਯਮ-ਚਲਿਤ ਰੱਖੋ, ਤਾਂ ਜੋ ਟੀਮ ਅਗਲਾ ਕੀ ਹੋਵੇ ਅਨੁਮਾਨ ਲਗਾ ਸਕੇ।
ਕੰਮ ਨੂੰ commit ਅਤੇ push ਵਿੱਚ ਵੰਡੋ। ਕਮਿਟ ਤੇਜ਼ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਲੋਕ ਹੋਕਸ ਨੂੰ ਬਾਈਪ ਨਾ ਕਰਨ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ:
ਫਲੇਕੀ ਅਤੇ ਧੀਮੇ ਟੈਸਟਾਂ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਨੀਤੀ ਲੋੜੀਂਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਤੁਹਾਡਾ ਹੋਕ ਸ਼ੋਰ ਬਣ ਜਾਵੇਗਾ। ਟੀਮ ਨਾਲ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਕਮਿਟ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਕੀ ਸਿਰਫ਼ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਕਾਰਗਰ ਰਵੱਈਆ ਇਹ ਹੈ ਕਿ ਸਪਸ਼ਟ ਫੇਲਾਂ (ਫਾਰਮੈਟਿੰਗ, ਆਮ ਤੌਰ 'ਤੇ ਸਥਿਰ ਯੂਨਿਟ ਟੈਸਟ) ਤੇ ਰੋਕੋ, ਜਾਣੇ-ਪਹਚਾਣੇ ਫਲੇਕੀ ਟੈਸਟਾਂ 'ਤੇ ਚੇਤਾਵਨੀ ਦਿਓ, ਅਤੇ ਧੀਮੇ ਸੂਟਾਂ ਨੂੰ push/CI 'ਤੇ ਰੱਖੋ। ਜੇ ਕੋਈ ਟੈਸਟ ਫਲੇਕੀ ਹੈ ਤਾਂ ਉਸਨੂੰ ਬੱਗ ਵਜੋਂ ਸੋਝੋ: ਟਰੈਕ ਕਰੋ, ਠੀਕ ਕਰੋ, ਅਤੇ ਜਿਵੇਂ ਹੀ ਸਥਿਰ ਹੋਵੇ warning mode ਹਟਾਓ।
ਚੰਗਾ ਡਿਫ ਹਮੇਸ਼ਾ ਆਸਾਨੀ ਨਾਲ ਸਮੀਖਿਆਯੋਗ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਛੋਟਾ ਕਮਿਟ-ਟਾਈਮ ਸੰਖੇਪ 10 ਮਿੰਟ ਦੀ ਪੜ੍ਹਾਈ ਨੂੰ 2 ਮਿੰਟ ਦੀ ਜਾਂਚ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਬਦਲਾਵ ਕਈ ਫਾਈਲਾਂ ਨੂੰ ਛੁਹਦੇ ਹਨ ਜਾਂ ਰੀਫੈਕਟਰ ਸ਼ਾਮਲ ਹੋ।
ਵिचਾਰ ਸਿੱਧਾ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ git commit ਚਲਾਉਂਦੇ ਹੋ, ਤੁਹਾਡਾ ਹੋਕ Claude Code ਨੂੰ ਸਟੇਜਡ ਡਿਫ ਪੜ੍ਹਣ ਲਈ ਪੁੱਛਦਾ ਹੈ ਅਤੇ 3–6 ਲਾਈਨਾਂ ਦਾ ਨੋਟ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਸਮੀਖਿਆਕਾਰਾਂ ਨੇ ਹਮੇਸ਼ਾ ਪੁੱਛਦੇ ਹਨ: ਕੀ ਬਦਲਿਆ, ਕਿਉਂ ਬਦਲਿਆ, ਰਿਸਕ ਕਿੱਥੇ ਹਨ, ਅਤੇ ਕੀ ਚਲਾਇਆ ਗਿਆ।
ਆਉਟਪੁੱਟ ਨੂੰ ਤੰਗ ਅਤੇ ਲਗਾਤਾਰ ਰੱਖੋ ਤਾਂ ਜੋ ਸਮੀਖਿਆਕਾਰ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਲੱਗਣ:
ਤੁਸੀਂ ਇਹ ਸਿੱਧੇ ਕਮਿਟ ਸੁਨੇਹੇ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਛੋਟਾ ਫੁੱਟਰ ਵਜੋਂ), ਜਾਂ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਸੇਵ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਟੀਮ PR ਵਰਣਨ ਵਿੱਚ ਨਕਲ ਕਰਦੀ ਹੈ। ਕਮਿਟ ਸੁਨੇਹਾ ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸੰਦਰਭ ਨਾਲ ਬਦਲਾਅ ਆਪਣੇ ਨਾਲ ਘੁੰਮੇ। ਵੱਖਰੀ ਫਾਈਲ ਉਸ ਸਮੇਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਟੀਮ ਨੂੰ ਸਾਫ਼, ਸੌਂਚੀ-ਵਿਧੀ ਕਮਿਟ ਵਿਸ਼ਿਆਂ ਪਸੰਦ ਹੋ।
ਇਕ ਸੰਖੇਪ ਟੂਲ ਨੂੰ ਸਮੀਖਿਆਕਾਰ ਨਾਲੋਂ ਸਖ਼ਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਡਿਫ ਸਮੱਗਰੀ ਨੂੰ ਮਾਡਲ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰੋ ਜੋ API ਕੀਜ਼, ਨਿੱਜੀ ਕੀ, ਟੋਕਨ, .env ਮੁੱਲ, ਅਤੇ ਪ੍ਰਮਾਣ-ਸੰਬੰਧੀ ਲਾਈਨਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ। ਜੇ ਹੋਕ ਸੰਵੇਦਨਸ਼ੀਲ ਪੈਟਰਨ ਪਾਓਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਲਾਈਨਾਂ ਨੂੰ ਰੈਡੈਕਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ "credentials-related changes redacted" ਵਰਗਾ ਸਾਰ fallback ਦੇ ਸਕਦਾ ਹੈ।
ਉਦਾਹਰਣ: ਤੁਸੀਂ ਬਿਲਿੰਗ ਐਂਡਪੌਇੰਟ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ ਅਤੇ ਤਿੰਨ ਫਾਈਲਾਂ ਛੁਹਦੀਆਂ ਹਨ। ਸਟੇਜਡ ਡਿਫ ਰੇਨਾਮਾਂ ਕਾਰਨ ਸ਼ੋਰ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਸੰਖੇਪ ਕਹਿੰਦਾ ਹੈ: “Adds idempotency key handling for charge creation to prevent double billing. Reason: retries caused duplicate charges. Risk: medium (payment path). Testing: unit tests for billing service, manual request replay.” ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਗੱਲ ਹੈ ਜੋ ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਚਾਹੀਦੀ ਹੈ, ਬਿਨਾਂ ਹਰ ਲਾਈਨ ਪੜ੍ਹੇ।
ਤੁਸੀਂ ਇਕ ਛੋਟੀ ਬੱਗ ਠੀਕ ਕਰਦੇ ਹੋ ਅਤੇ ਉਸੇ ਕਮਿਟ ਵਿੱਚ ਇੱਕ ਕਾਨਫਿਗ ਠੀਕ ਕਰਦੇ ਹੋ। ਬੱਗ billing/tax.go ਵਿੱਚ ਇੱਕ-ਲਾਈਨ ਬਦਲਾਅ ਹੈ। ਕਾਨਫਿਗ config/staging.yaml ਵਿੱਚ ਇੱਕ ਨਵੇਂ ਐਂਡਪੌਇੰਟ ਵੱਲ ਹਵਾਲਾ ਬਦਲਦਾ ਹੈ।
ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ git commit -am "Fix tax rounding"। ਤੁਹਾਡੇ Claude Code git hooks ਤੁਰੰਤ ਕੁਝ ਤੇਜ਼ ਚੇਕਸ ਕਰਦੇ ਹਨ, ਇੱਕ ਪੂਰਬ-ਨਿਰਧਾਰਤ ਕ੍ਰਮ ਵਿੱਚ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਗੁਪਤ ਸਕੈਨ ਤੁਹਾਡੇ ਬਦਲਾਅ ਨੂੰ ਵੇਖਦਾ ਹੈ, ਪੂਰੇ ਰੇਪੋ ਨੂੰ ਨਹੀਂ। ਇਹ ਫਲੈਗ ਕਰਦਾ ਹੈ ਕਿ ਸਟੇਜਡ ਕਾਨਫਿਗ ਵਿੱਚ ਕੁਝ ਅਜਿਹਾ ਹੈ ਜੋ ਅਸਲੀ API ਕੀ ਵਰਗਾ ਲੱਗਦਾ ਹੈ।
ERROR: Possible secret detected in config/staging.yaml:12
Pattern: api_key=sk_live_...
Fix: remove the key and use an env var reference (e.g., API_KEY)
Override: set ALLOW_SECRETS=1 (not recommended)
ਤੁਸੀਂ ਮੁੱਲ ਨੂੰ env var ਰੈਫਰੈਂਸ ਨਾਲ ਬਦਲ ਦਿੰਦੇ ਹੋ, ਫਿਰ ਫੇਰ ਕਮਿਟ ਕਰਦੇ ਹੋ।
ਅਗਲੇ, ਫਾਰਮੈਟਿੰਗ ਸਿਰਫ਼ ਜਿੱਥੇ ਲੋੜ ਸੀ ਉੱਥੇ ਚਲਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ Go ਫਾਈਲ ਫਾਰਮੈਟ ਨਹੀਂ ਸੀ, ਤਾਂ ਇਹ “run gofmt on billing/tax.go” ਵਰਗਾ ਸਪਸ਼ਟ ਹਿੰਟ ਦੇ ਕੇ ਫੇਲ ਕਰੇਗਾ। ਤੁਸੀਂ ਫਾਰਮੈਟਰ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਹੋਕ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ।
ਫਿਰ ਟੈਸਟ ਗੇਟ ਨਿਸ਼ਾਨਦਾਰ ਸੈੱਟ ਚਲਾਉਂਦੀ ਹੈ। ਕਿਉਂਕਿ ਤੁਸੀਂ billing/ ਨੂੰ ਛੂਹਿਆ, ਇਹ ਸਿਰਫ਼ billing ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਂਦਾ (ਪੂਰਾ ਸੂਟ ਨਹੀਂ)। ਜੇ ਕੋਈ ਟੈਸਟ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਹੋਕ ਸਹੀ ਕਮਾਂਡ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਲੋਕਲ ਦੁਬਾਰਾ-ਉਤਪੀੜਨ ਲਈ ਚਲਾਈ ਜਾ ਸਕੇ। ਤੁਸੀਂ ਰਾਊਂਡਿੰਗ ਇਸ਼ੂ ਠੀਕ ਕਰਦੇ ਹੋ ਅਤੇ ਇੱਕੋ ਹੀ ਟੈਸਟ ਫਿਰ ਤੋਂ ਚਲਾਉਂਦੇ ਹੋ।
ਅਖੀਰਕਾਰ, ਹੋਕ ਡਿਫ ਤੋਂ ਇੱਕ ਰਿਵਿਊਰ ਸੰਖੇਪ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਛੋਟਾ ਤੇ ਵਿਸ਼ੇਸ਼ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ:
ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਜੋ ਕੁਝ ਦਿਖਦਾ ਹੈ ਉਹ ਇੱਕ ਸਾਫ਼ ਕਮਿਟ ਹੁੰਦਾ ਹੈ: ਕੋਈ ਲੀਕ ਕੀ ਨਹੀਂ, ਇਕਸਾਰ ਫਾਰਮੈਟਿੰਗ, ਅਤੇ ਬਦਲਾਅ ਨਾਲ ਮੇਲ ਖਾਤੇ ਟੈਸਟ। ਉਹਨਾਂ ਕੋਲ ਤਿਆਰ-ਕੀਤਾ ਹੋਇਆ ਸੰਖੇਪ ਵੀ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਲਾਜ਼ਮੀ ਲਾਜਿਕ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਮਨ-ਹਟਾ ਖੋਜ 'ਤੇ।
ਹੋਕਸ ਨੂੰ ਦਰਦਨਾਕ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹੈ ਉਹਨਾਂ ਨੂੰ ਦਖ਼ਲ-ਅੰਜਾਮੀ ਬਣਾਉਣਾ। ਜੇ ਹੋਕ ਕਿਸੇ ਦਾ ਵਹੀਲਾ ਤੋੜਨ ਵਾਲਾ ਸਮਾਂ ਲੈ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲੋਕ ਉਹਨੂੰ --no-verify ਨਾਲ ਬਾਈਪ ਕਰ ਦੇਂਦੇ ਹਨ ਜਾਂ ਮਿਟਾ ਦਿੰਦੇ ਹਨ। pre-commit ਵਿੱਚ ਕੋਈ ਵੀ ਭਾਰੀ ਚੀਜ਼ ਰੱਖੋ ਨਾ; ਉਸਨੂੰ CI ਜਾਂ ਮੰਗ 'ਤੇ ਚਲਾਓ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: pre-commit ਨੂੰ ਇੱਕ ਟਾਈਪ-ਚੈੱਕ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨ ਕਿ ਇੱਕ ਟੈਸਟ ਸੂਟ। ਜੇ ਤੁਸੀਂ Claude Code git hooks ਤੋਂ ਸਮਝਦਾਰ ਚੇਕਸ ਚਾਹੁੰਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਇਹ ਚੁਣਨ ਲਈ ਵਰਤੋ ਕਿ ਕੀ ਚਲਾਉਣਾ ਹੈ, ਨਾ ਕਿ ਸਭ ਕੁਝ ਚਲਾਉਣਾ।
ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਹੋਕਸ ਤੇਜ਼ ਰੱਖੋ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਹੀ ਸਖ਼ਤ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ, ਹਰ ਕਮਿਟ ਤੇ ਛੇਤੀ ਫਾਰਮੈਟ + ਗੁਪਤ ਸਕੈਨ ਚਲਾਓ, ਪਰ ਟੈਸਟਸ ਸਿਰਫ਼ ਪ੍ਰਭਾਵਿਤ ਮੋਡੀਊਲਾਂ ਲਈ ਚਲਾਓ।
ਇੱਕ ਸਧਾਰਣ ਗਤੀ ਬਜਟ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:
pre-commit: ਕੁੱਲ 1 ਤੋਂ 5 ਸਕਿੰਟcommit-msg: 1 ਸਕਿੰਡ ਤੋਂ ਘੱਟAI ਸੁਝਾਅਾਂ ਲਈ ਵਧੀਆ ਹੈ, ਨੀਤੀ ਲਈ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ "ਡਿਫ ਰਿਵਿਊ ਕਰੋ" ਬਿਨਾਂ ਨਿਯਮ ਦੇਂਦੇ ਹੋ, ਤਾਂ ਹਰ ਵਾਰੀ ਵੱਖਰਾ ਨਤੀਜਾ ਮਿਲੇਗਾ। ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਹੋਕ ਨੂੰ ਕੀ ਕਰਨਾ ਹੈ (ਅਤੇ ਕੀ ਕਦੇ ਨਹੀਂ ਕਰਨਾ)। ਉਦਾਹਰਨ: ਇਹ ਰਿਵਿਊਰ ਸੰਖੇਪ ਜਣਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੋਡ ਨੂੰ ਮੁੜ-ਲਿਖ ਨਹੀਂ ਸਕਦਾ ਜਰੋਂ ਤੱਕ ਫਾਰਮੈਟਰ ਪਹਿਲਾਂ deterministic ਬਦਲਾਵ ਨ ਕੀਤਾ ਹੋਵੇ।
ਕਈ ਹੋਕ ਗਲਤੀ ਨਾਲ ਤੁਹਾਡੀ ਵਰਕਿੰਗ ਟ੍ਰੀ ਨੂੰ ਸਕੈਨ ਕਰ ਲੈਂਦੇ ਹਨ, ਫਿਰ ਤੁਹਾਡਾ ਕਮਿਟ ਫੇਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸਭ ਕੁਝ ਸਟੇਜ ਨਹੀਂ ਕੀਤਾ। ਇਹ ਨਿਰਿਆਇਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਇਸ ਤੋਂ ਬਚਣ ਲਈ ਸਦਾ ਸਟੇਜਡ ਸਮੱਗਰੀ ਨੂੰ ਇਨਪੁੱਟ ਵਜੋਂ ਵਰਤੋ। ਇੱਕ ਵਧੀਆ ਟੈਸਟ: ਇੱਕ ਫਾਈਲ ਸੋਧੋ, ਅੱਧੀ ਸਟੇਜ ਕਰੋ, ਅਤੇ ਵੇਰੋ ਕਿ ਹੋਕ ਸਿਰਫ਼ ਸਟੇਜਡ ਚੀਜ਼ ਦਿਖਾਉਂਦਾ ਹੈ।
ਜੇ ਹਰ ਕਮਿਟ 'ਤੇ ਚੇਤਾਵਨੀ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਚੇਤਾਵਨੀਆਂ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਪੈਟਰਨਜ਼ ਨੂੰ ਟਿਊਨ ਕਰੋ, ਫਿਕਸਚਰ ਪਾਥ ਲਈ allowlists ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ "ਸ਼ਾਇਦ" ਮਿਲਣ ਵਾਲੀਆਂ ਨਤੀਜਿਆਂ ਨੂੰ ਚੇਤਾਵਨੀ ਵਿੱਚ ਘਟਾਓ।
ਠੋਸ ਉਦਾਹਰਣ: ਜੇ ਤੁਹਾਡਾ ਗੁਪਤ ਸਕੈਨਰ fixtures/ ਵਿੱਚ ਟੈਸਟ ਕੀਜ਼ ਨੂੰ ਫਲੈਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸ ਫੋਲ਼ਡਰ ਨੂੰ ਛੂੜੋ, ਪਰ ਅਪਲੀਕੇਸ਼ਨ ਕਾਨਫਿਗ ਫਾਈਲਾਂ ਵਿੱਚ ਅਸਲ ਕੀਜ਼ ਨੂੰ ਅਜੇ ਵੀ ਰੋਕੋ।
ਜੇ ਤੁਸੀਂ Claude Code git hooks ਨੂੰ ਟੀਮ ਨੂੰ ਪਰੇਸ਼ਾਨ ਕੀਤੇ ਬਿਨਾਂ ਮਦਦ ਕਰਵਾਉਣ ਲਈ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਲਕਸ਼ ਸਾਦਾ ਹੈ: ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਫੜੋ, ਸਭ ਕੁਝ ਨਾਰਮਲ ਹੋਣ 'ਤੇ ਚੁੱਪ ਰਹੋ, ਅਤੇ ਕਮਿਟ ਲੂਪ ਨੂੰ ਤੇਜ਼ ਰੱਖੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਚੈੱਕਲਿਸਟ ਜੋ ਜ਼ਿਆਦਾਤਰ ਰੇਪੋਜ਼ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ:
ਇੱਕ ਛੋਟੀ ਵਿਸ਼ੇਸ਼ ਗੱਲ ਜੋ ਲਾਭ ਦਿੰਦੀ ਹੈ: ਰਿਵਿਊਰ ਸੰਖੇਪ ਹਰ ਵਾਰੀ ਇੱਕੋ ਜਿਹਾ ਲੱਗੇ। ਇਕ ਸਧਾਰਣ ਟੈਮਪਲੇਟ ਕਾਫੀ ਹੈ, ਅਤੇ ਇਸ ਨਾਲ ਸਮੀਖਿਆਕਾਰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨਾ ਸਿੱਖ ਜਾਂਦੇ ਹਨ।
Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>
ਅੱਗੇ ਕਰਨ ਵਾਲੇ ਕਦਮ ਜੋ ਇਸਨੂੰ ਅਸਾਨੀ ਨਾਲ ਅਪਨਾਉਣ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਚੈਟ-ਪਹਿਲੇ ਤਰੀਕੇ ਨਾਲ ਟੂਲਿੰਗ ਬਣਾਉਣ ਵਿੱਚ ਰੁਚੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਛੋਟੇ ਹੈਲਪਰ ਸਕ੍ਰਿਪਟ ਬਣਾਉਣ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇਟਰੇਟ ਕਰਨ ਲਈ ਸਹਾਇਕ ਹੋ ਸਕਦਾ ਹੈ, ਫਿਰ ਤੁਸੀਂ ਸਰੋਤ ਕੋਡ ਨੂੰ ਆਪਣੇ ਰੇਪੋ ਵਿੱਚ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ।
ਉਹ ਆਮ ਮੁੱਦੇ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸਮੀਖਿਆ ਦਾ ਸਮਾਂ ਨੱਸ ਹੁੰਦਾ ਹੈ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਜੋ ਕੁਝ ਵੀ ਧੀਰਾ ਹੈ (ਪੂਰਾ ਟੈਸਟ ਸੂਟ, ਡੀਪ ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ) ਉਸਨੂੰ pre-push ਜਾਂ CI ਲਈ ਰੱਖੋ।
ਇੱਕ ਚੰਗਾ ਡিফਾਲਟ:
pre-commit ਤੇ ਤੇਜ਼ ਚੈਕ ਜੋ ਸਟੇਜਡ ਬਦਲਾਵਾਂ ਨੂੰ ਦੇਖਦੇ ਹਨ (ਗੁਪਤ, ਫਾਰਮੈਟਿੰਗ, ਛੇਤੀ ਲਿੰਟ, ਨਿਰਧਾਰਿਤ ਯੂਨਿਟ ਟੈਸਟ)commit-msg ਲਈ ਕਮਿਟ ਸੁਨੇਹੇ ਨਿਯਮ (ਲੰਬਾਈ, ਫਾਰਮੈਟ, ਟਿਕਟ ID)pre-push ਲਈ ਧੀਮੀ ਪਰ ਅਜੇ ਵੀ ਲੋਕਲ ਚੈਕ (ਵਿਆਪਕ ਟੈਸਟ, ਬਿਲਡ)ਜੇ ਕੋਈ ਚੈਕ ਸਰਾਹਣਯੋਗ ਤੌਰ 'ਤੇ ਕੁਝ ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਲੈਂਦਾ ਹੈ, ਉਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਲਿਜਾਓ।
ਕਮਿਟ-ਸਮੇਂ ਹੋਕਸ ਨੂੰ ਗਾਰਡਰੇਲ ਸਮਝੋ, ਇਕਮਾਤਰ ਨਿਰਭਰ ਕਾਨੂੰਨ ਨਹੀਂ।
ਵਾਸਤਵਿਕ ਨੀਤੀ: ਹੋਕਸ ਵਿਕਾਸਕਾਰਾਂ ਦੀ ਮਦਦ ਕਰਦੇ ਹਨ; CI ਮੁੱਖ ਸ਼ਾਖ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ।
ਸਟੇਜਡ ਡਿਫ (index) ਨੂੰ ਸਕੈਨ ਕਰੋ, ਪੂਰੇ ਰੇਪੋ ਨੂੰ ਨਹੀਂ.
ਜੇ ਤੁਹਾਨੂੰ ਪੂਰੇ ਰੇਪੋ ਸਕੈਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸ਼ੈਡਿਊਲ 'ਤੇ ਜਾਂ CI ਵਿੱਚ ਚਲਾਓ।
ਜਦੋਂ ਮੇਚ ਉੱਚ-ਭਰੋਸੇਯੋਗ ਹੋਵੇ (ਅਸਲੀ ਕੀ ਫਾਰਮੈਟ, ਨਿੱਜੀ ਕੀ ਬਲੋਕ, ਸਪਸ਼ਟ password= ਕਨਫਿਗ), ਤਦ ਬਲੌਕ ਕਰੋ। ਸੰਦੇਹਾਸਪਦ ਹਾਲਤਾਂ 'ਚ ਚੇਤਾਵਨੀ ਦਿਓ।
ਨਾਲ ਹੀ ਘੱਟ-ਪੱਧਰੀ.allowlist ਬਣਾਓ ਜੋ ਵਿਸ਼ੇਸ਼ ਸੁਰੱਖਿਅਤ ਕੇਸਾਂ ਲਈ ਹੋਵੇ, ਉਦਾਹਰਨ ਲਈ:
DUMMY_KEY)ਜੇ ਲਗਾਤਾਰ ਜਨਰੇਟ ਹੋਣ ਵਾਲੀਆਂ ਚੇਤਾਵਨੀਆਂ ਹਨ, ਲੋਕ ਹੋਕ ਡਿਸੇਬਲ ਕਰ ਦੇਣਗੇ।
ਸਿਰਫ਼ ਸਟੇਜਡ ਫਾਈਲਾਂ ਨੂੰ ਫਾਰਮੈਟ ਕਰੋ, ਅਤੇ ਹਰ ਭਾਸ਼ਾ ਲਈ ਇੱਕ ਫਾਰਮੈਟਰ ਚੁਣੋ.
ਕੁਝ ਪ੍ਰਯੋਗਿਕ ਡਿਫਾਲਟ:
ਇਸ ਨਾਲ ਡਿਫ ਸਾਫ਼ ਰਹਿੰਦੇ ਹਨ ਬਿਨਾਂ ਹਰ ਕਮਿਟ ਨੂੰ ਲੰਮਾ ਬਣਾਏ।
ਚੁੱਕੀ ਹੋਈਆਂ ਪਾਥਾਂ ਨੂੰ ਨਕਸ਼ੇ ਵਿੱਚ ਲਿਆਓ ਅਤੇ ਸਿਰਫ਼ ਉਹ ਟੈਸਟ ਚਲਾਓ ਜੋ ਤੇਜ਼ ਅਤੇ ਨਿਸ਼ਾਨਦਾਰ ਹਨ.
ਉਦਾਹਰਣੀ ਵਿਧੀ:
git diff --cached --name-only ਦੇਖੋ ਤੱਕ ਬਦਲੇ ਹੋਏ ਖੇਤਰ ਡਿਟੈਕਟ ਕਰਨ ਲਈpre-push ਜਾਂ CI ਲਈ ਰੱਖੋਇਸ ਨਾਲ ਕਮਿਟ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਆਉਣ ਵਾਲੀਆਂ ਤੋਟੀਆਂ ਫੜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਛੋਟਾ ਅਤੇ ਲਗਾਤਾਰ ਰੱਖੋ (3–6 ਲਾਈਨਾਂ)। ਇੱਕ ਸਧਾਰਣ ਟੈਮਪਲੇਟ:
ਤੁਸੀਂ ਇਸਨੂੰ ਕਮਿਟ ਸੁਨੇਹੇ ਵਿੱਚ ਫੁੱਟਰ ਵਜੋਂ ਪਾ ਸਕਦੇ ਹੋ ਜਾਂ ਇੱਕ ਵੱਖਰਾ ਟੈਕਸਟ ਫਾਈਲ ਸੰਭਾਲ ਸਕਦੇ ਹੋ ਜੋ PR ਵਰਣਨ ਲਈ ਵਰਤੀ ਜਾਵੇ।
ਮਾਡਲ ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਰੈਡੈਕਟ ਕਰੋ, ਅਤੇ ਮਨੁੱਖੀ ਤਰ੍ਹਾਂ ਬਚਤ-ਪਹਚਾਣ ਰੱਖੋ:
.env ਮੁੱਲ, ਨਿੱਜੀ ਕੀ, ਕੂਕੀਜ਼, ਜਾਂ ਓਥਰ ਆਥ ਹੈਡਰ ਮੈਚ ਕਰਦੀਆਂ ਹਨਖਾਸ ਕਰਕੇ ਪ੍ਰਾਇਵੇਟ ਰੇਪੋਜ਼ ਵਿੱਚ “ਵੱਧ ਘੱਟ ਸਾਂਝਾ ਕਰੋ” ਦਾ ਨਿਯਮ ਰੱਖੋ।
ਹੋਕਸ ਨੂੰ ਪੇਸ਼ਗੀ ਅਤੇ ਤੇਜ਼ ਬਣਾਓ:
pre-commit ਲਈ 1–5 ਸੈਕੰਡ)ਜੇ ਹੋਕ ਫਲੇਕੀ ਜਾਂ ਧੀਰਾ ਮਹਿਸੂਸ ਹੋਵੇ ਤਾਂ ਡਿਵੈਲਪਰ --no-verify ਚੁਣ ਲੈਂਦੇ ਹਨ।