A ຮູບແບບສົບຜົນສໍາເລັດຂອງສາຂາໃນ Git

ຮູ້ຈັກວິທີການນໍາໃຊ້ Git ເປັນສິ່ງສໍາຄັນ, ແລະອັນນີ້ລວມເຖິງການຮັກສາການພັດທະນາສະພາບແວດລ້ອມຮ່ວມກັນຊອບແວການຄຸ້ມຄອງ.

ເຄດິດ

Post ນີ້ແມ່ນຕົ້ນສະບັບປອກຕຸຍການ, ໃນ​ພາ​ສາ​ອັງ​ກິດ, “ແບບຢ່າງທີ່ປະສົບຜົນ ສຳ ເລັດຂອງ Git“, ໄດ້ຮັບອະນຸຍາດຢ່າງຖືກຕ້ອງຈາກຜູ້ຂຽນ, Vincent Driessen. ຂອບໃຈຜູ້ຊາຍ!

ດ້ວຍເຫດຜົນດ້ານວິຊາການ, ບາງ ຄຳ ຫລັກຖືກເກັບຮັກສາໄວ້ເປັນພາສາອັງກິດ. ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມຮັບປະກັນຄວາມເປັນມາຂອງຕົວ ໜັງ ສື, ແຕ່ຂ້ອຍສາລະພາບວ່າຂ້ອຍຕ້ອງໄດ້ປັບປ່ຽນເພື່ອ ອຳ ນວຍຄວາມສະດວກໃຫ້ແກ່ຄວາມເຂົ້າໃຈໃນພາສາຂອງພວກເຮົາ (ບໍລິສັດ PT-BR). ການແກ້ໄຂຫລື ຄຳ ແນະ ນຳ ສຳ ລັບການປັບປຸງການແປແມ່ນຍິນດີຕ້ອນຮັບ.

ການນໍາສະເຫນີ

ນີ້ບໍ່ແມ່ນການສອນ Post ກ່ຽວກັບວິທີການໃຊ້ Git. ຖ້ານີ້ແມ່ນສິ່ງທີ່ທ່ານຕ້ອງການ, ຂ້ອຍຂໍແນະ ນຳ ໃຫ້ເບິ່ງ ຄູ່ມືເຮັດ Git. ມັນບໍ່ແມ່ນເປົ້າ ໝາຍ ຂອງພວກເຮົາທີ່ຈະສະແດງວິທີການເຮັດໂປຼແກຼມຮຸ່ນຊອບແວ, ໃນກໍລະນີນີ້, ເບິ່ງ Semantic Versioning.

ນີ້ແມ່ນຂໍ້ສະ ເໜີ ແມ່ນເພື່ອຈັດການຄວາມຮ່ວມມືຂອງທີມໃນການສ້າງແບບຊອບແວ. ຮູ້ເວລາທີ່ທ່ານມີນັກຂຽນໂປແກຼມຫຼາຍຄົນ “ການເຄື່ອນຍ້າຍ” ໃນລະຫັດແຫຼ່ງດຽວກັນ? ສິ່ງນີ້ແມ່ນສິ່ງ ສຳ ຄັນເພື່ອຍູ້ໄວການພັດທະນາ, ແຕ່ມັນສາມາດເຮັດໃຫ້ເກີດການເຈັບຫົວຫຼາຍ (ການສູນເສຍແລະ rework) ຖ້າບໍ່ມີການຄວບຄຸມ. ເພື່ອປ້ອງກັນນັກພັດທະນາຄົນ ໜຶ່ງ ບໍ່ໃຫ້ຂຽນທັບວຽກຂອງຄົນອື່ນແລະຮັບປະກັນການພັດທະນາທີ່ກ້າວ ໜ້າ ແລະມີການຈັດຕັ້ງ, ຫຼຸດຜ່ອນຂໍ້ຂັດແຍ່ງແລະການຄຸ້ມຄອງແບບຊອບແວ, ແມ່ນວ່າພວກເຮົາໃຊ້ Git ແລະ ສາຂາ ປະຕິບັດຕາມ.

ຮູບແບບສາຂາ

ໃນຂໍ້ຄວາມນີ້ຂ້ອຍຂໍ ນຳ ສະ ເໜີ ຮູບແບບການພັດທະນາທີ່ຂ້ອຍເຄີຍໃຊ້ໃນບາງໂຄງການຂອງຂ້ອຍ (ທັງໃນບ່ອນເຮັດວຽກແລະສ່ວນຕົວ) ໃກ້ 1 ປີກ່ອນຫນ້ານີ້, ແລະສິ່ງນັ້ນປະສົບຜົນ ສຳ ເລັດຫຼາຍ. ຂ້ອຍຢາກຂຽນກ່ຽວກັບມັນເປັນເວລາດົນນານ, ແຕ່ຂ້ອຍບໍ່ເຄີຍພົບເວລາທີ່ມີຢູ່, ເຖິງຕອນນັ້ນ. ຂ້ອຍຈະບໍ່ເວົ້າກ່ຽວກັບລາຍລະອຽດຂອງໂຄງການ, ພຽງແຕ່ກ່ຽວກັບຍຸດທະສາດ ສຳ ລັບ ສາຂາ ແລະການຄຸ້ມຄອງ ປ່ອຍຕົວ.

ຮູບແບບປະທັບຕານີ້ສະເພາະບໍ່ໄດ້ Git ເປັນເຄື່ອງມື ສຳ ລັບການ ກຳ ນົດລະຫັດແຫຼ່ງທັງ ໝົດ ຂອງພວກເຮົາ. (ໂດຍທາງ, ຖ້າທ່ານສົນໃຈ Git, ບໍລິສັດຂອງພວກເຮົາ GoPrime ສະຫນອງ, ທີ່ແທ້ຈິງທີ່ໃຊ້ເວລາ, ການວິເຄາະຂໍ້ມູນບາງຢ່າງທີ່ບໍ່ ໜ້າ ເຊື່ອ ສຳ ລັບການເພີ່ມປະສິດທິພາບດ້ານວິສະວະ ກຳ ຊອບແວ)

ເປັນຫຍັງ git?

