🔥 Git เป็น Version Control ที่ใช้จัดเก็บและควบคุมการเปลี่ยนแปลงที่เกิดขึ้นกับไฟล์ชนิดต่างๆ เช่น Text file, Source Code เป็นต้น
.
✍️ ซึ่งมันจะใช้เก็บบันทึกการเปลี่ยนแปลงของ Source Code เวอร์ชันล่าสุดที่เครื่องของเรา (Local Repository) สามารถทำงานได้โดยที่ไม่ต้องใช้เน็ต หากต้องการอัปเดต หรือเปลี่ยนแปลงก็สามารถทำการ Push ขึ้นไปเก็บที่ Remote Repository ได้นั่นเอง!
.
🔎 มันมีคำสั่งอะไร แล้วแต่ละอย่างใช้ทำอะไรบ้างไปดูกันเลยจ้า
.
⭐ 1) Git clone - ใช้ดาวน์โหลด/คัดลอกโปรเจกต์จาก Remote Repository ไว้ในเครื่องของเรา
.
คำสั่ง
git clone
⭐ 2) Git branch - สร้าง ลบ และเรียกดู Branch ได้ตามต้องการ
.
คำสั่งสร้าง Branch ใหม่
git branch
.
คำสั่งลบ Branch
git branch -d
⭐ 3) Git checkout - ใช้เปลี่ยน Branch ในการทำงาน
.
คำสั่ง
git checkout
.
หรือสามารถสร้าง Branch ใหม่และเรียกใช้ทันที ด้วยคำสั่ง
git checkout -b
⭐ 4) Git status - ใช้เช็คสถานะของไฟล์ต่างๆ ในโปรเจกต์ของเรา เช่น
.
คำสั่ง
git status
.
⭐ 5) Git add - ใช้สำหรับอัปเดตเวอร์ชันใหม่ของ Code ที่ถูกแก้ไขหรือสร้างใหม่ขึ้นบน Stage
.
คำสั่ง (ระบุชื่อไฟล์ที่ต้องการ)
git add
.
คำสั่ง (ไฟล์ทั้งหมดในโฟลเดอร์)
git add -A
.
⭐ 6) Git commit - ใช้สำหรับยืนยันการเปลี่ยนแปลงของไฟล์ที่ถูก Add ขึ้นมาบน Stage และสามารถใส่ Comment สั้นๆ ได้ด้วย
.
คำสั่ง
git commit -m "commit message"
.
⭐ 7) Git push - ใช้สำหรับอัปเดต Code ที่ถูก Commit ขึ้นบน Remote Repository
git push
.
แต่ถ้าเราเขียน Code ใน Branch ใหม่ที่ยังไม่มีบน Remote Repository ให้ใช้คำสั่ง
git push --set-upstream
.
หรือ
git push -u origin
.
⭐ 8) Git pull - รับการอัปเดตจาก Remote Repository มาในเครื่องของเรา
.
คำสั่ง
git pull
.
⭐ 9) Git revert - คำสั่งยกเลิกการอัปเดตจากฝั่งเราออกจาก Remote Repository
*ต้องใช้อย่างระวังเพราะอาจจะพลาดลบบางอย่างที่ไม่ต้องการได้
.
คำสั่ง
git revert
.
⭐ 10) Git merge - ใช้สำหรับรวม Branch ที่ต้องการเข้าด้วยกัน
.
คำสั่ง
git merge
.
ครบแล้วกับ 10 คำสั่ง Git เบื้องต้นที่มือใหม่ควรรู้ หวังว่าจะเป็นประโยชน์กับเพื่อนๆ นะคะ 😍
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
git pull branch 在 純靠北工程師 Facebook 八卦
#純靠北工程師50m
----------
知道什麼叫公司空轉嗎?
做了一個夢,有個專案前幾個進來接手的新人都會被要求從頭開始(公司只丟交接資料下來,也認為前人都沒做事;對新人而言也剛好拿到一段時間研究前人程式碼練手)。
後來更發現新-新人的git branch是從數個月前,前一位新人剛接手的master commit分支出去的。這代表什麼? master沒人維護,新-新人pull的版本直接跨過前一位新人的repo。
轟隆隆隆,夢醒了。
想說在吵什麼? 原來是外頭汽車空轉的引擎聲,震耳欲聾。
----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層!
👉 https://discord.gg/tPhnrs2
----------
💖 全平台留言、文章詳細內容
👉 https://init.engineer/cards/show/6502
git pull branch 在 91 敏捷開發之路 Facebook 八卦
看吧,每人每天至少 merge 回主幹一次,基於主幹的開發 搭配 feature toggle,才能比較容易達到真實的 CI, CD 的精神。
CI 本質是「持續整合」,不是 build server。
CD 是「持續佈署」,不是自動化佈署。
TDD 也不是自動化測試,是測試輔助開發,用測試來描述情境,確保每一行程式碼都是剛好的為某些情境而存在,沒有多餘,重構沒有負擔,顆粒度小的單元測試能完整且扎實。(你們確定你們團隊有能力在實務上有效、有用地使用TDD來獲得好處嗎?)
紅燈除錯時間降到最低,上版後要 hotfix 也可以直接關掉 toggle 再找到問題的原因,快速地 merge 回主幹,直接推到 production 再開 toggle。
如果走 feature branch,那你們產品是多久才 merge 回主幹一次?一天多次?如果是,那你會覺得連開 feature branch 本身都是個多餘、不必要的 effort。
一切都是基本功,不要只被絢麗的工具、解決方案給迷惑了。
#給了你鑿子也不會因此變成米開朗基羅
--
每次在上課或是在輔導的客戶那邊聊到,Odd-e 幾乎所有人一般都是不走/不建議 用 git flow 之類的 feature branch,工程師們總是十分吃驚。你們不拆 feature branch? 那你們怎麼做的?
feature branch 的主要目的就是為了避免 conflict 造成的成本,然後透過 delay merge 來降低這一段成本(事實上降低的是頻率,而不是成本),因此而付出「延遲整合」的代價。
其實如果退回來敏捷出來之前的瀑布式或傳統的開發方式,大部份都是 component team 或是專業分工團隊,依據大家的專業去內聚成一個 team, 看起來貌似 efficiency 提高,其實是在增加整合的困難,失去全局概念,增加依賴的不穩定性,甚至「避免」溝通。
如果你看過前端一個 team, 後端一個 team 在做一個產品,他們只透過 API spec 跟 文字在溝通如何界接,最終都會導致許多無形的浪費。(怪了,我們這樣分的原始目標還是為了避免浪費)
一個需求需要兩個 team 跨 team 合作的配合,才能正常且順利 deliver,分頭開發就是導致延遲整合,如果再用類似 sprint 的 iteration,一個 sprint 的結束之前才來做整合,當時間已經用盡,但整合出現問題時,就會開始出現責任歸屬問題。
例如前端改也可以,後端改也可以,那麼誰要改?沒時間了啊...後面的工作跟時程都安排好了。
其實,本質問題都是一樣的。
總是碰到客戶那邊用了華麗的 build server 之後,再套上潮流的 git-flow, github-flow,再搭配上一個產品超過 3 個團隊在同個 product code-based 上工作,不同專案不同時間點要上線,再加上從 local/dev 到 prod 至少有三個環境。
結論就是光一個佈署、merge、上版、退版、pull、解 conflict,他們就身在其中痛苦不已。越痛苦,就希望痛苦的頻率降低,做一次痛總比老是痛來得好。
所以,誰晚 merge 誰倒楣。
--
當然啦,feature toggle 也不是萬靈丹,他會帶來 application 複雜度的挑戰,而 application 的複雜度控制,其實卻反而是最簡單的,因為只要設計的底子夠足,這一段可以設計地很美、很無感、很無痛,而且開發維護成本低廉,品質良好。
git pull branch 在 Git Pull Request Tutorial - YouTube 的八卦
... <看更多>