Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
101 changes: 51 additions & 50 deletions book/06-github/sections/3-maintaining.asc
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
[[_maintaining_gh_project]]
=== Maintaining a Project
=== Perawatan Sebuah Proyek

Now that we're comfortable contributing to a project, let's look at the other side: creating, maintaining and administering your own project.
Sekarang setelah kita berkontribusi dalam sebuah proyek, mari kita lihat sisi lain: membuat, merawat dan mengelola proyek Anda sendiri.

==== Creating a New Repository
==== Membuat Repositori Baru

Let's create a new repository to share our project code with.
Start by clicking the ``New repository'' button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>.
Mari kita membuat repositori baru untuk berbagi kode proyek.
Mulailah dengan mengklik tombol ``New repository'' di sisi kanan dasbor, atau dari tombol `+` di toolbar atas di sebelah nama pengguna Anda seperti yang terlihat di <<_new_repo_dropdown>>.

.The ``Your repositories'' area.
image::images/newrepo.png[The ``Your repositories'' area.]
Expand All @@ -15,102 +15,102 @@ image::images/newrepo.png[The ``Your repositories'' area.]
.The ``New repository'' dropdown.
image::images/new-repo.png[The ``new repository'' dropdown.]

This takes you to the ``new repository'' form:
Ini membawa Anda ke formulir ``new repository'':

.The ``new repository'' form.
image::images/newrepoform.png[The ``new repository'' form.]

All you really have to do here is provide a project name; the rest of the fields are completely optional.
For now, just click the ``Create Repository'' button, and boomyou have a new repository on GitHub, named `<user>/<project_name>`.
Yang harus Anda lakukan di sini adalah memberikan nama proyek; sisa field yang lain sepenuhnya tambahan.
Untuk saat ini, cukup klik tombol ``Create Repository'', dan berhasilAnda memiliki repositori baru di GitHub, bernama `<user>/<project_name>`.

Since you have no code there yet, GitHub will show you instructions for how create a brand-new Git repository, or connect an existing Git project.
We won't belabor this here; if you need a refresher, check out <<_git_basics_chapter>>.
Karena Anda belum memiliki kode, GitHub akan menunjukkan petunjuk bagaimana membuat repositori Git yang baru, atau menghubungkan ke proyek Git yang ada.
Kita tidak akan mengulangi hal ini di sini; jika Anda membutuhkan penyegaran, cek di <<_git_basics_chapter>>.

Now that your project is hosted on GitHub, you can give the URL to anyone you want to share your project with.
Every project on GitHub is accessible over HTTP as `https://github.com/<user>/<project_name>`, and over SSH as `[email protected]:<user>/<project_name>`.
Git can fetch from and push to both of these URLs, but they are access-controlled based on the credentials of the user connecting to them.
Setelah proyek Anda di-host-kan di GitHub, Anda dapat memberikan URL kepada siapa pun yang ingin Anda bagikan proyek Anda.
Setiap proyek di GitHub dapat diakses melalui HTTP sebagai `https://github.com/<user>/<project_name>`, dan lebih dari SSH sebagai `[email protected]:<user>/<project_name>`.
Git dapat diambil dari dan di-push ke kedua URL ini, namun akses terkontrol berdasarkan kepercayaan pengguna yang terhubung dengannya.

[NOTE]
====
It is often preferable to share the HTTP based URL for a public project, since the user does not have to have a GitHub account to access it for cloning. Users will have to have an account and an uploaded SSH key to access your project if you give them the SSH URL. The HTTP one is also exactly the same URL they would paste into a browser to view the project there.
Hal ini sering lebih baik untuk berbagi URL berbasis HTTP untuk proyek publik, karena pengguna tidak harus memiliki akun GitHub untuk mengaksesnya untuk kloning. Pengguna harus memiliki akun dan kunci SSH yang diupload untuk mengakses proyek Anda jika Anda memberi mereka URL SSH. URL HTTP juga sama persis dengan URL yang akan mereka tempel ke browser untuk melihat proyek di sana.
====

==== Adding Collaborators
==== Menambah Kolaborator

If you're working with other people who you want to give commit access to, you need to add them as ``collaborators''.
If Ben, Jeff, and Louise all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project.
Doing so will give them ``push'' access, which means they have both read and write access to the project and Git repository.
Jika Anda bekerja dengan orang lain yang ingin Anda beri akses commit, Anda perlu menambahkannya sebagai ``collaborators''.
Jika Ben, Jeff, dan Louise mendaftar ke akun GitHub, dan Anda ingin memberi mereka akses push ke repositori Anda, Anda dapat menambahkannya ke proyek Anda.
Dengan melakukan hal ini akan memberi mereka akses ``push'', yang berarti keduanya memiliki akses baca dan tulis ke proyek dan repositori Git.