ສຳ ລັບການສົນທະນາຢ່າງລະອຽດກ່ຽວກັບຂໍ້ດີແລະຂໍ້ເສຍຂອງ Git ເມື່ອທຽບໃສ່ກັບລະບົບຄວບຄຸມແຫຼ່ງຂໍ້ມູນເປັນໃຈກາງ, ເບິ່ງ ເປັນ ເວັບ. ມີຢ່າງຫລວງຫລາຍ “ສົງຄາມ” ປະມານນັ້ນ. ເປັນຜູ້ພັດທະນາ, ຂ້ອຍມັກ Git ຫຼາຍກວ່າເຄື່ອງມືອື່ນໆທັງ ໝົດ ທີ່ມີຢູ່ໃນທຸກມື້ນີ້. Git ໄດ້ປ່ຽນແປງແນ່ນອນວິທີການຂອງນັກພັດທະນາຄິດກ່ຽວກັບການເຮັດ ລວມ ຫຼືສ້າງຫນຶ່ງ ສາຂາ. ຂ້ອຍມາຈາກໂລກເກົ່າແກ່ຂອງ CVS / Subversion, ຢູ່ໃສ ລວມ / ແຕກ ມັນແມ່ນສິ່ງທີ່ເຈົ້າເຮັດພຽງແຕ່ເທື່ອດຽວໃນເວລາດຽວກັນແລະມັນເບິ່ງຄືວ່າ ໜ້າ ຢ້ານເລັກນ້ອຍ (“ລະວັງຄວາມຂັດແຍ້ງດ້ານຜົນປະໂຫຍດ ລວມ, ພວກເຂົາກັດທ່ານ!”).

ດ້ວຍ Git, ການກະ ທຳ ເຫຼົ່ານີ້ [ລວມ / ແຕກ] ແມ່ນງ່າຍດາຍທີ່ສຸດແລະເປັນຕົວແທນ ໜຶ່ງ ໃນພາກສ່ວນຕົ້ນຕໍຂອງວຽກປົກກະຕິຂອງພວກເຮົາ, ເຊື່ອ. ສໍາລັບການຍົກຕົວຢ່າງ, ບໍ່ມີ ປື້ມ CSV / Subversion, ງ່າ e ການໂຮມເຂົ້າກັນ ຖືກປົກຄຸມເປັນຄັ້ງ ທຳ ອິດໃນບົດຕໍ່ໆມາ (ສຳ ລັບຜູ້ ນຳ ໃຊ້ຂັ້ນສູງ), ໃນຂະນະທີ່ຢູ່ໃນໃດໆ ປື້ມກ່ຽວກັບ Git, ນີ້ແມ່ນເຫັນໄດ້ໃນບົດ 3 (ພື້ນຖານ).

ເປັນຜົນມາຈາກຄວາມລຽບງ່າຍແລະລັກສະນະຊໍ້າຊາກຂອງມັນ, ງ່າ e ການໂຮມເຂົ້າກັນ ບໍ່ແມ່ນສິ່ງທີ່ຢ້ານກົວອີກຕໍ່ໄປ. ໃນ​ຄວາມ​ເປັນ​ຈິງ, ເຄື່ອງມືຄວບຄຸມເວີຊັນຄວນຊ່ວຍໃນການສ້າງລວມ ແລະສ້າງ ສາຂາ ຫຼາຍກ່ວາສິ່ງອື່ນ.

ການສົນທະນາພຽງພໍ, ໃຫ້ໄປສູ່ຮູບແບບການພັດທະນາ. ຮູບແບບທີ່ຂ້ອຍຈະ ນຳ ສະ ເໜີ ໃນນີ້ແມ່ນບໍ່ມີຫຍັງ ສຳ ຄັນນອກ ເໜືອ ຈາກຂັ້ນຕອນທີ່ ກຳ ນົດໄວ້ເຊິ່ງສະມາຊິກແຕ່ລະທີມຕ້ອງປະຕິບັດຕາມເພື່ອຈະມາເຖິງຂັ້ນຕອນການພັດທະນາຊອບແວ.

ແບ່ງຂັ້ນຄຸ້ມຄອງ, ແຕ່ເປັນໃຈກາງ

ການຕັ້ງຄ່າຂອງຫໍໄຕທີ່ພວກເຮົາໃຊ້ແລະເຮັດວຽກໄດ້ດີກັບຮູບແບບຂອງ ງ່າ ປະກອບດ້ວຍຫໍໄຕກາງ. ໃຫ້ສັງເກດວ່າຫໍສະມຸດແຫ່ງນີ້ເທົ່ານັ້ນ “ປະຕິບັດເປັນ” ໃຈກາງ (ເພາະວ່າ Git ແມ່ນ DVCS [ລະບົບຄວບຄຸມເວີຊັນແຈກຢາຍ], ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ບໍ່ມີຫຍັງຄືກັບຫໍໄຕກາງໃນລະດັບເຕັກນິກ). ພວກເຮົາຈະອ້າງອີງໃສ່ຫໍໄຕນີ້ ຕົ້ນກໍາເນີດ, ເນື່ອງຈາກຊື່ນີ້ຄຸ້ນເຄີຍກັບຜູ້ໃຊ້ Git ທັງ ໝົດ.

ນັກພັດທະນາແຕ່ລະຄົນເຮັດ ດຶງ e ຍູ້ ເຖິງ ຕົ້ນກໍາເນີດ. ແຕ່ນອກ ເໜືອ ຈາກຄວາມ ສຳ ພັນ push-pull ສຳ ລັບສູນກາງ [ຕົ້ນກໍາເນີດ], ນັກພັດທະນາແຕ່ລະຄົນກໍ່ສາມາດເລືອກເອົາໄດ້ [ດຶງ] ການປ່ຽນແປງຈາກຄູ່ອື່ນໆເພື່ອເປັນ subteams. ສໍາລັບການຍົກຕົວຢ່າງ, ນີ້ສາມາດເປັນປະໂຫຍດ ສຳ ລັບການເຮັດວຽກຮ່ວມກັນກັບສອງຫຼືຫຼາຍກວ່ານັກພັດທະນາກ່ຽວກັບຄຸນລັກສະນະ ໃໝ່ ທີ່ດີ, ກ່ອນ ໜ້າ ນີ້ສົ່ງ [ການຊຸກຍູ້] ເຮັດວຽກຢູ່ໃນຄວາມຄືບຫນ້າສໍາລັບການ ຕົ້ນກໍາເນີດ. ໃນຮູບຂ້າງເທິງ, ມີ subteams Alice ແລະ Bob ແມ່ນ, Alice e David, e Clair ແລະ David.

