├── .npmrc ├── public ├── cover.jpg ├── favicon.ico ├── seo-card.png ├── cover_small.jpg └── .gitbook │ └── assets │ ├── 04_gitlog.jpg │ ├── 04_tower.jpg │ ├── 05_dosya1.jpg │ ├── 01_branching.jpg │ ├── 02_git_reset.jpg │ ├── 03_git_diff.jpg │ ├── 03_git_fetch.jpg │ ├── 03_gitstatus.jpg │ ├── 04_conflict.jpg │ ├── 04_git_fetch.jpg │ ├── 05_gitlog_p.jpg │ ├── 06_git_push.jpg │ ├── 07_git_fetch.jpg │ ├── 07_git_stash.jpg │ ├── 08_git_push.jpg │ ├── 12_gitmerge.jpg │ ├── what-is-vcs.jpg │ ├── 01_git_revert.jpg │ ├── 03_git_branch.jpg │ ├── 04_git_branch_v.jpg │ ├── 04_local_diff.jpg │ ├── 05_git_status.jpg │ ├── 06_check_status.jpg │ ├── 06_diff_merge.jpg │ ├── 10_gitbranch_d.jpg │ ├── 13_gitmerge_log.jpg │ ├── 14_merge_commit.jpg │ ├── 01_git_remote_add.jpg │ ├── 02_git_branch_va.jpg │ ├── 07_tower_conflict.jpg │ ├── 08_git_stash_list.jpg │ ├── 09_git_branch_vva.jpg │ ├── 09_git_stash_pop.jpg │ ├── 11_git_stash_drop.jpg │ ├── 01_emptyprojectdir.jpg │ ├── 02_sourcetree_repo.jpg │ ├── 03_sourcetree_commit.jpg │ ├── 05_tower_workingcopy.jpg │ ├── 06_tower_commithist.jpg │ ├── 10_git_stash_apply.jpg │ ├── 05_git_checkout_track.jpg │ └── 01_sourcetree_bookmarks.jpg ├── app ├── assets │ ├── git.png │ ├── gitbook.png │ └── css │ │ └── main.css ├── components │ ├── MarkdownBlock.vue │ ├── navigation │ │ ├── sections │ │ │ ├── header.vue │ │ │ ├── top.vue │ │ │ └── index.vue │ │ ├── slider.vue │ │ ├── content.vue │ │ └── index.vue │ ├── card │ │ ├── book.vue │ │ └── community.vue │ ├── ButtonLink.vue │ ├── ColorModeSwitch.vue │ ├── AppNavbar.vue │ └── search.vue ├── stores │ ├── app.ts │ └── content.ts ├── layouts │ ├── full-width.vue │ └── content.vue ├── app.config.ts ├── types.ts ├── pages │ └── [...slug].vue └── app.vue ├── tsconfig.json ├── renovate.json ├── .gitignore ├── eslint.config.mjs ├── .vscode └── settings.json ├── content ├── git_arac_ve_servisleri │ ├── index.md │ ├── kaynakca_ve_referanslar.md │ ├── diffmerge_araclari.md │ ├── cevrimici_git_servisleri.md │ └── masaustu_gorsel_git_uygulamalari.md ├── ileri_seviye_komutlar_ve_islemler │ ├── index.md │ ├── merge_alternatifi_olarak_rebase_kullanimi.md │ ├── cakismalari_gidermek.md │ ├── diff_ile_farklari_incelemek.md │ └── degisikliklerinizi_geri_almak.md ├── versiyon_kontrolune_giris │ ├── index.md │ ├── git_tarihcesi.md │ ├── versiyon__kontrolu_nedir.md │ ├── remote_bir_proje_olusturmak.md │ ├── basit_anlamda_versiyon_kontrolu_is_akisi.md │ ├── neden_versiyon_kontrolune_ihtiyacimiz_var.md │ ├── yeni_bir_proje_olusturmak.md │ ├── git_ile_calismaya_baslamak.md │ └── projeniz_uzerinde_calismaya_baslayalim.md ├── branching_dallanma_ve_merging_birlestirme │ ├── index.md │ ├── branchler_ile_calismak.md │ ├── degisikliklerinizi_gecici_olarak_kaydetmek.md │ ├── local_bir_branchde_calismak.md │ ├── degisiklikleri_merge_etmek.md │ ├── branching_nedir-_ne_ise_yarar.md │ └── branching_is_akislari.md ├── alistirmalar │ ├── index.md │ ├── gun_02.md │ ├── gun_05.md │ ├── gun_03.md │ ├── gun_06.md │ ├── gun_07.md │ ├── gun_01.md │ ├── gun_10.md │ ├── gun_09.md │ ├── gun_08.md │ ├── gun_11.md │ └── gun_04.md ├── remote_repositoryler │ ├── branchleri_silmek.md │ ├── remote_bir_repositorye_baglanti_saglamak.md │ ├── local_bir_branchi_yayinlamak_publish.md │ ├── remote_degisiklikleri_entegre_etmek.md │ ├── index.md │ └── remote_repositorydeki_verilerin_incelenmesi.md ├── index.md └── git_kurulumu │ └── git_kurulumu.md ├── content.config.ts ├── nuxt.config.ts ├── LICENSE └── package.json /.npmrc: -------------------------------------------------------------------------------- 1 | shamefully-hoist=true 2 | strict-peer-dependencies=false 3 | -------------------------------------------------------------------------------- /public/cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/cover.jpg -------------------------------------------------------------------------------- /app/assets/git.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/app/assets/git.png -------------------------------------------------------------------------------- /public/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/favicon.ico -------------------------------------------------------------------------------- /public/seo-card.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/seo-card.png -------------------------------------------------------------------------------- /app/assets/gitbook.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/app/assets/gitbook.png -------------------------------------------------------------------------------- /public/cover_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/cover_small.jpg -------------------------------------------------------------------------------- /tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | // https://v3.nuxtjs.org/concepts/typescript 3 | "extends": "./.nuxt/tsconfig.json" 4 | } 5 | -------------------------------------------------------------------------------- /public/.gitbook/assets/04_gitlog.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/04_gitlog.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/04_tower.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/04_tower.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/05_dosya1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/05_dosya1.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/01_branching.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/01_branching.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/02_git_reset.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/02_git_reset.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/03_git_diff.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/03_git_diff.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/03_git_fetch.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/03_git_fetch.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/03_gitstatus.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/03_gitstatus.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/04_conflict.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/04_conflict.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/04_git_fetch.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/04_git_fetch.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/05_gitlog_p.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/05_gitlog_p.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/06_git_push.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/06_git_push.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/07_git_fetch.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/07_git_fetch.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/07_git_stash.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/07_git_stash.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/08_git_push.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/08_git_push.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/12_gitmerge.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/12_gitmerge.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/what-is-vcs.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/what-is-vcs.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/01_git_revert.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/01_git_revert.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/03_git_branch.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/03_git_branch.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/04_git_branch_v.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/04_git_branch_v.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/04_local_diff.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/04_local_diff.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/05_git_status.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/05_git_status.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/06_check_status.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/06_check_status.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/06_diff_merge.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/06_diff_merge.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/10_gitbranch_d.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/10_gitbranch_d.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/13_gitmerge_log.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/13_gitmerge_log.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/14_merge_commit.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/14_merge_commit.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/01_git_remote_add.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/01_git_remote_add.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/02_git_branch_va.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/02_git_branch_va.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/07_tower_conflict.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/07_tower_conflict.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/08_git_stash_list.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/08_git_stash_list.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/09_git_branch_vva.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/09_git_branch_vva.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/09_git_stash_pop.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/09_git_stash_pop.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/11_git_stash_drop.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/11_git_stash_drop.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/01_emptyprojectdir.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/01_emptyprojectdir.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/02_sourcetree_repo.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/02_sourcetree_repo.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/03_sourcetree_commit.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/03_sourcetree_commit.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/05_tower_workingcopy.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/05_tower_workingcopy.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/06_tower_commithist.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/06_tower_commithist.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/10_git_stash_apply.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/10_git_stash_apply.jpg -------------------------------------------------------------------------------- /renovate.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://docs.renovatebot.com/renovate-schema.json", 3 | "extends": [ 4 | "@nuxtjs" 5 | ] 6 | } 7 | -------------------------------------------------------------------------------- /public/.gitbook/assets/05_git_checkout_track.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/05_git_checkout_track.jpg -------------------------------------------------------------------------------- /public/.gitbook/assets/01_sourcetree_bookmarks.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/atlaxt/git101/HEAD/public/.gitbook/assets/01_sourcetree_bookmarks.jpg -------------------------------------------------------------------------------- /app/components/MarkdownBlock.vue: -------------------------------------------------------------------------------- 1 | 4 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | node_modules 2 | *.log* 3 | .nuxt 4 | .nitro 5 | .cache 6 | .output 7 | .env 8 | dist 9 | .DS_Store 10 | .data 11 | 12 | # Yarn 13 | .yarn/cache 14 | .yarn/*state* 15 | 16 | # Local History 17 | .history 18 | -------------------------------------------------------------------------------- /eslint.config.mjs: -------------------------------------------------------------------------------- 1 | // eslint.config.mjs 2 | import antfu from '@antfu/eslint-config' 3 | 4 | export default antfu({ 5 | rules: { 6 | 'no-undef': 'off', 7 | }, 8 | vue: true, 9 | typescript: true, 10 | }) 11 | -------------------------------------------------------------------------------- /app/stores/app.ts: -------------------------------------------------------------------------------- 1 | export const useAppStore = defineStore('app', () => { 2 | const silderIsOpen = ref(false) 3 | const searchModalIsOpen = ref(false) 4 | 5 | return { 6 | silderIsOpen, 7 | searchModalIsOpen, 8 | } 9 | }) 10 | -------------------------------------------------------------------------------- /.vscode/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "editor.codeActionsOnSave": { 3 | "source.fixAll.eslint": "explicit" 4 | }, 5 | "files.associations": { 6 | "*.css": "postcss" 7 | }, 8 | "editor.formatOnSave": false, 9 | "css.lint.unknownAtRules": "ignore" 10 | } 11 | -------------------------------------------------------------------------------- /app/components/navigation/sections/header.vue: -------------------------------------------------------------------------------- 1 | 6 | 7 | 12 | -------------------------------------------------------------------------------- /content/git_arac_ve_servisleri/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Git Araç ve Servisleri 6 | 7 | Bu bölümde aşağıdaki konulardan bahsedeceğiz 8 | 9 | * Görsel Git istemcileri 10 | * Git ile kullanılabilecek diff/merge araçları 11 | * Git servisleri 12 | * Kaynaklar ve Referanslar 13 | -------------------------------------------------------------------------------- /app/layouts/full-width.vue: -------------------------------------------------------------------------------- 1 | 12 | -------------------------------------------------------------------------------- /content.config.ts: -------------------------------------------------------------------------------- 1 | import { defineCollection, defineContentConfig, z } from '@nuxt/content' 2 | 3 | export default defineContentConfig({ 4 | collections: { 5 | content: defineCollection({ 6 | type: 'page', 7 | source: '**', 8 | schema: z.object({ 9 | layout: z.string(), 10 | }), 11 | }), 12 | }, 13 | }) 14 | -------------------------------------------------------------------------------- /content/ileri_seviye_komutlar_ve_islemler/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # İleri Seviye Komutlar ve İşlemler 6 | 7 | Bu bölümde aşağıdaki ileri seviye işlemleri ve ilişkili komutları ele alacağız 8 | 9 | * Değişikliklerinizi Geri Almak 10 | * Versiyonlar Arasındaki Farkları İncelemek 11 | * Çakışmaları Gidermek 12 | * Merge Alternatifi Olarak Rebase Kullanımı 13 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Versiyon Kontrolüne Giriş 6 | 7 | Bu bölümde aşağıdaki konuları ele alacağız 8 | 9 | * Versiyon Kontrolü Nedir 10 | * Versiyon Kontrolüne Neden İhtiyacımız Var 11 | * Git İle Çalışmaya Başlamak 12 | * Basit Anlamda Bir Versiyon Kontrolü İş Akışı 13 | * Local Bir Proje Oluşturmak 14 | * Remote Bir Proje Oluşturmak 15 | * Projemiz Üzerinde Çalışmaya Başlayalım 16 | -------------------------------------------------------------------------------- /content/branching_dallanma_ve_merging_birlestirme/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Branching \(Dallanma\) ve Merging \(Birleştirme\) 6 | 7 | Bu bölümümüzde aşağıdaki konuları ele alacağız 8 | 9 | * Branching Çalışma Şeklinizi Değiştirebilir 10 | * Branch'ler İle Çalışmak 11 | * Değişikliklerinizi Geçici Olarak Kaydetmek -> Git Stash 12 | * Basit Bir Branching Akışı 13 | * Değişiklikleri Merge Etmek 14 | * Farklı Branching İş Akışları 15 | -------------------------------------------------------------------------------- /app/app.config.ts: -------------------------------------------------------------------------------- 1 | export default defineAppConfig({ 2 | links: { 3 | book: 'https://www.dikeyeksen.com/products/git-ile-versiyon-kontrolu?variant=41096029901', 4 | sourceGithub: 'https://github.com/aliozgur/git101_book', 5 | sourceUrl: 'https://aliozgur.gitbooks.io/git101/content/', 6 | github: 'https://github.com/atlasyigitaydin', 7 | repoGithub: 'https://github.com/atlasyigitaydin/git101', 8 | }, 9 | icon: { 10 | aliases: { 11 | 'dark-mode': 'lucide-moon', 12 | 'light-mode': 'lucide-sun', 13 | }, 14 | }, 15 | }) 16 | -------------------------------------------------------------------------------- /app/components/navigation/sections/top.vue: -------------------------------------------------------------------------------- 1 | 7 | 8 | 16 | -------------------------------------------------------------------------------- /app/components/card/book.vue: -------------------------------------------------------------------------------- 1 | 8 | 9 | 21 | -------------------------------------------------------------------------------- /app/components/ButtonLink.vue: -------------------------------------------------------------------------------- 1 | 17 | 18 | 34 | -------------------------------------------------------------------------------- /app/types.ts: -------------------------------------------------------------------------------- 1 | export interface Section { 2 | id: string 3 | label: string 4 | subSections?: Section[] 5 | } 6 | 7 | export interface PageSchema { 8 | title?: string 9 | path?: string 10 | body?: { 11 | type?: string 12 | children?: any 13 | toc?: any 14 | } 15 | description?: string 16 | seo?: { 17 | title?: string 18 | description?: string 19 | } & Record 20 | navigation?: boolean | { 21 | title?: string 22 | description?: string 23 | icon?: string 24 | } 25 | // devamı var 26 | } 27 | 28 | export interface SearchResultItem { 29 | item: { 30 | content: string 31 | id: string 32 | level: number 33 | title: string 34 | titles: string[] 35 | } 36 | refIndex: number 37 | } 38 | -------------------------------------------------------------------------------- /nuxt.config.ts: -------------------------------------------------------------------------------- 1 | import tailwindcss from '@tailwindcss/vite' 2 | 3 | export default defineNuxtConfig({ 4 | modules: [ 5 | '@nuxt/content', 6 | '@nuxt/icon', 7 | '@nuxt/eslint', 8 | '@nuxtjs/color-mode', 9 | '@pinia/nuxt', 10 | '@nuxtjs/sitemap', 11 | '@nuxt/fonts', 12 | ], 13 | 14 | css: ['assets/css/main.css'], 15 | colorMode: { classSuffix: '' }, 16 | 17 | content: { 18 | build: { 19 | markdown: { 20 | highlight: { 21 | theme: { 22 | dark: 'github-dark', 23 | default: 'github-light', 24 | }, 25 | }, 26 | }, 27 | }, 28 | }, 29 | 30 | future: { 31 | compatibilityVersion: 4, 32 | }, 33 | compatibilityDate: '2025-02-19', 34 | 35 | vite: { 36 | plugins: [tailwindcss()], 37 | }, 38 | }) -------------------------------------------------------------------------------- /app/assets/css/main.css: -------------------------------------------------------------------------------- 1 | @import "tailwindcss"; 2 | @plugin "@tailwindcss/typography"; 3 | @custom-variant dark (&:where(.dark, .dark *)); 4 | @source "../../../content/**/*"; 5 | 6 | body { 7 | @apply dark:bg-neutral-900 bg-neutral-100 overflow-y-auto; 8 | } 9 | 10 | html { 11 | @apply scroll-smooth [&::-webkit-scrollbar]:w-1 12 | [&::-webkit-scrollbar-track]:rounded-none 13 | [&::-webkit-scrollbar-track]:bg-gray-100 14 | [&::-webkit-scrollbar-thumb]:rounded-none 15 | [&::-webkit-scrollbar-thumb]:bg-[#D44A2F] 16 | dark:[&::-webkit-scrollbar-track]:bg-neutral-700 17 | dark:[&::-webkit-scrollbar-thumb]:bg-[#D44A2F]; 18 | } 19 | 20 | div { 21 | font-family: Inter, sans-serif; 22 | } 23 | 24 | .prose a:not(h2 a, h3 a, h4 a, h5 a, h6 a, button a) { 25 | @apply text-[#cf3d21] dark:text-[#D44A2F]; 26 | } 27 | -------------------------------------------------------------------------------- /app/layouts/content.vue: -------------------------------------------------------------------------------- 1 | 24 | -------------------------------------------------------------------------------- /app/components/ColorModeSwitch.vue: -------------------------------------------------------------------------------- 1 | 6 | 7 | 30 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 Atlas Yiğit Aydın 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /app/pages/[...slug].vue: -------------------------------------------------------------------------------- 1 | 30 | 31 | 40 | -------------------------------------------------------------------------------- /app/components/card/community.vue: -------------------------------------------------------------------------------- 1 | 9 | 10 | 31 | -------------------------------------------------------------------------------- /content/git_arac_ve_servisleri/kaynakca_ve_referanslar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Kaynakça ve Referanslar 6 | 7 | Git oldukça çok seçeneği ve farklı kullanım şekli olan bir dağıtık bir versiyon kontrol sistemidir. Git ile ilgili daha fazla bilgi edinmek istiyorsanız önce iyi derecede İngilizce öğrenmenizi tavsiye ediyorum. Daha sonra da aşağıdaki kaynaklardan başlayarak Git ile ilgili bilginizi arttırabilirsinzi. 8 | 9 | 1. [Git-Scm Referans Dokümanı](http://git-scm.com/docs) 10 | 2. [GitRef Referans Dokümanı](http://gitref.org/branching/) 11 | 3. [Learn Version Control with Git](http://www.git-tower.com/learn/ebook/command-line/introduction) 12 | 4. [Atlassian Git Tutorials](https://www.atlassian.com/git/tutorial) 13 | 5. [Pro Git Book](http://git-scm.com/book) 14 | 6. [Atlassian Git Workflows](https://www.atlassian.com/git/workflows) 15 | 7. [Learn Git Branching Online Tutorial Application](http://pcottle.github.io/learnGitBranching/) 16 | 8. [Git: fetch and merge, don't pull](http://longair.net/blog/2009/04/16/git-fetch-and-merge/%20) 17 | 9. [Resolving a merge conflict from command line](https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line) 18 | 10. [Adding And Removing Remote Branches – Git Branch](http://www.gitguys.com/topics/adding-and-removing-remote-branches/) 19 | -------------------------------------------------------------------------------- /content/git_arac_ve_servisleri/diffmerge_araclari.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Diff/Merge Araçları 6 | 7 | Projenizde neler olup bittiğini anlamak için zaman zaman \(aslında bir takım içinde yer alıyorsanız sık sık da denilebilir\) dosyaların versiyonları arasındaki farkların ne olduğuna bakmanız ve çakışma durumunda da çakışmaları inceleyip çakışma durumunu gidermeniz gerekir. 8 | 9 | 4.Bölümde Terminal'den herhangi bir yardımcı uygulamaya gerek kalmadan da Git'in bize bu farkları gösterebildiğine ve bu farklar'ı nasıl okuyabileceğimize değinmiştik. Ancak büyük projelerde Git'in sunduğu bu işlev ile farkları okumak çok kolay olmayacaktır. Bu nedenle farkları daha rahat inceleyebilmek için bu farkları renkler ve formatlama yöntemleri ile görselleştiren araçlardan faydalanmak işinizi kolaylaştıracaktır. Farkları görselleştiren bu uygulamaların nerdeyse tamamı aynı zamanda çakışmaları da görselleştirip merge işlemini de kolayca yapmanız için araçlar sunar. 10 | 11 | Windows üzerinde çalışıyorsanız [WinMerge \(ücretsiz\)](http://winmerge.org/) veya [Araxis Merge \(ücretli\)](http://www.araxis.com/merge/) kullanabilirsiniz. 12 | 13 | Mac OS X üzerinde çalışıyorsanız [SourceGear DiffMerge \(ücretsiz\)](https://sourcegear.com/diffmerge/) veya Apple XCode ile birlikte ücretsiz gelen Apple'in FileMerge aracını kullanabilirsiniz. 14 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/git_tarihcesi.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Kısa Git Tarihçesi 6 | 7 | Git 2005 yılında, başta Linus Torvalds olmak üzere Linux çekirdeğini de kodlayan ekip tarafından Linux kaynak kodunu versiyon kontrolü altında tutmak ve kendi iş akışlarını düzenlemek için geliştirilmiştir 8 | 9 | Linux'un kaynak kodu 1991-2002 yılları arasındaki dönemde manuel olarak dosyaların paylaşılması şeklinde yönetiliyordu. 2002 yılında Linux geliştiricileri normalde ücretli olan ancak açık kaynak projeler için ücretsiz lisanslama modeli sunan BitKeeper isimli dağıtık versiyon kontrol sistemini kullanmaya başladılar. 2005 yılında BitKeeper'ın ücretsiz sağladığı lisansı geri çekmesi üzerine Linus Torvalds ve Linux ekibi kendi dağıtık versiyon kontrol sistemini geliştirmeye karar verdiler. 10 | 11 | Linux ekibi BitKeeper ile olan deneyimlerini de dikkate alarak öncelikli olarak aşağıdaki kriterleri sağlayan kendi yazılımlarını geliştirmeye başladılar 12 | 13 | * Hızlı 14 | * Kullanımı kolay 15 | * Lineer olmayan geliştirme iş akışına uygun \(branching\) 16 | * Tamamen dağıtık 17 | * Büyük projeleri destekleyebilecek 18 | 19 | 2005 yılından bugüne Git gelişmeye devam ediyor. Git'e yeni eklenen özelliklere rağmen Git bugün bile yukarıda bahsettiğim öncelikli kriterlerden taviz vermeden milyonlarca yazılım geliştiricinin hayatını kolaylaştırmaya devam ediyor. 20 | -------------------------------------------------------------------------------- /content/alistirmalar/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Git ile Versiyon Kontrolü - Günlük Alıştırmalar ile Tekrar 6 | 7 | ## Git ile Versiyon Kontrolü - Günlük Alıştırmalar ile Tekrar 8 | 9 | Bu depoda "Git ile Versiyon Kontrolü" kitabında ele alınan konuları da kapsayacak şekilde Git ile versiyon kontrolünü ve Git iş akışlarını kısa pratikler ile günlük çalışma akışımıza dahil etmek için uygulamalı alıştırmalara yer alıyor. 11 gün boyunca her gün sadece 1 saat ayırıp bir uygulama yaparak Git ile ilgili kitapta anlattığımız konulardaki bilginizi pekiştirebilirsiniz. 10 | 11 | > **NOT:** İnternet tarayıcınızı kullanarak Git komutlarını çalıştırmak için Code School tarafından hazırlanan [Try Git](http://try.github.com/) sayfasını da kullanabilirsiniz 12 | 13 | ## Gün gün alıştırmalar 14 | 15 | * [Gün 1 - İstemci Kurulumları](gun_01.md) 16 | * [Gün 2 - Yerel Depo Oluşturma](gun_02.md) 17 | * [Gün 3 - Klonlama](gun_03.md) 18 | * [Gün 4 - Değişiklikleri kaydetme](gun_04.md) 19 | * [Gün 5 - Değişiklikleri Versiyon Kontrolüne Alma](gun_05.md) 20 | * [Gün 6 - Commit Edilmiş Değişiklikleri İptal Etmek](gun_06.md) 21 | * [Gün 7 - Commit Edilmiş Değişiklikleri Silmek](gun_07.md) 22 | * [Gün 8 - Dal Oluşturmak](gun_08.md) 23 | * [Gün 9 - Değişiklikleri Birleştirme \(Merge\)](gun_09.md) 24 | * [Gün 10 - Rebase](gun_10.md) 25 | * [Gün 11 - Birlikte Çalışma \(Collaboration\)](gun_11.md) 26 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "content-wind", 3 | "version": "2.0.0", 4 | "private": false, 5 | "packageManager": "pnpm@10.5.2", 6 | "main": "nuxt.config.ts", 7 | "scripts": { 8 | "dev": "nuxi dev", 9 | "build": "nuxi build", 10 | "generate": "nuxi generate", 11 | "preview": "nuxi preview", 12 | "lint": "eslint", 13 | "lint:fix": "eslint --fix" 14 | }, 15 | "dependencies": { 16 | "@iconify-json/lucide": "^1.2.28", 17 | "@iconify-json/simple-icons": "^1.2.27", 18 | "@nuxt/content": "^3.4.0", 19 | "@nuxt/fonts": "0.11.4", 20 | "@nuxt/icon": "^1.10.3", 21 | "@nuxtjs/color-mode": "^3.5.2", 22 | "@nuxtjs/sitemap": "7.2.9", 23 | "@pinia/nuxt": "0.10.1", 24 | "@tailwindcss/typography": "^0.5.16", 25 | "@tailwindcss/vite": "^4.0.9", 26 | "fuse.js": "^7.1.0", 27 | "nuxt": "^3.16.1", 28 | "pinia": "^3.0.1", 29 | "tailwindcss": "^4.0.9" 30 | }, 31 | "devDependencies": { 32 | "@antfu/eslint-config": "^4.10.1", 33 | "@iconify-json/academicons": "^1.2.3", 34 | "@iconify-json/heroicons": "^1.2.2", 35 | "@iconify-json/heroicons-outline": "^1.2.1", 36 | "@iconify-json/mdi": "^1.2.3", 37 | "@nuxt/eslint": "^1.1.0", 38 | "eslint": "^9.21.0", 39 | "typescript": "^5.8.2" 40 | }, 41 | "pnpm": { 42 | "onlyBuiltDependencies": [ 43 | "@parcel/watcher", 44 | "better-sqlite3", 45 | "esbuild", 46 | "vue-demi" 47 | ] 48 | } 49 | } 50 | -------------------------------------------------------------------------------- /app/components/AppNavbar.vue: -------------------------------------------------------------------------------- 1 | 3 | 4 | 35 | -------------------------------------------------------------------------------- /content/remote_repositoryler/branchleri_silmek.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Branch'leri Silmek 6 | 7 | Bir önceki bölümde oluşturduğumuz **superyeniozellik** isimli branch üzerindeki çalışmamızı tamamlayıp kalite kontrol sürecimizi de işlettikten sonra bu değişiklikleri **master** branch'imize entegre ettiğimizi varsayalım. Bu entegrasyon sonrasında **superyeniozellik** isimli branch'e ihtiyacımız yok ve artık bu branch'i silebiliriz. Bu branch'i kendi bilgisayarımızdan silmek için **git branch -d superyeniozellik** komutunu, remote repository'den silmek için de **git branch -dr superyeniozellik** komutunu kullanabiliriz. 8 | 9 | ![git branch -d](/.gitbook/assets/10_gitbranch_d.jpg) 10 | 11 | > Silmek istediğiniz local branch aktif ise **git branch -d** komutu hata verecektir. Silme işlemi öncesinde sileceğiniz local branch'den farklı bir branch'i **git checkout** komutu ile aktif hale getirmeyi unutmayın. 12 | 13 | Remote branch'i **git branch -dr** komutu ile sildiğiniz halde remote repository'ye erişip branchleri kontrol ederseniz **superyeniozellik** isimli branch'in sunucuda hala durduğunuz göreceksiniz. Bunun nedeni **git branch -dr** komutundaki seçeneklerden **r** seçeneğinin sunucudaki branch'i değil yerel bilgisayarınızda remote branch bilgilerini siler. Bu değişikliğin sunucuda da geçerli olması için yani sunucudaki branch'i de silmek için **git push origin :superyeniozellik** komutu ile değişikliği bir anlamda remote repositry'de yayınlamanız gerekiyor. 14 | 15 | > [Daha ayrıntılı bilgi için bakınız \(StackOverflow - İngilizce \)](http://stackoverflow.com/questions/24216725/deleting-remote-branch-does-not-remove-from-github) 16 | -------------------------------------------------------------------------------- /content/remote_repositoryler/remote_bir_repositorye_baglanti_saglamak.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Remote Bir Repository'ye Bağlantı Sağlamak 6 | 7 | Remote bir repository'yi yerel diskinize **git clone** komutu ile indirdiğinizde Git otomatik olarak bu işlemi yapmak için kullandığınız bağlantı bilgilerini hatırlar. Git bu bilgi'yi varsayılan olarak **origin** adı verilen remote bir repository olarak kayıt altına alır. Local olan bir respository için ise böyle bir bilgi tutulmaz. Ancak bölüm girişinde de ele aldığımız gibi Local bir repository'yi baz alarak yeni bir remote repository oluşturabiliriz. Bunun için **git clone** komutunu kullanabiliriz. Örneğin 8 | 9 | ![git remote add](/.gitbook/assets/01_git_remote_add.jpg) 10 | 11 | Yukarıdaki ekran görüntüsünde ilk komutumuz olan **git remote add** ile local repository'miz ile remote repository'miz arasındak bağlantıyı kuruyoruz. İkinci komutumuz olan **git remote -v** ile de remote repositorymiz ile ilgili bilgileri görebiliriz. 12 | 13 | Dikkat ettiyseniz her bir remote repository için biri **fetch** diğeri de **push** işlemleri için kullanılan iki adres bulunur. **fetch** adresini remote repository'den yapılacak olan okuma işlemleri, **push** adresini de remote repository'ye yapılan yazma işlemleri için kullanılır. Genel olarak bu iki adres aynı olmakla birlikte performans ve güvenlik gibi gerekçeler ile iki farklı adres de kullanılabilir. 14 | 15 | > Local bir repository'nizi istediğiniz sayıda remote repository ile ilişkilendirebilirsiniz. Yukarıdaki ekran çıktısında sadece bizim oluşturduğumuz **git101\_ornek** isimli remote listeleniyor, birden fazla remote ilişkisi olsaydı hepsi listelenecekti. 16 | -------------------------------------------------------------------------------- /content/remote_repositoryler/local_bir_branchi_yayinlamak_publish.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Local Bir Branch'i Yayınlamak \(Publish\) 6 | 7 | Kendi bilgisayarınızda oluşturduğunuz Local bir branch siz yayınlamaya karar vermediğiniz sürece sadece sizin bilgisayarınızda yer alacaktır. Yani local bazı branchlerinizi sadece kendi bilgisayarınızda tutarken istediklerinizi de takım arkadaşlarınız ve hatta tüm dünya ile paylaşabilirsiniz. 8 | 9 | Gelin şimdi **superyeniozellik** isimli local branch'i remote repositorymizde paylaşalım. 10 | 11 | ![git push](/.gitbook/assets/08_git_push.jpg) 12 | 13 | Önce **git checkout** komutu ile branch'imizi aktif hale getiriyoruz ve sonra **git push** komutu ve **-u** seçeneği ile local branch'imizi remote repository'mizde yayınlıyoruz. Push komutu için verdiğimiz _origin_ ve _superyeniozellik_ değerleri ile **HEAD** branch'imizi **origin** remote repository'de **superyeniozellik** isimli branch olarak yayınlanmasını istediğimizi tanımlıyoruz. _-u_ seçeneği ise local branchimiz ile remote branchimiz arasında, önceki bölümlerde de bahsettiğimiz, Takip İlişkisi \(Tracking Relationship\) kurulmasını sağlar. 14 | 15 | > git branch komutunu **-vva** seçeneği ile çalıştırdığınızda kurulmuş Takip İlişkisi bilgilerini de görebilirsiniz. 16 | 17 | ![git branch -vva](/.gitbook/assets/09_git_branch_vva.jpg) 18 | 19 | Local branch'i remote repository'de yayınladıktan sonra local branch'de yaptığımız değişiklikleri **git push** komutunu parametresiz kullanarak remote branch'imizde yayınlayabiliriz. 20 | 21 | Artık remote repository'ye erişim yetkisi olan herkes **superyeniozellik** isimli bu branchinizi görebilir ve bu branch'i baz alarak kendi değişiklikleri üzerinde çalışma yapabilir. 22 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/versiyon__kontrolu_nedir.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Versiyon Kontrolü Nedir? 6 | 7 | Versiyon kontrolü nedir ve bizi neden ilgilendirmeli? Versiyon kontrolünü bir dosya veya bir küme dosyadaki değişiklikleri takip edebilmek için uyguladığımız bir yöntem olarak tanımlayabiliriz. Git gibi sistemler tüm bu değişikliklerin tarihçesini ve içeriğini elektronik olarak bizim için takip ederek kayıt altına almamızı sağlayan veri tabanları olarak düşünülebilir. 8 | 9 | Bu sistemleri kullanarak herhangi bir anda üzerinde çalıştığınız dosyaların o anki hallerini kaydedebilir, daha sonra da isterseniz bu dosyaların kaydedilmiş ve kontrol altına alınmış herhangi bir haline geri dönebilirsiniz. 10 | 11 | > Dosyaların kayıt altına alınmış herhangi bir andaki hallerine **versiyon** diyoruz 12 | 13 | ![Versiyon Kontrolü Nedir?](/.gitbook/assets/what-is-vcs.jpg) 14 | 15 | [_Görsel : Atlassian Git Workflows sayfasından alıntı_](https://www.atlassian.com/git/workflows) 16 | 17 | Versiyon kontrolünü, kullandığınız programlama dili, yardımcı programlama kütüphaneleri \(framework\), dosya tipi veya işletim sisteminden bağımsız bir yaklaşım olarak düşünmelisiniz. Çünkü versiyon kontrolü 18 | 19 | * HTML dosyalar için kullanılabileceği gibi, mimari tasarım amaçlı proje dosyaları ve iPhone uygulaması kaynak kodunuz için de kullanılabilir 20 | * Dosyalarınız üzerinde çalışırken hangi işletim sistemini veya hangi programları kullandığınız ile ilgilenmez \(Sublime Text, Notepad, Visual Studio, Word, AutoCAD\) 21 | 22 | > Ben de bu kitabın versiyon kontrolü için **Git** kullanıyorum 23 | 24 | Versiyon kontrol sistemleri en basit anlamda **dosyalarınızdaki değişikliklerin tarihçesini takip edip kayıt altında tutan** sistemlerdir. Bu nedenle versiyon kontrol sistemlerini yedekleme veya diğer yazılım geliştirme araçları ile karşılaştırmak doğru olmaz. 25 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_02.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 2.Gün: Yerel Depo Oluşturma 6 | 7 | Git ile çalışabilmek için illa bir sunucu kurulumuna veya bir Git servis sağlayıcısına ihtiyaç duyulmaz. Git kurulumumuzu tamamladığımıza göre artık kendi bilgisayarımızda da bir depo oluşturup denemelerimizi yapabiliriz. 8 | 9 | Bilgi Kutusu \(NOT\) : Git'in push, pull gibi birkaç komutu dışındaki tüm komutlar kendi bilgisayarınızda çalıştırdığınız komutlardır. 10 | 11 | Git'de boş bir repository oluşturmak için git init komutunu kullanırız. Init komutunun genel şablonu ve komut ile ilgili yardım almak için kullanabileceğiniz Git komutu aşağıdaki gibidir. 12 | 13 | ```bash 14 | git help 15 | git help init 16 | ``` 17 | 18 | ## Alıştırma-1 19 | 20 | Git Bash veya Terminal komut satırını ara yüzünü açarak herhangi bir parametre kullanmadan aşağıdaki komutları sırası ile çalıştırın 21 | 22 | ```bash 23 | Diskinizin C bölümüne konumlanın 24 | cd C:/ 25 | 26 | # pg_00 isimli boş bir klasör oluşturun. Bu projenizi temsil eden kök klasördür 27 | mkdir pg_00 28 | 29 | # pg_00 isimli klasöre konumlanın 30 | cd pg_00 31 | 32 | # pg_00 proje klasörünüzü Git deposu haline getirin 33 | git init 34 | ``` 35 | 36 | ## Alıştırma-2 37 | 38 | ```bash 39 | # Diskinizin C bölümüne konumlanın 40 | cd C:/ 41 | 42 | # pg_00 isimli klasörü silin 43 | rm -r pg_00 44 | 45 | # pg_00 proje klasörünü oluşturup Git deposu haline getirin 46 | git init pg_00 47 | ``` 48 | 49 | ## Alıştırma-3 50 | 51 | Bu alıştırmaya başlamadan önce kitabın 3. Bölümünde yer alan “Tek Dallı Akış” başlığı altındaki Yalın Depolar ile ilgili açıklamaları tekrar okuyun. 52 | 53 | Aşağıdaki komutları sırası ile çalıştırın ve en son komutun verdiği bilgi mesajını bir yere not edin. 54 | 55 | ```bash 56 | cd C:/ 57 | 58 | rm -r pg_00 59 | 60 | git init --bare pg_00.git 61 | 62 | cd pg_00.git 63 | 64 | git status 65 | ``` 66 | -------------------------------------------------------------------------------- /app/app.vue: -------------------------------------------------------------------------------- 1 | 33 | 34 | 41 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_05.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 5.Gün: Değişiklikleri Versiyon Kontrolüne Alma 6 | 7 | Git'in temel yaklaşımlarından birisi de değişikliklerinizin versiyon kontrolü altına alınmaya hazır olduğuna karar verene kadar Git ile herhangi bir etkileşime geçmenize gerek olmamasıdır. Staging Area denilen ara bir alanın varlığı da bu yaklaşım ile uyumludur; birden fazla dosyanızı değiştirip mantıksal olarak anlamlı bütünler halinde Staging Area'da yer almasını sağlayıp daha sonra da bu değişiklikleri yeni versiyon \(commit\) olarak mühürleyebilirsiniz 8 | 9 | Örneğin a.txt, b.txt ve c.txt isimli üç dosyada değişiklik yaptığınızı düşünelim. Bu değişikliklerden a.txt ve b.txt dosyalarındakilerinin birbiri ile ilişkili olduğunu, c.txt dosyasındaki değişikliğin ise kendi başına anlamlı olduğunu düşünelim. Aşağıdaki Git komutları ile değişikliklerimizi iki commit oluşturacak şekilde mantıksal olarak gruplayabilirsiniz. 10 | 11 | ```bash 12 | git add a.txt 13 | 14 | git add b.txt 15 | 16 | git commit -m "a ve b dosyalarında değişiklik yapıldı" 17 | 18 | git add c.txt 19 | 20 | git commit -m "c dosyasında değişiklik yapıldı" 21 | ``` 22 | 23 | Dosyalarınızda yaptığınız değişikliklerin versiyonlanması için önce Staging Area'ya eklenmesi daha sonra da git commit ile tüm değişikliklerinizin yeni bir versiyon olarak mühürlenerek Git tarafından kayıt altına alınmasını sağlamalısınız. Bu döngü tüm değişiklikler için geçerli olan edit/stage/commit döngüsü olarak anılır. 24 | 25 | ## Alıştırma - 1 26 | 27 | ```bash 28 | # Proje klasörünüze konumlanın 29 | cd 30 | 31 | # Boş bir dosya oluşturun 32 | touch .txt 33 | 34 | # Dosyayı Staging Area’ya ekleyin 35 | git add .txt 36 | 37 | # Değişikliklerinizi commit edin 38 | git commit -m " isimli dosyayı ekledim" 39 | ``` 40 | 41 | **Soru-1:** git commit komutunu -m parametresi kullanmadan çalıştırırsanız ne olur? 42 | 43 | **Soru-2:** Commit tarihçenizdeki commit mesajlarını tek satır halinde görmek için hangi komutu çalıştırmalısınız? 44 | 45 | ## Alıştırma - 2 46 | 47 | Git'in commit mesajları ve diğer metin düzenleme işlemler için varsayılan metin editör uygulaması olarak Windows üzerinde Notepad++, OSX üzerinde Sublime Text, Linux üzerinde de gEdit veya kendi tercih ettiğiniz bir metin editörü kullanabilmesi için gerekli Git ayarlarını yapın 48 | 49 | ## Alıştırma - 3 50 | 51 | Git’in her bir commit işlemi için otomatik ürettiği hash değerinin ne olduğunu araştırın. 52 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_03.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 3.Gün: Klonlama 6 | 7 | Klonlama işlemi ile uzakta bulunan bir Git deposunu kendi bilgisayarımıza indiriyoruz. Uzak depoyu klonlandıktan sonraki tüm değişiklikler artık bilgisayarımızdaki klon Git deposunda kayıt altına alınacak, ta ki git push komutu ile değişikliklerimizi uzaktaki depoya geri yazana kadar. 8 | 9 | ## Kolonlama Hazırlık 10 | 11 | * **Adım-1,** 1. Gün, 3. Alıştırmada Github, Gitlab veya Bitbucket üzerinde oluşturduğunuz projenin HTTP depo adresini öğrenmemiz gerekiyor. Bunun için kullandığınız Git servisinin sayfasına girip deponuzun ana sayfasındaki “Clone” linkini kullanabilirsiniz. 12 | * **Adım-2,** Aşağıdaki iki komutu çalıştırarak Git'in uzak deponuza HTTP üzerinden bağlanırken kullanacağı kullanıcı adını ve şifremizi geçici bir süre için kaydedeceği store bilgisini tanımlamalıyız 13 | 14 | ```bash 15 | # Windows üzerinde şifre'nin cacheleneceği store, wincred 16 | git config --global credential.helper wincred 17 | 18 | # Uzak depo servis sağlayıcısı depoları için kullanılacak olan kullanıcı adı 19 | git config --global credential.https:// 20 | ``` 21 | 22 | Wincred ve kullanıcı adımızı tanımladıktan sonra git clone komutu ile Git Bash'den \(veya Terminal\) klonlama işlemi yapıldığında Git size şifrenizi soracak ve şifre girildikten sonra klonlama işlemi gerçekleştirilecek. 23 | 24 | > **DİKKAT:** Klonlama işlemi SourceTree veya Git Eye ile değil Git Bash veya Terminal ile komut satırından yapılacak. clone komutu ile ilgili yardım almak için git help clone komutunu kullanabilirsiniz. 25 | 26 | ## Alıştırma-1 27 | 28 | Uzak depodaki projenizi Git Bash \(Terminal\) kullanarak Git'in komut satırı komutları ile kendi bilgisayarınıza klonlayın ve sonrasında aşağıdaki komutları çalıştırın 29 | 30 | ```text 31 | # Proje klasörünüze konumlanın 32 | cd 33 | 34 | git status 35 | git log -n 5 36 | ``` 37 | 38 | ## Alıştırma-2 39 | 40 | ```text 41 | # Proje klasörünüze konumlanın 42 | cd 43 | 44 | mkdir src 45 | touch .txt 46 | 47 | # Aşağıdaki komutları çalıştırmadan önce .txt dosyasını açıp içine herhangi bir metin yazın 48 | git status 49 | git log -n 5 50 | ``` 51 | 52 | ## Sorular 53 | 54 | **Soru-1:** `git status` komutunun çıktısında verilen bilgiyi nasıl yorumlamamız lazım? 55 | **Soru-2:** `git log` komutunun çıktısında eklediğiniz dosyaya ilişkin herhangi bir bilgi görüyor musunuz? 56 | -------------------------------------------------------------------------------- /app/components/navigation/slider.vue: -------------------------------------------------------------------------------- 1 | 13 | 14 | 60 | -------------------------------------------------------------------------------- /content/branching_dallanma_ve_merging_birlestirme/branchler_ile_calismak.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Branch'ler İle Çalışmak 6 | 7 | Git'de branch kullanımı tercihe bağlı değildir, aslında farkında olmasanız bile projeniz üzerinde çalışırken her zaman aktif tek bir branch üzerinde çalışırsınız. Git'de projenizi ilk oluşturduğunuzda Git varsayılan olarak sizin için **master** adı verilen bir branch oluşturur ve siz bu branch üzerinde çalışmaya başlarsınız. 8 | 9 | Gelin şimdi **git branch** komutunun basit kullanımı ile ilgili birkaç örnek görelim. 10 | 11 | **git branch deneme** komutunu çalıştırdığınızda git sizin için projenizdeki dosyaların o anki halini barındıran **deneme** isimli bir branch oluşturur. 12 | 13 | > Git **git branch** komutu ile oluşturduğunuz yeni branch'i otomatik olarak aktif hale getirmez. 14 | 15 | Branch'inizi oluşturduktan sonra **git branch** komutunu çalıştırdığınızda git size projeniz için oluşturduğunuz tüm branch'leri listeler ve aktif olan branch'i başına da **\*** simgesi olacak şekilde gösterir. 16 | 17 | ![git branch](/.gitbook/assets/03_git_branch.jpg) 18 | 19 | > **git status** komutunu çalıştırdığınızda da aktif olan branch "On branch ...." ifadesi ile gösterilir ![git status](/.gitbook/assets/05_git_status.jpg) 20 | 21 | Branch'leriniz ile ilgili daha fazla ayrıntı görmek için ise **git branch** komutunu **-v** parametresi ile çalıştırabilirsiniz. 22 | 23 | ![git branch -v](/.gitbook/assets/04_git_branch_v.jpg) 24 | 25 | Yeni oluşturduğumuz branch ile çalışmaya başlamadan önce gelin bir defa daha **git status** komutu ile projemizin ne durumda olduğuna bakalım. 26 | 27 | ![git status](/.gitbook/assets/06_check_status.jpg) 28 | 29 | Yukarıdaki ekran görüntüsünde de gördüğümüz üzere aktif olan **master** branch'imizde _dosya2.md_ isimli dosyamızda henüz commit etmediğiniz bir değişiklik var. Bu dosyadaki değişikliğin yeni eklediğimiz branch'de yer almasını istemediğimizi ve henüz tam anlamıyla bitirilmediğini varsayalım. Bu durumda dosyadaki değişikliği commit mi etmeliyiz yoksa tamamen göz ardı mı etmeliyiz? 30 | 31 | Versiyon Kontrolünün Altın Kuralları 32 | 33 | \#4 Yarım Yamalak Değişiklikleri Asla Commit etmeyin 34 | 35 | Tam anlamıyla bitirmediğiniz ve test etmediğiniz bir değişikliği asla commit etmeyin. Üzerinde çalışacağınız değişiklikleri planlarken bu değişiklikleri mümkün olduğunca küçük parçalar halinde ele almaya özen gösterirseniz yaptığınız değişiklikleri kayıt altına almak için henüz tamamlanmamış değişiklikleri commit etmek zorunda kalmazsınız. Buna rağmen ara safhada kayıt altına almak istediğiniz değişiklikler olursa Git'in \*\*Stash\*\* özelliğini kullanabilirsiniz. 36 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_06.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 6.Gün: Commit Edilmiş Değişiklikleri İptal Etmek 6 | 7 | Bu bölüme kadar değişiklikleri geri almanın iki yöntemini ele aldık, hatırlatmak gerekirse 8 | 9 | * Track edilmeyen dosyalardaki \(unstaged\) değişiklikleri iptal etmek için git checkout 10 | * Track edilen fakat henüz commit edilmemiş \(staged\) dosyalardaki değişiklikleri iptal etmek için ise git reset HEAD 11 | 12 | komutlarını kullanabiliriz. Bu bölümde ise commit edilmiş değişiklikleri git revert komutu ile nasıl geri alabileceğimizi hatırlayıp alıştırmalar yapacağız. 13 | 14 | Revert komutunun en önemli özelliği commit edilmiş bir değişikliği otomatik olarak yeni bir commit oluşturarak geri almanızı sağlamasıdır. Revert komutunun bu özelliği sayesinde hata ile yapılan commit'ler de proje tarihçesinde kalmaya devam eder. Özellikle diğer kullanıcılar ile paylaşılan bir depoda çalışıyorsanız ve geri almanız gereken bir commitiniz varsa revert komutunu kullanmamız tavsiye ediyoruz. Ekip arkadaşlarımız bizim yanlışlıkla oluşturduğumuz commit'e dayanarak geliştirme yapmış olabilirler bu nedenle commitimizi geri alırken proje tarihçesine bir iz bırakmalı ve ekipteki diğer kişilerin revert işleminden haberdar olmalarını sağlamamız gerekiyor. 15 | 16 | Özetlemek gerekirse git revert ile yeni bir commit oluşturularak önceki commit’deki değişiklikleri proje tarihçesinde iz bırakarak geri alabiliyoruz. 17 | 18 | Alıştırmaya geçmeden önce örnek proje deponuzda yaptığınız tüm değişiklikleri `git push` komutu ile uzak deponuza yazmanız gerekiyor 19 | 20 | ## Alıştırma 21 | 22 | ```bash 23 | # Projenizdeki herhangi bir dosyayı açıp içeriğini değiştirin 24 | # adiniz.txt dosyasını staging area'ya ekleyin 25 | git add -A . 26 | 27 | # Değişikliğinizi commit edin 28 | git commit -m “6. Gün alıştırma” 29 | 30 | # Yerel deponuzu uzak depo ile senkronize edin 31 | git push 32 | ``` 33 | 34 | Son commit işleminin hatalı olduğunu varsayalım. Bu değişikliği iptal edip bir önceki versiyona geri dönmek için aşağıdaki komutları sırası ile çalıştıralım 35 | 36 | ```bash 37 | # Commit tarihçesindeki en son 5 commit kaydının bilgilerini listeleyin 38 | git log -n 5 39 | 40 | # Geri dönmek istediğiniz commit’in hash değerini belirledikten sonra 41 | 42 | git revert --no-edit 43 | 44 | # Yerel deponuzu uzak depo ile senkronize edin 45 | git push 46 | ``` 47 | 48 | **Soru-1:** git push ile değişikliklerinizi uzak depoya göndermemiş olsaydınız geri alma işlemini nasıl yapacaktınız? 49 | 50 | **Soru-2:** Son commit hash değerinin tamamı veya 7 karakterini kullanmak yerine farklı nasıl bir parametre kullanabilirdiniz? 51 | 52 | **Soru-3:** Commit hash değerinin ilk 7 karakterini kullanmak neden yeterli? 53 | 54 | **Soru-4:** git reset ile git revert komutları arasındaki fark nedir? 55 | -------------------------------------------------------------------------------- /content/branching_dallanma_ve_merging_birlestirme/degisikliklerinizi_gecici_olarak_kaydetmek.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Değişikliklerinizi Geçici Olarak Kaydetmek 6 | 7 | Commit işlemi ile dosyalarınızda yaptığınız değişiklikler kalıcı olarak repository'de kayıt altına alınır. Ancak günlük çalışmamızda bazen tam olarak bitmeyen değişiklikleri de kayıt altına almak isteyebiliriz. Örneğin bir değişiklik üzerinde çalışırken başka bir konu ile ilgili kritik bir sorun bildirildiğinde yapmakta olduğumuz işi yarım bırakıp yeni soruna odaklanmak zorunda kalabilirsiniz. 8 | 9 | Bu gibi durumlarda yeni sorun ile ilgilenmeye başlamak için önceki değişikliklerinizi kaybetmeden yeni ve temiz bir branch oluşturmalısınız. Yarım kalan değişiklikleri kayıt altına almak için **git stash** komutunu kullanmalısınız. 10 | 11 | ![git stash](/.gitbook/assets/07_git_stash.jpg) 12 | 13 | **git stash** ile üzerinde çalıştığınız ancak henüz commit etmediğiniz değişikliklerin geçici olarak Git tarafından kayıt altına alınmasını ve aktif branch'inizin herhangi bir değişikliğin olmadığı temiz bir duruma getirilmesini sağlarsınız. **git stash** komutunu çalıştırdıktan sonra tekrar **git status** komutunu çalıştırırsanız önceki bölümde commit edilmemiş bir değişiklik olarak görünen _dosya2.md_ dosyasındaki değişiklik artık listelenmez çünkü **master** branch’imiz **git stash** sonrası temiz bir duruma geldi. 14 | 15 | **git stash list** komutunu kullanarak aktif branch'inizde geçici olarak kayıt altına aldığınız değişikliklerin listelenmesini sağlayabilirsiniz. 16 | 17 | ![git stash list](/.gitbook/assets/08_git_stash_list.jpg) 18 | 19 | Yukarıda görünen listede en son stash işlemi ile geçici olarak kaydedilen değişiklikler en üstte yer alır. Stash'de yer alan bir değişikliği geri yüklemek istediğinizde iki seçeneğiniz var 20 | 21 | * **git stash pop** komutu ile yukarıdaki listenin en üstünde yer alan değişiklik geri yüklenecek ve bu değişiklik listeden silinecek. ![git stash pop](/.gitbook/assets/09_git_stash_pop.jpg) 22 | * **git stash apply** komutu ile istediğiniz değişikliği geri yükleyebilirsiniz. Ancak bu işlem sonrasında yüklediğiniz değişiklik listeden **silinmeyecek**. ![git stash apply](/.gitbook/assets/10_git_stash_apply.jpg) 23 | 24 | Herhangi bir değişikliği listeden silmek için **git stash drop** komutunu kullanabilirsiniz. 25 | 26 | ![git stash drop](/.gitbook/assets/11_git_stash_drop.jpg) 27 | 28 | ## Stash Başka Hangi Durumlarda Kullanılabilir? 29 | 30 | Stash işlemini üzerinde çalıştığımız aktif branch'imizi temiz bir duruma getirmek için kullanabiliriz. Bunun dışında aşağıdaki durumlarda da Git'in Stash özelliğini kullanabilirsiniz 31 | 32 | * Farklı bir branch'i aktif hale getirmeden önce 33 | * Remote Repository değişikliklerinizi yerel diskinize indirmeden önce 34 | * Branch'inizi merge etmeden önce 35 | -------------------------------------------------------------------------------- /content/git_arac_ve_servisleri/cevrimici_git_servisleri.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Git Servisleri 6 | 7 | Takım çalışması söz konusu olduğunda en önemli konulardan birisi de kaynak kodunun veya daha genel anlamda dosyaların nasıl paylaşılacağına karar vermektir. Bu noktada iki seçeneğiniz var 1\) dosyalarınızı kendi sunucularınız üzeriden paylaşmak veya 2\) işi paylaşım ve barındırma hizmeti vermek olan online servisler kullanmak 8 | 9 | Dosyalarınızı kendi sunucularınız üzerinden paylaşmanın aşağıdaki gibi avantajları vardır 10 | 11 | * Düşük maliyet 12 | * Dosyalarınız kendi sunucularınzdadır 13 | * Git'in veya hangi versiyon kontrol sistemini kullanıyorsanız bu sistemin tüm özelliklerini istediğiniz gibi kullanabilirsiniz 14 | 15 | Ancak bu seçeneğin aşağıdaki dezavantajlarını da göz ardı edemeyiz 16 | 17 | * Sunucuların çalışır halde ve erişilebilir olmasını sağlamak sizin sorumluluğunuzdadır 18 | * Yedekleme sorumluluğu sizde olacak 19 | * Güvenlik ve yazılım güncellemelerini de sizin takip etmeniz gerekir 20 | 21 | Eğer sunucu kaynakları yeterli olan, yedekleme, güncelleme gibi sunucu yönetimi konularında ayrı ve uzman ekibi olan bir kurumda çalışıyorsanız dosyalarınızı kendi sunucularınızda barındırmak ilk tercihiniz olacaktır. Ancak küçük bir girişimseniz veya açık kaynak bir projeniz varsa sunucu yönetimi ile ilgili yeterince uzmanlığınız ve kaynağınız olmayabilir. Bu durumda dosyalarınızı online bir servis üzerinde barındırmak ve buradan paylaşıma açmak sizin için daha mantıklı olacaktır. 22 | 23 | ## GitHub 24 | 25 | Özellikle açık kaynak projeler için oldukça popüler bir servis olan GitHub'ı kullanabilirsiniz. GitHub açık kaynak projeler için ücretsiz olmakla birlikte, kurumlar ve özel projeler için de oldukça makul fiyatlara Git sunucu hizmet'i sunmaktadır. 26 | 27 | [GitHub Ana Sayfa](https://github.com/) 28 | 29 | ## BitBucket 30 | 31 | Daha önce küçük bir girişim olarak Mercurial \(bu da dağıtık bir versiyon kontrol sistemi\) hizmeti sunmak için kurulan BitBucket Atlassian tarafından satın alındıktan sonra Git sunucu hizmeti de sunmaya başladı. BitBucket açık kaynak veya özel 5 kullanıcıya kadar olan sınırsız sayıda projeniz için ücretsiz hizmet sunar aynı zamanda oldukça makul fiyatlara da daha fazla kullanıcı için ücretli hizmet seçeneği de var. 32 | 33 | [BitBucket Ana Sayfa](https://bitbucket.org/) 34 | 35 | ## Visual Studio Team Services 36 | 37 | Microsoft tarafından sunulan bu servis ile 5 kullanıcıya kadar sınırsız sayıda Git Repository'si oluşturabilirsiniz. Daha büyük takımlarınız için yapacağınız aylık ödemelerle de bu servisten yararlanabilirsiniz. Ayrıca Visual Studio Team Services'de, Git'in yanı sıra Microsoft'un kendi versiyon kontrol sistemi olan Team Foundation Server \(TFS\) ile de kodlarınızı versiyonlayabilirsiniz. 38 | 39 | [Visual Studio Team Services Ana Sayfa](https://www.visualstudio.com/team-services/) 40 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/remote_bir_proje_olusturmak.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Remote bir proje oluşturmak 6 | 7 | Versiyon kontrolü Git ile yapılan bir projede yer alıyorsanız _remote repository_'lerinizi nasıl yöneteceğinizi de öğrenmeniz gerekir. Remote repository'leri projelerinizi internette veya sınırlı erişime izin verilen şirket ağında yer alan versiyonları olarak düşünebilirsiniz. 8 | 9 | Diğer ekip üyeleri ile birlikte verimli çalışabilmek, onların yaptığı değişiklikleri kendi yerel çalışma alanınıza almak, kendi yaptığınız değişiklikleri onlar ile paylaşabilmek için remote repository'lerinizi doğru ve etkin bir şekilde yönetmelisiniz. 10 | 11 | Git ile versiyon kontrolü yapılan bir projeye dahil olduğunuzda size verilecek ilk bilgiler projenin Git adresi \(URL\) ve projeye erişim için kullanacağınız kullanıcı adı ve şifrenizdir. Uzaktaki bir repository'nin \(URL\) adresi aşağıdaki formatlardan birinde olacaktır 12 | 13 | * ssh://user@server/git-repo.git 14 | * kullanıcıadı@sunucuadı:git-repo.git 15 | * [http://example.com/git-repo.git](http://example.com/git-repo.git) 16 | * [https://example.com/git-repo.git](https://example.com/git-repo.git) 17 | * git://example.com/git-repo.git 18 | 19 | Bu adres formatlarından ilk iki tanesi [SSH](http://en.wikipedia.org/wiki/Secure_Shell) \(Secure Shell\) protokolüne karşılık gelir. http:// ve https:// protokolleri ise normal internet erişimi için de kullanılan protokollerdir. Son format ise git'in kendi protokolüne karşılık gelir. 20 | 21 | Remote repository'nizin adresini ve erişim için gerekli kullanıcı adınızı ve şifrenizi öğrendikten sonra yapmanız gereken tek şey bu adresten projenizin dosyalarını yerel diskinize klonlamak. Bunun için öncelikle yerel diskinizde projenizi indireceğiniz bir klasör oluşturmanız ve Terminal'den bu klasöre gitmeniz gerekiyor. Sırasıyla aşağıdaki komutları Terminal'de yazınız 22 | 23 | ![Boş Klasör Oluşturma](/.gitbook/assets/01_emptyprojectdir.jpg) 24 | 25 | Yukarıdaki ekran görüntüsünde yer alan ilk **cd** komutu ile proje klasörümün içinde yer alacağı ana klasör olan **Projects** klasörüne konumlanıyoruz. İkinci komut olan **mkdir** ile proje klasörümüz olan **git101\_kitap** klasörünü oluşturuyoruz. Üçüncü komutumuz ile de yeni oluşturduğumuz **git101\_kitap** klasörüne konumlanıyoruz. 26 | 27 | Yerel diskimizde boş proje klasörümüzü oluşturduğumuza göre şimdi remote repository'mizi yerel klasörümüze **git clone** komutu ile indirebiliriz. 28 | 29 | !\[Remote repository'yi klonlama\]\(02\_cloneremote.jpg "Remote repository'yi klonlama"\) 30 | 31 | > Kullanıcı adınızı ve şifrenizi vererek remote repository'yi klonlamak için aşağıdaki **git clone** komutuna bu bilgileri aşağıdaki formatta vermeniz gerekiyor 32 | > 33 | > git clone [https://kullanıcıadı:şifre@github.com/username/repository.git](https://kullanıcıadı:şifre@github.com/username/repository.git) 34 | -------------------------------------------------------------------------------- /app/components/navigation/content.vue: -------------------------------------------------------------------------------- 1 | 24 | 25 | 75 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_07.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 7.Gün: Commit Edilmiş Değişiklikleri Silmek 6 | 7 | Bu bölüme kadar değişiklikleri geri almanın üç yöntemini ele aldık, hatırlatmak gerekirse 8 | 9 | * Track edilmeyen dosyalardaki \(unstaged\) değişiklikleri iptal etmek için **git checkout \[dosya\_adı\]** 10 | * Track edilen fakat henüz commit edilmemiş \(staged\) dosyalardaki değişiklikleri iptal etmek için **git reset HEAD \[dosya\_adı\]** 11 | * Commit edilmiş bir değişikliği proje tarihçesini bozmadan **git revert \[commit\_hash\]** 12 | 13 | komutlarını kullanabiliriz. 14 | 15 | Bu bölümde ise commit edilmiş değişiklikleri `git reset --hard` komutu ile proje tarihçesinden nasıl silebileceğimizi ele alıyoruz. Reset komutunu **--hard** parametresi ile paylaşımlı çalışılan projelerde özellikle uzak depoya yazdığınız değişiklikler için kullanmamanızı öneriyorum. Ancak, çalışma kopyanızda \(Working Copy\) henüz uzak depoya yazarak ekibinizin geri kalanı ile paylaşmadığınız commitleri **--hard** parametresi ile silebilirsiniz. 16 | 17 | Özetlemek gerekirse `git reset --hard ` komutu ile yeni bir commit oluşturmadan geri dönülmez bir şekilde herhangi bir commit’i silebilirsiniz. 18 | 19 | ## Alıştırma-1: Tag oluşturma 20 | 21 | ```bash 22 | # Proje klasörünüze konumlanın 23 | cd 24 | 25 | # Yeni bir dosya oluşturun 26 | touch .txt 27 | 28 | # Oluşturduğunuz dosyayı commit edelim 29 | git add -A . 30 | git commit -m “7. gün 1. alıştırma” 31 | 32 | # Deponuzun şu anki halini yansıtan v0.1 isimli tag oluşturduk 33 | git tag v0.1 34 | # Depomuzdaki tag’ları listeledik 35 | git tag 36 | 37 | # Depomuzdaki değişiklikleri uzak depo ile senkronize ettik 38 | git push 39 | ``` 40 | 41 | ## Alıştırma-2: Değişikliğn geri alınması 42 | 43 | ```bash 44 | # Proje klasörünüze konumlanın 45 | cd 46 | 47 | # 1. Alıştırmadaki dosyanızın içeriğini değiştirin 48 | 49 | # Dosyadaki değişiklikleri commit edelim 50 | git add -A . 51 | git commit -m “7. gün 2. alıştırma” 52 | 53 | # Depomuzu v0.1 ile tagladığımız haline geri döndürelim. 54 | git reset --hard v0.1 55 | 56 | # Oluşturduğunuz dosyanın içeriğinin v0.1’deki hali ile aynı oldp olmadığını kontrol edin 57 | 58 | # Depomuzun commit tarihçesindeki son 5 commiti listeleyelim 59 | git log -n 5 60 | 61 | # Depomuzdaki değişiklikleri uzak depo ile senkronize ettik 62 | git push 63 | ``` 64 | 65 | **Soru-1:** Dosyanızın içeriğini tekrar değiştirerek add/commit/push işlemlerini yapın. Sonra projenizi git reset --hard v0.1 komutu ile tekrar v0.1 versiyonuna geri alıp ardından git push ile uzak depoya göndermeye çalıştığınızda nasıl bir hata ile karşılaşıyorsunuz? Bu durumda v0.1'e geri dönmek için ne yapmanız lazım? 66 | 67 | **Soru-2:** Oluşturduğunuz v0.1 isimli tag'ı nasıl silersiniz? 68 | 69 | **Soru-3:** Oluşturduğunuz tag’ları uzak deponuza nasıl gönderebilirsiniz? 70 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_01.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 1.Gün: İstemci Kurulumları 6 | 7 | * Putty \(Bu kurulum opsiyonel\), Putty Git tarafından depolara SSH ile erişmek için kullanılır. 2. adımda kuracağınız Git for Windows SSH için OpenSSH mı yoksa Putty/Plink mi kurmak istediğinizi soracak 8 | * Git for Windows, Git'in Windows'da çalışması için kullanılan paket. 9 | * Görsel istemciler. Aşağıdaki iki istemciden en az bir tanesini kurabilirsiniz. 10 | * Atlassian SourceTree \(Önerilen\) 11 | * CollabNet GitEye 12 | 13 | ## Alıştırma-1: Git kurulumunun doğru yapıldığının test edilmesi 14 | 15 | Windows > Start > Git Bash isimli uygulama gelmeli 16 | 17 | Git Bash'i çalıştırıp aşağıdaki komutu yazalım 18 | 19 | ```bash 20 | git --version 21 | ``` 22 | 23 | Bu komut çalıştığında aşağıdakine bezer bir versiyon bilgisi görmelisiniz. 24 | 25 | ```bash 26 | git version 2.9.2.windows.1 27 | ``` 28 | 29 | > Alıştırmaları OS X veya Linux işletim sistemlerinde yapıyorsanız komut satırında git --version komutunu çalıştırabilirsiniz. 30 | 31 | ## Alıştırma-2: Git konfigürasyonunun yapılması 32 | 33 | Bu alıştırmayı yapmadan önce 34 | 35 | * Kitabın 1. bölümündeki Git Konfigürasyonu başlığına tekrara göz atabilirsiniz 36 | * Git servislerinden Github, Gitlab veya Bitbucket üzerinde bir hesap oluşturmalısınız 37 | 38 | Git'in global konfigürasyonuna kullanıcı adınızı ve e-posta adresinizi git config komutu ile tanımlayın. 39 | 40 | ```bash 41 | git config --global user.name ali.ozgur 42 | git config --global user.email ali.ozgur@xyz.com.tr 43 | git config --global core.eol native 44 | git config --global core.autocrlf true 45 | ``` 46 | 47 | > **İPUCU**: core.eol ve core.autocrlf değerleri Windows platformu için önerilen değerler. Git’in windows’da End-Of-Line karaketerlerini \(Windows EOL için CRLF kullanıyor, Linux, Unix ve OSX ise LF kullanıyor\) düzgün çalışması için global git konfigürasyonunuzda core.eol ve core.autocrlf ayarlarının yapılması gerekiyor. Ancak, proje depolarınızda .gitattributes dosyasının ilk satırında text=auto değerini girerseniz bu ayar yukarıda yapılan core.eol ve core.autocrlf ayarlarını ezecektir. 48 | 49 | ## Alıştırma-3: Uzak deponun bilgisayarınıza klonlanması 50 | 51 | Önceki alıştırmada oluşturduğunuz Github, Gitlab veya Bitbucket hesabınız için ilgili servis sağlayıcısının sayfalarını kullanarak uzak sunucuda boş bir proje deposu oluşturun. Örneğin, Git101 isimli boş bir depo oluşturabilirsiniz. Daha sonra da SourceTree veya GitEye uzak depoyu bilgisayarınıza kopyalayın. 52 | 53 | Kopyalama işlemini alternatif olarak git clone komutu ile komut satırı ara yüzünden \(Git Bash veya Terminal\) de yapabilirsiniz. Clone komutu kullanmak isteyenler 54 | 55 | * Kullanıcı adı ve şifre bilgisinin bu komutta nasıl geçileceğini 56 | * Klonlama sırasında karşılaşabileceğiniz fatal: index-pack failed şeklindeki hatayı gidermek için ne yapılması gerektiğini araştırabilir 57 | -------------------------------------------------------------------------------- /content/git_arac_ve_servisleri/masaustu_gorsel_git_uygulamalari.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Görsel Git İstemcileri 6 | 7 | Önceki bölümlerde Terminal kullanarak birçok Git komutununun nasıl kullanıldığını size gösterdik. Ancak günlük çalışmanızda her bir komutun ayrıntılı olarak ne işe yaradığını, hangi parametreler ve seçenekleri kabul ettiğini aklınızda tutumak zor olacaktır. Bu nedenle Git'i günlük iş akışınıza entegre edip Git kavramlarını öğrendikten sonra görsel bir Git istermcisi kullanmak işinizi ciddi oranda kolaylaştıracaktır. 8 | 9 | ### Atlassian SourceTree 10 | 11 | SourceTree ücretsiz bir uygulama. SourceTree'yi Mac OS X ve Windows işletim sistemlerinde kullanabilirsiniz. 12 | 13 | [SourceTree'yi bu linkten indirebilirsiniz](http://www.sourcetreeapp.com/) 14 | 15 | ![SourceTree Bookmarks](/.gitbook/assets/01_sourcetree_bookmarks.jpg) 16 | 17 | ![SourceTree Repository](/.gitbook/assets/02_sourcetree_repo.jpg) 18 | 19 | ![SourceTree Commit and Push](/.gitbook/assets/03_sourcetree_commit.jpg) 20 | 21 | ### Tower 22 | 23 | Tower, sadece Mac OS X'de çalışan ücretli bir uygulama.[Bu linki](http://www.git-tower.com/) kullanarak uygulamanın 30 günlük deneme sürümünü indirebilirsiniz. 24 | 25 | ![Tower Repos](/.gitbook/assets/04_tower.jpg) ![Tower Working Copy](/.gitbook/assets/05_tower_workingcopy.jpg) ![Tower Commit History](/.gitbook/assets/06_tower_commithist.jpg) ![Tower Conflict View](/.gitbook/assets/07_tower_conflict.jpg) 26 | 27 | ## GitHub 28 | 29 | Projelerinizin kaynak kodunu [GitHub'da](http://www.github.com) tutuyorsanız GitHub'ın ücretsiz Mac OS X ve Windows için geliştirdiği kullanımı oldukça kolay olan ve Git'in karmaşasından sizi bir nebze olsun uzaklaştırabilecek uygulamasını kullanabilirsiniz. Bu uygulamanın Mac OS X versiyonunu [buradan](https://mac.github.com) ve Windows versiyonunu da [buradan](https://windows.github.com) indirebilirsiniz. 30 | 31 | > Windows versiyonunda GitShell isimli Terminal benzeri uygulamanın kurulumu da yer alıyor. Bu nedenle daha karmaşık Git komutları için Terminal benzeri bir deneyim istiyorsanız GitShell'i rahatlıkla kullanabilirsiniz. 32 | 33 | ## TortoiseGit 34 | 35 | Windows kullananlar ücretsiz bir uygulama olan Tortoise Git uygulamasını [bu linkten](https://code.google.com/p/tortoisegit/) indirip kullanabilirler. Özellikle daha önce Subversion ve TortoiseSVN kullananlar için TortoiseGit benzer bir deneyim sunmaktadır. 36 | 37 | ### Multiplatform İstemciler 38 | 39 | * [GitEye](http://www.collab.net/products/giteye) 40 | * [SmartGit](http://www.syntevo.com/smartgit/) 41 | 42 | ### Linux'a Özel İstemciler 43 | 44 | * [gitg](https://wiki.gnome.org/Apps/Gitg/) 45 | * [giggle](https://wiki.gnome.org/Apps/giggle/) 46 | * [GitForce](http://gdevic.github.com/GitForce) 47 | * [RabbitVCS](http://www.rabbitvcs.org/) 48 | 49 | ## Diğer Uygulamalar 50 | 51 | Diğer görsel Git uygulamalarını Git'in [kendi sayfasından](http://git-scm.com/downloads/guis) inceleyebilirsiniz. 52 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_10.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 10.Gün: Rebase 6 | 7 | Git’de merge ve rebase komutları benzer işlevleri yerine getirmek için kullanılıyor. Her iki komut da bir daldaki değişiklikleri başka bir dala birleştirmek için kullanılır. Ancak bu iki komut arasında proje tarihçesinin oluşturulması ile ilgili ciddi bir farklılık vardır. 8 | 9 | Merge komutu ile A dalındaki değişiklikler B dalı ile birleştirildiğinde B dalının commit tarihçesinde merge işleminden kaynaklanan ve merge commit adı verilen otomatik oluşturulmuş bir commit yer alır. Bu commit A ve B dallarının tarihçelerini birbiri ile ilişkilendirir. 10 | 11 | > Merge commit’in ayrıntılarını kitabımızın 5. Bölümünde “Merge Alternatifi Olarak Rebase Kullanımı” başlığı altında ele almıştık. 12 | 13 | **rebase** komutu kullandığımızda ise ile A dalındaki her bir commit B dalına sanki commit işlemi B dalında yapılmış gibi yeniden yazılır. Bu sayede B dalının commit tarihçesi sanki tüm değişiklikler bu dalda olmuş gibi düz ve kesintisiz görünür. 14 | 15 | ## Ne zaman rebase kullanmalıyız? 16 | 17 | Rebase komutu yerel ve kısa süreliğine \(örneğin bir hata giderme veya deneysel bir çalışma için oluşturulan\) geçerli dallar için kullanılmalı. Paylaşılan depolarda rebase komutunu kullanmamanızı tavsiye ediyorum, çünkü rebase sonrasında projenizin ana dallarında değişikliklerin nereden kaynaklandığına dair bir bilgi veya ipucu göremezsiniz. Bu durum takım çalışmasını olumsuz yönde etkiler. 18 | 19 | > Alıştırmalara başlamadan önce master dalından kopyalanan yerel bir dal oluşturun 20 | 21 | ## Alıştırma-1 22 | 23 | ```bash 24 | # Proje klasörünüze konumlanın 25 | cd 26 | 27 | # master dalını aktif hale getirelim 28 | git checkout master 29 | 30 | # Yeni bir dosya oluşturun 31 | touch ornek_rebase1.txt 32 | 33 | # Değişikliklerinizi commit edin 34 | git add -A . 35 | git commit -m “Ad ve soyad eklendi” 36 | ``` 37 | 38 | ## Alıştırma-2 39 | 40 | ```bash 41 | # Proje klasörünüze konumlanın 42 | cd 43 | 44 | # Oluşturduğunuz dalı aktif hale getirelim 45 | git checkout 46 | 47 | # rebase işlemini yapın 48 | git rebase master 49 | 50 | # dalınızın commit tarihçesinin bilgilerini listeleyen 51 | git hist --all # repository tarihçesine göz atın 52 | ``` 53 | 54 | **Soru-1:** Merge ile rebase arasındaki farkı yorumlayın. 55 | 56 | ## Alıştırma-3 57 | 58 | ```bash 59 | # Proje klasörünüze konumlanın 60 | cd 61 | 62 | # master dalını aktif hale getirelim 63 | git checkout master 64 | 65 | # ornek_rebase1 dosyasının içeriğini metin editörünüz ile değiştirin 66 | git add -A . 67 | git commit -m “Master dalındaki değişiklik mesajınız” 68 | 69 | # Dalınızı aktif hale getirin 70 | git checkout 71 | 72 | # ornek_rebase1 dosyasının içeriğini metin editörünüz ile değiştirin 73 | git add -A . 74 | git commit -m “Diğer daldaki değişiklik mesajınız” 75 | 76 | # rebase işlemini yapın 77 | git rebase master 78 | ``` 79 | -------------------------------------------------------------------------------- /content/remote_repositoryler/remote_degisiklikleri_entegre_etmek.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Remote Değişiklikleri Entegre Etmek 6 | 7 | Takım arkadaşlarınız kendi değişikliklerini tamamlayıp remote branch'de yayınladıktan sonra siz de bu değişiklikleri inceleyip kendi local branch'inize entegre ederek çalışmanıza devam edebilirsiniz. Ancak remote branch'deki değişiklikleri entegre etmeden önce bu değişikliklere ilişkin bilgileri \(dosyaları değil sadece değişikliklere dair Git'de tutulan bilgiler\) görmeniz ve incelemeniz gerekir. 8 | 9 | ![git fetch](/.gitbook/assets/07_git_fetch.jpg) 10 | 11 | Remote branch'deki değişiklikleri indirmek için **git fetch** komutunu kullanıyoruz. Git fetch komutuna geçilen _origin_ değeri ise daha önceki bölümlerde gösterdiğimiz _remotes/origin/master_ isimli remote branch bağlantısına referans vermek için kullanılır. 12 | 13 | > _origin_ değeri **git fetch** komutunun bir parçası değil sadece bir parametre. Origin yerine daha önce local branchimiz ile bağlantısını/ilişkisini kurduğumuz herhangi bir remote branch'i gösteren bir değer olabilir. 14 | 15 | _git fetch_ komutu ile remote branch'deki değişiklikleri indirdikten sonra ise **git log** komutunu kullanarak bu remote branch'deki değişiklikler ile ilgili bilgileri görebiliriz. \(değişiklik tarihi, kimin yaptığı, değişen dosyalar ve commiti sırasında girilen mesaj gibi\) 16 | 17 | Değişiklikleri inceledikten sonra bunları local branch'inize entegre etmeye karar verdiğimizde ise **git pull** komutunu kullanmamız gerekecek 18 | 19 | > Remote branchdeki değişikliklerin bilgilerini indirmek için kullanılan **fetch** \(türkçe anlamı [getirmek](http://www.seslisozluk.net/?word=fetch&lang=tr-en)\) ve bu değişiklikleri entegre etmek için kullanılan **pull** \(türkçe anlamı [çekmek](http://www.seslisozluk.net/?word=pull&lang=tr-en)\) ifadelerinin birbirine yakın anlamları olduğu için karıştırabilirsiniz. Bu karışıklığın önüne geçmek için yapacağınız en güzel şey **git pull** komutunu hiç kullanmamak olacaktır. Ayrıntılar için İngilizce bir blog post olan [_Git: fetch and merge, don't pull_](http://longair.net/blog/2009/04/16/git-fetch-and-merge/%20) inceleyebilirsiniz. 20 | 21 | Git pull komutu aslında arka arkaya iki şey yapmanızı sağlar 22 | 23 | * Remote branch'deki değişiklikler ile ilgili bilgileri indirmek, yani **git fetch** 24 | * Remote branch'deki değişiklikleri local branch'inize entegre etmek yani **git merge** 25 | 26 | İlerleyen bölümlerde çakışmaların tespit edilmesi, çözülmesi ve değişikliklerin entegre edilmesi konularını ayrıntılı olarak ele alacağız şimdilik sadece iş akışımızı özetleyip bu konuyu burada sonlandıralım. Akışımız özetle şöyle olacak 27 | 28 | * git fetch : remote'dan güncelleme bilgilerini indir 29 | * git diff : remote ve local arasındaki farkları incele 30 | * git merge : değişiklikleri otomatik merge et çakışma varsa bir sonraki adıma geçin 31 | * Çakışma olan dosyalarınızı açın ve çakışmaları düzeltin 32 | * git add: çakışmanın giderildi ve değişiiklik Staging Area'ya alındı 33 | -------------------------------------------------------------------------------- /content/remote_repositoryler/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Remote Repository'ler 6 | 7 | Günlük çalışmamız sırasında staging ve commit gibi versiyon kontrolü ile ilgili işlemlerin çoğunu yerel diskimizde yer alan local repository üzerinde yaparız. Proje'de çalışan tek kişi siz iseniz muhtemelen Internet'de veya yerel ağıda yer alan remote bi repository oluşturmanıza da gerek olmayacaktır. 8 | 9 | Ancak takım çalışması söz konusu olduğunda, takımdaki geliştiricilerin birlikte çalışabilmesi için herkesin değişikliklerini ortak bir alanda yayınlaması ve diğerlerinin de bu ortak alan üzerinden bu değişiklikleri kendi branch'lerine entegre etmesi gerekecektir. Bu durumda başvuracağınız en etkin araç Git'deki Remote Repository işlevleridir. Remote repository'leri en basit anlamda tüm ekibin erişimi olan dosya sunucusu olarak düşünebilirsiniz. 10 | 11 | Gelin şimdi Local ve Remote repository'leri birbirinden ayıran temel özelliklere göz atalım 12 | 13 | ## Konum 14 | 15 | Local repository'ler geliştiricilerin kendi bilgisayarlarında yer alırken Remote repository'ler, çoğunlukla internet olmak üzere, ekipteki herkesin erişebileceği bir sunucuda yer alırlar. 16 | 17 | ## Özellikler 18 | 19 | Teknik olarak remote repository'ler ile local repositoryler arasında bir fark yoktur. Local repository'ler için önceki bölümlerde ele aldığımız commit işlemi, branch oluşturma gibi işlemlerin tamamı remote repository'ler için de yapılabiliyor. Ancak tüm bu benzerliklere rağmen remote repository'ler için Working Copy \(aktif branch'deki dosyaların diskimizdeki kopyaları\) yapısı geçerli değildir, remote repository'lerde sadece Git'in veri tabanının tutulduğu **.git** klasörü yer alır. 20 | 21 | ## Repository Oluşturma 22 | 23 | Local bir repository ancak iki şekilde oluşturulabilir 24 | 25 | * Boş bir repository olarak sıfırdan **git init** komutu ile oluşturabilirsiniz veya 26 | * Remote bir repository'yi **git clone** komutu ile yerel diskinizde indirebilirsiniz. 27 | 28 | Remote repository'ler de iki yöntem ile oluşturulabilir 29 | 30 | * Local repository'nizi **git clone** komutunu **--bare** parametresi ile kullanarak remote bir repoository'ye klonlayabilirsiniz veya 31 | * Boş bir remote repository oluşturmak için **git init** komutunu yine **--bare** parametresi ile kullanabilirsiniz. 32 | 33 | ## Local/Remote iş akışı 34 | 35 | Git'de remote repository işlemleri için az sayıda komut vardır. Günlük çalışmamız srasında bölümün başında da belirttiğimiz gibi Git işlemlerimizin çoğu local repositorymiz üzerinde gerçekleşir ve internet veya ağ bağlantısına ihtiyaç duymayız. Ancak remote repository komutlarını kullanabilmek için internet veya ağ bağlantısına ihtiyaç vardır. 36 | 37 | Bu bölümümüzde Remote Respository'ler ile ilgili aşağıdaki konuları ele alarak ayrıntıları öğreneceğiz 38 | 39 | * Remote Bir Repository'ye Nasıl Bağlantı Sağlanır 40 | * Remote Repository'deki Verilerin İncelenmesi 41 | * Remote Değişiklikleri Entegre Etmek 42 | * Local Bir Branch'i Yayınlamak \(Publish\) 43 | * Branch'leri Silmek 44 | -------------------------------------------------------------------------------- /app/components/navigation/index.vue: -------------------------------------------------------------------------------- 1 | 42 | 43 | 83 | -------------------------------------------------------------------------------- /content/branching_dallanma_ve_merging_birlestirme/local_bir_branchde_calismak.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Local Bir Branch'de Çalışmak 6 | 7 | Gelin şimdi hep birlikte günlük çalışmanız sırasında kullanabileceğiniz basit bir branching akışını ele alalım. Çalışma senaryomuzun şöyle geliştiğini düşünelim 8 | 9 | 1. Bir web sitesi üzerinde çalışmaya başladınız 10 | 2. Bu siteye yeni bir özellik eklemek için bir branch oluşturdunuz 11 | 3. Bu yeni branch üzerinden değişikliklerinizi yapmaya başladınız 12 | 13 | Bu sırada web sitesinde bir güvenlik açığı tespit edildiğini bildiren bir email aldınız. Acil olarak bu güvenlik açığını gidermeniz için yapmakta olduğunuz çalışmayı bırakmanız ve bu durumu düzeltmeniz gerekiyor. Böyle bir durumda aşağıdaki adımları takip edebilirsiniz 14 | 15 | 1. Aktif branch'inizi web sitenizin son stabil versiyonunun bulunduğu **master** branch olarak değiştirdiniz. 16 | 17 | > **git checkout master** komutunu kullandık 18 | 19 | 2. Güvenlik açığını giderme çalışmanız için yeni bir branch oluşturdunuz. 20 | 21 | > * **git branch loginsorunu** komutunu kullanarak branch oluşturduk ve 22 | > * **git checkout loginsorunu** komutu ile bu branch'i aktif > hale getirdik 23 | 24 | 3. Güvenlik açığını giderecek değişikliği tamamladınız, testlerinizi yaptınız ve bu değişikliği Staging Area'ya ekleyip sonrasında da commit ettiniz. 25 | 26 | > * **git add login.xyz login.html login.css** ile değişiklikleri Staging Area'ya gönderdik 27 | > * **git commit -m "Özel karakter içeren kullanıcı adlarında ortaya çıkan güvenlik sorunu giderildi"** ile değişikliklerimizi commit ettik. 28 | 29 | 4. **master** branch’imizi aktif hale getirdik. 30 | 31 | > **git checkout master** komutu ile 32 | 33 | 5. Commit ettiğiniz değişikliği web sitenizin stabil versiyonunu içeren **master** branch’imize merge ettik. 34 | 35 | > **git merge loginsorunu** 36 | 37 | 6. Daha önce üstünde çalışmakta olduğunuz yeni özellik ile ilgili değişiklikleri içeren branch'inizi aktif hale getirerek çalışmanıza kaldığınız yerden devam edebilirsiniz. 38 | 39 | > **git checkout yeniozellik\_xyz** komutu ile 40 | 41 | ## Checkout, HEAD ve Working Copy kavramları 42 | 43 | Git'de bir branch otomatik olarak o branch için yaptığınız son commit işlemine bir işaretçi tutar ve hangi dosyaların o branch'e ait olduğunu bilir. Herhangi bir anda bir proje için tek bir branch **aktif** olabilir. Bu branch'e **HEAD** denir ve Working Copy içindeki \(Working Copy'yi projenizin yerel diskinizdeki dosyalarının tamamı olarak düşünebilirsiniz\) dosyalar aktif olan branch'e yani **HEAD**'e aittir. Diğer branch’lerinizdeki dosyalar diskiniz üzerinde değil Git'in veri tabanında \(.git klasörü içinde özel bir formatta\) bulunur. 44 | 45 | Farklı bir branch'i aktif hale getirmek için **git checkout** komutu kullanılır. Bu durumda Git otomatik olarak sizin için iki şey yapar 1. Aktif hale getirdiğiniz branch'i **HEAD** yapar ve 2. Aktif hale getirdiğiniz branch'e ait dosyaları Git veri tabanınızdan yerel diskinize kopyalar ve önceki branch'e ait dosyaları diskinizden kaldırır. Yani Working Copy'nize yeni branch'e ait olan dosyaları koyar. 46 | -------------------------------------------------------------------------------- /content/ileri_seviye_komutlar_ve_islemler/merge_alternatifi_olarak_rebase_kullanimi.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Merge Alternatifi Olarak Rebase Kullanımı 6 | 7 | Merge komutu iki branch arasındaki değişiklikleri entegre etmenin en kolay yolu olmakla birlikte tek yol değildir. Rebase komutu da iki branch'ı entegre etmek için kullanılan merge komutuna alternatif bir komuttur. Bu durumda kafanızda "Neden **merge** yerine **rebase** kullanmak isteyelim?" şeklinde bir soru oluşabilir. Bu sorunun cevabını bulmak için önce gelin **merge** komutunun biraz daha iyi anlamaya çalışalım. 8 | 9 | ## Merge komutuna daha yakın bir bakış 10 | 11 | Git merge işlemini gerçekleştirmeden önce aşağıdaki üç commit'i tespit eder 12 | 13 | * **İki branch'in ortak commit'i:** İki branch'in de tarihçesini daha yakından incelediğinizde bu branch'lerin zamanın bir noktasında ortak bir commit'e sahip olduklarını görürüz. Bu anda her iki branch'in de içeriği bire bir aynıdır. 14 | * **Branch'lerin son commit'leri:** Her iki branch için de yapılan son commit'ler 15 | 16 | Bu üç commit tespit edildikten sonra Git bu üç commit'i birleştirerek entegrasyonu yapabilir. 17 | 18 | ## Fast-Forward ve Merge Commit 19 | 20 | Basit bazı durumlarda branch'lerden bir tanesinde herhangi bir değişiklik yapılmamıştır ve bu branch'in yukarıdaki bölümde belirttiğimiz ortak commit'i ve son commit'i aynıdır. Bu durumda merge işlemi çok basitleşir ve git diğer branch'in tüm commit'lerini ortak commit'in üzerine ekleyerek merge işlemini yapar. Bu özel duruma Git terminolojisinde **"Fast-Forward Merge"** denir ve her iki branch'in tarihçesi de ortaktır. 21 | 22 | Fakat çoğu zaman her iki branch'de birbirinden bağımsız olarak değişikliğe uğrar ve tarihçe açısından birbirinden uzaklaşırlar. Bu durumda merge işlemini yapmak için Git'in her iki branch arasındaki değişiklikleri içeren otomatik bir commit oluşturması gerekir. Oluşturulan bu commit'e Git terminolojisinde **"Merge Commit"** denir. 23 | 24 | ## Normal Commitleri ve Merge Commitleri Ayırt Etmek 25 | 26 | Normal commit'leri yazılım geliştiriciler ince eleyip sık dokuyarak oluşturulurlar, diğer yandan Merge Commitler ise Git tarafından otomatik oluşturulurlar. Merge işlemi ile ilgili ayrıntıları daha sonradan incelemek isterseniz her iki branch'in commit tarihçesine ve commit çizelgesine bakmanız gerekir. 27 | 28 | ## Rebase ile değişiklikleri entegre etmek 29 | 30 | Bazı takımlar iki branch'i yukarıda anlattığımız otomatik merge commit'ler yerine **rebase** ile entegre etmeyi tercih edebilir. Rebase sonrasında projenizin iki farklı branch'i olduğuna dair herhangi bir tarihsel iz oluşmaz. 31 | 32 | Gelin şimdi rebase işleminin nasıl yapıldığına bakalım. Örnek senaryomuzda Branch-B'deki değişiklikleri Branch-A'ya entegre edeceğiz. Rebase işlemini **git rebase** komutunu aşağıdaki gibi kullanarak yapıyoruz. 33 | 34 | > **$ git rebase Branch-B** 35 | 36 | Bu komut ile Git öncelikle Branch-A ile Branch-B'nin ortak en son commit'ini bulup ortak commit sonrasında Branch-A'da yapılan diğer tüm commit'leri geri alır. Aslında bu commitler silinmez sadece geçici olarak farklı bir yerde saklanır. Daha sonra Branch-B'deki tüm commitler Branch-A'ya uygulanır. Son aşamada ise Branch-A'nın geçici olarak farklı bir yerde saklanan commit'leri tekrar uygulanır. Bu işlemler sonrasında tüm değişiklikler sanki sadece Branch-A üzerinde gerçekleşmiş gibi görünür. 37 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_09.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 9.Gün : Değişiklikleri Birleştirme \(Merge\) 6 | 7 | Oluşturduğumuz dallardaki değişiklikleri master dalına veya master dalındaki değişiklikleri üzerinde çalıştığınız başka bir dala entegre işlemine birleştirme \(merge\) denir. 8 | 9 | Alıştırmalarımıza geçmeden önce aşağıdaki komutları kullanarak git log komutu için bir alias \(kısaltma\) oluşturalım. 10 | 11 | ```bash 12 | git config --global alias.hist = "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short" 13 | ``` 14 | 15 | ## Alıştırma-1 16 | 17 | ```bash 18 | # Proje klasörünüze konumlanın 19 | cd 20 | 21 | # Yeni bir dal oluşturalım 22 | git checkout -b 23 | 24 | # Yeni bir dosya oluşturalım 25 | touch dosya1.txt 26 | # Oluşturduğunuz dosyayı commit edin 27 | git add -A . 28 | git commit -m “Dosya 1 eklendi” 29 | 30 | # Yeni bir dosya daha oluşturalım 31 | touch dosya2.txt 32 | # Oluşturduğunuz dosyayı commit edin 33 | git add -A . 34 | git commit -m “Dosya 2 eklendi” 35 | 36 | # Yeni bir dosya daha oluşturalım 37 | touch dosya3.txt 38 | # Oluşturduğunuz dosyayı commit edin 39 | git add -A . 40 | git commit -m “Dosya 3 eklendi” 41 | ``` 42 | 43 | ## Alıştırma-2 44 | 45 | ```bash 46 | # Proje klasörünüze konumlanın 47 | cd 48 | 49 | # master dalını aktif hale getirelim 50 | $ git checkout master 51 | 52 | # Proje klasörünüzün içeriğini listeleyin 53 | ls -lah 54 | 55 | # Yeni bir dosya oluşturalım 56 | touch ornek1.txt 57 | 58 | # Oluşturduğunuz dosyayı commit edin 59 | git add -A . 60 | git commit -m “Örnek 1 eklendi” 61 | ``` 62 | 63 | **Soru-1:** git hist --all komutu çalıştırdığınızda iki alıştırmada yaptığınız işlemleri görüyor musunuz? Çıktıyı nasıl yorumlarsınız? 64 | 65 | ## Alıştırma-3 66 | 67 | **master** dalındaki değişiklikleri oluşturduğunuz dal’a entegre edelim. Bu durumda birleştirme işlemi için master kaynak oluşturduğunuz diğer dal da hedeftir. 68 | 69 | ```bash 70 | # Proje klasörünüze konumlanın 71 | cd 72 | 73 | # Oluşturduğunuz dalı aktif hale getirin 74 | git checkout 75 | 76 | # master dalındaki değişiklikleri birleştirin 77 | git merge master 78 | 79 | git hist --all 80 | ``` 81 | 82 | ## Alıştırma-4 83 | 84 | ```bash 85 | # Proje klasörünüze konumlanın 86 | cd 87 | 88 | # master dalını aktif hale getirelim 89 | git checkout master 90 | 91 | # Eklediğiniz ornek1.txt dosyasını metin editörünüz ile açıp içine adınızı ve soyadınızı yazın 92 | # Değişikliklerinizi commit edin 93 | git add -A . 94 | git commit -m “Ad ve soyad eklendi” 95 | 96 | # Oluşturulan dalı aktif hale getirelim 97 | git checkout 98 | 99 | # ornek1.txt dosyasını metin editörünüz ile açıp içine Deneme yazın 100 | # Değişikliklerinizi commit edin 101 | git add -A . 102 | git commit -m “Ad soyad bilgisi Deneme olarak değiştirildi” 103 | 104 | git hist --all 105 | git merge master 106 | ``` 107 | 108 | **Soru-1:** Çakışma oluşan dosyayı açın ve çakışma olan satırların nasıl gösterildiğini inceleyip gösterimde kullanılan notasyonu yorumlayın. 109 | 110 | **Soru-2:** git mergetool komutunu çalıştırın ve bu komutun ne işe yaradığını yorumlayın. 111 | 112 | **Soru-3:** merge/diff işlemlerinde Windows üzerinde WinMerge uygulamasının kullanılması için Git’de nasıl bir konfigürasyon yapmanız gerektiğini araştırın. \(OSX kullanıyorsanız SourceGear DiffMerge, Linux kullanıyorsanız da KDiff3 için araştırmanızı yapabilirsiniz\) 113 | -------------------------------------------------------------------------------- /app/components/navigation/sections/index.vue: -------------------------------------------------------------------------------- 1 | 59 | 60 | 98 | -------------------------------------------------------------------------------- /content/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Önsöz 6 | 7 | Bu kitapta son 4-5 yılda yazılım geliştiricilerin ve yazılım şirketlerinin vazgeçilmez araçlarından biri olan ve benim de bir yazılım geliştirici olarak çok başarılı bulduğum Git Dağıtık Versiyon Kontrol Sistemini \(Distributed Version Control System\) örnekler ile ele alarak size tanıtmaya çalışacağım. 8 | 9 | İster kıdemli bir yazılım geliştirici olun isterseniz yazılım geliştirme işine yeni başlayan bir profesyonel iş görüşmelerinde temel bilgisayar bilimleri, programlama dilleri ve veri tabanları ile ilgili sorulardan sonra ilk 5 soru içinde yer alacak konulardan birisi de Git olacaktır. Özellikle 2009 yılı itibariyle bulut tabanlı bir sistem olarak kullanıma açılan GitHub’ın yıllar içindeki yükselişi ile birlikte GitHub profiliniz, GitHub’da takip ettiğiniz ve katkı yaptığınız projeler işverenler açısından sizinle ilgili önemli ipuçları sağlayan bir bilgi olarak değerlendirilmektedir. 10 | 11 | Versiyon kontrol sistemi olarak Git’in yükselişi GitHub’ın yükselişi ile paralellik göstermiştir. 2005 yılında ilk stabil sürümü yayınlanan Git, 2009 ve 2010 yılına kadar sadece Linux ile iç içe olan çevrelerin takip edip kullandığı dağıtık bir versiyon kontrol sistemiydi. Ancak 2009 itibariyle GitHub’ın açık kaynak projeler için ücretsiz Git hizmeti vermeye başlaması, hemen ardından aynı yıllarda Bitbucket’ın ve sonrasında GitLab’ın benzer Git servislerin sağlamaya başlaması Git’in daha geniş kitlelere ulaşmasını ve farklı profillerdeki yazılım geliştiriciler tarafından yoğun bir şekilde kullanılmasını sağladı. 12 | 13 | Yazılım Geliştirme ile ilgili çoğu konuda olduğu gibi Git ile ilgili kaynaklar da ağırlıklı olarak İngilizce yazılmaktadır. Türkçe bir kaynak kitap hazırlamanın terminoloji anlamında en büyük zorluğu İngilizce terimler için uygun Türkçe karşılıklarını bulmaktır. Ancak bu kitapta İngilizce-Türkçe geçişini birebir yapmayacağız, mümkün olduğu kadar Versiyon Kontrolü ve Git ile ilgili terimlerin İngilizce hallerine yer vereceğiz. Yazılım Geliştirme alanında kullanılan araçların çoğu kendi terminolojisi ve jargonu ile bilinir bu nedenle kullandığımız İngilizce terimleri İngilizce birere kelime olarak değil Git ile çalışmanın terminolojisi ve jargonu olarak düşünebilirsiniz. Bu terimler profesyonel yaşamınızda ekip arkadaşlarınız ile yapacağınız konuşmalarda sıkça duyup kullanacağınız Git’e dair terimler olarak zihninize yerleştirmelisiniz. 14 | 15 | Konuların diziliminde ve içeriğin oluşturulmasında kendi kişisel tecrübemin yansıra Git’i öğrenme ve kendi ekibime bu bilgileri aktarma aşamasında faydalandığım birçok basılı ve çevrimiçi kaynaktan faydalanılmıştır. 16 | 17 | Bu kitapta yer verdiğimiz giriş ve temel seviyedeki konuları iyice kavrayıp kendi projelerinizde uyguladıktan sonra daha ileri seviyede Git öğrenmek isterseniz ücretsiz e-kitap olarak yayınlanan ve her zaman güncel tutulan Pro Git isimli kitaptan faydalanabilirsiniz. Pro Git kitabı Git’in temel kaynaklarından birisidir ve Git ile ilgili yayınlanan çoğu basılı ve çevrimiçi kaynak bu kitaba atıfta bulunmaktadır. 18 | 19 | Kitaptaki örneklerimizi Terminal \(komut satırı veya command line olarak da tabir edilen\) üzerinden Apple OSX ve Windows işletim sistemleri üzerinde oluşturacağız. Bu kaynağın oluşturulduğu sırada kullanılan OSX ve Git sürüm bilgileri şöyleydi 20 | 21 | * OSX 10.12.3 \(Sierra\) 22 | * Git 2.9.3 \(Apple Git-75\) 23 | 24 | Windows tarafında ise sürüm bilgileri şu şekilde 25 | 26 | * Windows 10 Pro 64 bit 27 | * Git 2.9.2 \(Git for Windows\) 28 | 29 | Git, OSX'in yanısıra tüm Linux dağıtımları ve Windows'da da çalışmaktadır. Git komutları kullandığınız işletim sistemine göre değişmez ancak Git kurulumu ve kullanacağımız yardımcı araçlar işletim sistemine göre değişebilir. 30 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/basit_anlamda_versiyon_kontrolu_is_akisi.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Basit Anlamda Versiyon Kontrolü İş Akışı 6 | 7 | Git'in derinliklerine dalmadan önce gelin basit bir versiyon kontrol iş akışına adım adım göz atalım. 8 | 9 | Versiyon kontrolünün en temel bileşeni **repository** denilen yapıdır. Repository, dosyalarınızdaki tüm değişiklikleri ve bu değişiklikler ile ilgili ilave bilgileri \(değişikliği kim, ne zaman yaptı ve değişiklik ile ilgili girilen açıklamalar\) ayrı birer **versiyon** olarak kayıt altında tutan bir veri tabanıdır. Git tüm bu bilgileri genellikle dosya sisteminde gizli bir klasör olarak oluşturulan **.git** isimli klasör içinde bir dizi dosya olarak tutar. 10 | 11 | Yukarıda bahsettiğimiz **repository**'yi kendi bilgisayarınızda oluşturmak için iki yöntem kullanabilirsiniz. 12 | 13 | * Henüz versiyon kontrolünde olmayan bir projeniz varsa _\*git init_ komutu ile projenizi tüm klasör ve dosyaları ile birlikte versiyon kontrolüne alabilirsiniz 14 | * Projeniz uzaktaki veya şirket ağınızdaki bir Git sunucusunda versiyon kontrolü altında tutuluyorsa projeyi kendi bilgisayarınıza **git clone** komutu ile indirebilirsiniz. 15 | 16 | Projeniz için yukarıdaki yöntemlerden biri ile _repository_ oluşturduktan sonra aşağıdaki basit akışı kullanarak değişikliklerinizi yapmaya başlayabilirsiniz 17 | 18 | 1. Projenizin repository’sini oluşturduktan sonra dosyalarınız üzerinde istediğiniz değişiklikleri istediğiniz uygulamayı kullanarak yapabilirsiniz. Bu aşamada yaptığınız değişiklikleri versiyon kontrolü için birebir ve doğrudan takip etmenize gerek yoktur. 19 | 2. Yaptığınız değişiklikler istediğiniz bir noktaya ulaştığında veya bir özellik veya sorun giderme düzenlemesi ile ilgili çalışmanız tamamlandığında versiyon kontrolü bakış açısı ile değişikliklerinizi değerlendirmeniz gerekir. Bu aşamada değişikliklerinizi **commit** adı verilen bir bütünü olarak tarif etmelisiniz. Böylece projenizin yeni bir versiyonunu oluşturma işleminin ilk adımını tamamlamış olacaksınız. 20 | 3. Fakat, commit işlemi öncesinde dosyalarınızda yaptığınız değişikliklerin bir özetini görmek isteyebilirsiniz. _git status_ komutu ile hangi dosyaları değiştirdiğinizi, sildiğinizi veya hangi dosyaları eklediğinizi kolayca görebilirsiniz. 21 | 4. Bir sonraki aşamada değişen dosyalarınızdan hangilerinin commit'e dahil olduğunu belirlemeniz gerekiyor. Bu adımda commit'e dahil etmek istediğiniz dosyaları **staging area** denilen ara bir alana alırız. 22 | 23 | > Dosyaların içeriğinin değiştirilmiş olması, silinmesi veya yeni dosya eklenmesi bu dosyaların otomatik olarak **staging area**'ya eklenmesini sağlamaz. Bu işlemi ilgili dosyaları seçerek sizin yapmanız gerekir. 24 | 25 | 5. Dosyalarınızı **staging area**'ya ekledikten sonra şimdi _commit_ işlemine hazırsınız. Commit işlemi ile dosyalarınızdaki değişiklikler yeni bir versiyon olarak Git'de kayıt altına alınır. 26 | 6. Zaman zaman, özellikle de bir takım çalışması söz konusu ise, projenizdeki değişikliklere göz atmak isteyebilirsiniz. Projeniz için oluşturduğunuz commit'lerin tarihçesini incelemek için _git log_ komutunu kullanabilirsiniz. 27 | 7. Yaptığınız değişikliklerin takımın geri kalanı tarafından da görülmesini ve kullanılmaya başlanmasını sağlamak için değişikliklerinizi zaman zaman uzaktaki repository’de yayınlamanız gerekir. Bunun için _git push_ komutunu kullanırız. 28 | 29 | > **Local \(Yerel\) & Remote \(Uzak\) Repository'ler** 30 | > 31 | > * Local repository, kendi bilgisayarınızda proje klasörünüzün altında bulunan **.git** klasörüdür. Bu repository üzerinde sadece siz çalışabilirsiniz ve değişiklikler yerel diskinize kaydedilir. 32 | > * Remote repository'ler ise genellikle uzaktaki bir sunucuda yer alırlar ve bu sunucudaki **.git** klasöründen ibarettirler. Takım çalışması söz konusu ise takımdaki kişiler değişikliklerini bu uzaktaki repository üzerinden paylaşırlar. 33 | -------------------------------------------------------------------------------- /content/ileri_seviye_komutlar_ve_islemler/cakismalari_gidermek.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Çakışmaları Gidermek 6 | 7 | Versiyon kontrolü ile ilgili insanların en sevmedikleri ve korktukları şey değişiklikleri entegre etme \(merge\) işlemi sırasında oluşan çakışmalar ve bu çakışmaların çözülmesi sürecidir. Bu bölümde çakışmalardan korkmamamız gerektiğini ve çakışmaları en kolay ve efektif bir şekilde nasıl çözebileceğimizi ele alacağız. 8 | 9 | ## Git ile güvendesiniz 10 | 11 | Git ile çalışıyorsanız istediğiniz zaman yanlış yaptığınız değişiklik entegre etme işlemini geri alarak bu işleme temiz dosyalar ile yeniden başlayabilirsiniz. Bu konuda Git'e güvenmeniz yeterli olacaktır. Merge işlemi sırasında işin çoğunu Git sizin yerinize otomatik olarak yapacak ve size sadece basit çakışmaları çözmek kalacaktır. Git'in diğer bir güzel tarafı ise çakışmaların sadece kendi local branch'inizde olması ve hiçbir zaman sunucu tarafında olamamasıdır. Böylece merge işlemi sırasında meydana gelen çakışmada takım arkadaşlarınız etkilenmeyecektir. 12 | 13 | ## Çakışma Nasıl Oluşur? 14 | 15 | Git'de **merge** işlemi başka bir branch'deki değişiklikleri üzerinde çalıştığınız kendi branch'inize entegre etme işlemidir. Git merge işlemi sırasında değişikliklerin çoğunu sizin için otomatik olarak entegre eder. 16 | 17 | Ancak bazı durumlarda Git merge işlemini otomatik olarak gerçekleştiremez ve sizin müdahale ederek hangi değişikliğin nasıl entegre edileceğine karar vermeniz gerekir. Bu durum genellikle aynı dosya üzerinde değişiklikler yapıldığında ortaya çıkar, bu durumda bile Git dosyadaki değişiklikleri nasıl entegre edileceğine çoğu zaman otomatik karar verebilir. Fakat aynı satırda yapılan değişiklikler veya takımdaki bir kişinin bir satırı silmesi durumunda sizin bu değişikliği kendi branch'inize nasıl entegre edileceğine karar vermeniz gerekir. Bu durumda Git dosyanızı conflicted \(çakışmalı\) olarak işaretler ve sizin çalışmanıza devam edebilmeniz için bu çakışmayı çözmeniz gerekir. 18 | 19 | ## Çakışmaları Nasıl Çözeriz 20 | 21 | Çakışma oluştuğunda ilk yapmanız gereken şey çakışmanın neden olduğunu anlamak olmalıdır. Örneğin takım arkadaşınız aynı dosyada sizin de değiştirdiğiniz bir satırı mı değiştirdi veya aynı dosyada bir satır mı sildi veya sizinle aynı isimli yeni bir dosya mı oluşturdu? 22 | 23 | **git status** komutunu çalıştırdığınızda Git size branch'inizde entegre edilmemiş dosyalar olduğunu söyleyecektir. 24 | 25 | ![unmerged paths](/.gitbook/assets/04_conflict.jpg) 26 | 27 | Yukarıdaki ekran görüntüsünde **dosya1.md** isimli dosyamızda çakışma olduğunu görebiliriz. Bu çakışmayı düzeltmek için dosyamızı açıp çakışan satırları düzeltmemiz gerekiyor. 28 | 29 | ![dosya1.md](/.gitbook/assets/05_dosya1.jpg) 30 | 31 | dosya1.md dosyasını açtığımızda yukarıdakine benzer bir görüntü ile karşılaşıyoruz. 32 | 33 | * **<<<<<<<<< HEAD** ile başlayan ve **============** kadar devam eden kısım dosyanın bizim branch'imizde olan versiyonuna ait 34 | * **================** belirtecinden sonraki kısım da değişiklikleri entegre etmek istediğiniz branch'de yer alan dosyanın içeriğini gösterir. 35 | 36 | > **$ git mergetool dosya1.md** komutunu çalıştırarak önceki bölümlerde konfigürasyon ayarlarını yaptığımız DiffMerge uygulamasını da açabilirsiniz. ![diff merge](/.gitbook/assets/06_diff_merge.jpg) 37 | 38 | Dosyamızın içeriğinin ne olacağına karar verip kaydettikten sonra normal bir commit işlemi ile çakışmayı çözme işlemini tamamlıyoruz. 39 | 40 | > * **$ git add dosya1.md** ile dosyamızı Staging Area'ya ekliyoruz 41 | > * **$ git commit -m "değişiklikler entegre edildi"** komutu ile de commit işlemini tamamlarız. 42 | 43 | ## Merge İşlemini Nasıl Geri Alabiliriz? 44 | 45 | Dosyanızın merge işlemine başlamadan önceki haline istediğiniz zaman geri dönebilirsiniz. Bunun için yapmanız gereken tek şey **git merge --abort** komutunu çalıştırmak. 46 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_08.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 8. Gün: Dal Oluşturmak 6 | 7 | Projelerimizde önemli ve göreceli olarak uzun sürebilecek değişikliklere başlamadan önce yerel deponuzda bir dal \(branch\) oluşturup değişiklikleri bu dal üzerinde yapmanızı öneriyorum. Bu öneri aslında Konu Dalları Akışı adı verilen ve kitabımızın 3. Bölümünde ele aldığımız Git iş akışlarından bir tanesini tanımlar. 8 | 9 | Oluşturduğunuz yerel dal üzerinden çalışmalarımızı yapmaya devam ederken herhangi bir anda, örneğin acil bir hata durumunu gidermek için master \(master olmak zorunda değil başka herhangi bir dal de olabilir\) dalı aktif hale getirip oradaki düzenlememizi yaparak tekrar önceki dal’a geri dönebiliriz. Bu geçişler sırasında dallarda yaptığınız değişiklikler korunur. 10 | 11 | Git'de dal oluşturmak için iki yöntemden birini kullanabilirsiniz 12 | 13 | **Yöntem-1,** branch komutu 14 | 15 | ```bash 16 | git branch 17 | ``` 18 | 19 | Branch komutu ile dalınızı oluşturduktan sonra yeni dalda çalışmaya başlayabilmek için `git checkout ` komutu ile dalınızı aktif hale getirmeniz lazım. 20 | 21 | **Yöntem-2,** checkout komutu 22 | 23 | ```bash 24 | git checkout -b 25 | ``` 26 | 27 | Bu komut ile yeni bir dal oluşturulur ve otomatik olarak yeni dal için checkout işlemi yapılır. 28 | 29 | > **DİKKAT:** Yeni dal oluşturma komutlarını yazdığınız sırada hangi dalın aktif olduğu önemlidir. Her iki komut da yeni dalı o sırada aktif olan dalı referans alarak aktif dalın bir kopyasını oluşturur. 30 | 31 | ## Dal İşlemleri 32 | 33 | ```bash 34 | # Tüm dalları listele 35 | git branch 36 | 37 | # Bir dalı silme 38 | git branch -d 39 | 40 | # Dalın adını değiştir 41 | git branch -m 42 | ``` 43 | 44 | > **İPUCU:** git status komutunu çalıştırdığınızda aktif olan dalın adını da görebilirsiniz 45 | 46 | ## Alıştırma-1 47 | 48 | ```bash 49 | # yöntem 1 50 | git branch 51 | git branch -d 52 | 53 | $ # yöntem 2 54 | $ git checkout -b 55 | $ git branch -d 56 | ``` 57 | 58 | **Soru-1:** Yukarıdaki alıştırmada kullandığımız git branch komutlarının çıktıları arasında nasıl bir fark var? 59 | 60 | **Soru-2:** 2. yöntem ile oluşturduğunuz dalı nasıl silersiniz? 61 | 62 | ## Alıştırma-2 63 | 64 | ```bash 65 | # Proje klasörünüze konumlanın 66 | cd 67 | 68 | # Yeni bir dal oluşturun 69 | git checkout -b 70 | # Proje klasörünüze yeni bir dosya ekleyin 71 | # Eklediğiniz dosyayı commit edin 72 | 73 | # master dalını aktif hale getirin 74 | git checkout master 75 | 76 | # Dalı silin 77 | git branch -d 78 | ``` 79 | 80 | ## Alıştırma-3 81 | 82 | ```bash 83 | # Proje klasörünüze konumlanın 84 | cd 85 | 86 | # Yeni bir dal oluşturun 87 | git checkout -b 88 | # Proje klasörünüze yeni bir dosya ekleyin 89 | 90 | # master dalını aktif hale getirin 91 | git checkout master 92 | 93 | # Dalı silin 94 | git branch -d 95 | 96 | # Deponuzun durumunu inceleyin 97 | git status 98 | ``` 99 | 100 | **Soru-1:** En son çalıştırdığınız git status komutu eklediğiniz dosyayı neden listeliyor? 101 | 102 | ## Alıştırma-4 103 | 104 | ```bash 105 | # Proje klasörünüze konumlanın 106 | cd 107 | 108 | # Yeni bir dosya oluşturun 109 | touch .txt 110 | 111 | # Yeni bir dosya oluşturun 112 | git add -A . 113 | git commit -m “8.gün 4. alıştırma” 114 | 115 | # Yeni dosyanızın içeriğini metin editörü ile değiştirin ve sonra aşağıdaki komutu çalıştırın 116 | 117 | git stash 118 | 119 | # Yeni dosyanızın metin editörü ile açıp içeriğini kontrol edin 120 | ``` 121 | 122 | **Soru-1:** stash komutunu çalıştırmadan önceki dosya içeriğinizi nasıl geri getirebilirsiniz? 123 | -------------------------------------------------------------------------------- /content/branching_dallanma_ve_merging_birlestirme/degisiklikleri_merge_etmek.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Değişiklikleri Merge Etmek 6 | 7 | Projemizde yaptığımız farklı konular ve bağlamlardaki değişiklikleri takip etmek bir önceki bölümde anlattığımız basit iş akışı ile günlük çalışmamızda bize ciddi kolaylıklar ve esneklikler sunmaktadır. Ancak branch'lerimiz üzerinde değişikliklerimizi tamamlayıp Staging ve Commit işlemlerimizi yaptıktan sonra tüm bu değişiklikleri projemizin stabil versiyonu olan **master** branch ile merge etmemiz gerekiyor _\(branch -> \[merge\] -> master\)_. Merging en basit anlamda herhangi bir brach'de yaptığımız değişiklikleri **master** branch'imiz ile birleştirme veya **master** branch'e entegre etme işlemidir. 8 | 9 | > Bir branch'deki değişikliklerinizi sadece **master** branch’iniz ile merge etmek zorunda değilsiniz. Kullandığınız Git çalışma pratiğine bağlı olarak herhangi bir branch'i başka bir branch'e merge edebilirsiniz. 10 | 11 | Değişikliklerinizi **master** branch’inize merge etmek durumlardan sadece bir tanesidir, günlük çalışmanız sırasında karşılaşacağınız diğer bir durum ise üzerinde çalıştığınız branch'e **master** branch'deki değişikliklerin merge edilmesidir _\(master -> \[merge\] -> branch\)_. Bu durumu doğurabilecek aşağıdakilere benzer durumlar ile karşılaşabilirsiniz 12 | 13 | * Büyük bir ekipte çalışıyorsunuz ve ekip arkadaşlarınız yaptıkları değişiklikleri sık sık **master** branch'e merge ediyorlar. Bu durumda siz de uzun zamandır üzerinde çalıştığınız branch'in master'dan geri kalmaması için merge işlemi yapmak isteyebilirsiniz. 14 | * Tek başınıza çalışıyorsunuz ancak farklı zamanlarda farklı sebepler ile master branch'e merge ettğiniz bir çok düzeltme yaptınız. Diğer yandan da daha uzun soluklu bir çalışmanızı ayrı bir branch üzerinde yapıyorsunuz. Üzerinde çalıştığınız branch'in master'daki değişikliklerden geri kalmaması için merge işlemi yapmak isteyebilirsiniz. 15 | 16 | > **Commit'leri değil branch'leri entegre etmek!** Git'de değişikliklerinizi merge etme işlemi sırasında kaynak branch'inizde tekil olarak hangi değişiklikleri \(commit'ler\) merge etmek istediğinizi teker teker söylemezsiniz. Bunun yerine Git'de doğrudan kaynak branch'inizin tamamını hedef branch'e merge edersiniz, çünkü git hangi değişikliklerin hedef branch'de bulunmadığını otomatik olarak tespit edip sadece bunların entegre edilmesini sağlar. Kaynak branch'deki değişiklikler her zaman HEAD'e yani aktif branch'iniz hangisi ise ona entegre edilir. 17 | 18 | Git'de merge işlemi çok basit iki adımda yapılır. 1. **git checkout** komutu ile değişikliklerin aktarılacağı hedef branch'inizi aktif \(HEAD\) hale getirirsiniz. 2. **git merge** komutu ile kaynak branch'deki commit edilmiş değişiklikler HEAD'e entegre edilir. 19 | 20 | ![Git Merge](/.gitbook/assets/12_gitmerge.jpg) 21 | 22 | Merge işleminden sonra **git log** komutunu çalıştırdığınızda ise hangi değişikliklerimizin \(commit\) **master** branch'imize entegre edildiğini \(merge\) kolayca görebilirsiniz. 23 | 24 | ![Git Merge -&gt; Log](/.gitbook/assets/13_gitmerge_log.jpg) 25 | 26 | Ancak Git merge işlemini her zaman bu kadar sade bir şekilde yapamaz, yani Git her zaman kaynak branch'inizdeki commit'lerinizi HEAD'e sırasıyla entegre edemeyebilir. Bu durum genellikle hedef branch'de ve kaynak branch'de birbirinden bağımsız değişikliklerin yapılması durumunda gündeme gelecektir. Bu durumda Git "merge commit" adı verilen; hedef ve kaynak branch'deki en son commit ile gerçekleşen değişiklikleri birleştiren otomatik bir commit adımı ekledikten sonra merge işlemini gerçekleştirir. 27 | 28 | ![Merge Commit](/.gitbook/assets/14_merge_commit.jpg) [_Görsel : Tower-Learn Git sayfasından alıntıdır_](http://www.git-tower.com/learn/ebook/command-line/branching-merging/merging#start) 29 | 30 | > Bazı durumlarda Git birden fazla otomatik **merge commit** oluşturmak zorunda kalabilir. Bu durumda sizin hangi **merge conflict** noktasını seçip işlemin devam etmesini istediğinizi belirtmeniz gerekecektir \(Merge Conflict Resolution\) 31 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/neden_versiyon_kontrolune_ihtiyacimiz_var.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Versiyon Kontrolüne Neden İhtiyacımız Var? 6 | 7 | Versiyon kontrol sistemi kullanmanın bir çok faydası var ve bu bölümde versiyon kontrol sistemi kullanımının bize sağladığı avantajlardan bahsediyoruz. 8 | 9 | ## Uyumlu ekip çalışması 10 | 11 | Herhangi bir versiyon kontrol sistemi kullanmadığınızda beraber çalıştığınız diğer kişiler ile aynı dosyalar üzerinde çalışabilmek için muhtemelen herkesin erişimine açık paylaşımlı bir klasör kullanmak zorunda kalacaksınız. 12 | 13 | Bu tür bir senaryoda kullanılan yazılımların çoğu değiştirilen dosyaya **kilit** koyar ve başka birisi aynı dosyayı düzenlemek istediğinde 14 | 15 | * Kullandığı programa bağlı olarak dosya yazma korumalı olarak salt okunur modda \(readonly\) açılır veya 16 | * Değişiklikler kaydedilmek istendiğinde hata verir 17 | 18 | Bu tür bir çalışma hem çok zahmetli hem de hatalara açıktır. Örneğin bir dosyanın en son geçerli versiyonunun nerede olduğunun takip edilmesi gibi çözüm bulunması gereken sorunlar ile uğraşmak zorunda kalırsınız. 19 | 20 | > Üzerinde çalıştığınız dosyada sizden önce başkasının değişiklik yapıp yapmadığından haberiniz yoksa hatalı içerik üretme ihtimaliniz vardır. 21 | 22 | Versiyon kontrol sistemi kullanıldığında ise ekibinizdeki herkes özgür bir şekilde istediği dosyalar üzerinde güvenli bir şekilde istediği değişikliği yapabilir. Herkes değişikliklerini tamamladıktan sonra da tüm değişiklikler versiyon kontrol sistemi kullanılarak sağlıklı bir şekilde **merge** \(_birleştirme_\) edilebilir. 23 | 24 | ## Versiyonların düzgün bir şekilde takip edilebilmesi 25 | 26 | Üzerinde çalıştığınız bir dosyanın veya bir dizi proje dosyasının zaman içinde farklı versiyonları oluşur ve bu versiyonların kayıt altına alınması gerekir. Bu sorumluluk genelde çok zahmetli ve sıkıcı bir iş ve süreçtir. Aşağıdakine benzer sorular canınızı gereğinden fazla sıkabilir 27 | 28 | * Sadece değişen dosyalar mı yoksa bir projedeki tüm dosyaların versiyonları mı kaydedilmeli? 29 | 30 | > * Bir sürü dosya içinden sadece değişen dosyaların belirlenmesi zordur 31 | > * Her seferinde dosyaların hepsinin teker teker kaydedilmesi durumunda ise ihtiyaç duyulandan daha fazla disk alanı kullanılır 32 | 33 | * Dosyalara verilecek isimler tam bir baş ağrısına dönüşebilir. 34 | 35 | > * Personel\_Maas.xlsx 36 | > * Personel\_Maas1.xlsx 37 | > * Personel\_Maas\_Ozet.xlsx 38 | > * Personel\_Maas\_BrutHaricDetay.xlsx 39 | > 40 | > şeklinde dosya isimleri üretmek zorunda kalabilirsiniz. 41 | 42 | * Belki de canınızı en çok sıkacak şey projenizin iki versiyonu arasında tam olarak ne tür farkların olduğunu sağlıklı bir şekilde bilme şansınız olmaması olacaktır 43 | 44 | Versiyon kontrol sistemi kullandığınızda sizin çalıştığınız disk alanında proje dosyalarının sadece bir versiyonu bulunur, bu dosyaların daha önceki halleri versiyon kontrol sisteminin denetimindedir. Bu sayede istediğiniz zaman önceki versiyonlara geri dönebilir, versiyonlar arasındaki farklılıkları rahatlıkla inceleyebilir ve versiyonları kaydederken eklediğiniz ilave bilgileri ve yorumlarınızı rahatlıkla görebilirsiniz. 45 | 46 | ## Önceki Versiyonlara Geri Dönebilme 47 | 48 | Dosyalarınızın veya aslında tüm projenizin daha önceki versiyonuna geri dönebilme imkanın size ciddi anlamda özgürlük sağlar; dosyalarınızı ve projenizi istediğiniz gibi değiştirme özgürlüğü. Yaptığınız değişiklikler projenizi çöpe döndürdüyse, geliştirdiğiniz bir işlev tam istediğiniz gibi olmadıysa veya müşteriniz veya patronunuz geliştirdiğiniz bir işlevi artık istemediğine karar verirse projenizin önceki temiz haline çok hızlı ve rahat bir şekilde dönebilirsiniz. 49 | 50 | ## Dosyalarınızın neden değiştiğini anlama 51 | 52 | Versiyon kontrol sistemleri değişikliklerinizi tamamlayıp **commit** etmek istediğinizde **comment** adı verilen açıklamalar girmenizi isterler. Bu comment’ler sayesinde projenizin herhangi bir versiyonundaki değişikliklerin nedenlerini de kayıt altına alıp ihtiyaç halinde geri dönüp inceleyebilirsiniz. 53 | 54 | > Git'de commit işlemi yapılırken comment \(yorum metni\) girilmesi zorunludur 55 | 56 | ## Yedekleme 57 | 58 | Git gibi dağıtık versiyon kontrol \(DVCS\) sistemlerinin yan etki olarak sağladığı faydalardan birisi de yedeklemedir. Git sayesinde aynı projede çalışan herkesin kendi bilgisayarında projenin tam bir tarihçesi tutulur. Merkezi versiyon kontrol sistemi sunucusunda bir sorun oluştuğunda takımdaki herhangi birinin kendi diskindeki projeyi sunucuya geri yüklemesi yeterlidir. Diğerleri de kendi bilgisayarlarındaki proje dosyalarını geri yüklenen proje dosyaları ile senkronize edebilirler. 59 | -------------------------------------------------------------------------------- /content/remote_repositoryler/remote_repositorydeki_verilerin_incelenmesi.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Remote Repository'deki Verilerin İncelenmesi 6 | 7 | **git clone** komutu remote bir repository'yi yerel diskimize indirdikten sonra **git branch -va** komutunu çalıştırdığımızda aşağıdaki görüntüde yer alan bilgiler listelenecektir. 8 | 9 | ![git branch -va](/.gitbook/assets/02_git_branch_va.jpg) 10 | 11 | Dikkat edecek olursanız local repository'lerimiz hala yerinde duruyor ancak listemizde ilave olarak **origin/HEAD** ve **origin/master** isimli iki remote kaydı var. Peki daha önceki bölümde **git add git101\_ornek** komutu ile oluşturduğumuz remote repository kayıtlarımız neden listlenmiyor? Bunun nedeni önceki bölümde kullandığımız **git add** komutu ile local ve remote repository arasında sadece bir ilişki/bağlantı tanımladık, aslında bu komut sonrasında local ve remote arasında herhangi bir veri trasferi gerçekleşmez. 12 | 13 | > **Remote Repository bilgileri güncel olmayabilir!** Git remote repository'ler ile ilgili yerel diskinizde bir takım bilgileri içerir. Ancak Git arka planda otomatik olarak bu bilgileri sizin için belirli aralıklarda güncellemez! Bu işlemin gerçekleşmesi ve sizin diğer takım arkadaşlarınızın yaptığı değişikliklerden haberdar olabilmeniz için Git'e bu bilgileri güncellemesini söylemeniz gerekir. 14 | 15 | Git'in remote repository ile ilgili yerel diskinizde tuttuğu bilgileri güncellemesini sağlamak için **git fetch** komutunu kullanmanız gerekir. 16 | 17 | ![git fetch](/.gitbook/assets/03_git_fetch.jpg) 18 | 19 | Fetch komutu yerel diskinizdeki branchlerinizi ve Working Copy'deki dosyalarınızı güncellemez veya değiştirmez. Bu komut ile sadece takım arkadaşlarınızın remote repository'de yayınladıkları değişikliklere ilişkin bilgiler yerel diskinize indirilir. Daha sonra bu değişikliklerden hangilerini hangi local branch'e entegre edeceğinize kendiniz karar verebilirsiniz. 20 | 21 | Bu işlemden sonra tekrar **git branch -va** komutunu çalıştırdığımızda **gitornek\_101/master** isimli remote repositorymizdeki branchlere ilişkin bilgileri de görebiliriz. 22 | 23 | ![git banch -va](/.gitbook/assets/04_git_fetch.jpg) 24 | 25 | Bilgilerini güncellediğimiz git101\_ornek/master isimli branch'de değişiklikler yapmak için öncelikle bu branch'i baz alarak yeni bir local branch oluşturup dosyaların Working Copy alanımıza kopyalanmasını sağlamamız gerekiyor. Bunun için **git checkout** komutunu **--track** parametresi ile kullnıyoruz. 26 | 27 | ![git checkout --track](/.gitbook/assets/05_git_checkout_track.jpg) 28 | 29 | **git checkout --track** komutu ile aşağıdaki işlemler gerçekleşir 30 | 31 | 1. Remote branch ile aynı isimde local bir branch oluşturulur 32 | 2. Yeni oluşturulan branch aktif hale getirilir 33 | 3. --tracking parametresini kullandığımız için yeni oluşan local branch ile remote branch arasında "tracking relationship" adı verilen ve local branch'in hangi remote branch'deki değişiklikleri takip ettiğini gösteren ilişki kurulur 34 | 35 | > **Tracking Relationship \(Takip İlişkisi\)**: Git'de daha önceki bölümlerde de bahsettiğimiz gibi branchler aslında birbirinden tamamen bağımsızdır ve aralarında doğrudan bir ilişki yoktur. Ancak _track_ parametresi ile local bir branch'in hangi remote branch'deki değişiklikleri takip edeceğini tanımlayabiliriz. Bu durumda Git iki branch'den herhangi birinde yer alan ancak diğerinde yer almayan commit'leri tespit ederek bizi bilgilendirecektir. Yani 36 | > 37 | > * Local branch'inizde remote branch'e yayınlamadığınız \(push\) commit'ler varsa bu durumda local branch'inizin remote branch'den önde \(ahead\) olduğu 38 | > * Takım arkadaşlarınız remote branch'e bazı commitleri push ettiğinde ve siz de local branch'inizi güncellemediğiniz durumda local branch'inizi remote branch'in gerisinde \(behind\) olduğu 39 | > 40 | > bilgisi Git tarafından "Tracking Relationship" tanımı sayesinde **git status** komutunun çıktısı olarak gösterilir 41 | 42 | Local branch'imizi hazırladığımıza göre gelin şimdi birkaç değişiklik yapalım. Bu değişiklikleri yaptıktan sonra her zamanki gibi önce değişikliklerimizi Staging Area'ya alıyoruz ve sonrasında da commit işlemini gerçekleştirerek local repository'de versiyon kontrolüne ilişkin işlemlerimizi bitiriyoruz. Son adım olarak da **git push** komutu ile localdeki bu değişikliklerimizi remote branch'de yayınlıyoruz. 43 | 44 | ![git push](/.gitbook/assets/06_git_push.jpg) 45 | 46 | > **git push** push komutu aslında **git push** formatındadır. Ancak local branch'imizi oluştururken kullandığımız _track_ parametresi sayesinde kurulan "Takip İlişkisi" sayesinde push komutunun uzun hali yerine sade hali olan **git push** formatında kullanabiliyoruz. 47 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/yeni_bir_proje_olusturmak.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Local bir proje oluşturmak 6 | 7 | Henüz version kontrolü altında olmayan bir projenizi versiyon kontrolü altına almak için **git init** komutunu kullanırız. Bu işlemi gerçekleştirmek için Mac OS X'de Terminal uygulamasını Windows'da ise Git Bash'i açarak aşağıdaki komutları çalıştırmanız gerekir 8 | 9 | ```text 10 | $ cd proje/klasörünüzün/yolu/ 11 | $ git init 12 | ``` 13 | 14 | Bu işlemden sonra 15 | 16 | ```text 17 | ls -la 18 | ``` 19 | 20 | komutu ile proje klasörünüz altındaki dosyaları listelediğinizde klasörün içinde _.git_ isimli gizli bir klasörün olduğunu göreceksiniz. _git init_ komutu ile projemiz için **boş** bir repository oluşturduk. Ancak proje klasörümüzde dosyalar ve başka klasörler bulunmasına rağmen bu dosya ve klasörlerin hiç biri henüz Git tarafından versiyon kontrolü altına alınmadı. 21 | 22 | > **Working copy**: Projenizin ana klasörüne _Working Copy_ veya _Working Directory_ ismi verilir. Bu klasörde projenizde yer alan dosyaların ve klasörlerin bir kopyası bulunur. Versiyon kontrol sistemine projenizin herhangi bir versiyonunu Working Copy'nize kopyalamasını söyleyebilirsiniz, ancak bir anda Working Copy'nizde projenizin sadece bir versiyonu yer alır. 23 | 24 | ## Versiyon kontrolü altına almak istemediğimiz dosyalar 25 | 26 | Tüm geliştirme ortamları ve işletim sistemlerinde kullandığımız araçlar tarafından ara bir ürün olarak üretilen ve aslında doğrudan versiyon kontrolü altına almak istemediğimiz dosya veya klasörler olacaktır. Örneğin Mac OS X'in otomatik olarak ürettiği gizli _DS\_Store_ isimli klasör veya C++ derleyicileri tarafından üretilen _.o_ uzantılı _obj_ dosyaları gibi. Hangi dosyaların versiyon kontrolü altında tutulacağına ve hangilerinin göz ardı edileceğine Git otomatik olarak karar vermez, bu kararı sizin vermeniz gerekir. 27 | 28 | > Kullandığınız geliştirme araçlarına bağlı olarak hangi dosyaların göz ardı edilebileceği ile ilgili GitHub'ın yayınladığı [derlemeye](https://github.com/github/gitignore) göz atabilirsiniz. 29 | 30 | Versiyon kontrolü altına almak istemediğiniz dosya ve klasörleri tanımlamak için proje klasörüne eklenen _.gitignore_ dosyası kullanılır. Bu dosyaya göz ardı etmek istediğiniz dosya ve klasörlerin tespit edilebilmesi için doğrudan isimler veya basit kurallar ekleriz. Projelerinizi versiyon kontrolü altına aldıktan sonra ilk iş olarak GitHub'ın yayınladığı derlemeyi veya kendi deneyiminiz ve bilginiz ile karar vereceğiniz dosya ve klasörleri **.gitignore** dosyasına ekleyiniz. Projenizin ilerleyen aşamalarında bu işlemi yapmanız biraz daha zahmetli olacaktır. 31 | 32 | Şimdi gelin _.gitignore_ dosyasında kuralları nasıl tanımlayabileceğimize bir göz atalım 33 | 34 | ```text 35 | *.[oa] 36 | .~ 37 | ``` 38 | 39 | İlk satırda **o** veya **a** uzantısı ile biten dosyaların versiyon kontrolü dışında tutulması için bir kural tanımlıyoruz. İkinci satırda ise **~** karakteri ile biten \(çoğu metin düzenleme uygulaması geçici dosyaları ~ ile biten dosyalar olarak otomatik oluşturur\) dosyaların versiyon kontrolü haricinde tutması için kural tanımlıyoruz. 40 | 41 | .gitignore dosyasında tanımlama yaparken aşağıdaki kurallar geçerlidir 42 | 43 | * Boş satırlar veya \# ile başlayan satırlarda yaptığınız tanımlamalar Git tarafından dikkate alınmaz. 44 | * \*, ?, \[ \], { }, \[!\] ve gibi karakterler kullanılarak oluşturulan ve [_globbing patterns_](http://www.tldp.org/LDP/GNU-Linux-Tools-Summary/html/x11655.htm) adı verilen tanımlayıcılar kullanabilirsiniz 45 | * Klasörleri belirtmek için **/** karakteri kullanılır. Örneğin **/projemde/versiyon/kontrolü/istemedigim/bir/klasor/** şeklinde bir tanım yaptığımızda ilgili klasör ve altındaki tüm dosyalar Git tarafından göz ardı edilir. 46 | * Tanımladığınız bir kuralın tersini **!** simgesi ile tanımlarız. Örneğin _!/projemin/kaynak/kodu/_ şeklinde bir tanım yaptığımızda bu klasör dışındaki tüm klasör ve dosyalar Git tarafından göz ardı edilecektir. 47 | 48 | ## İlk commit’imiz 49 | 50 | Projemizi versiyon kontrolüne alıp göz ardı edilmesini istediğimiz klasör ve dosyaları da belirledikten sonra aşağıdaki komutlar ile ilk commit işlemimizi yapabiliriz 51 | 52 | ```text 53 | $ git add -A 54 | $ git commit -m "İlk commit işlemimizi yaptık" 55 | ``` 56 | 57 | Bu komutların ne işe yaradığına sonraki bölümlerde değineceğiz, şimdilik 58 | 59 | * İlk komutun tüm proje dosyalarının Staging Area'ya eklenmesi için, 60 | * İkinci komutun ise dosyalarımızın bir açıklama ile commit edilmesi için 61 | 62 | kullanıldığını söylemek ile yetinelim. 63 | 64 | > Yukarıdaki iki komutu arka arkaya kullanmak yerine aynı işlemi _git commit -a_ komutu ile de yapabiliriz. 65 | -------------------------------------------------------------------------------- /content/ileri_seviye_komutlar_ve_islemler/diff_ile_farklari_incelemek.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Diff İle Farkları İncelemek 6 | 7 | Daha önceki bölümlerde bolca kullandığımız **git status** ve **git log** komutları yaptığınız değişiklikler ile ilgili önemli bilgiler sunar. Ancak bu iki komut ile sadece değişikliklerimizin genel bilgilerini görebiliriz, dosyalarımızda yaptığımız değişikliklerin ayrıntılarını bu komutlar ile göremeyiz. Git'de bu iki komut dışında değişiklikleri ve farkları incelemek için farklı komutlar da yer alır. 8 | 9 | ## İki versiyon arasındaki farkları yorumlamak 10 | 11 | Versiyon kontrol sistemlerinde iki versiyon arasındaki değişikliklere İngilizce difference \(fark\) kelimesinin kısaltması olan **diff** denir. Git'de iki versiyon arasındaki farkları görmek için **git diff** komutunu kullanabilirsiniz. Örneğin **git diff 374c6f..5d903e dosya1.md** komutu ile dosya1.md dosyasının 374c6f ve 5d903e hash'li commitlerdeki iki versiyonunun diff'ini alıyoruz. 12 | 13 | ![git diff](/.gitbook/assets/03_git_diff.jpg) 14 | 15 | git diff komutunu çalıştırdığımızda yukarıdaki gibi bir ekran ile karşılaşacaksınız. Gelin şimdi bu ekranda numaralandırdığımız önemli alanlarda hangi bilgilerin bize gösterildiğini ele alalım 16 | 17 | 1. **Karşılaştırılan Dosyalar \(A/B\):** Diff komutu iki dosyayı birbiri ile karşılaştırır, A dosyası ve B dosyası. Bu A ve B dosyaları genelde aynı dosyanın \(bizim örneğimizde dosya1.md\) farklı versiyonlarıdır. Çok sık olmasa da diff işlemi ile tamamen farklı olan dosyaları \(örneğin dosya1.md ve dosya1\_enyeni.md\) da karşılaştırabilirsiniz. Hangi dosyaların karşılaştırıldığını açıkça belirtmek için diff komutunun çıktısı her zaman hangi dosyanın A hangi dosyanın da B olduğunu belirterek başlar. 18 | 19 | > Bu bilginin hemen altında **index** ile başlayan satırda pratik olarak pek işinize yaramayacak dosya bilgileri yer alır. Bu bilgilerden ilk ikisi karçılaştırılan versiyonların hash değeri sonuncusu da \(1000644\) dosya modu bilgisidir. 20 | 21 | 2. **A/B Dosya Simgeleri:** Dosya içeriğinin hangi kısmının A hangi kısmının da B dosyasına ait olduğunu belirtmek için kullanılan - ve + sembollerinden hangisinin hangi dosyaya ait olduğu bilgisi. 22 | 3. **Fark İşaretçileri:** Diff komutu ile sadece iki dosya \(aslında versiyon da denilebilir\) arasındaki farkların olduğu satırlar gösterilir, dosyanın tamamı \(değişmeyen satırlar da dahil\) gösterilmez. @@ simgeleri ile başlayan satırda A ve B dosyaları arasındaki farklı satırların hangi satırdan başlayıp kaç satır olduğu bilgisi gösterilir. Bizim ekran görüntümüzde yer alan **@@ -1,4 +1,2 @@** bilgisi bize şunu söyler 23 | 24 | > \(-\) simgesi ile tanımlanan A dosyasından 1. satırdan başlayarak 4 satır, + simgesi ile tanımlanan B dosyasından 1. satırdan başlayarak 2 satır birbirinden farklı 25 | 26 | 4. **Değişiklikleri Okumak :** Değişen her satırın başında \(-\) veya \(+\) simgesi yer alır. Bu simgeler ile A ve B versiyonlarının içeriğinin ne olduğunu anlamamızda bize yardımcı olacaktır. Örnek ekran görüntüsünde \(-\) ile başlayan ve A versiyondaki satırların daha sonra \(+\) ile başlayan B versiyonundaki satırlar ile değiştirildiğini görüyoruz. 27 | 28 | ## Local Branch'deki farkları incelemek 29 | 30 | Daha önceki bölümlerde **git status** komutu ile Local branch'imizde hangi dosyaların değiştiğini görebileceğimizi öğrenmiştik. **git status** komutu ile dosyaların içeriğindeki değişiklikleri göremeyiz. İçerik değişikliklerini de görmek için doğrudan **git diff** komutunu herhangi bir parametre veya seçenek belirtmeden kullanabilirsiniz. 31 | 32 | ![git diff](/.gitbook/assets/04_local_diff.jpg) 33 | 34 | Sadece Staging Area'ya commit edilmek üzere eklenmiş/çıkarılmış dosyalardaki değişiklikleri görmek isterseniz **git diff --staged** komutunu kullanabilirsiniz. 35 | 36 | ## Commit edilmiş dosyalardaki farkları görmek 37 | 38 | **git log** komutunu commit işlemleri ile ilgili özet bilgileri görmek için kullanabiliriz. Bu komutu herhangi bir parametre veya seçenek belirtmeden kullanırsanız dosya içeriğindeki farkları göremezsiniz. Dosyaların içeriğindeki farkları da görmek için _git log_ komutunu **-p** seçeneği ile kullanabilirsiniz. 39 | 40 | > **$ git log -p** şeklinde 41 | 42 | ## İki Farklı Branch'i Karşılaştırmak 43 | 44 | İki farklı branch'in arasındaki içerik farklarını görmek için _git diff_ komutuna karşılaştırmak istediğiniz branch isimlerini parametre olarak verebilirsiniz. Örneğin **master** ile **superyeniozellik** branch'ini karşılaştırmak için _git diff_ komutu aşağıdaki gibi olacaktır 45 | 46 | > **$ git diff master..superyeniozellik** 47 | 48 | Branch'leri karşılaştırabildiğiniz gibi iki farklı versiyon arasındaki tüm dosyaların içeriğini de versiyonların **hash** değerlerini _git diff_ komutuna parametre olarak vererek karşılaştırabiliriz. Örneğin 49 | 50 | > **$ git diff 74c6f..5d903e** 51 | 52 | komutu ile 74c6f hash değeri olan commit \(versiyon\) ile 5d903e hash değerine sahip commit'in dosyaları arasındaki farkları görebilirsiniz. 53 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_11.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 11.Gün: Birlikte Çalışma \(Collaboration\) 6 | 7 | Bu bölüme kadar ele aldığımız Git komutları ile kendi lokalimizde Git ile temel versiyon kontrol işlemlerini nasıl yapacağımız ile ilgili alıştırmalar yaptık. Bu bölümde ise takım çalışması için, tüm diğer versiyon kontrol sistemlerinde olduğu gibi, Git'in de bize sunduğu imkanlar ile ilgili alıştırmalar yapacağız . 8 | 9 | Takım çalışması ve birlikte çalışma modeli açısından Git'i öncülü olan CVS ve Subversion gibi versiyon kontrol sistemlerinden ayıran en önemli iki özelliği şunlardır 10 | 11 | * Git her takım üyesine merkezi uzak deponun tam bir yerel kopyasını sağlar. Takım üyeleri bu yerel kopya üzerinde kendi commit'lerini ve dallarını merkezi depo’ya ihtiyaç duymadan istedikleri gibi oluşturup yönetebilirler 12 | * Git ile takım üyeleri değişiklik kümeleri yerine \(change set\) tekil değişiklikleri ifade eden commit'leri birbirleri ile merkezi depo üzerinden paylaşırlar. 13 | 14 | Bu bölümde ele aldığımız komutlar ile diğer repository'ler ile olan bağlantıların nasıl sağlandığını \(remote\), kendi lokalimizdeki değişiklikleri diğerleri ile nasıl paylaşacağımızı \(push\) ve diğerlerinin değişikliklerini kendi lokalimize nasıl entegre edeceğimizi \(pull\) öğreneceğiz. 15 | 16 | ## git remote 17 | 18 | Remote komutu ile yerel deponuz ile uzaktaki bir depo arasında bağlantıları tanımlayabilir, silebilir veya isimlerini değiştirebilirsiniz. Remote komutu ile tanımlanan bağlantı gerçek zamanlı ve canlı bir bağlantı değildir ve bu bağlantılar kullanılarak uzaktaki depo üzerinden doğrudan işlem yapamazsınız. Bu bağlantıları uzun URL'ler yerine diğer Git komutlarında parametre olarak kullanılabilecek kısa yollar olarak düşünmelisiniz. 19 | 20 | ```bash 21 | # Proje klasörünüze konumlanın 22 | cd 23 | 24 | # Uzak depo kısa yol isimlerini listele 25 | git remote 26 | 27 | # Uzak depo ilişkilerini daha ayrıntılı listele 28 | git remote -v 29 | 30 | # Uzak depo ilişkisi tanımla 31 | git remote add 32 | 33 | # Uzak depo ilişkisini sil 34 | git remote rm 35 | 36 | # Uzak depo kısa yolunun adını değiştir 37 | git remote rename 38 | ``` 39 | 40 | **Soru-1:** remote komutunu çalıştırdığınızda çıktı olarak gördüğünüz origin ne anlama geliyor? 41 | 42 | **Soru-2:** git remote add komutu ile kullanabileceğimiz URL tipleri nelerdir? 43 | 44 | ## git fetch 45 | 46 | Fetch komutu uzak depolardaki değişiklikler ile ilgili bilgeleri yerel deponuzun Git veri tabanı ile senkronize etmenizi sağlar. 47 | 48 | ```bash 49 | # varsayılan uzak depodaki (origin) tüm dalların bilgilerini almak için 50 | git fetch 51 | 52 | # Uzak depo kısa yolu ile tanımlı uzak depodaki tüm dalların bilgilerini almak için 53 | git fetch 54 | 55 | # Uzak depo kısa yolu ile tanımlı uzak depodaki belirli bir dalın bilgilerini almak için 56 | git fetch 57 | ``` 58 | 59 | Fetch sonrasında uzak depo dallarını git checkout ile aktif hale getirip inceleyebilir ve git log ile de uzak depo dalının commit tarihçesine göz atabilirsiniz. Eğer uzak depo dalındaki değişiklikleri kendi yerel deponuzdaki bir dala birleştirmek etmek isterseniz git merge komutunu kullanabilirsiniz. 60 | 61 | ### Alıştırma 62 | 63 | Projeniz için Git servisi üzerinde oluşturduğunuz uzak depodaki değişiklikleri fetch ile alıp yerel dalınız ile birleştirin. Bu alıştırmayı yapmak için uzak deponuzu bu aşamaya kadar kullandığınız klasörden farklı bir konuma klonlayın ve bu klon üzerinden değişikli yaparak uzak deponuza push edin. 64 | 65 | **Soru-1:** downstream ve upstream terimlerinin ne anlama geldiğini araştırın. 66 | 67 | ## git pull 68 | 69 | Uzak depodaki değişikliklerin yerel deponuza kopyalanması ve otomatik olarak entegre edilmesi için kullanılır. Bu işlemi git fetch ve sonrasında git merge ile iki komut kullanarak da yapabilirsiniz, ancak git pull bu işlemi tek komutla yapmamızı sağlar. 70 | 71 | ```bash 72 | # varsayılan uzak depodaki (origin) değişiklikleri almak için 73 | git pull 74 | 75 | # Uzak depo kısa yolu ile ilişkilendirilmiş konumdan değişiklikleri almak için 76 | git pull 77 | 78 | # Merge yerine rebase kullanarak değişiklikleri almak için 79 | git pull –rebase 80 | ``` 81 | 82 | ## git push 83 | 84 | Yerel deponuzdaki commit'leri \(değişiklikleri\) uzaktaki depoya gönderip takımın geri kalanı ile paylaşmak için git push komutu kullanılır. 85 | 86 | ```bash 87 | # Yerel daldaki değişiklikleri uzak depoya gönder 88 | git push 89 | 90 | # Bir daldaki değişiklikleri uzak depo kısa yolu ile ilişkilendirilmiş uzak depoya gönder 91 | git push 92 | 93 | # Tüm yerel dallardaki değişiklikleri uzak depo kısa yolu ile ilişkilendirilmiş uzak depoya gönder 94 | git push -- all 95 | 96 | # Yerel depodaki tag’leri uzak depoya gönder 97 | git push -- tags 98 | ``` 99 | 100 | **Soru-1:** push işlemi sırasında bir çakışma oluşabilir mi? 101 | -------------------------------------------------------------------------------- /content/branching_dallanma_ve_merging_birlestirme/branching_nedir-_ne_ise_yarar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Branching Çalışma Şeklinizi Değiştirebilir 6 | 7 | Bazı araçların sağladığı imkanlar günlük iş yapma şeklimizi çok derinden etkileyip, yaptığımız işe daha farklı bakabilmemizi sağlar. Git'in **branching** yaklaşımı \(Türkçeye **dallanma** olarak da çevirebiliriz\) da bahsettiğim bu dönüştürücü etkiye sahip araçlardan birisidir. Branching konusundaki hakimiyetimizin artması ve sağlamlaşması ile birlikte daha farklı iş yapmaya başlayıp daha iyi birer yazılım geliştirici olabilirsiniz. 8 | 9 | Branching denilen yöntem aslında Git dışındaki diğer versiyon kontrol sistemlerinde de öteden beri kullanılmakta ve yazılım geliştiricilerin hayatını önemli derecede kolaylaştırmaktadır. Ancak, Git'deki branching yaklaşımı kullanım kolaylığı ve yüksek performansı nedeniyle kendine has olduğunu da söylemeliyiz. 10 | 11 | Öyleyse gelin şimdi yavaş yavaş branching'in \(dallanma\) ne olduğunu anlayalım. 12 | 13 | ## Birden Fazla Bağlamda Çalışmak 14 | 15 | Daha önceki bölümün son alt başlığında \(git commit\) zaman zaman bireysel olarak kısa zaman dilimlerinde aynı projenin farklı özellikleri ile ilgili değişiklikler yapılması gerekebileceğinden bahsetmiştik. Büyük projelerde ise bu durum kişisel bir tercih olmaktan çıkıp iş bölümü/uzmanlık gibi kriterlere bağlı olarak proje/ürün yönetiminin önemli bir parçası halinde ele alınır. Örneğin 5 kişilik bir ekibin her bir üyesi aynı yazılımın farklı özellikleri ile ilgili çalışabilir veya iki farklı kişi aynı özelliğin farklı şekillerde nasıl geliştirilebileceği ile ilgili deneysel çalışma yapıyor olabilirler. Bahsettiğim tüm bu alternatif senaryolar aslında kendi yaşam döngüleri olabilen, çoğu zaman kısa veya uzun süreli eş zamanlı ilerleyen farklı birer **bağlama** denk gelir. 16 | 17 | Pratikte üzerinde çalıştığınız projenin/yazılımın her zaman son stabil durumu yansıtan **ana** bir bağlamı ve X numaralı hata bildiriminin düzeltilmesi, yeni bir Y özelliği üzerinde yapılan çalışma veya deneysel bir özellik ile ilgili yapılan çalışma gibi birden fazla yan bağlamı olacaktır. 18 | 19 | ## Branching olmasa da olur mu? 20 | 21 | Net olarak birbirinden ayrılmış farklı bağlamlar oluşturmak için branching benzeri araçlar olmasaydı aşağıdakilere benzer senaryolarda nasıl davranacağımız konusunda sıkıntılar yaşayacaktık 22 | 23 | * Örneğin müşteriniz veya yöneticiniz iki alternatif sayfa tasarımından birincisini değil de ikincisini beğendi ve bu arada siz de sayfa tasarımı dışında birkaç tane bug fix ve birkaç tane de dokümantasyon değişikliğini farklı zamanlarda tamamladınız. Bu durumda müşterinizin beğendiği ikinci tasarımı diğer tüm düzenlemeleri kaybetmeden nasıl devreye alacaktınız? 24 | * Üzerinde çalıştığınız alışveriş sitesi için özel olarak geliştirdiğiniz Sepet modülü yerine 3. parti bir modül kullanılması kararı alındı ve sizin de kendi modülünüzü ana yazılımdan sökmeniz istendi. Bu durumda sökmeniz gereken modül kodunu tespit edip diğer modülleri etkilemeden nasıl sökecektiniz? 25 | * Yeni geliştirdiğiniz Beni Haberdar Et işlevi yazılımınızın geri kalan özelliklerinin bir çoğunun değiştirilmesine sebep olmuşken birden Beni Haberdar Et işlevinin saçma ve gereksiz olduğuna karar verilseydi bu işlevi aradan geçen zamanda yazılımın farklı yerlerinde yapılan diğer değişikliklerden izole ederek nasıl çöpe atacaktınız? 26 | 27 | Birden fazla konu ile ilgili değişikliklerin tamamını tek bir bağlam ile yönetmeye çalışırsanız işler hızla sarpa saracaktır. Bu karmaşanın önüne geçmek için her bir değişiklik için projenizin tamamının farklı klasörlere kopyalamayı deneyebilirsiniz. Ancak bu durumda 28 | 29 | * Bu klasörler versiyon kontrolünde olmadığı için ekibin geri kalanı ile iş birliği yapmanız çok zorlaşacak 30 | * Farklı değişiklikleri entegre etmek çok zor ve hataya açık bir işlem olacak 31 | 32 | Uzun lafın kısası projenizdeki değişiklikleri profesyonel bir yaklaşımla ele almak istiyorsanız farklı bağlamlarda çalışmak ve bu bağlamları düzgün yönetmek için bir yol bulmanız gerekiyor. 33 | 34 | ## Neyse ki branching var 35 | 36 | Branching bir önceki bölümde değindiğimiz tüm sorunların önüne geçmek için kullanabileceğimiz bir araç ve yaklaşımdır. Branching ile farklı bağlamları birbirinde kolayca izole ederek her birini kolayca ve ayrı ayrı yönetebilirsiniz. 37 | 38 | ![Branching](/.gitbook/assets/01_branching.jpg) 39 | 40 | [_Görsel : Atlassian Git Workflows sayfasından alıntı_](https://www.atlassian.com/git/workflows) 41 | 42 | Herhangi bir anda yaptığınız değişiklikler sadece aktif olarak üzerinde çalıştığınız branch'e \(dal\) yansıyacak diğer branch’ler bu değişikliklerden etkilenmeyecektir. Böylece aynı anda birden fazla branch üzerinde özgürce çalışabilirsiniz ve en önemlisi de bu çalışmalarınızdan bir kısmının çöpe dönmesinden çekinmeden denemelerinizi yapabilirsiniz. 43 | 44 | Versiyon Kontrolünün Altın Kuralları 45 | 46 | \#3 Branch'leri Bol Bol Kullanın 47 | 48 | Branch’ler git'in en güçlü özelliklerinden birisidir. Hızlı ve kullanımı kolay branching mekanizması git'in tasarımında ilk gününden itibaren ciddi bir gereksinim olarak ele alınmıştır. Branch'ler farklı bağlamlarda çalışmaktan kaynaklanabilecek karmaşanın önüne geçmek için biçilmiş kaftandır. Branch'leri bug fix'ler, yeni özellikler üzerinde çalışmak veya deneysel özellikleri geliştirmek için bol bol kullanın. 49 | -------------------------------------------------------------------------------- /content/ileri_seviye_komutlar_ve_islemler/degisikliklerinizi_geri_almak.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Değişikliklerinizi Geri Almak 6 | 7 | Git'in en güzel yanlarından biri de yaptığınız herhangi bir değişikliği kolayca geri alabilmemizi sağlamasıdır. 8 | 9 | ## Son Commit Bilgilerini Düzeltmek 10 | 11 | Commit işlemlerinizi ne kadar dikkatli yaparsanız yapın bazen commit'e dahil etmeyi unuttuğunuz veya yanlışlıkla dahil ettiğiniz dosyalar olabilir veya commit mesajında eksik bilgi vermiş olabilirsiniz. Bu durumda son commit işleminizi yeniden yapmak için **git commit** komutunu **--amend** seçeneği ile kullanabilirsiniz. Sadece commit mesajınızı değiştirmek istiyorsanız **-- amend -m** seçenekleri ile git commit komutunu çalıştırabilirsiniz, eğer son commit'e dosya eklemek veya dosya çıkarmak isterseniz commit komutundan önce önceki bölümlerde de bahsettiğimiz **git add** ve **git rm** komutları ile önce Staging işlemini yapabilirsiniz. 12 | 13 | Versiyon Kontrolünün Altın Kuralları 14 | 15 | \#5 Asla Yayınlanmış Commitlerinizi Düzeltip Tekrar Yayınlamayın 16 | 17 | \*\*git commit\*\* komutunun --amend seçeneği commit hatalarımızı hızlıca ve kolayca düzeltebilmemiz için oldukça faydalı bir seçenektir. Ancak bu seçeneği kullanmadan önce aşağıdaki noktaları dikkate almalısınız 18 | 19 | * Bu seçenek sadece son commit işlemimizi düzeltmemizi sağlar, önceki commitlerimizi bu seçenek ile düzeltemeyiz. 20 | * Bu seçenek ile commit işlemi sonrasında bir önceki commit işlemine dair bilgiler silinir. Proje üzerinde çalışan tek kişi iseniz bu seçeneği kullanmanız sorun yaratmayacaktır ancak bir takım içinde yer alıyorsanız diğer takım arkadaşlarınız sonradan --amend ile düzeltttiğiniz hatalı commit işleminizi baz alarak kendileri de değişiklikler yapmış olabilirler. Bu durum takım arkadaşlarınız için sorun oluşturacaktır, çünkü onların baz aldıkları commit ile ilgili Git'de artık herhangi bir kayıt yer almayacak. 21 | 22 | ## Local Değişiklikleri Geri Almak 23 | 24 | Henüz commit etmediğimiz değişikliklere Local değişiklik denir. Bazen önceki halinden daha kötü olan kod yazabilirsiniz ve bu değişikliği geri almak isteyebilirsiniz. Bu gibi durumlarda değiştirdiğiniz halinden memnun olmadığınız dosyadaki değişiklikleri geri alıp dosyanın son commit edilmiş haline geri dönmek istediğinizde, önceki bölümlerde de sıkca kullandığımız, **git checkout** komutunu **--** seçeneği ile çalıştırmanız yeterli olacaktır. 25 | 26 | > * **$ git checkout -- dosya1.md** veya 27 | > * **$ git checkout -- klasor/dosya2.md** 28 | > 29 | > şeklinde kullanabilirsiniz. 30 | 31 | Tüm dosyalarda yaptığınız değişiklikleri geri almak istiyorsanız **git reset** komutunu **--hard** seçeneği ile kullanabilirsiniz 32 | 33 | > **$ git reset --hard HEAD** 34 | 35 | Bu komut ile Git tüm dosyaların son commit edilen değişiklikleri içeren HEAD versiyonundaki hallerinin Working Copy'nize geri yükler. 36 | 37 | > **git checkout --** ve **git reset --hard** komutları sonrasında kayıt altına alınmamış olan tüm değişiklikler geri dönüşü olmayacak şekilde yok olur. Bu nedenle bu komutları çalıştırırken dikkatli olmalısınız ve iki defa düşünmelisiniz. 38 | 39 | ## Commit Edilen Bir Değişikliği Geri Almak 40 | 41 | Hatalı bir düzenleme yaptığınızda \(ki bu genelde test edilmeden yapılan commit'ler sonrasında oluşan bir durumdur\) veya geliştirdiğiniz bir özelliğin artık gerekli olmadığına karar verildiğinde yaptığınız değişikliği geri almanız gerekecektir. 42 | 43 | **git revert** komutu commit ettiğiniz herhangi bir değişikliği geri almak için kullanılır. Bu komut ile commit işleminizin kendisi veya bilgileri silinmez sadece commit işleminizdeki değişiklik geri alınır. Örneğin eklediğiniz bir satırı kaldırmak isterseniz **git revert** komutu ile bunu yapabilirsiniz. Aslında git revert komutu değişikliğinizi geri almak için otomatik olarak yeni bir commit oluşturur ve geri alma işlemi bu commit sayesinde değişiklik tarihçesinde görünür hale gelir. 44 | 45 | ![git revert](/.gitbook/assets/01_git_revert.jpg) 46 | 47 | Yukarıdaki ekran görüntüsünde ilk önce **git revert** komutunu çalıştırdık. Bu komutun en önemli parametresi geri almak istediğimiz commit'in hash değeri \(hash'in ilk yedi karakterini kullanabiliriz\). Komutu çalıştırdıktan sonra değişiklik tarihçesini incelediğimizde git'in otomatik olarak bir commit oluşturduğunu ve bu commit'in bilgilerinde hangi değişikliğin geri alındığına dair ayrıntıların yer aldığını görüyoruz. 48 | 49 | Değişiklikleri geri almak için kullanabileceğimiz diğer bir komut ise **git reset** komutu. Bu komut da herhangi bir bilginizi silmeden işlemi gerçekleştirir, ancak git revert komutundan farklı olarak otomatik yeni bir commit üretmeden değişikliğinizi geri almanızı sağlar. 50 | 51 | ![git reset](/.gitbook/assets/02_git_reset.jpg) 52 | 53 | Bu komut için de git revert komutunda olduğu gibi geri almak istediğimiz commit'in hash değerini veriyoruz. Kullandığımız diğer bir seçenek olan **--hard** seçeneği ise local tüm commitlerinizi silerek geri alma işleminin yapılmasına neden olur, bu nedenle --hard seçeneğini kulllanırken dikkatli olmalısınız. Local commit'lerinizin korunmasını istiyorsanız **--keep** komutunu kullanabilirsiniz. 54 | 55 | > **30 gün iade garantisi!** git reset komutu ile geri alma işlemi sonrasında geri aldığınız noktadan sonraki tüm değişiklikler tarihçeden silinecektir. Ancak git bu silinen bilgileri 30 gün kadar veritabanında tutmaya devam edecektir. Eğer yanlışlıkla geri alma işlemi yaptığınızı farkederseniz 30 gün içinde silinen herhangi bir commit'inizi geri alabilirsiniz. 56 | > 57 | > * [30 günlük süre nasıl değiştirilebilir](http://www-cs-students.stanford.edu/~blynn/gitmagic/ch07.html) 58 | > * [Silinen commit hangi komutlar ile geri alınır](http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html) 59 | -------------------------------------------------------------------------------- /app/components/search.vue: -------------------------------------------------------------------------------- 1 | 70 | 71 | 141 | -------------------------------------------------------------------------------- /content/branching_dallanma_ve_merging_birlestirme/branching_is_akislari.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Branching İş Akışları 6 | 7 | Nasıl kullanıldıklarına bağlı olarak branch'leri iki ana grup altında toplayabiliriz. 8 | 9 | > Bu gruplama sadece anlamsal ve kullanım pratikleri ile ilgili bir gruplandırmadır, sonuç itibariyle branch kavramı daha önceki bölümlerde anlattığımız kadar basit bir Git aracıdır 10 | 11 | ## Kısa Vadeli / Konu Bazlı Branch'ler 12 | 13 | Daha önceki bölümlerde branch kullanımı noktasında elinizi korkak alıştırmamanız ile ilgili tavsiyelerde bulunduk. Örneğin yeni özellikleri kodlarken, bug fix yaparken veya deneysel özellikler ile ilgili çalışırken istediğiniz şekilde kolayca ve hızlı bir şekilde üstelik düşük maliyetli branch'ler oluşturabilirsiniz. Bu tür amaçlar için oluşturulan branch'lerin iki ortak özelliği vardır 14 | 15 | * Bu branch'ler tek konu veya değişiklik için oluşturulur. Örneğin size bildirilen bir hata için oluşturduğunuz branch üzerinde "GitHub İle Sisteme Giriş" benzeri yeni bir özelliği kodlamayız. 16 | * Bu branch'ler üzerindeki çalışmanız göreceli kısa sürmektedir. Çalışmamız tamamlandığında bu branch'leri **master** veya daha geniş kapsamda tarif edilen bir branch'e merge edip sileriz. 17 | 18 | ## Uzun Soluklu Branch'ler 19 | 20 | İkinci türdeki branch'ler ise daha üst seviyede anlam taşırlar ve yeni özellikler, bug fix ve deneysel çalışmalar gibi odaklanmış konular yerine projenizi stabil, test ve development gibi aşamalarını temsil ederler. Bu tür branch’ler projeniz üzerinde geliştirme yaptığınız sürece varlıklarını sürdüreceklerdir. Tipik olarak bu tür branch'ler ile ilgili aşağıdaki kurallar geçerlidir 21 | 22 | * Genelde bu tür uzun soluklu branch’ler üzerinde doğrudan değişiklik yapmazsınız. Çalışmalarınızı kısa vadeli branch’ler üzerinde yaparak değişiklikleri bu branch'lere entegre edersiniz. 23 | * Uzun soluklu branch'ler arasında bir hiyerarşi vardır. Genellikle **master** branch projenizin stabil versiyonudur ve hiyerarşik olarak bir altında geliştirmelerinizi entegre ettiğiniz ve daha az stabil olabilen **development** branch'i yer alır. 24 | 25 | Uzun soluklu branch'lerin hangi kriterlere göre oluşturulacağı, nasıl yönetileceği ve isimlerinin ne olacağı genellikle çalışan ekibe ve projeye göre değişebilir. Ancak her hâlükârda nasıl bir branching stratejisinin izleneceğine ekip olarak fikir birliği içinde karar verilmelidir. 26 | 27 | ## Basit ve Faydalı Branching Stratejileri 28 | 29 | Yukarıda da belirttiğimiz gibi branch'in stratejileri ekibe ve projeye göre değişebilir, ancak aşağıda çoğu ekip tarafından kullanılabilecek basit bir iş akışı kullanabilirsiniz 30 | 31 | ### Sadece bir tane uzun soluklu branch kullanın 32 | 33 | Daha önce de belirttiğimiz gibi birden fazla uzun soluklu branch kullanabilirsiniz ancak çoğu zaman bu tip bir yaklaşım karışıklıklara ve fazladan efor sarf etmek gibi zorluklara sebep olabilir. Tek bir uzun soluklu branch kullanmanız durumunda \(genelde **master** ismi kullanılır\) işiniz önemli miktarda sadeleşip kolaylaşacaktır. 34 | 35 | > Bu yaklaşım ile çalışmanız durumunda **master** branch'iniz projenizin stabil kodunu barındırmalıdır. Kodunuzun stabil olmasını garantilemek için **master** branch'e entegre edilen \(merge\) tüm değişikliklerin testler, kod okuma vs gibi kalite kontrol yöntemleri ile denetlenmesi gerekecektir. Bunun bir yansıması olarak değişikliklerin doğrudan **master** branch üzerinde yapılmaması gibi bir zorunluluk da doğacaktır. Eğer _git checkout master_ ve sonrasında _git commit_ komutlarını çalıştırıyorsanız bilin ki stabilite kuralını ihlal ediyorsunuz. 36 | 37 | ### Konu Bazlı Branchler'i Bolca Kullanabilirsiniz 38 | 39 | Projeniz için yeni bir özellik üzerinde çalışmak için, bug fix yapmak için veya deneysel özellikleri ve iyileştirmeleri kodlamak için ayrı birer branch oluşturmaktan ve bu branch'ler üzerinde değişikliklerinizi yapmaktan imtina etmeyin. Bu yaklaşım nerdeyse tüm branching iş akışlarında çok sık kullanılan ve sizin de alışkanlık haline getirmeniz gereken bir yaklaşımdır. 40 | 41 | Sadece bir tane uzun soluklu ve stabil branch'iniz \(master\) olduğu için konu bazlı branch’lerinizin hepsini bu ana branch'i baz alarak oluşturup değişikliklerinizi tamamlayıp kalite kontrol sürecinizi \(testler, kod okuma vs\) de işlettikten sonra bu değişiklikleri tekrar ana branch'iniz olan master'a entegre etmelisiniz. 42 | 43 | Diğer yandan siz kendi konu bazlı branch'inizde değişiklikleri yaparken ekip arkadaşlarınız da arada kendi değişikliklerini master branch'e entegre ediyor olacaklarıdır. Bu durumda da kendi branch'inizi master branch'deki değişiklikler nedeniyle güncel tutmak için master'daki değişiklikleri de kendi konu bazlı branch'inize sıkça entegre etmelisiniz. 44 | 45 | Bu basit akışta unutmamanız gereken tek bir altın kural var; değişikliklerinizi kalite kontrol süreçlerinizi işletmeden ana branch'iniz olan ve her zaman stabil olması gereken master'a entegre etmeyin aksi durumda master branch'inizin stabilitesini bozabilirsiniz. 46 | 47 | ### Remote ve Yerel Branch'lerinizi Senkronize Edin 48 | 49 | Git'de remote ve yerel branch'leriniz pratik olarak birbirinden tamamen bağımsızdırlar. Ancak gündelik çalışmanız sırasında kendi bilgisayarınızda oluşturduğunuz branch'lerin uzaktaki sunucudaki eşleniğinin de olmasını sağlamalısınız. 50 | 51 | ### Değişikliklerinizi Sıkça Remote Branch'lere Yükleyin \(Push\) 52 | 53 | Remote branch’ler ile yerel branch’leri sadece yapısal olarak değil yaptığınız değişiklikler anlamında da senkronize etmelisiniz. Bu şekilde ekibinizin geri kalanı da sizin yaptığınız güncel değişikliklerden haberdar olacak ilave olarak yerel branch'lerinizi yedeğini almış olacaksınız. 54 | 55 | ## Diğer Branching Stratejileri 56 | 57 | Bu bölümde bahsettiğimiz basit stratejiler ve iş akışları genelde küçük ve çevik \(agile\) takımlar tarafından kullanıma uygundur. Daha büyük projelerde ve farklı takım kurgularında daha sıkı kurallar ve daha farklı branching yaklaşımlarının kullanımını gerektirebilir. 58 | 59 | > Gitflow, Forking ve Pull Request adı verilen alternatif iş akışları ile ilgili arama yaparak farklı yaklaşımları kendiniz inceleyebilirsiniz. 60 | -------------------------------------------------------------------------------- /app/stores/content.ts: -------------------------------------------------------------------------------- 1 | import type { ContentNavigationItem } from '@nuxt/content' 2 | import type { /* PageSchema, */ Section } from '~/types' 3 | 4 | export const useContentStore = defineStore('contents', () => { 5 | const page = ref() 6 | const navigation = ref([]) 7 | const sections = ref([]) 8 | const contentNavigationMap = ref<{ path: string, stem: string, title: string }[]>([]) 9 | const sort = ref<{ stem: string, subStems: string[] }[]>([ 10 | { 11 | stem: 'git_kurulumu', 12 | subStems: ['git_kurulumu/git_kurulumu'], 13 | }, 14 | { 15 | stem: 'versiyon_kontrolune_giris', 16 | subStems: [ 17 | 'versiyon_kontrolune_giris/versiyon__kontrolu_nedir', 18 | 'versiyon_kontrolune_giris/neden_versiyon_kontrolune_ihtiyacimiz_var', 19 | 'versiyon_kontrolune_giris/git_tarihcesi', 20 | 'versiyon_kontrolune_giris/git_ile_calismaya_baslamak', 21 | 'versiyon_kontrolune_giris/basit_anlamda_versiyon_kontrolu_is_akisi', 22 | 'versiyon_kontrolune_giris/yeni_bir_proje_olusturmak', 23 | 'versiyon_kontrolune_giris/remote_bir_proje_olusturmak', 24 | 'versiyon_kontrolune_giris/projeniz_uzerinde_calismaya_baslayalim', 25 | ], 26 | }, 27 | { 28 | stem: 'branching_dallanma_ve_merging_birlestirme', 29 | subStems: [ 30 | 'branching_dallanma_ve_merging_birlestirme/branching_nedir-_ne_ise_yarar', 31 | 'branching_dallanma_ve_merging_birlestirme/branchler_ile_calismak', 32 | 'branching_dallanma_ve_merging_birlestirme/degisikliklerinizi_gecici_olarak_kaydetmek', 33 | 'branching_dallanma_ve_merging_birlestirme/local_bir_branchde_calismak', 34 | 'branching_dallanma_ve_merging_birlestirme/degisiklikleri_merge_etmek', 35 | 'branching_dallanma_ve_merging_birlestirme/branching_is_akislari', 36 | ], 37 | }, 38 | { 39 | stem: 'remote_repositoryler', 40 | subStems: [ 41 | 'remote_repositoryler/remote_bir_repositorye_baglanti_saglamak', 42 | 'remote_repositoryler/remote_repositorydeki_verilerin_incelenmesi', 43 | 'remote_repositoryler/remote_degisiklikleri_entegre_etmek', 44 | 'remote_repositoryler/local_bir_branchi_yayinlamak_publish', 45 | 'remote_repositoryler/branchleri_silmek', 46 | ], 47 | }, 48 | { 49 | stem: 'ileri_seviye_komutlar_ve_islemler', 50 | subStems: [ 51 | 'ileri_seviye_komutlar_ve_islemler/degisikliklerinizi_geri_almak', 52 | 'ileri_seviye_komutlar_ve_islemler/diff_ile_farklari_incelemek', 53 | 'ileri_seviye_komutlar_ve_islemler/cakismalari_gidermek', 54 | 'ileri_seviye_komutlar_ve_islemler/merge_alternatifi_olarak_rebase_kullanimi', 55 | ], 56 | }, 57 | { 58 | stem: 'git_arac_ve_servisleri', 59 | subStems: [ 60 | 'git_arac_ve_servisleri/masaustu_gorsel_git_uygulamalari', 61 | 'git_arac_ve_servisleri/diffmerge_araclari', 62 | 'git_arac_ve_servisleri/cevrimici_git_servisleri', 63 | 'git_arac_ve_servisleri/kaynakca_ve_referanslar', 64 | ], 65 | }, 66 | { 67 | stem: 'alistirmalar', 68 | subStems: [ 69 | 'alistirmalar/gun_01', 70 | 'alistirmalar/gun_02', 71 | 'alistirmalar/gun_03', 72 | 'alistirmalar/gun_04', 73 | 'alistirmalar/gun_05', 74 | 'alistirmalar/gun_06', 75 | 'alistirmalar/gun_07', 76 | 'alistirmalar/gun_08', 77 | 'alistirmalar/gun_09', 78 | 'alistirmalar/gun_10', 79 | 'alistirmalar/gun_11', 80 | ], 81 | }, 82 | ]) 83 | 84 | const cleanId = (id: string) => id.replace(/-/g, ' ') 85 | const formatId = (label: string) => label.split(' ').join('-') 86 | 87 | const _isNavigationSet = ref(false) 88 | const setNavigation = (contentNavigationItem: ContentNavigationItem[] | undefined | null) => { 89 | if (!_isNavigationSet.value && contentNavigationItem) { 90 | const sortedNavigation = contentNavigationItem 91 | .filter(n => n.stem && !n.stem.includes('index')) 92 | .sort((a, b) => { 93 | const indexA = sort.value.findIndex(s => a.stem?.startsWith(s.stem)) 94 | const indexB = sort.value.findIndex(s => b.stem?.startsWith(s.stem)) 95 | return (indexA === -1 ? sort.value.length : indexA) - (indexB === -1 ? sort.value.length : indexB) 96 | }) 97 | .map((n) => { 98 | const currentSort = sort.value.find(s => n.stem?.startsWith(s.stem)) 99 | const sortedChildren = n.children?.filter(sn => !sn.stem?.includes('/index')) 100 | .sort((a, b) => { 101 | const aIndex = currentSort?.subStems.indexOf(a.stem || '') ?? Infinity 102 | const bIndex = currentSort?.subStems.indexOf(b.stem || '') ?? Infinity 103 | return aIndex - bIndex 104 | }) ?? [] 105 | 106 | sortedChildren.forEach((sn) => { 107 | if (sn.stem && sn.path && sn.title) { 108 | contentNavigationMap.value.push({ 109 | path: sn.path, 110 | stem: sn.stem, 111 | title: sn.title, 112 | }) 113 | } 114 | }) 115 | 116 | return { 117 | ...n, 118 | title: n.stem?.replace(/_/g, ' ') ?? '', 119 | children: sortedChildren, 120 | } 121 | }) 122 | 123 | navigation.value = sortedNavigation 124 | _isNavigationSet.value = true 125 | } 126 | } 127 | 128 | const setSections = (_page: any) => { 129 | page.value = _page 130 | sections.value = [] 131 | 132 | let currentSection: Section | null = null 133 | 134 | _page.body.value.forEach((item: any) => { 135 | if (item[0] === 'h2') { 136 | if (currentSection) 137 | sections.value.push(currentSection) 138 | 139 | currentSection = { 140 | id: formatId(item[1].id), 141 | label: cleanId(item[1].id), 142 | subSections: [], 143 | } 144 | } 145 | else if (item[0] === 'h3' && currentSection) { 146 | currentSection.subSections?.push({ 147 | id: formatId(item[1].id), 148 | label: cleanId(item[1].id), 149 | }) 150 | } 151 | }) 152 | 153 | if (currentSection) 154 | sections.value.push(currentSection) 155 | 156 | sections.value.sort((a, b) => { 157 | const findIndex = (label: string) => { 158 | const match = sort.value.find(s => s.subStems.some(stem => stem.endsWith(label))) 159 | return match ? sort.value.indexOf(match) * 100 + match.subStems.findIndex(stem => stem.endsWith(label)) : Infinity 160 | } 161 | return findIndex(a.id) - findIndex(b.id) 162 | }) 163 | } 164 | 165 | return { 166 | page, 167 | navigation, 168 | sections, 169 | contentNavigationMap, 170 | setNavigation, 171 | setSections, 172 | } 173 | }) 174 | -------------------------------------------------------------------------------- /content/alistirmalar/gun_04.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # 4.Gün: Değişiklikleri Kaydetme 6 | 7 | Bu bölümde bilgisayarınızda oluşturduğunuz yerel bir deponun veya uzaktaki bir deponun bilgisayarınızdaki kopyasında yapacağınız değişiklikleri nasıl versiyon kontrolü altına alacağımız ile ilgili bilgilerimizi tazeleyip alıştırmalar yapacağız. 8 | 9 | Projenizi ister yerel bir depoda olsun isterseniz uzak bir depodan klonlamış olsun tüm değişiklikleriniz yerel diskinizde gerçekleşecek ve commitleriniz ile oluşturacağınız tüm versiyonlar git tarafından yerel diskinizdeki .git klasöründeki Git veri tabanında kayıt altına alınıp takip edilecektir. git push komutunu çalıştırmadığınız sürece yaptığınız değişiklikler sadece yerel diskinizde kayıt altına alınır. 10 | 11 | ## Dosya Durumları 12 | 13 | Git'de dosyalarınız genel olarak iki durumda olabilir 14 | 15 | Takip Edilmeyen \(Untracked\), bu durumdaki dosyalar versiyon kontrolü altında olmayan veya sizin henüz versiyon kontrolü yapmak için Git'e eklemediğiniz dosyalardır. Bu dosyalardaki değişiklikler siz dosyaları Git'e eklemediğiniz sürece versiyon kontrolüne tabi değildir 16 | 17 | Takip Altında \(Tracked\), bu durumdaki dosyalar ise Git'in versiyon kontrolü takibi altında olan dosyalardır. Bu dosyalar üzerinde yapacağınız tüm değişiklikler git tarafından takip edilmektedir. 18 | 19 | ## Staging Area 20 | 21 | Çoğu versiyon kontrol sisteminde değişiklikleriniz iki yerde kaydedilir 22 | 23 | * Yerel diskinizdeki çalışma klasörünüz \(working copy\) veya 24 | * Versiyon kontrol sisteminin veri tabanı 25 | 26 | Ancak Git'de değişikliklerinizin kayıt altına alındığı üçüncü bir alan daha vardır ki buna Staging Area denir ve Git'in en temel kavramlarından birisidir. Staging Area'yı, proje dosyalarımızdaki bir dizi değişikliği yeni bir versiyon olarak mühürlemeden önce kayıt altında tuttuğunuz veri tabanı olarak tanımlayabiliriz. 27 | 28 | ## git add 29 | 30 | Git ile versiyon kontrolü altına aldığınız projenize dosya eklediğinizde, dosya sildiğinizde veya var olan bir dosyanın içeriğini değiştirdiğinizde bu değişiklikler Git tarafından otomatik olarak takip edilmez. Git'in bu dosyaları takip etmesi için git add komutu ile bu dosyaları önce Git’e tanıtmanız gerekir. 31 | 32 | ### Alıştırma - 1 33 | 34 | Uzak deponuzdan bilgisayarınıza klonladığınız proje deponuzun src klasörü altındaki gun\_04\_01.txt isimli bir dosya ekleyip bu dosyanın içine adınızı ve soyadınızı yazın ve komut satırı ara yüzünden aşağıdaki komutları çalıştırın 35 | 36 | ```bash 37 | # Proje klasörünüze konumlanın 38 | cd 39 | 40 | git status 41 | ``` 42 | 43 | **Soru:** `git status` komutunun sonucunda yeni eklediğiniz dosya yukarıda bahsedilen iki durumdan hangisindedir? 44 | 45 | ### Alıştırma - 2 46 | 47 | Uzak deponuzdan bilgisayarınıza klonladığınız proje deponuzun kök klasörü altında gun\_04\_02 isimli yeni bir klasör oluşturun ve aşağıdaki komutları komut satırı ara yüzünde çalıştırın 48 | 49 | ```bash 50 | cd 51 | 52 | git add -A . 53 | 54 | git status 55 | ``` 56 | 57 | **Soru:** `git status` komutunun sonucunda yeni eklediğiniz klasör _tracked_ bir klasör haline geldi mi? 58 | 59 | **Soru:** Boş klasörü tracked hale getirmek için nasıl bir yöntem izlemelisiniz? 60 | 61 | ### Alıştırma - 3 62 | 63 | `git help add` komutu çalıştırarak add komutuna aşağıdaki işlemleri desteklemek için hangi parametrelerin geçilebileceğini araştırıp her bir durum için git add komutunu çalıştırın. 64 | 65 | * gun\_04\_03 isimli klasörün altındaki tüm txt uzantılı dosyalar 66 | * gun\_04\_03 isimli klasörün altındaki tüm dosyalar 67 | * Proje klasörünüze eklenen tüm dosyalar 68 | * gun\_04\_03.txt isimli tek bir metin dosya 69 | 70 | ## git checkout 71 | 72 | Checkout komutu birden fazla amaçla kullanılabilen komutlardan birisidir. Bunlar 73 | 74 | * Bir dosyadaki değişiklikleri iptal etmek 75 | * Çalışma kopyanızdaki \(Working Copy\) değişiklikleri kaybetmeden projenizin herhangi bir commit'ini incelemek 76 | * Farklı bir dalı çalışma kopyanız olarak aktif hale getirmek 77 | 78 | Bu bölümde bu komutun kullanımlarından birincisi ile ilgileniyoruz. Checkout komutu ile değiştirdiğimiz ancak henüz git add ile Staging Area'ya eklemediğimiz dosyalardaki değişiklikleri aşağıdaki komut şablonunun kullanarak iptal edebiliriz. 79 | 80 | ```bash 81 | git checkout 82 | ``` 83 | 84 | ### Alıştırma - 1 85 | 86 | Bu alıştırmayı yapmak için öncelikle proje kök klasörü altındaki src klasörüne txt uzantılı metin bir dosya ekleyip dosyayı commit etmeniz gerekiyor. Bu işlemi aşağıdaki komutlar ile hızlıca yapabilirsiniz. 87 | 88 | ```bash 89 | # Proje klasörünüze konumlanın 90 | cd 91 | 92 | touch .txt 93 | 94 | git add -A . 95 | 96 | git commit -m “4. gün, ikinci bölüm 1. Alıştırma hazırlığı” 97 | ``` 98 | 99 | Dosyanızı commit ettikten sonra komut satırı ara yüzünde aşağıdaki komutları çalıştırın 100 | 101 | ```text 102 | # Proje klasörünüze konumlanın 103 | cd 104 | 105 | # .txt dosyasının içeriğini değiştirdikten sonra aşağıdaki komutları çalıştırın 106 | git status 107 | 108 | git checkout .txt 109 | ``` 110 | 111 | ### Alıştırma - 2 112 | 113 | ```bash 114 | # Proje klasörünüze konumlanın 115 | cd 116 | 117 | # .txt isimli yeni bir dosya ekleyin ve içine adınızı soyadınızı yazın 118 | git status 119 | 120 | git checkout .txt 121 | ``` 122 | 123 | **Soru:** Aldığınız hatayı nasıl yorumlamamız lazım. 124 | 125 | ### Alıştırma - 3 126 | 127 | ```bash 128 | # önceki alıştırmada eklediğiniz .txt dosyasını git add ile Staging Area'ya ekleyin 129 | # dosyanın içeriğini değiştirin ve kaydedin 130 | 131 | $ git checkout .txt 132 | ``` 133 | 134 | **Soru:** git checkout işlemi sonrasında .txt dosyasının içeriği Staging Area'ya eklenmeden önceki haline döndü mü? Neden? 135 | 136 | ## git reset 137 | 138 | Reset komut ile Staging Area'ya git add ile eklediğimiz ve Git tarafından takip edilen \(tracked\) dosyaları Staging Area'dan çıkarabiliriz. Komut şu şablonu şöyle 139 | 140 | ```bash 141 | git reset HEAD 142 | ``` 143 | 144 | Komut şablonundaki parametre değerini vermeden de komutu çalıştırabilirsiniz. Bu durumda Staging Area'daki tüm dosyalar bu alandan çıkarılır ve tekrar takip edilmeyen\(untracked\) durumuna gelir. 145 | 146 | Komut şablonundaki **HEAD** parametre değeri verilmeden de komutu çalıştırabilirsiniz. Bu durumda reset işlemi dosyanızı son commit’de olduğu haline geri getirir. 147 | 148 | ### Alıştırma 149 | 150 | ```bash 151 | # Proje klasörünüze konumlanın 152 | cd 153 | 154 | # Daha önceki alıştırmalarda eklediğiniz ve commit ettiğiniz herhangi bir dosyanın içeriğini değiştirin 155 | git status 156 | 157 | # dosyanız henüz track edilmiyor 158 | 159 | # Değiştirdiğiniz txt uzantılı tüm dosyaları Staging Area’ya ekleyin 160 | git add *.txt 161 | 162 | git status 163 | # dosyalarınız tracked hale geldi 164 | 165 | git reset HEAD .txt 166 | 167 | git status 168 | # .txt isimli dosyanız tekrar untracked halde 169 | ``` 170 | 171 | **Soru-1:** Dosyanızda yaptığınız değişiklik kayboldu mu? 172 | 173 | **Soru-2:** Dosyanızı değişiklik yapılmadan önceki hale getirmek için hangi komutu kullanmanız lazım? \(İPUCU: Son durumda dosyanız untracked durumda yani Staging Area'da değil\) 174 | -------------------------------------------------------------------------------- /content/git_kurulumu/git_kurulumu.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Git İle Çalışmaya Başlamak 6 | 7 | ## Komut satırı mı yoksa görsel arayüz mü? 8 | 9 | Git ile çalışmak için git'in kendi **komut satırı arayüzünü** (Git Command Line Interface) veya görsel kullanıcı arayüzü olan masaüstü uygulamalar (SourceTree, Tortoise Git, Tower veya GitHub) kullanabilirsiniz. 10 | 11 | Git ile çalışırken görsel arayüzü olan bir uygulama kullanmanız üretkenliğinizi arttırıp Git'in çok sayıdaki karmaşık komutuna daha hızlı ve kolay erişmenizi sağlar. Diğer yandan Git'in komut satırı arayüzünü kullanmanız Git ile ilgli daha ayrıntılı bilgilenmenizi ve 3. parti uygulamalara bağımlı kalmadan Git ile çalışabilmenizi sağlar. 12 | 13 | > Git komutlarını komut satırında öğrendikten sonra günlük çalışmanızda 14 | görsel arayüzü olan bir uygulamayı mutlaka kullanmanızı öneriyorum. 15 | 16 | ## Kurulum 17 | 18 | Git'in kurulumu hem Windows hem de Mac OS X için oldukça kolay bir işlemdir. Her iki işletim sistemi için tek tıkla kurulum yapmanızı sağlayan kurulum sihirbazları vardır. 19 | 20 | ### Windows 21 | İşletim sisteminiz Windows ise git ile çalışmak için "msysgit" paketini kullanabilirsiniz. 22 | 23 | **msysgit** paketini kurmak için [http://msysgit.github.io/](http://msysgit.github.io/) adresinden kurulum uygulamasını indirip çalıştırmalısınız. Kurulum adımları sırasında karşınıza çıkacak olan ekranlarda varsayılan ayarları seçili olarak bırakarak kurulumunuzu tamamlayabilirsiniz. 24 | 25 | Kurulum tamamlandıktan sonra Windows Başlangıç menüsünden *Git* klasörü altındaki **Git Bash** uygulamasını çalıştırıp Git'in komut satırı arayüzünü kullanmaya başlayabilirsiniz. 26 | 27 | > Git'in kurulumunun sorunsuz gerçekleştiğini teyid etmek için **Git Bash**'i açıp **git --version** komutunu yazın. Bu komut ekrana Git'in versiyon bilgisini basar. Eğer hata alırsanız msysgit ana sayfasından sorunun giderilmesi için ne yapmanız gerektiğini öğrenebilirsiniz. 28 | 29 | ### Mac OS X 30 | 31 | İşletim sisteminiz Mac OS X ise Git kurulumu için iki yöntem kullanabilirsiniz. 32 | * Apple'in geliştirici araçlarını kurarak (XCode) Apple tarafından sağlanan Git dağıtımını kurabilirsiniz 33 | * [Git OS X Installer](https://code.google.com/p/git-osx-installer/downloads/list?can=3) paketini indirip Git'i kurabilirsiniz. 34 | 35 | Git kurulumunu tamamladıktan sonra Applications klasörü altındaki Terminal.app uygulamasını çalıştırın. 36 | 37 | > Spotlight'a *terminal* yazarak da Terminal.app uygulamasını bulup çalıştırabilirsiniz 38 | 39 | Kurulumunuzu denetlemek için komut satırında **git --version** komutunu çalıştırın. Bu komut Git'in versiyonunu ekrana basar.Herhangi bir hata almanız durumunda kurulum yönteminize göre ilgili kaynakları araştırmanız gerekebilir. 40 | 41 | ### Git Konfigürasyonu 42 | Git'i kurduğumuza göre artık Git ile çalışmak için bazı ayarlar yapabiliriz. Bu ayarlar için Git bize **git config** isimli bir araç/komut sunar. Git ayarlarını bir defa yapmanız yeterli olacaktır. 43 | 44 | > Bu ayarları istediğiniz zaman değiştirebilirsiniz. 45 | 46 | Git ayarlarınız aşağıda belirtilen üç konumda kaydedilir ve hiyerarşik olarak bu konumlardan yüklenir 47 | 48 | 1. Seviye (/etc/gitconfig dosyası) : Tüm kullanıcı ve projeler için geçerli olan ayarlar bu dosyada kaydedilir. **git config** komutunu **--system** seçeneği ile çalıştırırsanız ayarlar bu dosyada kaydedilecek ve bu dosyadan okunacaktır 49 | 2. Seviye (/.gitconfig dosyası) : Sadece sizin kullanıcınız için tanımlanan ayarların kaydedildiği dosyadır. **git config** komutunu **--global** seçeneği ile çalıştırısanız ayarlar bu dosyaya kaydedilecek ve bu dosyadan okunacaktır 50 | 3. Seviye : Proje klasörünüzün (projenizin Git ile versiyon kontrolüne alınmış olması gerekiyor) altında yer alan **.git/config** dosyasında ise proje bazındaki git ayarlarınız yer alır. 51 | 52 | Git, ayarlarınızın değerini belirlemek için bu üç konumdaki dosyaları 3. seviye, 2. seviye ve 1. seviye sıralaması ile hiyerarşik olarak okur. Belirli bir ayar'a ilişkin değere ilk hangi seviyede rastlandıysa o seviyedeki değer dikkate alınır diğer seviyelerdeki değerler dikkate alınmaz. 53 | 54 | Windows'da global (**git config --global** komutu) git ayarlarınız Windows'un $HOME klasörü altında yer alan (genellikle C:\Documents and Settings\$USER) **.config** dosyasında yer alır. Proje seviyesindeki ayarlarınız ise OS X'de olduğu gibi **[Projenizin Ana Klasörü]\.git\config** dosyasında kayıt altına alınır. 55 | 56 | ### Kullanıcı adınızı ve email bilgisi 57 | 58 | Git ayarlarından en önemli olanları kullanıcı adınız ve email adresinizdir. Git, ayar olarak tanımladığınız değerleri **commit** vb işlemlerde otomatik olarak kullanır. Bu ayarların değerini belirlemek için komut satırında aşağıdaki komutları çalıştırıyoruz 59 | 60 | git config --global user.name "ali özgür" 61 | git config --global user.email "ali.ozgur@example.com" 62 | 63 | Yukarıdaki komutlarda 64 | * **--global** seçeneği ile Git'e global ayarları düzenlediğinizi söylüyoruz 65 | * **user.name** (ve user.email) ile değerini değiştirmek istediğiniz ayarın anahtar'ını belirtiyoruz 66 | * Ardından da çift tırnak içinde ilgili ayarın değerini giriyoruz 67 | 68 | Bu ayarları **--global** ibaresi ile tüm projelerinizde geçerli olacak şekilde yaptık, proje seviyesinde bu ayarları yapmak için komut satırında (terminal'de) projenizin klasörüne konumlanıp **git config user.name "ali özgür"** komutu ile *--global* seçeneğini kullanmadan yapabilirsiniz. 69 | 70 | Kendi yaptığımız veya kurulum ile hazır gelen ayarların değerlerini görmek için aşağıdaki komutları kullanabiliriz. 71 | 72 | * Global seviyede tüm ayarları listelemek için 73 | > **git config --global -l** 74 | * Global seviyede tek bir ayar'ın değerini (örneğimizde user.name anahtarına sahip ayar) görmek için ise 75 | > **git config --global user.name** 76 | 77 |
78 |