Click the ``Settings'' link at the bottom of the right-hand sidebar.
Klik tautan ``Settings'' di bagian bawah sidebar kanan.

.The repository settings link.
image::images/reposettingslink.png[The repository settings link.]

Then select ``Collaborators'' from the menu on the left-hand side.
Then, just type a username into the box, and click ``Add collaborator.''
You can repeat this as many times as you like to grant access to everyone you like.
If you need to revoke access, just click the ``X'' on the right-hand side of their row.
Kemudian pilih ``Collaborators'' dari menu di sisi kiri.
Kemudian, ketik saja nama pengguna ke dalam kotak, dan klik ``Add collaborator.''
Anda dapat mengulangi ini sebanyak yang Anda inginkan untuk memberikan akses kepada semua orang yang Anda sukai.
Jika Anda perlu mencabut akses, klik saja ``X'' di sisi kanan baris itu.

.Repository collaborators.
image::images/collaborators.png[The repository collaborators box.]

==== Managing Pull Requests
==== Mengelola Pull Requests

Now that you have a project with some code in it and maybe even a few collaborators who also have push access, let's go over what to do when you get a Pull Request yourself.
Sekarang setelah Anda memiliki sebuah proyek dengan beberapa kode di dalamnya dan mungkin bahkan beberapa kolaborator yang juga memiliki akses push, mari kita membahas apa yang harus dilakukan saat Anda mendapatkan Pull Request.

Pull Requests can either come from a branch in a fork of your repository or they can come from another branch in the same repository. The only difference is that the ones in a fork are often from people where you can't push to their branch and they can't push to yours, whereas with internal Pull Requests generally both parties can access the branch.
Pull Request bisa berasal dari branch di fork repositori Anda atau branch lain di repositori yang sama. Perbedaannya adalah branch di fork biasanya berasal dari orang-orang dimana Anda tidak dapat melakukan push ke branch mereka dan mereka tidak dapat melakukan push ke branch Anda, sedangkan dengan Pull Request Internal umumnya, keduanya dapat mengakses branch tersebut.