ດ້ານວິຊາການ, ນີ້ຫມາຍຄວາມວ່າບໍ່ມີຫຍັງນອກເຫນືອຈາກ Alice ໄດ້ກໍານົດ Git ຫ່າງໄກສອກຫຼີກທີ່ເອີ້ນວ່າ Bob, ຊີ້ໄປທີ່ຫໍໄຕຂອງ Bob, ແລະໃນທາງກັບກັນ.

ສາຂາຕົ້ນຕໍ

ໃນຄວາມເປັນມາ, ຮູບແບບການພັດທະນານີ້ແມ່ນໄດ້ຮັບແຮງບັນດານໃຈຈາກຕົວແບບທີ່ມີຢູ່ແລ້ວ. ຫໍພັກສູນກາງມີສອງສາຂາ [ສາຂາ] ອໍານວຍການທີ່ມີຊີວິດອັນເປັນນິດ:

  • ຕົ້ນສະບັບ
  • ພັດທະນາ

ໄດ້ ສາຂາສາຂາ ໃນ ຕົ້ນກໍາເນີດ ຄວນຈະຄຸ້ນເຄີຍກັບຜູ້ໃຊ້ Git ທຸກຄົນ. ຂະຫນານກັບ ສາຂາສາຂາ, ມີອີກ ສາຂາ ເອີ້ນວ່າ ພັດທະນາ.

ພວກເຮົາພິຈາລະນາ ຕົ້ນສະບັບ / ຕົ້ນສະບັບ ເປັນສາຂາຫຼັກທີ່ລະຫັດແຫຼ່ງຂອງ ຫົວ ໜ້າ ສະທ້ອນໃຫ້ເຫັນລັດສະເຫມີ ການຜະລິດພ້ອມແລ້ວ [ກຽມພ້ອມ ສຳ ລັບການຜະລິດ].

ພວກເຮົາພິຈາລະນາ ຕົ້ນ ກຳ ເນີດ / ພັດທະນາ ເປັນ ສາຂາ ຕົ້ນຕໍບ່ອນທີ່ລະຫັດແຫຼ່ງຂອງ ຫົວ ໜ້າ ສະເຫມີໄປສະທ້ອນໃຫ້ເຫັນລັດທີ່ມີການປ່ຽນແປງການພັດທະນາລ້າສຸດທີ່ຈະສົ່ງໃນສະບັບຕໍ່ໄປ. ບາງຄົນກໍ່ຈະເອີ້ນແບບນີ້ “ສາຂາ ຂອງການເຊື່ອມໂຍງ”. ນີ້ແມ່ນບ່ອນທີ່ການກໍ່ສ້າງທີ່ໂຫດຮ້າຍທີ່ສຸດເກີດຂື້ນ.

ເມື່ອລະຫັດແຫຼ່ງຂໍ້ມູນເຂົ້າ ສາຂາ ໄປຮອດຈຸດທີ່ ໝັ້ນ ຄົງແລະພ້ອມທີ່ຈະເປີດຕົວ [ປ່ອຍອອກມາ], ທຸກໆການປ່ຽນແປງຕ້ອງຖືກລວມເຂົ້າກັນ [ລວມເຂົ້າກັນ] ກັບຄືນໄປບ່ອນ ສາຂາສາຂາ ແລະຈາກນັ້ນ ໝາຍ ເລກ ໝາຍ ເລກຮຸ່ນ [ປ່ອຍ]. ວິທີການນີ້ເຮັດໄດ້ລະອຽດ, ຈະໄດ້ຮັບການປຶກສາຫາລືໃນພາຍຫລັງ.

ເພາະສະນັ້ນຈຶ່ງ, ແຕ່ລະຄັ້ງການປ່ຽນແປງແມ່ນລວມເຂົ້າກັນ [ລວມເຂົ້າກັນ] ກັບ​ໄປ ຕົ້ນສະບັບ, ຮຸ່ນ ໃໝ່ ຈະຖືກສ້າງຂື້ນ [ປ່ອຍອອກມາ], ໂດຍຄໍານິຍາມ. ພວກເຮົາພະຍາຍາມຢ່າງເຂັ້ມງວດກ່ຽວກັບເລື່ອງນີ້, ຫຼັງຈາກນັ້ນ, ທາງທິດສະດີ, ພວກເຮົາສາມາດໃຊ້ສະຄິບໄດ້ hook ຈາກ Git ເພື່ອສ້າງແລະອັບໂຫລດແອັບພລິເຄຊັນຂອງພວກເຮົາໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍການຜະລິດທຸກຄັ້ງໂດຍອັດຕະໂນມັດ ຄໍາຫມັ້ນສັນຍາ ບໍ່ມີ ຕົ້ນສະບັບ.

ສາຂາຊ່ວຍ

ນອກຈາກ ສາຂາ ຕົ້ນຕໍ, ຕົ້ນສະບັບ e ພັດທະນາ, ຮູບແບບການພັດທະນາຂອງພວກເຮົາໃຊ້ຫລາກຫລາຍ ສາຂາ ສະ ໜັບ ສະ ໜູນ ການຊ່ວຍເຫຼືອການພັດທະນາພ້ອມກັນລະຫວ່າງສະມາຊິກໃນທີມ, ແມ່ນ​ຫຍັງ 1) ອໍານວຍຄວາມສະດວກໃນການຕິດຕາມຄຸນລັກສະນະ ໃໝ່ [ຄຸນ​ລັກ​ສະ​ນະ], 2) ກຽມຕົວ ສຳ ລັບການຈັດສົ່ງລຸ້ນ ໃໝ່ [ປ່ອຍ] e 3) ຊ່ວຍໃນການແກ້ໄຂຄວາມລົ້ມເຫຼວຂອງການຜະລິດຢ່າງໄວວາ [hotfix]. ຕ່າງຈາກ ສາຂາ ຕົ້ນຕໍ, estes ສາຂາ ມີອາຍຸຍືນ, ຍ້ອນວ່າພວກເຂົາຈະຖືກໂຍກຍ້າຍອອກໃນທີ່ສຸດ.

ປະເພດຕ່າງໆຂອງ ສາຂາ [ຜູ້ຊ່ວຍ] ສິ່ງທີ່ພວກເຮົາສາມາດນໍາໃຊ້, ພວກເຂົາເຈົ້າມີຄວາມ:

  • ສາຂາຄຸນນະສົມບັດ
  • ປ່ອຍສາຂາ
  • ສາຂາ Hotfix

