Скачать или смотреть Git Branching and Merging Strategies

NOTE 2019/09/19: This video is over 7 years old now. Many of the ideas I have moved on from and do things differently now. The video is still useful -- AS IT WAS ORIGINALLY INTENDED -- to provide an example of how you COULD do things, not as an authoritative process. Since I get away from my computer whenever I can now and go biking instead, I will not likely create an updated video. Thanks for all the comments and interactions over the years! I never thought I'd have 200k views when I made this back in 2012. It's been fun. I likely won't be as responsive on comments as I was in previous years, mainly because after close to 30 years of programming, I don't spend much extra time beyond my work hours thinking about this stuff any more. Take care!

PLEASE READ: This video demonstrates an EXAMPLE of git branching and merging strategies. It's a decent template to get you started in different situations. It's not a "THIS IS HOW YOU SHOULD DO IT" video. These are ideas based upon my experience. Hopefully they will increase your understanding of git. In the end, you should UNDERSTAND your own process, how git works, and then create a branching and merging strategy that works for YOU and your situation.

----

Three similar branching and merging strategies in Git, with a common goal of keeping development history linear.

PowerPoint: http://goo.gl/kQPwb

NOTE 1: This example branching and merging strategy is intended for larger development teams that manage a formalized development cycle with distinct development, testing, and release phases, and require production maintenance of more than just the latest version of the product. I don't recommend these thoughts for small teams and simple development processes.

NOTE 2: One thing to remember is that my advice is simply an example put together from my experiences. If you don't know where to start, the specific processes I've laid out are a good starting point, but be sure as you get more comfortable with things to adapt them to your specific needs or preferences.

NOTE 3: Note 2 implies that you take the time to understand what I've laid out and not just emulate it and also to be in touch with what your development process needs are.