İPUCU

79 |

Git'in komutları ve bu komutların seçenek ve parametreleri ile ilgili yardım almak istediğinizde 80 |

    81 |
  • git [komut adı] --help (örneğin: git init --help)
    • 82 |
  • git help [komut adı] (örneğin: git help init)
    • 83 |
84 | komutlarını kullanabilirsiniz. 85 |

86 |
87 | 88 | ### Editör ayarı 89 | Git'in bazı komutları sizden interaktif olarak yorum veya bilgi girmenizi ister. Bu tür durumlar için Git'in hangi metin düzenleme uygulamasını kullanacağını ayarlayabilirsiniz. Git varsayılan olarak [Vi](http://en.wikipedia.org/wiki/Vi) veya [Vim](http://en.wikipedia.org/wiki/Vim_(text_editor)) kullanır. Ancak bu editörlerin kullanımı başlangıç seviyesindeki kullanıcılar için zor olabilir. Ben, Vi veya Vim ile karşılaştırıldığında kullanımının daha kolay olduğunu düşündüğüm **[GNU Midnight Commander (MC)](https://www.midnight-commander.org/)** kullanmanızı öneriyorum. 90 | 91 | Midnight Commander'i Mac OS X'e [Homebrew](http://brew.sh/) kullanarak 92 | 93 | brew install midnight-commander 94 | komutu ile kurabilirsiniz. 95 | 96 | Midnight Commander veya Git'i destekleyen editör kurulumunu tamamladıktan sonra 97 | 98 | git config --global core.editor mcedit 99 | 100 | ile Git'in kullanacağı editör ayarınızı yapabilirsiniz. 101 | 102 | ### Diff aracı ayarları 103 | 104 | Diff kavramını ilerleyen bölümlerimizde daha ayrıntılı ele alacağız, ancak kısaca değinmek gerekirse 105 | 106 | > Bir dosyanın Tx anındaki içeriği ile Ty anındaki içeriğinin arasındaki farkları tespit etme ve gösterme işlemidir. İngilizcede **difference** (fark) kelimesinin kısaltması olan **diff** şeklide kullanılır. 107 | 108 | Bu işlemi göz ile yapmak zorunda kalmadan dosyalar ve/veya klasörler arasındaki farkları tespit etmek ve görselleştirmek için kullanılan araçlara genel olarak Diff Araçları ismi verilir. 109 | 110 | Ben, Mac OS X üzerinde ücretsiz bir uygulama olan **SourceGear DiffMerge** kullanmayı tercih ediyorum. Git'in diff aracı olarak SourceGear DiffMerge'i kullanmasını sağlamak için 111 | 112 | git config --global merge.tool diffmerge 113 | 114 | komutu ile ayar yapabilirsiniz. DiffmMerge'in OS X'de tam olarak ayarlarının nasıl yapılacağını öğrenmek için [bu linkte](http://twobitlabs.com/2011/08/install-diffmerge-git-mac-os-x/) göz atabilirsiniz. 115 | 116 | Windows'da ise yine ücretsiz bir uygulama olan [WinMerge](http://winmerge.org/downloads/) veya ücretli bir uygulama olan [Araxis Merge'i](http://www.araxis.com/merge/download.en) kullanılabilir. Bu araçların Git ayarlarının nasıl yapılacağını yardım dokümanlarından faydalanarak öğrenebilirsiniz. 117 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/git_ile_calismaya_baslamak.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Git İle Çalışmaya Başlamak 6 | 7 | ## Komut satırı mı yoksa görsel arayüz mü? 8 | 9 | Git ile çalışmak için git'in kendi **komut satırı arayüzünü** \(Git Command Line Interface\) veya görsel kullanıcı arayüzü olan masaüstü uygulamalar \(SourceTree, Tortoise Git, Tower veya GitHub\) kullanabilirsiniz. 10 | 11 | Git ile çalışırken görsel arayüzü olan bir uygulama kullanmanız üretkenliğinizi arttırıp Git'in çok sayıdaki karmaşık komutuna daha hızlı ve kolay erişmenizi sağlar. Diğer yandan Git'in komut satırı arayüzünü kullanmanız Git ile ilgli daha ayrıntılı bilgilenmenizi ve 3. parti uygulamalara bağımlı kalmadan Git ile çalışabilmenizi sağlar. 12 | 13 | > Git komutlarını komut satırında öğrendikten sonra günlük çalışmanızda görsel arayüzü olan bir uygulamayı mutlaka kullanmanızı öneriyorum. 14 | 15 | ## Kurulum 16 | 17 | Git'in kurulumu hem Windows hem de Mac OS X için oldukça kolay bir işlemdir. Her iki işletim sistemi için tek tıkla kurulum yapmanızı sağlayan kurulum sihirbazları vardır. 18 | 19 | ### Windows 20 | 21 | İşletim sisteminiz Windows ise git ile çalışmak için "msysgit" paketini kullanabilirsiniz. 22 | 23 | **msysgit** paketini kurmak için [http://msysgit.github.io/](http://msysgit.github.io/) adresinden kurulum uygulamasını indirip çalıştırmalısınız. Kurulum adımları sırasında karşınıza çıkacak olan ekranlarda varsayılan ayarları seçili olarak bırakarak kurulumunuzu tamamlayabilirsiniz. 24 | 25 | Kurulum tamamlandıktan sonra Windows Başlangıç menüsünden _Git_ klasörü altındaki **Git Bash** uygulamasını çalıştırıp Git'in komut satırı arayüzünü kullanmaya başlayabilirsiniz. 26 | 27 | > Git'in kurulumunun sorunsuz gerçekleştiğini teyid etmek için **Git Bash**'i açıp **git --version** komutunu yazın. Bu komut ekrana Git'in versiyon bilgisini basar. Eğer hata alırsanız msysgit ana sayfasından sorunun giderilmesi için ne yapmanız gerektiğini öğrenebilirsiniz. 28 | 29 | ### Mac OS X 30 | 31 | İşletim sisteminiz Mac OS X ise Git kurulumu için iki yöntem kullanabilirsiniz. 32 | 33 | * Apple'in geliştirici araçlarını kurarak \(XCode\) Apple tarafından sağlanan Git dağıtımını kurabilirsiniz 34 | * [Git OS X Installer](https://code.google.com/p/git-osx-installer/downloads/list?can=3) paketini indirip Git'i kurabilirsiniz. 35 | 36 | Git kurulumunu tamamladıktan sonra Applications klasörü altındaki Terminal.app uygulamasını çalıştırın. 37 | 38 | > Spotlight'a _terminal_ yazarak da Terminal.app uygulamasını bulup çalıştırabilirsiniz 39 | 40 | Kurulumunuzu denetlemek için komut satırında **git --version** komutunu çalıştırın. Bu komut Git'in versiyonunu ekrana basar.Herhangi bir hata almanız durumunda kurulum yönteminize göre ilgili kaynakları araştırmanız gerekebilir. 41 | 42 | ### Git Konfigürasyonu 43 | 44 | Git'i kurduğumuza göre artık Git ile çalışmak için bazı ayarlar yapabiliriz. Bu ayarlar için Git bize **git config** isimli bir araç/komut sunar. Git ayarlarını bir defa yapmanız yeterli olacaktır. 45 | 46 | > Bu ayarları istediğiniz zaman değiştirebilirsiniz. 47 | 48 | Git ayarlarınız aşağıda belirtilen üç konumda kaydedilir ve hiyerarşik olarak bu konumlardan yüklenir 49 | 50 | 1. Seviye \(/etc/gitconfig dosyası\) : Tüm kullanıcı ve projeler için geçerli olan ayarlar bu dosyada kaydedilir. **git config** komutunu **--system** seçeneği ile çalıştırırsanız ayarlar bu dosyada kaydedilecek ve bu dosyadan okunacaktır 51 | 2. Seviye \(/.gitconfig dosyası\) : Sadece sizin kullanıcınız için tanımlanan ayarların kaydedildiği dosyadır. **git config** komutunu **--global** seçeneği ile çalıştırısanız ayarlar bu dosyaya kaydedilecek ve bu dosyadan okunacaktır 52 | 3. Seviye : Proje klasörünüzün \(projenizin Git ile versiyon kontrolüne alınmış olması gerekiyor\) altında yer alan **.git/config** dosyasında ise proje bazındaki git ayarlarınız yer alır. 53 | 54 | Git, ayarlarınızın değerini belirlemek için bu üç konumdaki dosyaları 3. seviye, 2. seviye ve 1. seviye sıralaması ile hiyerarşik olarak okur. Belirli bir ayar'a ilişkin değere ilk hangi seviyede rastlandıysa o seviyedeki değer dikkate alınır diğer seviyelerdeki değerler dikkate alınmaz. 55 | 56 | Windows'da global \(**git config --global** komutu\) git ayarlarınız Windows'un $HOME klasörü altında yer alan \(genellikle C:\Documents and Settings$USER\) **.config** dosyasında yer alır. Proje seviyesindeki ayarlarınız ise OS X'de olduğu gibi **\[Projenizin Ana Klasörü\].git\config** dosyasında kayıt altına alınır. 57 | 58 | ### Kullanıcı adınızı ve email bilgisi 59 | 60 | Git ayarlarından en önemli olanları kullanıcı adınız ve email adresinizdir. Git, ayar olarak tanımladığınız değerleri **commit** vb işlemlerde otomatik olarak kullanır. Bu ayarların değerini belirlemek için komut satırında aşağıdaki komutları çalıştırıyoruz 61 | 62 | ```text 63 | git config --global user.name "ali özgür" 64 | git config --global user.email "ali.ozgur@example.com" 65 | ``` 66 | 67 | Yukarıdaki komutlarda 68 | 69 | * **--global** seçeneği ile Git'e global ayarları düzenlediğinizi söylüyoruz 70 | * **user.name** \(ve user.email\) ile değerini değiştirmek istediğiniz ayarın anahtar'ını belirtiyoruz 71 | * Ardından da çift tırnak içinde ilgili ayarın değerini giriyoruz 72 | 73 | Bu ayarları **--global** ibaresi ile tüm projelerinizde geçerli olacak şekilde yaptık, proje seviyesinde bu ayarları yapmak için komut satırında \(terminal'de\) projenizin klasörüne konumlanıp **git config user.name "ali özgür"** komutu ile _--global_ seçeneğini kullanmadan yapabilirsiniz. 74 | 75 | Kendi yaptığımız veya kurulum ile hazır gelen ayarların değerlerini görmek için aşağıdaki komutları kullanabiliriz. 76 | 77 | * Global seviyede tüm ayarları listelemek için 78 | 79 | > **git config --global -l** 80 | 81 | * Global seviyede tek bir ayar'ın değerini \(örneğimizde user.name anahtarına sahip ayar\) görmek için ise 82 | 83 | > **git config --global user.name** 84 | 85 | İPUCU 86 | 87 | Git'in komutları ve bu komutların seçenek ve parametreleri ile ilgili yardım almak istediğinizde 88 | 89 | * git \[komut adı\] --help \(örneğin: git init --help\) 90 | * git help \[komut adı\] \(örneğin: git help init\) 91 | 92 | komutlarını kullanabilirsiniz. 93 | 94 | ### Editör ayarı 95 | 96 | Git'in bazı komutları sizden interaktif olarak yorum veya bilgi girmenizi ister. Bu tür durumlar için Git'in hangi metin düzenleme uygulamasını kullanacağını ayarlayabilirsiniz. Git varsayılan olarak [Vi](http://en.wikipedia.org/wiki/Vi) veya \[Vim\]\([http://en.wikipedia.org/wiki/Vim\_\(text\_editor](http://en.wikipedia.org/wiki/Vim_%28text_editor)\)\) kullanır. Ancak bu editörlerin kullanımı başlangıç seviyesindeki kullanıcılar için zor olabilir. Ben, Vi veya Vim ile karşılaştırıldığında kullanımının daha kolay olduğunu düşündüğüm [**GNU Midnight Commander \(MC\)**](https://www.midnight-commander.org/) kullanmanızı öneriyorum. 97 | 98 | Midnight Commander'i Mac OS X'e [Homebrew](http://brew.sh/) kullanarak 99 | 100 | ```text 101 | brew install midnight-commander 102 | ``` 103 | 104 | komutu ile kurabilirsiniz. 105 | 106 | Midnight Commander veya Git'i destekleyen editör kurulumunu tamamladıktan sonra 107 | 108 | ```text 109 | git config --global core.editor mcedit 110 | ``` 111 | 112 | ile Git'in kullanacağı editör ayarınızı yapabilirsiniz. 113 | 114 | ### Diff aracı ayarları 115 | 116 | Diff kavramını ilerleyen bölümlerimizde daha ayrıntılı ele alacağız, ancak kısaca değinmek gerekirse 117 | 118 | > Bir dosyanın Tx anındaki içeriği ile Ty anındaki içeriğinin arasındaki farkları tespit etme ve gösterme işlemidir. İngilizcede **difference** \(fark\) kelimesinin kısaltması olan **diff** şeklide kullanılır. 119 | 120 | Bu işlemi göz ile yapmak zorunda kalmadan dosyalar ve/veya klasörler arasındaki farkları tespit etmek ve görselleştirmek için kullanılan araçlara genel olarak Diff Araçları ismi verilir. 121 | 122 | Ben, Mac OS X üzerinde ücretsiz bir uygulama olan **SourceGear DiffMerge** kullanmayı tercih ediyorum. Git'in diff aracı olarak SourceGear DiffMerge'i kullanmasını sağlamak için 123 | 124 | ```text 125 | git config --global merge.tool diffmerge 126 | ``` 127 | 128 | komutu ile ayar yapabilirsiniz. DiffmMerge'in OS X'de tam olarak ayarlarının nasıl yapılacağını öğrenmek için [bu linkte](http://twobitlabs.com/2011/08/install-diffmerge-git-mac-os-x/) göz atabilirsiniz. 129 | 130 | Windows'da ise yine ücretsiz bir uygulama olan [WinMerge](http://winmerge.org/downloads/) veya ücretli bir uygulama olan [Araxis Merge'i](http://www.araxis.com/merge/download.en) kullanılabilir. Bu araçların Git ayarlarının nasıl yapılacağını yardım dokümanlarından faydalanarak öğrenebilirsiniz. 131 | -------------------------------------------------------------------------------- /content/versiyon_kontrolune_giris/projeniz_uzerinde_calismaya_baslayalim.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: content 3 | --- 4 | 5 | # Projemiz Üzerinde Çalışmaya Başlayalım 6 | 7 | Üzerinde çalışacağımız projenin dosyaları artık yerel diskimizde yer aldığına göre projemiz ile ilgili normal çalışmamıza başlayabiliriz. 8 | 9 | > Projenizi ister local bir proje olarak oluşturmuş olun isterseniz remote bir repository'yi klonlamış olun tüm değişiklikleriniz yerel diskinizde gerçekleşecek ve **commit’leriniz** ile oluşturacağınız tüm versiyonlar git tarafından yerel diskinizdeki .git klasöründe takip edilecektir. İlerleyen bölümlerde ayrıntılı olarak ele alacağımız **git push** komutunu çalıştırmadığınız sürece yaptığınız değişiklikler sadece yerel diskinizde kayıt altına alınır. 10 | 11 | ## Dosya Durumları 12 | 13 | Git'de dosyalarınız genel olarak iki durumda olabilir 14 | 15 | * Untracked \(Takip Edilmeyen\): Bu dosyalar versiyon kontrolü altında olmayan veya sizin henüz versiyon kontrolü yapmak için git'e eklemediğiniz dosyalardır. Bu dosyalardaki değişiklikler siz dosyaları git'e eklemediğiniz sürece versiyon kontrolüne tabi değildir 16 | * Tracked \(Takip Edilen\): Bu dosyalar ise git'in versiyon kontrolü takibi altında olan dosyalardır. Bu dosyalar üzerinde yapacağınız tüm değişiklikler git tarafından takip edilmektedir. 17 | 18 | ## Staging Area 19 | 20 | Çoğu versiyon kontrol sisteminde değişiklikleriniz iki yerde kaydedilir 21 | 22 | * Yerel diskinizdeki çalışma klasörünüz \(working folder\) veya 23 | * Versiyon kontrol sisteminin veri tabanı 24 | 25 | Ancak git'de değişikliklerinizin kayıt altına alındığı üçüncü bir alan daha vardır ki buna **Staging Area** denir ve git'in en temel kavramlarından birisidir. Staging Area'yı, proje dosyalarımızdaki bir dizi değişikliği remote repository'ye göndermeden önce kayıt altında tuttuğunuz veri tabanı/alan olarak tanımlayabiliriz. 26 | 27 | Versiyon Kontrolünün Altın Kuralları 28 | 29 | \#1 Sadece Birbiri İle Alakalı Değişiklikleri Commit Edin 30 | 31 | Değişikliklerinizi commit etmeye karar verdiğinizde birbiri ile alakalı değişiklikleri tek bir commit olarak ele almaya özen gösterin. Birbiri ile alakalı olmayan değişiklikleri aynı commit ile versiyon kontrol sisteminde kayıt altına aldığınızda aşağıdakilere benzer sorunlar yaşama ihtimaliniz artacaktır 32 | 33 | * Commit’inizdeki değişiklikleri inceleyen ekip arkadaşlarınız yaptığınız değişikliklerden hangisinin hangi konu ile ilgili olduğunu anlamakta güçlük çekeceklerdir. 34 | * Alakalı alakasız değişiklikler tek bir commit içinde yer aldığı için herhangi bir nedenle belirli ve tek bir değişikliği geri almakta güçlük çekeceksiniz. 35 | 36 | Alakalı alakasız değişiklikleri tek bir commit ile ele almak yerine örneğin iki ayrı sorunu gidermek için yaptığınız değişiklikler iki ayrı commit ile kayıt altına alınmalı veya daha büyük bir özellik üzerinde çalışırken bu özelliği oluşturan ve anlamsal bir bütün olarak ifade edilen daha küçük özellikleri de ayrı commit’ler ile kayıt altına almalısınız. 37 | 38 | Projeniz üzerinde çalışırken belirli bir zaman aralığında yaptığınız değişikliklerin tamamının aynı konu veya özellikle ilgili olması mümkün olmayacaktır. Tam da bu noktada **Staging Area** mekanizmasının güzelliği ortaya çıkar, çünkü git hangi değişikliğinizin Staging Area'ya gideceğine karar vermeniz için sizin devreye girmenizi ister. Daha önce de belirttiğimiz gibi yaptığınız değişiklikler git tarafından otomatik takip edilmez, bunun yerine git tüm değişiklikleri sizin gözden geçirerek kontrollü bir şekilde Staging Area'ya almanızı ister. 39 | 40 | ## Yaptığınız Değişiklikleri Listelemek 41 | 42 | Son commit işleminizden sonra proje dosyalarınızda yaptığınız değişiklikleri listelemek için **git status** komutunu kullanabilirsiniz. 43 | 44 | ![git status](/.gitbook/assets/03_gitstatus.jpg) Yukarıdaki terminal ekran görüntüsünde de görebileceğiniz gibi git oldukça ayrıntılı durum bilgisi sunmaktadır. **git status** komutu ile git aşağıdaki 3 ana grupta yer alan dosyaları size listeler 45 | 46 | * Changes to be committed \(Commit edilmeye hazır dosyalar\): Bu gruptaki dosyalar **git add** veya **git rm** komutu ile Staging Area'ya eklediğimiz dosyalardır. Bu dosyalar bir sonraki commit'imizin içinde yer alacaktır 47 | * Changes not staged for commit \(Commit için henüz hazır olmayan dosyalar\): Bu gruptaki dosyalar değişiklik yaptığımız fakat henüz Staging Area'ya eklemediğimiz dosyalardır. Bu dosyalar bir önceki grubun içine eklemediğimiz sürece bir sonraki commit'e dahil olmayacaklarıdır 48 | * Untracked files \(Versiyon takibinde olmayan dosyalar\): Bu gruptaki dosyalar ise henüz versiyon kontrolü altına almadığımız dosyalardır. 49 | 50 | ## "git add" ve "git rm" komutları 51 | 52 | Bir önceki başlıkta değindiğimiz ve **git status** komutu sonrasında git'in bize özetlediği 3 gruptan son ikisinde yer alan dosyaların ilk gruba dahil edilmesi için **git add** ve **git rm** komutlarını kullanabiliriz. 53 | 54 | Aşağıda oluşturduğumuz **git add** komutu ile **baslik\_2.md** ve **baslik\_2\_1.md** dosyaları ile **resimler** klasörü altındaki tüm dosyaların Staging Area'ya eklenmesini sağlayabiliriz. 55 | 56 | > $ **git add** baslik\_2.md baslik\_2\_1.md resimler/\* 57 | 58 | Benzer şekilde aşağıdaki **git rm** komutu ile **ornek2.md** dosyasının bir sonraki commit’imizde yer almayacağını belirtebiliriz. 59 | 60 | > $ **git rm** ornek2.md 61 | 62 | ## Değişikliklerimizi Commit Edelim 63 | 64 | Değişikliklerinizi **git add** ve **git rm** ile Staging Area'ya aldıktan sonra **git commit** komutu ile yeni bir versiyon olarak kayıt altına alabilirsiniz. 65 | 66 | > $ **git commit** -m "1.7 numaralı alt başlık içeriği tamamlandı" 67 | 68 | Yukarıdaki komutta yer alan **-m** parametresi ile yaptığınız değişiklikleri özetleyen bir mesajı da commit'inize ekleyebilirsiniz. Eğer birden fazla satırı olan bir commit mesajı gireceksiniz **-m** parametresini kaldırmanız yeterli olacaktır. Bu durumda 1.3 numaralı bölümde ayarladığınız editör açılır ve bu editöre mesajınızı istediğimiz uzunlukta girebilirsiniz. 69 | 70 | Versiyon Kontrolünün Altın Kuralları 71 | 72 | \#2 Anlamlı Commit Mesajları 73 | 74 | Commit işlemi sırasında yazacağınız bilgilendirici bir mesaj hem ekibinizdeki diğer kişilerin hem de daha sonra kendinizin yapılan değişikliği daha rahat ve hızlı anlamanızı sağlayacaktır. Mesajınıza kısa bir özet satırı yazdıktan sonra bir sonraki satırda da değişikliğin nedeni ve içeriği hakkında bilgi verebilirsiniz. 75 | 76 | ### İyi Bir Commit Nasıl Olmalı? 77 | 78 | 1. Commit'inizde sadece kavramsal olarak ilişkili değişiklikleri içermeye özen göstermelisiniz. Zaman zaman iki farklı konu veya sorun ile ilgili aynı anda veya çok kısa aralıklarla değişimli olarak çalışmak zorunda kalabilirsiniz. Bu şekilde yapılan bir çalışma sonrasında commit zamanı geldiğinde mümkün ise iki konu ile ilgili değişikliklerinizi bir defada commit etmek yerine iki defada ayrı ayrı commit edin. Bu çok zor oluyorsa kısa yoldan bir anda tek bir değişikliğe odaklanmayı da düşünebilirsiniz. 79 | 2. Tamamlanmamış değişikliklerinizi kesinlikle commit etmemeye özen gösterin. Eğer zaman zaman değişikliklerinizi kayıt altına almak istiyorsanız commit işlemi yerine Git'in **Stash** özelliğini/komutunu kullanabilirsiniz. 80 | 3. Test edilmemiş değişiklikleri commit etmemeye özen gösterin. Bu öneri aslında bir önceki önerimiz ile pratikte aynı anlama geliyor 81 | 4. Commit'leriniz kısa ve açıklayıcı mesajlar içermeli. 82 | 5. Son olarak da sık sık commit işlemi yapmayı alışkanlık haline getirmenizi önerebiliriz. Bu alışkanlık ile birlikte yukarıdaki maddeleri de yerine getirebilirseniz iş yapma şekliniz ve konsantrasyonunuz da olumlu yönde etkilenecektir. 83 | 84 | ## Commit Tarihçesi 85 | 86 | Git projeniz üzerinde çalıştığınız her anda yaptığınız commit işlemlerini kayıt altına almaktadır. Özellikle ekip çalışması söz konusu ise commit işlemleri ile ilgili git tarafından kayıt altına alınan bu bilgiler daha da önem kazanmaktadır. 87 | 88 | Git'in commit’leriniz ile ilgili kayıt altına aldığı tarihsel bilgileri görmek için **git log** komutunu kullanıyoruz. Bu komut tüm commit’ler ile ilgili bilgileri, en son commit en üstte olacak şekilde, tarihsel olarak sıralar. Eğer Terminal pencerenize sığmayacak kadar çok tarihsel kayıt var ise son satırda **:** simgesi yer alacaktır, klavyenizden **SPACE/BOŞLUK** tuşuna basarak bir sonraki sayfanın listelenmesini **q** tuşuna basarak da listelemenin sonlandırılmasını sağlayabilirsiniz. 89 | 90 | ![Commit Tarihçesi](/.gitbook/assets/04_gitlog.jpg) 91 | 92 | Terminal'de listelenen her commit tarihçesi kaydı, diğer bilgilerin yanı sıra, aşağıdaki temel bilgileri içerir 93 | 94 | * Commit'in Hash değeri 95 | * Commit'i gerçekleştiren kişinin adı ve email'i 96 | * Commit tarihi 97 | * Commit mesajı 98 | 99 | > **Commit Hash** : Her bir commit'in benzersiz ve tek bir tanımlayıcı değeri vardır. Bu değer git tarafından commit'e dahil olan tüm değişiklikleriniz ve commit'in kendisi ile ilgili bilgiler de kullanılarak otomatik hesaplanır. Genel olarak git'in listelemelerinde ve bazı komutların parametresi olarak bu değerin ilk 7 karakterinin kullanılması yeterlidir. Çünkü bu ilk 7 karakterin de nerdeyse benzersiz ve tekil olduğunu söyleyebiliriz. 100 | 101 | git log komutu ile birlikte commit işlemi ile ilgili bilgilendirici çoğu bilgiyi görmekle birlikte parametre olarak **-p** değerini kullanırsanız dosyalarda yapılan değişiklikler de ayrıntılı olarak listelenecektir. 102 | 103 | ![Commit Tarihçesi Değişiklik Ayrıntıları](/.gitbook/assets/05_gitlog_p.jpg) 104 | 105 | Kitabımızın ilerleyen bölümlerinde **git log -p** komutu ile gördüğümüz bilgileri nasıl yorumlayacağımızı ayrıntılı olarak ele alacağız. 106 | --------------------------------------------------------------------------------