ແຕ່ລະສິ່ງເຫລົ່ານີ້ ສາຂາ ມີຈຸດປະສົງສະເພາະແລະຖືກຜູກມັດໂດຍກົດລະບຽບທີ່ເຂັ້ມງວດ, ດັ່ງ​ນັ້ນ, ສາຂາ ສາມາດເຮັດໃຫ້ເພີ່ມຂຶ້ນ ສາຂາ ແມ່ນວ່າ ສາຂາ ຕ້ອງໄດ້ລວມເຂົ້າກັນ [ລວມເຂົ້າກັນ] ເພື່ອເປົ້າ ໝາຍ ຂອງທ່ານ. ພວກເຮົາຈະເຫັນພວກເຂົາແຕ່ລະຄົນ [ສາຂາ] ໃນທັນທີ.

ຈາກມຸມມອງດ້ານວິຊາການ, ເຫຼົ່ານັ້ນ ສາຂາ ຍັງບໍ່ໄດ້ພິຈາລະນາ “ພິເສດ”. ແຕ່ລະປະເພດຂອງ ສາຂາ ຖືກຈັດປະເພດໂດຍວິທີທີ່ພວກເຮົາໃຊ້ພວກມັນ. ໃນທີ່ສຸດ, ແມ່ນງ່າຍດາຍພຽງແຕ່ ສາຂາ ຂອງ Git ເກົ່າທີ່ດີ.

ສາຂາຄຸນນະສົມບັດ

[ຄຸນລັກສະນະ = ຄຸນລັກສະນະ / ການເຮັດວຽກ]

– ສາມາດ [ສາຂາ] ຈາກ:
ພັດທະນາ
– ມັນຄວນຈະຜະສົມຜະສານ [ລວມ] ອີກເທື່ອຫນຶ່ງ:
ພັດທະນາ
– ການຕັ້ງຊື່ສົນທິສັນຍາ ສາຂາ:
ສິ່ງໃດກໍ່ຕາມ, ຍົກເວັ້ນ ຕົ້ນສະບັບ, ພັດທະນາ, ປ່ອຍ - *, ຫຼື hotfix- *

ສາຂາຄຸນນະສົມບັດ (ຫຼືບາງຄັ້ງກໍ່ເອີ້ນ ສາຂາຫົວຂໍ້) ຖືກ ນຳ ໃຊ້ເພື່ອພັດທະນາຄຸນນະສົມບັດ / ໜ້າ ທີ່ ໃໝ່ ສຳ ລັບລຸ້ນທີ່ ກຳ ລັງຈະມາເຖິງຫຼືໃນອະນາຄົດ. ໃນເວລາທີ່ເລີ່ມຕົ້ນການພັດທະນາຂອງ a ຄຸນ​ນະ​ສົມ​ບັດ, ສະບັບເປົ້າ ໝາຍ ທີ່ຄຸນລັກສະນະນີ້ຈະລວມເຂົ້າກັນອາດຈະຍັງບໍ່ຮູ້ເທື່ອໃນຈຸດນີ້.

ໂດຍເນື້ອແທ້ແລ້ວຂອງກ ສາຂາຄຸນນະສົມບັດ ແມ່ນວ່າມັນມີຢູ່ໃນຂະນະທີ່ ຄຸນ​ນະ​ສົມ​ບັດ ແມ່ນຢູ່ໃນການພັດທະນາ, ແຕ່ໃນທີ່ສຸດມັນຈະຖືກລວມເຂົ້າກັນ [ລວມເຂົ້າກັນ] ກັບ​ໄປ ພັດທະນາ (ແນ່ນອນຕື່ມສິ່ງ ໃໝ່ໆ ຄຸນ​ນະ​ສົມ​ບັດ ຕໍ່ໄປ ປ່ອຍ) ຫຼືຍົກເລີກ (ໃນກໍລະນີຂອງການທົດລອງທີ່ບໍ່ປະສົບຜົນ ສຳ ເລັດ).

ສາຂາຄຸນນະສົມບັດ ໂດຍປົກກະຕິມີພຽງແຕ່ຢູ່ໃນຫໍໄຕ ພັດທະນາ, ບໍ່ໄດ້ຢູ່ໃນ ຕົ້ນກໍາເນີດ.

ການສ້າງສາຂາທີ່ມີຄຸນລັກສະນະ

$ git checkout -b myfeature ພັດທະນາ
# Switched to a new branch "myfeature"

ລວມເອົາຮູບແບບ ສຳ ເລັດຮູບເຂົ້າໃນການພັດທະນາ

ຄຸນ​ລັກ​ສະ​ນະ ສຳ ເລັດສາມາດລວມເຂົ້າກັນໄດ້[ລວມເຂົ້າກັນ] ເປັນ ສາຂາ ເພື່ອເພີ່ມພວກມັນໃຫ້ແນ່ນອນຕໍ່ໄປ ປ່ອຍ.

$ git checkout ພັດທະນາ
# ປ່ຽນເປັນສາຂາ 'ພັດທະນາ'
$ ໄປຮ່ວມກັນ --ບໍ່ມີ-ff myfeature
# ການປັບປຸງ ea1b82a..05e9557
# (ບົດສະຫຼຸບຂອງການປ່ຽນແປງ)
# $ ສາຂາ git -d myfeature
# ສາຂາຖືກຍົກເລີກ (ແມ່ນ 05e9557).
$ git push ຕົ້ນ ກຳ ເນີດພັດທະນາ

ທຸງຊາດ –no-ff ສາເຫດຂອງການລວມຕົວ [ລວມ] ສະເຫມີສ້າງໃຫມ່ ຄໍາຫມັ້ນສັນຍາ, ເຖິງແມ່ນວ່າການລວມຕົວສາມາດຖືກປະຕິບັດດ້ວຍ a ກ້າວໄປຂ້າງ ໜ້າ [ff]. ນີ້ຫລີກລ້ຽງການສູນເສຍຂໍ້ມູນກ່ຽວກັບປະຫວັດຂອງການມີຢູ່ຂອງກ ສາຂາຄຸນນະສົມບັດ, ການຈັດກຸ່ມທັງ ໝົດ ສັນຍາ ທີ່ໄດ້ຖືກເພີ່ມເຂົ້າ ຄຸນ​ນະ​ສົມ​ບັດ. ປຽບທຽບ:

