It's a bit long so whoever make it to the end, thanks!

http://nvie.com/posts/a-successful-git-branching-model/

This model works, but if Bob's feature branch only merge with the origin/master (e.g. development branch) at the end of the feature branch life (completion), then we potentially break code. Example: Alice renamed some classes. This also mean we break our continuous integration.

I am new to this domain. I am asking for advice. One solution is each developer pull and merge with origin/master from the repo on github every single morning when they come to work. If a merge conflict occurs, Bob has to talk to Alice or whoever is responsible for the diff. This could also be our morning scrum meeting.

Is this a reasonable solution? Or is there is a better way to handle? This may work for 2 people. But I see flaws for more workers. Too many branches. Too little commits per day. Also, how are we going to perform CI on Jenkins?

I am so loss in this domain. I have never worked in a real software engineering environment.

I was at a Google Tech Talk this summer (see https://www.youtube.com/watch?v=KH2_sB1A6lA&list=PLAD8A7B6D66DDD297) and I am amazed at how they manage the commits. If you have like 10 people committing every 2-3 hours from 9am to 5pm. I don't think you can use branching?

I just don't understand how these things work. If I can't figure this out, I can't go ahead and make a Puppet/Chef/Ansible deployment/configuration system because the workflow will be beaten to death.

Oh my current workflow? Ugly, I think. Each developer(really, just students in the lab) clone repo from github. Work on their features on their local master branch. Tests, then perform a pull request.

Again, if anyone can share their best practices or resolve my concerns, please do. Thanks a lot!