For these examples, let's assume you are ``tonychacon'' and you've created a new Arudino code project named ``fade''.
Untuk contoh ini, mari kita anggap Anda adalah `tonychacon'' dan Anda telah membuat proyek kode Arudino baru yang bernama ``fade''.

[[_email_notifications]]
===== Email Notifications
===== Notifikasi Surel

Someone comes along and makes a change to your code and sends you a Pull Request. You should get an email notifying you about the new Pull Request and it should look something like <<_email_pr>>.
Seseorang bergabung dan membuat perubahan pada kode Anda dan mengirimkan Pull Request kepada Anda. Anda pasti mendapatkan surel yang memberi tahu Anda tentang Pull Request yang baru dan seharusnya terlihat seperti <<_email_pr>>.

[[_email_pr]]
.Email notification of a new Pull Request.
image::images/maint-01-email.png[Pull Request email notification]

There are a few things to notice about this email. It will give you a small diffstat -- a list of files that have changed in the Pull Request and by how much. It gives you a link to the Pull Request on GitHub. It also gives you a few URLs that you can use from the command line.
Ada beberapa hal yang harus diperhatikan mengenai surel ini. Ini akan memberi Anda diffstat pendek -- sebuah daftar berkas yang telah berubah dan seberapa banyak berubahnya di Pull Request tersebut. Ini memberikan Anda tautan ke Pull Request pada GitHub. Ini juga memberikan Anda beberapa URL yang dapat Anda gunakan dari baris perintah.

If you notice the line that says `git pull <url> patch-1`, this is a simple way to merge in a remote branch without having to add a remote. We went over this quickly in <<_checking_out_remotes>>. If you wish, you can create and switch to a topic branch and then run this command to merge in the Pull Request changes.
Jika Anda melihat baris yang mengatakan `git pull <url> patch-1`, ini adalah cara mudah untuk melakukan merge branch remote tanpa harus menambahkan remote. Kita membahasnya dengan cepat di <<_checking_out_remotes>>. Jika Anda mau, Anda dapat membuat dan beralih ke branch topik dan kemudian menjalankan perintah ini untuk di-merge-kan dalam perubahan Pull Request.

The other interesting URLs are the `.diff` and `.patch` URLs, which as you may guess, provide unified diff and patch versions of the Pull Request. You could technically merge in the Pull Request work with something like this:
URL menarik lainnya adalah URL `.diff` dan `.patch`, yang mungkin Anda duga, menyediakan versi diff dan patch terpadu dari Pull Request. Anda dapat melakukan merge secara teknis pekerjaan Pull Request dengan hal seperti ini:

[source,shell]
----
$ curl http://github.com/tonychacon/fade/pull/1.patch | git am
----

===== Collaborating on the Pull Request
===== Berkolaborasi di Pull Request

As we covered in <<_github_flow>>, you can now have a conversation with the person who opened the Pull Request. You can comment on specific lines of code, comment on whole commits or comment on the entire Pull Request itself, using GitHub Flavored Markdown everywhere.
Seperti yang kita bahas di <<_github_flow>>, Anda sekarang bisa melakukan percakapan dengan orang yang membuka Pull Request. Anda dapat mengomentari baris kode tertentu, mengomentari keseluruhan commit atau mengomentari seluruh Pull Request itu sendiri, dengan menggunakan GitHub Flavoured Markdown di mana-mana.

Every time someone else comments on the Pull Request you will continue to get email notifications so you know there is activity happening. They will each have a link to the Pull Request where the activity is happening and you can also directly respond to the email to comment on the Pull Request thread.
Setiap kali orang lain berkomentar mengenai Pull Request Anda akan terus mendapatkan notifikasi surel sehingga Anda tahu ada aktivitas yang sedang terjadi. Mereka masing-masing akan memiliki tautan ke Pull Request di mana aktivitas itu terjadi dan Anda juga dapat langsung menanggapi surel untuk memberi komentar pada thread Pull Request.

.Responses to emails are included in the thread.
image::images/maint-03-email-resp.png[Email response]

Once the code is in a place you like and want to merge it in, you can either pull the code down and merge it locally, either with the `git pull <url> <branch>` syntax we saw earlier, or by adding the fork as a remote and fetching and merging.
Setelah kode berada di tempat yang Anda suka dan ingin melakukan merge, Anda dapat melakukan pull kode ke bawah dan me-merge-kannya secara lokal, dengan sintaks `git pull <url> <branch>` yang telah kita lihat sebelumnya, atau dengan menambahkan fork sebagai remote dan pengambilan dan melakukan merge.

If the merge is trivial, you can also just hit the ``Merge'' buton on the GitHub site. This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. This means that no matter what, every time you hit the merge button, a merge commit is created. As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link.
Jika ingin merge yang mudah, Anda cukup menekan tombol ``Merge'' di situs GitHub. Ini akan melakukan merge ``non-fast-forward'', membuat commit merge bahkan jika merge cepat mungkin diteruskan. Ini berarti dalam keadaan apapun, setiap kali Anda menekan tombol merge, sebuah commit merge dibuat. Seperti yang bisa Anda lihat di <<_merge_button>>, GitHub memberi Anda semua informasi ini jika Anda mengklik tautan petunjuknya.

[[_merge_button]]
.Merge button and instructions for merging a Pull Request manually.
image::images/maint-02-merge.png[Merge button]

If you decide you don't want to merge it, you can also just close the Pull Request and the person who opened it will be notified.
Jika Anda memutuskan tidak ingin melakukan merge, Anda juga bisa menutup Pull Request dan orang yang membukanya akan diberitahu.

[[_pr_refs]]
===== Pull Request Refs

If you're dealing with a *lot* of Pull Requests and don't want to add a bunch of remotes or do one time pulls every time, there is a neat trick that GitHub allows you to do. This is a bit of an advanced trick and we'll go over the details of this a bit more in <<_refspec>>, but it can be pretty useful.
Jika Anda mempunyai *banyak* Pull Request dan tidak ingin menambahkan banyak remote atau satu kali melakukan pull setiap saat, ada trik bagus yang memungkinkan GitHub Anda lakukan. Trik ini adalah sedikit maju dan kita akan membahas rincian ini lebih banyak di <<_refspec>>, tapi ini dapat menjadi sangat berguna.

GitHub actually advertises the Pull Request branches for a repository as sort of pseudo-branches on the server. By default you don't get them when you clone, but they are there in an obscured way and you can access them pretty easily.
GitHub benar-benar mengiklankan branch Pull Request untuk repositori sebagai sejenis pseudo-branch di server. Secara default Anda tidak mendapatkannya ketika Anda mengkloning, tapi mereka berada di sana dengan cara yang tidak jelas dan Anda dapat mengaksesnya dengan mudah.

To demonstrate this, we're going to use a low-level command (often referred to as a ``plumbing'' command, which we'll read about more in <<_plumbing_porcelain>>) called `ls-remote`. This command is generally not used in day-to-day Git operations but it's useful to show us what references are present on the server.
Untuk menunjukkan ini, kita akan menggunakan perintah tingkat-rendah (sering disebut sebagai perintah ``plumbing'', yang akan kita baca lebih lanjut di <<_plumbing_porcelain>>) yang disebut `ls-remote`. Perintah ini umumnya tidak digunakan dalam operasi Git sehari-hari namun berguna untuk menunjukkan kepada kita referensi apa yang ada di server.

If we run this command against the ``blink'' repository we were using earlier, we will get a list of all the branches and tags and other references in the repository.
Jika kita menjalankan perintah ini terhadap repositori ``blink'' yang kita gunakan sebelumnya, kita akan mendapatkan daftar semua branch dan tag dan referensi lainnya di repositori.

[source,shell]
----
Expand All @@ -125,13 +125,13 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge
----

Of course, if you're in your repository and you run `git ls-remote origin` or whatever remote you want to check, it will show you something similar to this.
Tentu saja, jika Anda berada di repositori Anda dan Anda menjalankan `git ls-remote origin` atau remote yang ingin Anda periksa, itu akan menunjukkan sesuatu yang sama dengan ini.

If the repository is on GitHub and you have any Pull Requests that have been opened, you'll get these references that are prefixed with `refs/pull/`. These are basically branches, but since they're not under `refs/heads/` you don't get them normally when you clone or fetch from the server -- the process of fetching ignores them normally.
Jika repositori itu berada di GitHub dan Anda memiliki Pull Requests yang telah dibuka, Anda akan mendapatkan referensi yang diawali dengan `refs/pull/`. Referensi ini pada dasarnya adalah branch-branch, tapi karena tidak berada di bawah `refs/heads/` Anda tidak mendapatkannya secara normal saat Anda mengkloning atau mengambil dari server -- proses pengambilan mengabaikannya secara normal.

There are two references per Pull Request - the one that ends in `/head` points to exactly the same commit as the last commit in the Pull Request branch. So if someone opens a Pull Request in our repository and their branch is named `bug-fix` and it points to commit `a5a775`, then in *our* repository we will not have a `bug-fix` branch (since that's in their fork), but we _will_ have `pull/<pr#>/head` that points to `a5a775`. This means that we can pretty easily pull down every Pull Request branch in one go without having to add a bunch of remotes.
Ada dua referensi per Pull Request - yang satu berakhir pada `/head` mengarahkan ke commit yang sama seperti commit terakhir di branch Pull Request. Jadi jika seseorang membuka Pull Request di repositori kita dan branch mereka diberi nama `bug-fix` dan mengarahkan ke commit `a5a775`, maka di repositori *our* kita tidak akan memiliki branch `bug-fix` branch (karena itu berada di fork mereka), tapi kita _akan_ memiliki `pull/<pr#>/head` yang mengarahkan ke `a5a775`. Ini berarti kita dapat dengan mudah melakukan pull ke bawah setiap branch Pull Request dalam satu putaran tanpa harus menambahkan banyak remote.