ບໍ່ແມ່ນກໍລະນີສຸດທ້າຍ [ຂອງຮູບຂ້າງເທິງ], ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຫັນຈາກປະຫວັດສາດ Git ວ່າແມ່ນຫຍັງ ສັນຍາ ໄດ້ຖືກຈັດຕັ້ງປະຕິບັດພາຍໃນ ຄຸນ​ນະ​ສົມ​ບັດ; ທ່ານຕ້ອງໄດ້ອ່ານຂໍ້ຄວາມບັນທຶກທັງ ໝົດ ດ້ວຍຕົນເອງ. ປ່ຽນຄືນກ ຄຸນ​ນະ​ສົມ​ບັດ ທັງຫມົດ (ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ກຸ່ມຂອງ ສັນຍາ), ມັນເປັນການເຈັບຫົວແທ້ໆໃນສະຖານະການສຸດທ້າຍ, ໃນຂະນະທີ່ມັນເຮັດໄດ້ຢ່າງງ່າຍດາຍຖ້າຫາກວ່າທຸງຊາດ –no-ff ໄດ້ຖືກນໍາໃຊ້.

Sim, ນີ້ຈະສ້າງວັດຖຸອີກສອງສາມຢ່າງຂອງ ສັນຍາ (ຫວ່າງເປົ່າ), ແຕ່ວ່າຜົນໄດ້ຮັບແມ່ນຫຼາຍກ່ວາຄ່າໃຊ້ຈ່າຍ.

ປ່ອຍສາຂາ

[ລຸ້ນ = ປ່ອຍ / ສົ່ງ / ສະບັບ]

– ສາມາດ [ສາຂາ] ຈາກ:
ພັດທະນາ
– ມັນຄວນຈະຜະສົມຜະສານ [ລວມ] ອີກເທື່ອຫນຶ່ງ:
ພັດທະນາ e ຕົ້ນສະບັບ
– ການຕັ້ງຊື່ສົນທິສັນຍາ ສາຂາ:
ປ່ອຍ - *

ປ່ອຍສາຂາ ຊ່ວຍໃນການກະກຽມຮູບແບບການຜະລິດ ໃໝ່ [ການປ່ອຍຜະລິດຕະພັນ]. ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ທ່ານສາມາດເອົາຢອດລົງໃສ່ນາທີສຸດທ້າຍ. ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ການແກ້ໄຂຂະຫນາດນ້ອຍຂອງ ແມງໄມ້ ແລະ ຄຳ ນິຍາມຂອງ ຂໍ້ມູນ meta ສຳ ລັບ ປ່ອຍ (ໝາຍ ເລກຮຸ່ນ, ວັນທີລວບລວມ, ແລະອື່ນໆ). ໂດຍການເຮັດວຽກທັງ ໝົດ ນີ້ເປັນ ໜຶ່ງ ດຽວ ສາຂາປ່ອຍ, ໄດ້ ພັດທະນາສາຂາ ຮັກສາຄວາມສະອາດເພື່ອຮັບ ຄຸນ​ລັກ​ສະ​ນະ ໃຫຍ່ຕໍ່ໄປ ປ່ອຍ [ສະບັບພາສາ].

ປັດຈຸບັນທີ່ ສຳ ຄັນໃນການສ້າງສິ່ງ ໃໝ່ ສາຂາປ່ອຍ ແຕກຈາກ ພັດທະນາ ແມ່ນເວລາທີ່ ພັດທະນາ ມັນແມ່ນແລ້ວ (ເກືອບ​ທັງ​ຫມົດ) ສະທ້ອນໃຫ້ເຫັນສະພາບທີ່ຕ້ອງການຂອງສິ່ງ ໃໝ່ ປ່ອຍ [ສະບັບພາສາ]. ທັງ ໝົດ ຄຸນ​ລັກ​ສະ​ນະ ຜູ້ສະ ໝັກ ສຳ ລັບ ປ່ອຍ ການກໍ່ສ້າງຈະຕ້ອງລວມເຂົ້າກັນ [ລວມ] ເຖິງ ພັດທະນາ ໃນ​ເວ​ລາ​ນີ້. ທ ຄຸນ​ລັກ​ສະ​ນະ ກຳ ລັງປະເຊີນ ປ່ອຍຕົວ ອະນາຄົດຄວນຄາດຫວັງໃນຕໍ່ ໜ້າ ປ່ອຍ [ສະບັບພາສາ].

ມັນແມ່ນແທ້ຢູ່ໃນຕອນຕົ້ນຂອງ a ສາຂາປ່ອຍ ຕໍ່ໄປ ປ່ອຍ ໄດ້ຮັບ ໝາຍ ເລກຮຸ່ນ – ບໍ່ກ່ອນ. ຈົນຮອດດຽວນີ້, ໄດ້ ພັດທະນາສາຂາ ສະທ້ອນໃຫ້ເຫັນການປ່ຽນແປງກັບ “ລຸ້ນຕໍ່ໄປ” [ສະບັບຕໍ່ໄປ], ແຕ່ວ່າຍັງບໍ່ເປັນທີ່ຈະແຈ້ງເທື່ອວ່າເລື່ອງນີ້ “ສະບັບຕໍ່ໄປ” ມັນຈະສິ້ນສຸດເຖິງການເປັນ 0.3 ຫຼື 1.0, ຈົນກ່ວາ ສາຂາປ່ອຍ ເລີ່ມ​ຕົ້ນ. ການຕັດສິນໃຈນີ້ແມ່ນໄດ້ເຮັດໃນຕອນຕົ້ນຂອງພຣະ ຄຳ ພີມໍມອນ ສາຂາປ່ອຍ ແລະຖືກປະຕິບັດໂດຍກົດລະບຽບຂອງໂຄງການກ່ຽວກັບການສະບັບ [ແນະ ນຳ ໃຫ້ເບິ່ງກ່ຽວກັບ “Semantic Versioning“].

ການສ້າງສາຂາປ່ອຍຕົວ

