-
1. Иш бошланиши
- 1.1 Талқинларни бошқариш ҳақида
- 1.2 Git нинг қисқача тарихи
- 1.3 Git асоси
- 1.4 Командалар сатри
- 1.5 Git ни ўрнатиш
- 1.6 Git да биринчи созлашлар
- 1.7 Қандай ёрдам олиш мумкин?
- 1.8 Хулосалар
-
2. Git асослари
-
3. Git да тармоқланиш
-
4. Git серверда
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Sizning SSH ochiq (public) kalitingizni generatsiyalash
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Хулосалар
-
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Qism modullar (Submodule)
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Summary
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
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.
![A linear view of progressive-stability branching.](png/lr-branches-1.png)
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.
![A ``silo'' view of progressive-stability branching.](png/lr-branches-2.png)
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
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:
![Multiple topic branches.](png/topic-branches-1.png)
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:
![History after merging `dumbidea` and `iss91v2`.](png/topic-branches-2.png)
dumbidea
and iss91v2
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.