Git
Jawaban ini termasuk GitHub karena banyak orang bertanya tentang itu juga.
Repositori lokal
Git (lokal) memiliki direktori ( .git) tempat Anda mengkomit file Anda dan ini adalah 'repositori lokal' Anda. Ini berbeda dari sistem seperti SVN tempat Anda menambahkan dan langsung berkomitmen ke repositori jarak jauh.
Git menyimpan setiap versi file yang berubah dengan menyimpan seluruh file. Ini juga berbeda dari SVN dalam hal ini karena Anda dapat pergi ke versi individual apa pun tanpa 'membuat ulang' melalui perubahan delta.
Git tidak 'mengunci' file sama sekali dan dengan demikian menghindari fungsi 'kunci eksklusif' untuk diedit (sistem lama seperti pvc datang ke pikiran), sehingga semua file selalu dapat diedit, bahkan ketika offline. Ini sebenarnya melakukan pekerjaan yang luar biasa untuk menggabungkan perubahan file (dalam file yang sama!) Bersama selama menarik atau mengambil / mendorong ke repositori jarak jauh seperti GitHub. Satu-satunya waktu Anda perlu melakukan perubahan manual (sebenarnya mengedit file) adalah jika dua perubahan melibatkan baris kode yang sama.
Ranting
Cabang memungkinkan Anda untuk mempertahankan kode utama (cabang 'master'), membuat salinan (cabang baru) dan kemudian bekerja di dalam cabang baru itu. Jika pekerjaan memerlukan waktu atau master mendapatkan banyak pembaruan sejak cabang dibuat maka penggabungan atau rebasing (sering lebih disukai untuk sejarah yang lebih baik dan lebih mudah untuk menyelesaikan konflik) terhadap cabang master harus dilakukan. Setelah selesai, Anda menggabungkan perubahan yang dibuat di cabang kembali ke repositori master. Banyak organisasi menggunakan cabang untuk setiap karya apakah itu fitur, bug atau item tugas. Organisasi lain hanya menggunakan cabang untuk perubahan besar seperti peningkatan versi.
Fork: Dengan cabang Anda mengontrol dan mengelola cabang, sedangkan dengan garpu orang lain mengontrol menerima kode kembali.
Secara umum, ada dua pendekatan utama untuk melakukan cabang. Yang pertama adalah menjaga sebagian besar perubahan pada cabang master, hanya menggunakan cabang untuk hal-hal yang lebih besar dan berjalan lebih lama seperti perubahan versi di mana Anda ingin memiliki dua cabang tersedia untuk kebutuhan yang berbeda. Yang kedua adalah di mana Anda pada dasarnya membuat cabang untuk setiap permintaan fitur, memperbaiki bug atau tugas dan kemudian secara manual memutuskan kapan untuk benar-benar menggabungkan cabang-cabang tersebut ke cabang master utama. Walaupun ini terdengar membosankan, ini adalah pendekatan yang umum dan merupakan salah satu yang saat ini saya gunakan dan rekomendasikan karena ini membuat master branch cleaner dan master yang kami promosikan untuk produksi, jadi kami hanya ingin menyelesaikan, menguji kode, melalui rebasing dan penggabungan cabang.
Cara standar untuk membawa cabang 'dalam' untuk dikuasai adalah dengan melakukan a merge. Cabang-cabang juga bisa "diubah" menjadi 'membersihkan' sejarah. Ini tidak memengaruhi kondisi saat ini dan dilakukan untuk memberikan riwayat 'bersih'.
Pada dasarnya, idenya adalah Anda bercabang dari titik tertentu (biasanya dari master). Sejak Anda bercabang, 'master' itu sendiri telah bergerak maju dari titik percabangan itu. Ini akan menjadi 'lebih bersih' (lebih mudah untuk menyelesaikan masalah dan sejarah akan lebih mudah dipahami) jika semua perubahan yang Anda lakukan di cabang dimainkan melawan kondisi master saat ini dengan semua perubahan terbaru. Jadi, prosesnya adalah: menyimpan perubahan; dapatkan master 'baru', dan kemudian terapkan kembali (ini adalah bagian rebase) perubahan lagi terhadap itu. Sadarilah bahwa rebase, seperti penggabungan, dapat menghasilkan konflik yang harus Anda selesaikan secara manual (yaitu, edit dan perbaiki).
Satu pedoman yang perlu diperhatikan:
Hanya rebase jika cabang lokal dan Anda belum mendorongnya ke jauh!
Ini terutama karena rebasing dapat mengubah sejarah yang dilihat orang lain yang mungkin termasuk komitmen mereka sendiri.
Cabang pelacakan
Ini adalah cabang-cabang yang dinamai origin/branch_name(sebagai lawan dari adil branch_name). Ketika Anda mendorong dan menarik kode ke / dari repositori jarak jauh ini sebenarnya adalah mekanisme yang melaluinya. Misalnya, ketika Anda git pushcabang dipanggil building_groups, cabang Anda pergi pertama ke origin/building_groupsdan kemudian pergi ke repositori jarak jauh. Demikian pula, jika Anda melakukan git fetch building_groups, file yang diambil ditempatkan di origin/building_groupscabang Anda . Anda kemudian dapat memilih untuk menggabungkan cabang ini ke salinan lokal Anda. Praktik kami adalah untuk selalu melakukan a git fetchdan manual menggabungkan daripada hanya git pull(yang melakukan kedua hal di atas dalam satu langkah).
Mengambil cabang baru.
Mendapatkan cabang baru: Pada titik awal kloning, Anda akan memiliki semua cabang. Namun, jika pengembang lain menambahkan cabang dan mendorong mereka ke jarak jauh, perlu ada cara untuk 'mengetahui' tentang cabang-cabang dan nama-nama mereka untuk dapat menarik mereka secara lokal. Ini dilakukan melalui git fetchyang akan mendapatkan semua cabang baru dan yang diubah ke repositori lokal menggunakan cabang pelacakan (misalnya, origin/). Setelah fetchdiedit, Anda dapat git branch --remotemendaftar cabang pelacakan dan git checkout [branch]untuk benar-benar beralih ke cabang tertentu.
Penggabungan
Penggabungan adalah proses menggabungkan perubahan kode dari cabang yang berbeda, atau dari versi yang berbeda dari cabang yang sama (misalnya ketika cabang lokal dan remote tidak sinkron). Jika seseorang telah mengembangkan pekerjaan di cabang dan pekerjaan itu selesai, siap dan diuji, maka itu dapat digabungkan ke dalam mastercabang. Ini dilakukan dengan git checkout masterberalih ke mastercabang, lalu git merge your_branch. Penggabungan akan menyatukan semua file yang berbeda dan bahkan perubahan yang berbeda untuk file yang sama. Ini berarti bahwa itu benar-benar akan mengubah kode di dalam file untuk menggabungkan semua perubahan.
Ketika melakukan checkoutdari masteritu juga dianjurkan untuk melakukan git pull origin masteruntuk mendapatkan versi paling terakhir dari master terpencil digabung menjadi tuan setempat. Jika master jarak jauh berubah, yaitu moved forward, Anda akan melihat informasi yang mencerminkan itu selama itu git pull. Jika itu masalahnya (master berubah) Anda disarankan untuk git checkout your_branchkemudian rebasemenguasainya sehingga perubahan Anda benar-benar 'diputar ulang' di atas master 'baru'. Kemudian Anda akan terus mendapatkan master yang terbaru seperti yang ditunjukkan pada paragraf berikutnya.
Jika tidak ada konflik, maka master akan menambahkan perubahan baru. Jika ada konflik, ini berarti bahwa file yang sama memiliki perubahan di sekitar baris kode yang sama yang tidak dapat digabungkan secara otomatis. Dalam hal ini git merge new_branchakan melaporkan bahwa ada konflik yang harus diselesaikan. Anda 'menyelesaikannya' dengan mengedit file (yang akan memiliki kedua perubahan di dalamnya), memilih perubahan yang Anda inginkan, menghapus baris-baris dari perubahan yang tidak Anda inginkan dan kemudian menyimpan file. Perubahan ditandai dengan pemisah seperti ========dan <<<<<<<<.
Setelah Anda menyelesaikan konflik apa pun, Anda akan sekali lagi git adddan git commitperubahan itu untuk melanjutkan penggabungan (Anda akan mendapatkan umpan balik dari git selama proses ini untuk memandu Anda).
Ketika proses tidak bekerja dengan baik, Anda akan menemukan bahwa git merge --abortsangat berguna untuk mengatur ulang berbagai hal.
Rebasing interaktif dan squashing / pemesanan ulang / menghapus komitmen
Jika Anda telah melakukan pekerjaan dalam banyak langkah kecil, misalnya, Anda mengkomit kode sebagai 'work-in-progress' setiap hari, Anda mungkin ingin 'menghancurkan' banyak komit kecil menjadi beberapa komit yang lebih besar. Ini bisa sangat berguna ketika Anda ingin melakukan review kode dengan rekan kerja. Anda tidak ingin memutar ulang semua 'langkah' yang Anda ambil (melalui komit), Anda hanya ingin mengatakan di sini adalah efek akhir (beda) dari semua perubahan saya untuk pekerjaan ini dalam satu komit.
Faktor kunci untuk mengevaluasi ketika mempertimbangkan apakah akan melakukan ini adalah apakah banyak komit terhadap file yang sama atau lebih dari sekali (lebih baik untuk squash melakukan dalam kasus itu). Ini dilakukan dengan alat rebasing interaktif. Alat ini memungkinkan Anda menekan komit, menghapus komit, menulis ulang pesan, dll. Misalnya, git rebase -i HEAD~10( perhatikan: itu a ~, bukan a- ) menampilkan hal-hal berikut:
Berhati-hatilah dan gunakan alat ini 'dengan hati-hati'. Lakukan satu squash / delete / reorder pada satu waktu, keluar dan simpan komit itu, kemudian masukkan kembali alat. Jika komit tidak bersebelahan, Anda dapat memesan ulang (dan kemudian squash sesuai kebutuhan). Anda sebenarnya dapat menghapus komit di sini juga, tetapi Anda benar-benar harus yakin dengan apa yang Anda lakukan saat melakukannya!
Garpu
Ada dua pendekatan utama untuk kolaborasi dalam repositori Git. Yang pertama, dirinci di atas, adalah langsung melalui cabang yang ditarik dan didorong orang dari / ke. Kolaborator ini memiliki kunci SSH mereka yang terdaftar di repositori jarak jauh. Ini akan membiarkan mereka mendorong langsung ke repositori itu. Kelemahannya adalah Anda harus mempertahankan daftar pengguna. Pendekatan lain - forking - memungkinkan siapa saja untuk 'fork' repositori, pada dasarnya membuat salinan lokal di akun repositori Git mereka sendiri. Mereka kemudian dapat melakukan perubahan dan ketika selesai mengirim 'permintaan tarik' (sebenarnya itu lebih merupakan 'dorongan' dari mereka dan permintaan 'tarik' untuk pengelola repositori yang sebenarnya) untuk mendapatkan kode yang diterima.
Metode kedua ini, menggunakan garpu, tidak mengharuskan seseorang untuk mempertahankan daftar pengguna untuk repositori.
GitHub
GitHub (repositori jarak jauh) adalah sumber jarak jauh yang biasanya Anda tekan dan tarik perubahan yang dilakukan jika Anda memiliki (atau ditambahkan ke) repositori tersebut, sehingga lokal dan jarak jauh sebenarnya cukup berbeda. Cara lain untuk memikirkan repositori jarak jauh adalah bahwa itu adalah .gitstruktur direktori yang hidup di server jauh.
Ketika Anda 'bercabang' - di GUI browser web GitHub Anda dapat mengklik tombol ini 
- Anda membuat salinan ('klon') dari kode di akun GitHub Anda . Ini bisa menjadi sedikit halus pertama kali Anda melakukannya, jadi tetap pastikan Anda melihat repositori yang basis kode-nya terdaftar di bawah - baik pemilik asli atau 'bercabang dari' dan Anda, misalnya, seperti ini:
Setelah memiliki salinan lokal, Anda dapat membuat perubahan sesuai keinginan (dengan menarik dan mendorongnya ke mesin lokal). Ketika Anda selesai maka Anda mengirimkan 'tarik permintaan' ke pemilik / admin repositori asli (terdengar mewah tetapi sebenarnya Anda cukup mengklik ini 
:) dan mereka 'menariknya'.
Yang lebih umum untuk tim yang mengerjakan kode bersama adalah 'mengkloning' repositori (klik ikon 'salin' di layar utama repositori). Kemudian, ketik git clonedan tempel secara lokal . Ini akan mengatur Anda secara lokal dan Anda juga dapat mendorong dan menarik ke lokasi GitHub (dibagi).
Klon
Seperti yang ditunjukkan di bagian GitHub, klon adalah salinan dari repositori. Ketika Anda memiliki repositori jarak jauh, Anda mengeluarkan git cloneperintah terhadap URL-nya dan Anda kemudian berakhir dengan salinan lokal, atau kloning, dari repositori. Klon ini memiliki segalanya , file, cabang master, cabang lainnya, semua komit yang ada, seluruh shebang. Klon inilah yang membuat Anda melakukan penambahan dan komit, lalu repositori jarak jauh itu sendiri yang mendorongnya. Konsep lokal / jarak jauh inilah yang menjadikan Git (dan sistem yang serupa dengannya seperti Mercurial) menjadi DVCS ( Sistem Kontrol Versi Terdistribusi ) yang bertentangan dengan CVS (Sistem Versi Kode) yang lebih tradisional seperti SVN, PVCS, CVS, dll. Anda komit langsung ke repositori jarak jauh.
Visualisasi
Visualisasi konsep inti dapat dilihat di
http://marklodato.github.com/visual-git-guide/index-en.html dan
http://ndpsoftware.com/git-cheatsheet.html#loc=index
Jika Anda ingin tampilan visual tentang bagaimana perubahan bekerja, Anda tidak bisa mengalahkan alat visual gitg( gitxuntuk macOS) dengan GUI yang saya sebut 'peta kereta bawah tanah' (terutama London Underground), bagus untuk menunjukkan siapa yang melakukan apa, bagaimana hal berubah, menyimpang dan bergabung, dll.
Anda juga dapat menggunakannya untuk menambah, melakukan, dan mengelola perubahan Anda!
Meskipun gitg / gitx cukup minim, jumlah alat GUI terus berkembang. Banyak pengguna Mac menggunakan forb gitx fork dan untuk Linux, opsi yang bagus adalah smart-git dengan antarmuka yang intuitif namun kuat:
Perhatikan bahwa bahkan dengan alat GUI, Anda mungkin akan melakukan banyak perintah di baris perintah.
Untuk ini, saya memiliki alias berikut di ~/.bash_aliasesfile saya (yang dipanggil dari ~/.bashrcfile saya untuk setiap sesi terminal):
# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '
DAN saya memiliki "alias git" berikut dalam ~/.gitconfigfile saya - mengapa memilikinya?
Sehingga penyelesaian cabang (dengan kunci TAB) berfungsi!
Jadi ini adalah:
[alias]
co = checkout
cob = checkout -b
Contoh penggunaan: git co [branch]<- penyelesaian tab untuk cabang akan berfungsi.
Alat Belajar GUI
Anda dapat menemukan https://learngitbranching.js.org/ berguna dalam mempelajari beberapa konsep dasar. Cuplikan layar:
Video: https://youtu.be/23JqqcLPss0
Akhirnya, 7 penyelamat utama!
Anda membuat perubahan, menambah dan mengkomitnya (tetapi jangan mendorong) dan kemudian oh! Anda sadar bahwa Anda adalah master!
git reset [filename(s)]
git checkout -b [name_for_a_new_branch]
git add [file(s)]
git commit -m "A useful message"
Voila! You've moved that 'master' commit to its own branch !
Anda mengacaukan beberapa file saat bekerja di cabang lokal dan hanya ingin kembali ke apa yang terakhir kali Anda lakukan git pull:
git reset --hard origin/master # You will need to be comfortable doing this!
Anda mulai membuat perubahan secara lokal, Anda mengedit setengah lusin file dan kemudian, oh sial, Anda masih di cabang master (atau yang lain):
git checkout -b new_branch_name # just create a new branch
git add . # add the changes files
git commit -m"your message" # and commit them
Anda mengacaukan satu file tertentu di cabang Anda saat ini dan pada dasarnya ingin 'mereset' file itu (kehilangan perubahan) menjadi bagaimana itu terakhir kali Anda menariknya dari repositori jarak jauh:
git checkout your/directories/filename
Ini sebenarnya me-reset file (seperti banyak perintah Git itu tidak bernama dengan baik untuk apa yang dilakukannya di sini).
Anda membuat beberapa perubahan secara lokal, Anda ingin memastikan Anda tidak kehilangan mereka saat Anda melakukan git resetatau rebase: Saya sering membuat salinan manual dari seluruh proyek ( cp -r ../my_project ~/) ketika saya tidak yakin apakah saya mungkin mengacaukan Git atau kehilangan penting perubahan.
Anda rebasing tetapi hal-hal menjadi kacau:
git rebase --abort # To abandon interactive rebase and merge issues
Tambahkan cabang Git Anda ke PS1prompt Anda (lihat https://unix.stackexchange.com/a/127800/10043 ), mis.
Cabang itu selenium_rspec_conversion.