ປ່ອຍສາຂາ ຖືກສ້າງຂື້ນຈາກ ພັດທະນາສາຂາ. ສໍາລັບການຍົກຕົວຢ່າງ, ໃຫ້ເວົ້າວ່າສະບັບ 1.1.5 ແມ່ນລຸ້ນຜະລິດໃນປະຈຸບັນແລະພວກເຮົາມີທີ່ຍິ່ງໃຫຍ່ ປ່ອຍ ມາຮອດ. ຫຼືລັດຂອງ ພັດທະນາ ມັນພ້ອມແລ້ວ ສຳ ລັບ a “ສະບັບຕໍ່ໄປ” [ລຸ້ນຕໍ່ໄປ] ແລະພວກເຮົາໄດ້ຕັດສິນໃຈວ່າສິ່ງນີ້ຈະກາຍເປັນສະບັບ 1.2 (ແທນ​ທີ່​ຈະ 1.1.6 ຫຼື 2.0). ຫຼັງຈາກນັ້ນ, ພວກເຮົາສາຂາອອກແລະເອົາຂອງ ສາຂາປ່ອຍ ຊື່ທີ່ສະທ້ອນໃຫ້ເຫັນຕົວເລກຮຸ່ນ ໃໝ່:

$ git checkout -b ປ່ອຍຕົວ-1.2 ພັດທະນາ
# Switched to a new branch "release-1.2"
$ ./ຕຳ-ສະບັບພາສາ.sh 1.2
# ໄຟລ໌ດັດແກ້ຢ່າງ ສຳ ເລັດຜົນ, ສະບັບ bumped ກັບ 1.2.
$ git ຫມັ້ນສັນຍາ -ເປັນ -"Bumped version number to 1.2"
# [ປ່ອຍ-1.2 74d9424] ໝາຍ ເລກ ຕຳ ແໜ່ງ ທີ່ຖືກ ຕຳ 1.2
# 1 ໄຟລ໌ປ່ຽນແປງ, 1 ບ່ອນແຊກ(+), 1 ການລົບ(-)

ຫລັງຈາກສ້າງ ໃໝ່ ສາຂາ ແລະເຂົ້າຫາມັນ, ພວກເຮົາ ຕຳ ໃສ່ ຈຳ ນວນລຸ້ນ. ຢູ່ທີ່ນີ້, ຕຳ --version.sh ແມ່ນສະຄິບຫອຍທີ່ປ່ຽນແປງບາງເອກະສານ ສຳ ເນົາທີ່ເຮັດວຽກເພື່ອສະທ້ອນລຸ້ນ ໃໝ່. (ນີ້ສາມາດເຮັດໄດ້, ແຈ້ງ, ເປັນການປ່ຽນແປງຄູ່ມື – ຈຸດແມ່ນວ່າບາງເອກະສານປ່ຽນ.) ຫຼັງຈາກນັ້ນ, ແມ່ນເຮັດໄດ້ ຄໍາຫມັ້ນສັນຍາ ໝາຍ ເລກຮຸ່ນທີແກ້ໄຂ.

ໃໝ່ ນີ້ ສາຂາ ອາດຈະມີຢູ່ໃນໄລຍະຫນຶ່ງ, ຈົນກ່ວາ ປ່ອຍ ຖືກປ່ອຍຕົວຢ່າງແນ່ນອນ. ໃນໄລຍະນີ້, ການແກ້ໄຂຂໍ້ຜິດພາດສາມາດຖືກ ນຳ ໃຊ້ໃນນີ້ ສາຂາ (ແທນ​ທີ່ ພັດທະນາສາຂາ). ການເພີ່ມຂອງ ໃໝ່ ແລະໃຫຍ່ ຄຸນ​ລັກ​ສະ​ນະ ນີ້ແມ່ນຖືກຫ້າມຢ່າງເຂັ້ມງວດ. ພວກເຂົາຕ້ອງຖືກລວມເຂົ້າກັນ [ລວມເຂົ້າກັນ] ໃນ ພັດທະນາ e, ສະນັ້ນ, ລໍຖ້າໃຫຍ່ຕໍ່ໄປ ປ່ອຍ.

ການເຮັດ ສຳ ເລັດສາຂາການປ່ອຍຕົວ

ໃນ​ເວ​ລາ​ທີ່ ສາຂາປ່ອຍ ກຽມພ້ອມທີ່ຈະກາຍເປັນສະບັບທີ່ແທ້ຈິງ, ຕ້ອງມີການກະ ທຳ ບາງຢ່າງ. ກ່ອນອື່ນ ໝົດ, ໄດ້ ສາຂາປ່ອຍ ຖືກລວມເຂົ້າໄປໃນ ຕົ້ນສະບັບ (ນັບຕັ້ງແຕ່ແຕ່ລະຄົນ ຄໍາຫມັ້ນສັນຍາ ບໍ່ມີ ຕົ້ນສະບັບ ແມ່ນລຸ້ນ ໃໝ່ ຕາມ ຄຳ ນິຍາມ, ຈື່ຖ້າ). ຫຼັງຈາກນັ້ນ, ນັ້ນ ຄໍາຫມັ້ນສັນຍາ ບໍ່ມີ ຕົ້ນສະບັບ ຄວນກວດສອບເພື່ອ ອຳ ນວຍຄວາມສະດວກໃນການອ້າງອີງໃນອະນາຄົດຂອງປະຫວັດສາດສະບັບນີ້. ສຸດທ້າຍ, ການປ່ຽນແປງທີ່ໄດ້ເຮັດຕໍ່ ສາຂາປ່ອຍ ຕ້ອງການລວມເຂົ້າກັນ [ລວມເຂົ້າກັນ] ອີກເທື່ອຫນຶ່ງສໍາລັບການ ພັດທະນາ, ດັ່ງນັ້ນ ປ່ອຍຕົວ ອະນາຄົດຍັງມີຂໍ້ແກ້ໄຂຂໍ້ບົກພ່ອງເຫລົ່ານີ້.

ສອງບາດກ້າວ ທຳ ອິດໃນ Git:

$ git checkout ຕົ້ນສະບັບ
# ປ່ຽນເປັນສາຂາ 'ສາຂາ'
$ ໄປຮ່ວມກັນ --ບໍ່ມີ-ff ປ່ອຍຕົວ-1.2
# ຜະສົມຜະສານໂດຍການເອີ້ນຄືນ.
# (ບົດສະຫຼຸບຂອງການປ່ຽນແປງ)
$ git tag -ເປັນ 1.2

ໄດ້ ປ່ອຍ ປະຈຸບັນ ສຳ ເລັດແລ້ວແລະ ກຳ ນົດການອ້າງອີງໃນອະນາຄົດ.

ຂໍ້ສັງເກດ: ທ່ານຍັງສາມາດໃຊ້ທຸງ -s ຫຼື -u ເພື່ອເຊັນຊື່ໂຄດຄໍາສັ່ງຂອງທ່ານເປັນ cryptographically.

