translation to indonesia-distributed-workflows.asc

book/05-distributed-git/sections/distributed-workflows.asc

@@ -1,88 +1,88 @@
 === Distributed Workflows
 
 (((workflows)))
-Unlike Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
-In centralized systems, every developer is a node working more or less equally on a central hub.
-In Git, however, every developer is potentially both a node and a hub – that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to.
-This opens a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
-We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each.
+Tidak seperti Centralized Version Control Systems (CVCSs), sifat terdistribusi Git memungkinkan Anda untuk menjadi jauh lebih fleksibel dalam bagaimana pengembang berkolaborasi dalam proyek.
+DI centralized systems, Setiap pengembang adalah node yang bekerja kurang lebih sama pada hub pusat.
+Di Git, bagaimanapun, Setiap pengembang berpotensi menjadi node dan hub – itulah, Setiap pengembang bisa menyumbang kode ke repositori yang lain dan memelihara repositori umum dimana orang lain dapat mendasarkan pekerjaan mereka dan kemana mereka bisa menyumbangkannya.
+Ini membuka berbagai kemungkinan alur kerja untuk proyek anda/atau tim anda, Jadi kita akan membahas beberapa paradigma umum yang memanfaatkan fleksibilitas ini.
+Kita akan membahas kelebihan dan kekurangan masing-masing desain; anda dapat memilih satu untuk digunakan, atau anda bisa mencampur dan mecocokkan fitur dari masing-masing.
 
 ==== Centralized Workflow
 
 (((workflows, centralized)))
-In centralized systems, there is generally a single collaboration model–the centralized workflow.
-One central hub, or repository, can accept code, and everyone synchronizes their work to it.
-A number of developers are nodes – consumers of that hub – and synchronize to that one place.
+Di centralized systems, umumnya ada satu model kolaborasi–alur kerja terpusat.
+Satu pusat hub, atau repositori, dapat menerima kode, dan setiap orang menyinkronkan pekerjaan mereka ke situ.
+Sejumlah pengembang adalah node – konsumen dari itu hub – dan menyinkronkan ke satu tempat itu.
 
 .Centralized workflow.
 image::images/centralized.png[Centralized workflow.]
 
-This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems.
-The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes.
-This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git.
+Ini berarti bahwa jika dua pengembang mengkloning dari hub dan keduanya melakukan perubahan, pengembang pertama yang push perubahan back up-nya dapat melakukannya tanpa masalah.
+Pengembang kedua harus bergabung dalam pekerjaan pertama sebelum push perubahan, agar tidak menimpa perubahan pengembang pertama.
+Konsep ini sama seperti di Git seperti ini juga di Subversion(((Subversion))) (or any CVCS), dan model ini bekerja dengan baik di git.
 
-If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git.
-Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other.
-Say John and Jessica both start working at the same time.
-John finishes his change and pushes it to the server.
-Then Jessica tries to push her changes, but the server rejects them.
-She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges.
-This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with.
+Jika anda telah terbiasa dengan alur kerja terpusat di perusahaan anda atau tim anda, anda bisa dengan mudah melanjutkan menggunakan alur kerja itu dengan Git.
+Cukup atur satu repositori, dan berikan setiap orang di tim anda push akses; Git tidak akan membiarkan pengguna saling menimpa.
+Katakan John dan Jessica keduanya memulai pekerjaan dalam waktu yang bersamaan.
+John menyelesaikan perubahannya dan pushes itu ke server.
+Kemudian Jessica mencoba untuk push perubahannya, tetapi server menolaknya.
+Dia diberitahu bahwa dia mencoba untuk push tidak-maju-cepat perubahan dan bahwa dia tidak akan dapat melakukannya sampai dia menjemput dan menyatu.
+Alur kerja ini sangat menarik bagi banyak orang karena ini adalah paradigma yang sudah biasa dan nyaman bagi banyak orang.
 
-This is also not limited to small teams. With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously.
+Ini juga tidak terbatas pada tim kecil. Dengan model percabangan Git, Ini mungkin bagi ratusan pengembang untuk berhasil mengerjakan proyek tunggal melalui puluhan cabang secara bersamaan.
 
 [[_integration_manager]]
 ==== Integration-Manager Workflow
 
 (((workflows, integration manager)))
-Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's.
-This scenario often includes a canonical repository that represents the ``official'' project.
-To contribute to that project, you create your own public clone of the project and push your changes to it.
-Then, you can send a request to the maintainer of the main project to pull in your changes.
-The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository.
-The process works as follows (see <<wfdiag_b>>):
-
-1.  The project maintainer pushes to their public repository.
-2.  A contributor clones that repository and makes changes.
-3.  The contributor pushes to their own public copy.
-4.  The contributor sends the maintainer an e-mail asking them to pull changes.
-5.  The maintainer adds the contributor's repo as a remote and merges locally.
-6.  The maintainer pushes merged changes to the main repository.
+Karena Git memungkinkan Anda memiliki beberapa repositori jarak jauh, ini memungkinkan untuk memiliki sebuah alur kerja dimana setiap pengembang memiliki akses tulis ke repositori umum mereka sendiri dan membaca akses untuk orang lain.
+Skenario ini sering dimasukkan sebuah kanonik repositori itu mewakili ``official'' proyek.
+Untuk berkontribusi pada proyek itu, Anda membuat tiruan publik proyek Anda sendiri dan push perubahan anda untuk itu.
+Lalu, Anda bisa mengirim permintaan kepada pengelola proyek utama untuk pull di perubahan anda.
+Pengelola kemudian dapat menambahkan repositori Anda sebagai remote, uji perubahan Anda secara lokal, menggabungkan mereka ke cabangnya, dan push kembali ke repositori mereka.
+proses pekerjaan sebagai berikut (see <<wfdiag_b>>):
+
+1.  Pemelihara proyek pushes ke repositori umum mereka.
+2.  Sebuah klon penyumbang repositori dan membuat perubahan.
+3.  Penyumbang tersebut pushes salinan publik mereka sendiri.
+4.  Penyumbang mengirimkan pemelihara sebuah e-mail meminta mereka untuk pull perubahan.
+5.  Pengelola menambahkan repo kontributor sebagai remote dan bergabung secara lokal.
+6.  Pengelola pushes perubahan gabungan ke repositori utama.
 
 [[wfdiag_b]]
 .Integration-manager workflow.
 image::images/integration-manager.png[Integration-manager workflow.]
 
 (((forking)))
-This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see.
-One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time.
-Contributors don't have to wait for the project to incorporate their changes – each party can work at their own pace.
+Ini adalah alur kerja yang sangat umum dengan alat berbasis hub seperti GitHub atau GitLab, dimana mudah untuk mengerjakan proyek dan push perubahan Anda ke garpu Anda untuk dilihat semua orang.
+Salah satu keuntungan utama dari pendekatan ini adalah Anda dapat terus bekerja, dan pengelola repositori utama dapat menarik perubahan Anda kapan saja.
+Kontributor tidak perlu menunggu proyek memasukkan perubahan mereka – Masing-masing pihak bisa bekerja dengan kecepatan mereka sendiri.
 
 ==== Dictator and Lieutenants Workflow
 
 (((workflows, dictator and lieutenants)))
-This is a variant of a multiple-repository workflow.
-It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel.
-Various integration managers are in charge of certain parts of the repository; they're called lieutenants.
-All the lieutenants have one integration manager known as the benevolent dictator.
-The benevolent dictator's repository serves as the reference repository from which all the collaborators need to pull.
-The process works like this (see <<wfdiag_c>>):
-
-1.  Regular developers work on their topic branch and rebase their work on top of `master`.
-    The `master` branch is that of the dictator.
-2.  Lieutenants merge the developers' topic branches into their `master` branch.
-3.  The dictator merges the lieutenants' `master` branches into the dictator's `master` branch.
-4.  The dictator pushes their `master` to the reference repository so the other developers can rebase on it.
+Ini adalah varian dari alur kerja multi-repositori.
+Ini umumnya digunakan oleh proyek besar dengan ratusan kolaborator; Salah satu contoh yang terkenal adalah kernel Linux.
+Berbagai manajer integrasi bertanggung jawab atas bagian-bagian tertentu dari repositori; mereka disebut letnan.
+Semua letnan memiliki satu manajer integrasi yang dikenal sebagai diktator yang baik hati.
+Repositori diktator baik hati tersebut berfungsi sebagai repositori referensi dari mana semua kolaborator perlu pull.
+Proses pekerjaannya seperti ini (see <<wfdiag_c>>):
+
+1.  Pengembang reguler bekerja pada cabang topik mereka sendiri dan mendasarkan ulang pekerjaan mereka di atas dari `master`.
+    seorang `master` cabang adalah milik diktator.
+2.  Letnan menggabungkan cabang topik pengembang menjadi cabang `master` mereka.
+3.  Diktator menggabungkan cabang letnan 'master` ke cabang `master` sang diktator.
+4.  Diktator pushes `master` mereka ke repositori referensi sehingga pengembang lainnya dapat mendasarkan ulang di atasnya.
 
 [[wfdiag_c]]
 .Benevolent dictator workflow.
 image::images/benevolent-dictator.png[Benevolent dictator workflow.]
 
-This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments.
-It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
+Alur kerja seperti ini tidak umum, namun bisa bermanfaat dalam proyek yang sangat besar, atau di lingkungan yang sangat hierarkis.
+Hal ini memungkinkan pemimpin proyek (the dictator)untuk mendelegasikan sebagian besar pekerjaan dan mengumpulkan himpunan bagian kode yang besar di banyak titik sebelum mengintegrasikannya.
 
 ==== Workflows Summary
 
-These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow.
-Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows.
-In the next section, you'll learn about a few common patterns for contributing to a project.
+Ini adalah beberapa alur kerja yang umum digunakan yang mungkin dilakukan dengan sistem terdistribusi seperti Git, namun anda dapat melihat Bahwa banyak variasi mungkin sesuai dengan alur kerja dunia nyata Anda.
+Sekarang Anda bisa (hopefully) menentukan kombinasi alur kerja mana yang sesuai untuk Anda, kami akan membahas beberapa contoh yang lebih Spesifik bagaimana cara mencapai peran utama yang membentuk arus yang berbeda.
+Di bagian selanjutnya, Anda akan belajar tentang beberapa pola umum untuk berkontribusi dalam sebuah proyek.