โฟลว์การทำงานกับ GIT Version Control แบบง่ายจะเป็นเช่นในภาพนี้
ในภาพข้างต้นเป็นโฟลว์แบบง่ายที่ไม่มีการแตก Branch สังเกตว่าเครื่องใหม่ที่ยังไม่มีโปรเจคอยู่เลยจะเริ่มด้วยการ clone คือก็อปปี้ทั้ง Repository จาก Remote มาไว้ที่เครื่องตัวเองเรียกว่าเป็น Local Repository หลังจากนั้นเมื่อมีการแก้ไขไฟล์จะ commit เข้า Local Repository บนเครื่องตนเองก่อน ไฟล์จะเกิดเป็น Revision ใหม่ทุกครั้งที่มีการ commit เมื่อได้เสร็จสิ้นในขั้นตอนหนึ่งที่โปรเจคมีความก้าวหน้าไปอีกหนึ่งเวอร์ชัน ก็จะส่งการเปลี่ยนแปลงทั้งหมดไปเก็บบน Remote Repository เรียกว่าเป็นการ push ในขณะเดียวกันหากในทีมงานคืนอื่นต้องการเอาไฟล์ Revision ใหม่มาไว้ที่เครื่องตนเองก็จะสั่ง pull หรือ fetch จาก Remote Repository ไฟล์ล่าสุดก็จะถูกดาวน์โหลดมาอัพเดตใน Local Repository และใช้งานต่อไป ในภาพเป็นการแก้ไขแบบง่ายๆโดยไม่มีการแตก Branch ถ้าไม่มีการแตก Branch ออกไปเราจะมี Branch เดียวเสมอทั้งฝั่ง Remote และ Local เรียกว่าเป็น Master และไฟล์ล่าสุดจะเรียกว่าเป็น Head Revision ในกรณีที่ทำงานร่วมกันเป็นทีม และการพัฒนางานหนึ่งชิ้นมักจะไม่ต้องการให้ระหว่างการพัฒนางานอยู่นั้นไฟล์ต่างๆที่เกี่ยวข้องได้รับผลกระทบจากผู้อื่นในทีม รวมทั้งไฟล์ที่เราแก้ไขไปก็ไม่ต้องการให้ไปกระทบผู้อื่นด้วยเช่นกัน จึงมักจะแตก Branch ออกมา ซึ่งจะเป็นโฟลว์ตามภาพต่อไปนี้
ในภาพข้างต้นจะเห็นว่าขั้นตอนแบบมี Branch จะคล้ายแบบเดิม แต่แตกต่างกันออกไปที่คำสั่ง git checkout นั่นคือเมื่อผู้ร่วมงานในทีม เห็นว่างานที่ต้องทำนั้นกินเวลานานอยู่ช่วงหนึ่งและอาจจะมีคุณสมบัติเพิ่มเติมหลายอย่าง จึงใช้คำสั่ง checkout เพื่อแตก Branch ออกมา ในภาพจะเห็น Branch ชื่อว่า CR-123 (CR ย่อมาจาก Change Request) เมื่อแตก Branch ออกมาแล้วและแก้ไขไฟล์ ถ้าสั่ง commit ไฟล์ Revision ใหม่จะเกิดขึ้นภายใน Branch ใหม่นี้เท่านั้น และเมื่อเสร็จสิ้นการทำงานแล้วจะ push ทั้ง Branch ขึ้นไปที่ Remote โดยวิธีการในภาพคือ push ขึ้นไปที่ Remote Branch ที่ชื่อเดียวกันคือ CR-123 ดังนั้นการแก้ไขเหล่านี้จะไม่กระทบกับ Master Branch ในภาพจะเห็นว่าเมื่อ push เสร็จแล้วจะสร้าง Pull Request ทิ้งไว้ โดย Pull Request เป็นเหมือนข้อความสั้นๆฝากบอกให้ DevOps Manager (เช่น ผู้จัดการทีม หรือ ผู้รวมซอร์สโค้ดเข้าด้วยกัน เรียกว่า DevOps Manager) มาดึงเอาการเปลี่ยนแปลงทั้งหมดไปรวมเข้ากับ Master Branch ในระหว่างนั้น DevOps Manager อาจจะมีการโต้ตอบกับเจ้าของ Branch เพื่อให้แก้ไขจนกว่าจะสมบูรณ์และรวม CR-123 เข้ากับ Master Branch ได้สำเร็จ สุดท้ายเมื่อรวมสำเร็จแล้ว DevOps Manager จะลบ Branch แยกทิ้งไป และฝั่ง Local เองก็จะลบ Branch แยกทิ้งไปและ pull เอา Master Branch กลับออกมาก็จะรวมเข้ากับทีมหลักและดำเนินการเช่นนี้ในรอบถัดไป