ເພື່ອຮັກສາການປ່ຽນແປງທີ່ໄດ້ເຮັດ ສາຂາປ່ອຍ, ພວກເຮົາຕ້ອງການໃຫ້ພວກເຂົາກັບກັນ ພັດທະນາ. ບໍ່ມີ Git:

$ git checkout ພັດທະນາ
# ປ່ຽນເປັນສາຂາ 'ພັດທະນາ'
$ ໄປຮ່ວມກັນ --ບໍ່ມີ-ff ປ່ອຍຕົວ-1.2
# ຜະສົມຜະສານໂດຍການເອີ້ນຄືນ.
# (ບົດສະຫຼຸບຂອງການປ່ຽນແປງ)

ບາດກ້າວນີ້ສາມາດ ນຳ ໄປສູ່ການປະທະກັນ (ອາດຈະໄປ, ເມື່ອພວກເຮົາປ່ຽນເລກ ໝາຍ ເລກ). ໃນກໍລະນີທີ່ຢັ້ງຢືນ, ສ້ອມແປງແລະເຮັດ ຄໍາຫມັ້ນສັນຍາ.

ໃນປັດຈຸບັນ, ວ່າພວກເຮົາໄດ້ສໍາເລັດການກໍ່, ໄດ້ ສາຂາປ່ອຍ ສາມາດເອົາອອກໄດ້, ເນື່ອງຈາກວ່າພວກເຮົາຈະບໍ່ຕ້ອງການມັນອີກຕໍ່ໄປ:

$ ສາຂາ git --1.2
# ການປ່ອຍສາຂາທີ່ຖືກລຶບ-1.2 (ນີ້ແມ່ນ ff452fe).

ສາຂາ Hotfix

– ສາມາດ [ສາຂາ] ຈາກ:
ຕົ້ນສະບັບ
– ມັນຄວນຈະຜະສົມຜະສານ [ລວມ] ອີກເທື່ອຫນຶ່ງ:
ພັດທະນາ e ຕົ້ນສະບັບ
– ການຕັ້ງຊື່ສົນທິສັນຍາ ສາຂາ:
hotfix- *

ສາຂາ Hotfix ແມ່ນຄ້າຍຄືກັນກັບ ປ່ອຍສາຂາ, ຍ້ອນວ່າພວກມັນມີຈຸດປະສົງເພື່ອກະກຽມຮູບແບບການຜະລິດ ໃໝ່, ເຖິງແມ່ນວ່າບໍ່ໄດ້ວາງແຜນໄວ້. ມັນເກີດຂື້ນຈາກຄວາມຕ້ອງການທີ່ຈະປະຕິບັດທັນທີຫຼັງຈາກສະຖານະການຜະລິດທີ່ບໍ່ຕ້ອງການ [ໃນການນໍາໃຊ້]. ເມື່ອຄວາມຜິດພາດທີ່ ສຳ ຄັນເກີດຂື້ນໃນລຸ້ນຜະລິດ, ຕ້ອງໄດ້ຮັບການແກ້ໄຂທັນທີ, ຫຼັງຈາກນັ້ນຫນຶ່ງ ສາຂາ hotfix ສາມາດໄດ້ມາຈາກປ້າຍຊື່ທີ່ ໝາຍ ເຖິງລຸ້ນທີ່ຜະລິດຢູ່ໃນ ສາຂາຕົ້ນສະບັບ.

ເນື້ອແທ້ແມ່ນວຽກຂອງສະມາຊິກທີມ (ບໍ່ມີ ພັດທະນາສາຂາ) ສືບຕໍ່ໄປ, ໃນຂະນະທີ່ຜູ້ອື່ນ ກຳ ລັງກະກຽມແກ້ໄຂຄວາມລົ້ມເຫຼວຂອງການຜະລິດ.

ການສ້າງສາຂາ hotfix

ສາຂາ hotfix ຖືກສ້າງຂື້ນຈາກ ສາຂາຕົ້ນສະບັບ. ສໍາລັບການຍົກຕົວຢ່າງ, ສົມມຸດວ່າສະບັບ 1.2 ແມ່ນລຸ້ນລຸ້ນການຜະລິດທີ່ ກຳ ລັງ ດຳ ເນີນຢູ່ແລະມີປັນຫາຍ້ອນຄວາມຜິດພາດທີ່ຮ້າຍແຮງ. ການປ່ຽນແປງໃນ ພັດທະນາ ປ່ອຍໃຫ້ຍັງບໍ່ສະຖຽນລະພາບ. ຈາກນັ້ນພວກເຮົາສາມາດແຍກອອກຈາກກັນໄດ້ ສາຂາ hotfix ແລະເລີ່ມຕົ້ນແກ້ໄຂບັນຫາ:

$ git checkout -b hotfix-1.2.1 ຕົ້ນສະບັບ
# Switched to a new branch "hotfix-1.2.1"
$ ./ຕຳ-ສະບັບພາສາ.sh 1.2.1
# ໄຟລ໌ດັດແກ້ຢ່າງ ສຳ ເລັດຜົນ, ສະບັບ bumped ກັບ 1.2.1.
$ git ຫມັ້ນສັນຍາ -ເປັນ -"Bumped version number to 1.2.1"
# [hotfix-1.2.1 41e61bb] ໝາຍ ເລກ ຕຳ ແໜ່ງ ທີ່ຖືກ ຕຳ 1.2.1
# 1 ໄຟລ໌ປ່ຽນແປງ, 1 ບ່ອນແຊກ(+), 1 ການລົບ(-)

ຢ່າລືມປ່ຽນ ໝາຍ ເລກຮຸ່ນຫຼັງຈາກງ່າ!

ຫຼັງຈາກນັ້ນ, ແກ້ໄຂຂໍ້ຜິດພາດແລະເຮັດ ຄໍາຫມັ້ນສັນຍາ ການແກ້ໄຂໃນຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ ຄໍາຫມັ້ນສັນຍາ ແຍກອອກຈາກກັນ.

$ git ຫມັ້ນສັນຍາ -"Fixed severe production problem"
# [hotfix-1.2.1 abbe5d6] ແກ້ໄຂບັນຫາການຜະລິດທີ່ຮຸນແຮງ
# 5 ໄຟລ໌ປ່ຽນແປງ, 32 ບ່ອນແຊກ(+), 17 ການລົບ(-)