Now, you could do something like fetching the reference directly.
Sekarang, Anda bisa melakukan sesuatu seperti mengambil referensi secara langsung.

[source,shell]
----
Expand All @@ -140,10 +140,11 @@ From https://github.com/libgit2/libgit2
* branch refs/pull/958/head -> FETCH_HEAD
----

This tells Git, ``Connect to the `origin` remote, and download the ref named `refs/pull/958/head`.''
Git happily obeys, and downloads everything you need to construct that ref, and puts a pointer to the commit you want under `.git/FETCH_HEAD`.
You can follow that up with `git merge FETCH_HEAD` into a branch you want to test it in, but that merge commit message looks a bit weird.
Also, if you're reviewing a *lot* of pull requests, this gets tedious.
Ini menginformasikan Git, ``Hubungkan ke remote `origin`, dan unduh ref yang bernama `refs/pull/958/head`.''
Git akan mengikuti dan mengunduh semua yang Anda butuhkan untuk membuat ref itu, dan meletakkan pointer ke commit yang Anda inginkan dibawah `.git/FETCH_HEAD`.
Anda dapat menggabungkannya dengan `git merge FETCH_HEAD` ike branch yang ingin Anda uji, tapi pesan commit merga akan sedikit aneh.

Begitu juga, jika Anda meninjau *banyak* pull request, ini menjadi lama.

There's also a way to fetch _all_ of the pull requests, and keep them up to date whenever you connect to the remote.
Open up `.git/config` in your favorite editor, and look for the `origin` remote.
Expand Down