---
title: "Bekerja dengan Git dan GitHub"
version: 5.0
locale: id
source: https://docs.djangoproject.com/id/5.0/internals/contributing/writing-code/working-with-git/
canonical: https://djangodocs.dev/id/5.0/internals/contributing/writing-code/working-with-git/
---
# Bekerja dengan Git dan GitHub

This section explains how the community can contribute code to Django via pull
requests. If you're interested in how [mergers](/id/5.0/internals/organization/#mergers-team) handle
them, see [Memperbaiki kode](/id/5.0/internals/contributing/committing-code/).

Dibawah ini, kami akan menunjukkan bagaimana membuat pull request GitHub mengandung perubahan untuk tiket Trac #xxxxx. Dengan membuat pull request sepenuhnya siap, anda akan membuat pekerjaan peninjau lebih mudah, berarti bahwa pekerjaan anda lebih mungkin digabungkan kedalam Django.

Anda dapat juga menunggah tambalan tradisional ke Trac, tetapi dia kurang praktis untuk peninjauan.

## Memasang Git

Django menggunakan [Git](https://git-scm.com/) untuk kendali sumbernya. Anda dapat mengunduh Git [download](https://git-scm.com/download), tetapi itu terkadang lebih mudah memasang dengan pengelola paket sistem operasi anda.

[Git repository](https://github.com/django/django/) Django disimpan di [GitHub](https://github.com/), dan itu dianjurkan bahwa anda juga bekerja menggunakan GitHub.

After installing Git, the first thing you should do is set up your name and
email:

```shell
$ git config --global user.name "Your Real Name"
$ git config --global user.email "you@email.com"
```

Catat bahwa `user.name` harus nama asli anda, bukan nama pendek GitHub. GitHub harus tahu surel anda gunakan di bidang `user.email`, karena ini akan digunakan untuk menghubungkan perbaikan anda ke akun GitHub anda.

## Mengatur gudang lokal

When you have created your GitHub account, with the nick "GitHub\_nick", and
[forked Django's repository](https://github.com/django/django/fork),
create a local copy of your fork:

```shell
git clone https://github.com/GitHub_nick/django.git
```

This will create a new directory "django", containing a clone of your GitHub
repository. The rest of the git commands on this page need to be run within the
cloned directory, so switch to it now:

```shell
cd django
```

Gudang GitHub anda akan dipanggil "origin" dalam Git.

You should also set up `django/django` as an "upstream" remote (that is, tell
git that the reference Django repository was the source of your fork of it):

```shell
git remote add upstream https://github.com/django/django.git
git fetch upstream
```

You can add other remotes similarly, for example:

```shell
git remote add akaariai https://github.com/akaariai/django.git
```

## Bekerja pada tiket

When working on a ticket, create a new branch for the work, and base that work
on `upstream/main`:

```shell
git checkout -b ticket_xxxxx upstream/main
```

Bendera -b membuat cabang baru untuk anda secara lokal. Jangan ragu-ragu membuat cabang-cabang baru bahkan untu hal-hal terkecil - itulah apa mereka ada.

If instead you were working for a fix on the 1.4 branch, you would do:

```shell
git checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x
```

Assume the work is carried on the ticket\_xxxxx branch. Make some changes and
commit them:

```shell
git commit
```

When writing the commit message, follow the [commit message
guidelines](/id/5.0/internals/contributing/committing-code/#committing-guidelines) to ease the work of the merger. If you're
uncomfortable with English, try at least to describe precisely what the commit
does.

If you need to do additional work on your branch, commit as often as
necessary:

```shell
git commit -m 'Added two more tests for edge cases'
```

### Menerbitkan pekerjaan

You can publish your work on GitHub by running:

```shell
git push origin ticket_xxxxx
```

Ketika anda pergi ke halaman GitHub, anda akan melihat cabang baru telah dibuat.

Jika anda sedang bekerja pada tiket Trac, anda harus menyebutkan dalam tiket yang pekerjaan anda tersedia dari cabang ticket\_xxxxx dari gudang GitHub. Sertakan sebuah tautan pada cabang anda.

Catat bahwa cabang diatas dipanggil "topic branch" di bahasa Git. Anda bebas menulis kembali riwayat dari cabang ini, dengan menggunakan `git rebase` sebagai contoh. Orang lain tidak harus dasarkan pekerjaan mereka pada cabang seperti itu, karena kloningan mereka akan menjadi rusak ketika anda menyunting perbaikan.

There are also "public branches". These are branches other people are supposed
to fork, so the history of these branches should never change. Good examples
of public branches are the `main` and `stable/A.B.x` branches in the
`django/django` repository.

Ketika anda berpikir pekerjaan anda siap untuk ditarik ke Django, anda harus membuat sebuah pull request pada GitHub. Pull request baik artinya:

- perbaiki dengan satu perubahan logika di setiapnya, mengikuti [coding style](/id/5.0/internals/contributing/writing-code/coding-style/),
- Pesan-pesan berbentuk baik untuk setiap perbaikan: sebuah baris ringkasan dan kemudian paragraf dibungkus pada 72 karakter setelah itu -- lihat [committing guidelines](/id/5.0/internals/contributing/committing-code/#committing-guidelines) untuk lebih rinci,
- dokumentasi dan percobaan, jika dibutuhkan -- percobaan sebenarnya selalu dibutuhkan, kecuali untuk perubahan dokumentasi.

Rangkaian percobaan harus dilewati dan dokumentasi harus dibangun tanpa peringatan.

Sekali anda telah membuat pull request anda, anda harus menambahkan sebuah komentar di tiket Trac terkait menjelaskan apa yang telah anda lakukan. Khususnya, anda harus catat lingkungan dimana anda menjalankan percobaan, sebagai contoh: "semua percobaan lolos dibawah SQLite dan MySQL".

Pull requests at GitHub have only two states: open and closed. The merger who
will deal with your pull request has only two options: merge it or close it.
For this reason, it isn't useful to make a pull request until the code is ready
for merging -- or sufficiently close that a merger will finish it themselves.

### Rebase cabang-cabang

Di contoh diatas, anda membuat dua perbaikan, perbaikan "Fixed ticket\_xxxxx" dan perbaikan "Added two more tests".

Kami tidak ingin memiliki seluruh riwayat dari pengolahan pekerjaan anda di gudang anda. Perbaikan anda "Added two more tests" akan menjadi kebisingan yang tidak membantu. Malahan, kami bukan hanya mempunyai satu perbaikan mengandung semua pekerjaan anda.

To rework the history of your branch you can squash the commits into one by
using interactive rebase:

```shell
git rebase -i HEAD~2
```

HEAD~2 diatas adalah tangan cepat untuk dua perbaikan terakhir. Perintah diatas akan membuka sebuah penyunting menunjukkan dua perbaikan, diawali dengan kata "pick".

Rubah "pick" pada baris kedua pada "squash" sebagai gantinya. Ini akan menjaga perbaikan pertama, dan melumat perbaikan kedua kedalam yang pertama. Simpan dan hemtikan penyunting. Jendela penyunting kedua harus terbuka, jadi anda dapat menaruh kata lain pesan perbaikan untuk perbaikan sekarang dimana dia menyertakan kedua langkah-langkah anda.

You can also use the "edit" option in rebase. This way you can change a single
commit, for example to fix a typo in a docstring:

```shell
git rebase -i HEAD~3
# Choose edit, pick, pick for the commits
# Now you are able to rework the commit (use git add normally to add changes)
# When finished, commit work with "--amend" and continue
git commit --amend
# Reword the commit message if needed
git rebase --continue
# The second and third commits should be applied.
```

If your topic branch is already published at GitHub, for example if you're
making minor changes to take into account a review, you will need to force-push
the changes:

```shell
git push -f origin ticket_xxxxx
```

Catat bahwa ini akan menulis kembali riwayat dari ticket\_xxxxx - jika anda memeriksa campuran commit sebelum dan sesudah tindakan pada GitHub anda akan menyadari bahwa campuran commit tidak cocok lagi. Ini dapat diterima, ketika cabang adalah cabang topik, dan tidak seorangpun harus mendasarkan pekerjaannya pada itu.

### Setelah upstream telah berubah

When upstream (`django/django`) has changed, you should rebase your work. To
do this, use:

```shell
git fetch upstream
git rebase upstream/main
```

The work is automatically rebased using the branch you forked on, in the
example case using `upstream/main`.

Perintah rebase memindahkan semua perbaikan lokal sementara, berlakukan perbaikan upstream, dan kemudian berlakukan perbaikan lokal anda pada pekerjaan.

Jika ada pertentangan penggabungan, anda akan butuh menyelesaikan mereka dan kemudian menggunakan `git rebase --continue`. Pada tiap titik anda dapat menggunakan `git rebase --abort` untuk mengembalikan ke keadaan asli.

Catat bahwa anda ingin *rebase* pada upstream, bukan *merge* upstream.

Alasan untuk ini adalah dengan rebase, perbaikan anda akan selalu *on top of* pekerjaan upstream, bukan *mixed in with* perubahan di upstream. Cara ini cabang anda akan mengandung hanya perbaikan terhubung pada topiknya, yang membuat pelumatan lebiih mudah.

### Setelah meninjau

Itu tidak biasa mendapatkan setiap jumlah bukan sepele dari kode kedalam inti tanpa perubahan diminta oleh peninjau. Di kasus ini, itu adalah sering ide bagus untuk menambahkan perubahan sebagai perbaikan menaik pada pekerjaan anda. Ini mengizinkan peninjau dengan mudah memeriksa perubahan apa anda telah lakukan.

In this case, do the changes required by the reviewer. Commit as often as
necessary. Before publishing the changes, rebase your work. If you added two
commits, you would run:

```shell
git rebase -i HEAD~2
```

Squash the second commit into the first. Write a commit message along the lines
of:

```text
Made changes asked in review by <reviewer>

- Fixed whitespace errors in foobar
- Reworded the docstring of bar()
```

Finally, push your work back to your GitHub repository. Since you didn't touch
the public commits during the rebase, you should not need to force-push:

```shell
git push origin ticket_xxxxx
```

Pull request anda sekarang harus mengandung perbaikan baru juga.

Note that the merger is likely to squash the review commit into the previous
commit when committing the code.

## Bekerja pada tambalan

One of the ways that developers can contribute to Django is by reviewing
patches. Those patches will typically exist as pull requests on GitHub and
can be easily integrated into your local repository:

```shell
git checkout -b pull_xxxxx upstream/main
curl -L https://github.com/django/django/pull/xxxxx.patch | git am
```

Ini akan membuat cabang baru dan kemudian memberlakukan perubahan dari pull request ke itu. Pada titik ini anda dapat menjalankan percobaan atau melakukan apapun lainnya anda butuhkan untuk menyelidiki kualitas tambalan.

For more detail on working with pull requests see the
[guidelines for mergers](/id/5.0/internals/contributing/committing-code/#handling-pull-requests).

## Ringkasan

- Bekerja pada GitHub jika anda bisa.
- Umumkan pekerjaan anda di tiket Trac dengan menautkan ke cabang GitHub anda.
- Ketika anda mempunyai sesuatu yang siap, buat pull request.
- Buat pull request sebaik anda bisa.
- Ketika melakukan perbaikan ke pekerjaan anda, gunakan `git rebase -i` untuk melumat perbaikan.
- Ketika upstream telah dirubah, lakukan `git fetch upstream; git rebase`.