ສຳ ເລັດສາຂາ hotfix

ເມື່ອ ສຳ ເລັດ, ໄດ້ bugfix ຕ້ອງການລວມເຂົ້າກັນ ຕົ້ນສະບັບ, ແຕ່ມັນຍັງ ຈຳ ເປັນຕ້ອງໄດ້ລວມເຂົ້າກັນອີກ ພັດທະນາ, ເພື່ອຮັບປະກັນວ່າ bugfix ແມ່ນລວມຢູ່ໃນສະບັບຕໍ່ໄປ. ນີ້ແມ່ນຄ້າຍຄືກັນກັບວິທີການ ປ່ອຍສາຂາ ແມ່ນສຸດທ້າຍແລ້ວ.

ກ່ອນອື່ນ ໝົດ, ປັບປຸງ ຕົ້ນສະບັບ ມື້ e ປ່ອຍ [ກວດເບິ່ງລະດູຮ້ອນ]:

$ git checkout ຕົ້ນສະບັບ
# ປ່ຽນເປັນສາຂາ 'ສາຂາ'
$ ໄປຮ່ວມກັນ --ບໍ່ມີ-ff hotfix-1.2.1
# ຜະສົມຜະສານໂດຍການເອີ້ນຄືນ.
# (ບົດສະຫຼຸບຂອງການປ່ຽນແປງ)
$ git tag -ເປັນ 1.2.1

ຂໍ້ສັງເກດ: ທ່ານຍັງສາມາດໃຊ້ທຸງ -s ຫຼື -u ເພື່ອເຊັນຊື່ໂຄດຄໍາສັ່ງຂອງທ່ານເປັນ cryptographically.

ຫຼັງຈາກນັ້ນ, ປະກອບມີ bugfix ບໍ່ມີ ພັດທະນາ ຍັງ:

$ git checkout ພັດທະນາ
# ປ່ຽນເປັນສາຂາ 'ພັດທະນາ'
$ ໄປຮ່ວມກັນ --ບໍ່ມີ-ff hotfix-1.2.1
# ຜະສົມຜະສານໂດຍການເອີ້ນຄືນ.
# (ບົດສະຫຼຸບຂອງການປ່ຽນແປງ)

ຂໍ້ຍົກເວັ້ນພຽງແຕ່ກົດລະບຽບຢູ່ທີ່ນີ້ແມ່ນວ່າ, ເມື່ອມີ ສາຂາປ່ອຍ ໃນຄວາມຄືບຫນ້າ, ການປ່ຽນແປງໃນ hotfix ຕ້ອງການລວມເຂົ້າກັນເພື່ອສິ່ງນີ້ ສາຂາປ່ອຍ, ແທນ​ທີ່​ຈະ ພັດທະນາ. ຜະສົມຜະສານ bugfix ບໍ່ມີ ສາຂາປ່ອຍ ຈະເຮັດໃຫ້ bugfix ຖືກລວມເຂົ້າໄປໃນ ພັດທະນາ ຍັງ, ໃນ​ເວ​ລາ​ທີ່ ສາຂາປ່ອຍ ແມ່ນສໍາເລັດ. (ຖ້າເຮັດວຽກ ພັດທະນາ ທັນທີຮຽກຮ້ອງໃຫ້ມີວ່າ bugfix ແລະບໍ່ສາມາດລໍຖ້າຈົນກ່ວາ ສາຂາປ່ອຍ ຈະສໍາເລັດ, ທ່ານສາມາດຮວມເຂົ້າກັນໄດ້ຢ່າງປອດໄພ bugfix ສໍາລັບການ deveolp ຍັງ.)

ສຸດທ້າຍ, ເອົາ ສາຂາ ຊົ່ວຄາວ:

$ ສາຂາ git -d ຄຳ ສັບດ່ວນ-1.2.1
# ສາຂາທີ່ຖືກລຶບແລ້ວ hotfix-1.2.1 (ນີ້ແມ່ນ abbe5d6).

ສະຫຼຸບ

ເຖິງແມ່ນວ່າມັນບໍ່ມີຫຍັງພິເສດແທ້ໆກ່ຽວກັບຮູບແບບສາຂານີ້, ຕົວເລກໃນຕອນຕົ້ນຂອງ Post ສາມາດເປັນປະໂຫຍດຫຼາຍໃນໂຄງການຂອງພວກເຮົາ. ມັນສະແດງໃຫ້ເຫັນຮູບແບບຈິດໃຈທີ່ເຂົ້າໃຈງ່າຍແລະຊ່ວຍໃຫ້ສະມາຊິກທີມພັດທະນາຄວາມເຂົ້າໃຈທົ່ວໄປ ງ່າ e ປ່ອຍຕົວ.

ຕົວເລກ PDF ທີ່ມີຄຸນນະພາບສູງແມ່ນຖືກສະ ໜອງ ໃນ blog ຂອງໂພສຕ໌ເດີມ: http://nvie.com/posts/a-successful-git-branching-model/ [ຫຼືການເຊື່ອມຕໍ່ດາວໂຫລດຢູ່ດ້ານລຸ່ມ]. ສືບຕໍ່ເດີນຫນ້າແລະເອົາໃສ່ຝາເພື່ອເປັນການອ້າງອິງດ່ວນທຸກເວລາ.

ຈໍານວນທັງຫມົດ: 10292

A ການທົບທວນຄືນກ່ຽວກັບ “A ຮູບແບບສົບຜົນສໍາເລັດຂອງສາຂາໃນ Git

  1. Deivson ເກີດ ກ່າວວ່າ:

    ຕອນບ່າຍດີ, ຂ້າພະເຈົ້າຮູ້ວ່າ Git ໄດ້ພັດທະນາເບື້ອງຕົ້ນສໍາລັບ Linux ແຕ່ໃນເວລາທີ່ເວົ້າກ່ຽວກັບການ Portable, ຂ້າພະເຈົ້າສິ່ງມະຫັດຖ້າຫາກວ່າ Git ເນັ້ນໃສ່ POSIX MSIS ແລະປ່ອງຢ້ຽມ??

ອອກຈາກ Reply ເປັນ

ທີ່ຢູ່ອີເມວຂອງທ່ານຈະບໍ່ໄດ້ຮັບການຈັດພີມມາ. ທົ່ງນາທີ່ກໍານົດໄວ້ແມ່ນຫມາຍດ້ວຍ *