3.4 Git да тармоқланиш - Иш жараёнларини тармоқлаш

Шунинг учун ҳам Git оддий 3 томонламали бирлаштиришни қўллайди. Узоқ вақт этган тармоқланишдаги бир тармоқдан иккинчи тармоққа бир неча бор бирлаштиришни умуман онсонгина бажарилади. Бу шуни англатадики сиз яратувчанлик билан шуғулланаётган вақтингиз давомида бир нечта тармоққа эга бўлиб улардан фойдаланган ҳолда турли хил тайёр соҳаларни (stage) яратишингиз мумкин бўлади. Сиз қоидага мос ҳолда улардан баъзиларини бошқаларига бирлаштириш учун фойдаланишингиз мумкин бўлади.

Кўпгина Git да ишловчи яратувчилар деярли йўлга қўйиш учун тайёр бўлган ёки йўлга қўйилаётган ишчи соҳа master тармоққа эга бўлишади. Улар бошқа параллел бўлган develop ёки next дея номланадиган тармоқни яратиб олишади. Унда улар ишлашади ёки лойиҳани йўлга қўйишга тайёрлигини тест қилишади. У ҳар доим ҳам йўлга қўйишга тайёр бўлмайди. Аммо уни йўлга қўйиш учун ўтказилган тест муваффиқиятли ўтганда master тармоққа бирлаштириш мумкин бўлади. Бу, тармоқлар (қисқа-яшаган тармоқлар сизни аввалги iss53 тармоғингизга ўхшайди) мавзусида улар тайёр бўлганида олиш (pull) учун ишлатилган эди, уларни ишонч билан яратиш жуда кўп тестларни ўтказишга имкон беради ва хатоликларни (bug) келиб чиқишини олдини олади.

Ҳақиқатда биз сиз яратган фиксирлашларни кўрсаткичларини силжитиш ҳақида гаплашдик. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history.

It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested.

You can keep doing this for several levels of stability. Some larger projects also have a proposed or pu (proposed updates) branch that has integrated branches that may not be ready to go into the next or master branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them. Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.

Topic branches, however, are useful in projects of any size. A topic branch is a short-lived branch that you create and use for a single particular feature or related work. This is something you’ve likely never done with a VCS before because it’s generally too expensive to create and merge branches. But in Git it’s common to create, work on, merge, and delete branches several times a day.

You saw this in the last section with the iss53 and hotfix branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely – because your work is separated into silos where all the changes in that branch have to do with that topic, it’s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they’re ready, regardless of the order in which they were created or worked on.

Consider an example of doing some work (on master), branching off for an issue (iss91), working on it for a bit, branching off the second branch to try another way of handling the same thing (iss91v2), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (dumbidea branch). Your commit history will look something like this:

Now, let’s say you decide you like the second solution to your issue best (iss91v2); and you showed the dumbidea branch to your coworkers, and it turns out to be genius. You can throw away the original iss91 branch (losing commits C5 and C6) and merge in the other two. Your history then looks like this:

We will go into more detail about the various possible workflows for your Git project in Distributed Git, so before you decide which branching scheme your next project will use, be sure to read that chapter.

It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository – no server communication is happening.