git - Der einfache Einstieg
29 |eine einfache Anleitung, um git zu lernen. Kein Schnick-Schnack ;)
30 | Tweet 31 | 32 | 56 |
57 | eine einfache Anleitung, um git zu lernen. Kein Schnick-Schnack ;)
30 | Tweet 31 | 32 | 56 |
57 | 63 | git für OS X herunterladen 64 |
65 |66 | git für Windows herunterladen 67 |
68 |69 | git für Linux herunterladen 70 |
71 |
76 | erstelle ein neues Verzeichnis, öffne es und führe
77 | git init
78 | aus, um ein neues git-Repository anzulegen.
79 |
85 | erstelle eine Arbeitskopie, indem du folgenden Befehl ausführst:
86 | git clone /pfad/zum/repository
87 | Falls du ein entferntes Repository verwendest, benutze:
88 | git clone benutzername@host:/pfad/zum/repository
89 |
95 | Dein lokales Repository besteht aus drei "Instanzen", die von git verwaltet werden.
96 | Die erste ist deine Arbeitskopie, welche die echten Dateien enthält.
97 | Die zweite ist der Index, welcher als Zwischenstufe agiert und
98 | zu guter Letzt noch der HEAD, der auf deinen letzten Commit zeigt.
99 |
101 |
106 | Du kannst Änderungen vorschlagen (zum Index hinzufügen) mit
107 | git add <dateiname>
108 | git add *
109 | Das ist der erste Schritt im git workflow, du bestätigst deine Änderungen mit:
110 | git commit -m "Commit-Nachricht"
111 | Jetzt befindet sich die Änderung im HEAD, aber noch nicht im entfernten Repository.
112 |
118 | Die Änderungen sind jetzt im HEAD deines lokalen Repositories. Um die Änderungen an dein entferntes Repository zu senden, führe:
119 | git push origin master
120 | aus. Du kannst master auch mit einem beliebigen anderen Branch ersetzen, mehr über Branches erfährst du später.
121 |
122 | Wenn du dein lokales Repository nicht von einem entfernten geklont hast und du diese aber mit einem anderen Repository verbinden möchtest, musst du dieses mit
123 | git remote add origin <server>
124 | hinzufügen. Jetzt bist du bereit, deine Änderungen hochzuladen
125 |
131 | Branches werden benutzt, um verschiedene Funktionen isoliert voneinander zu entwickeln. Der master-Branch ist der "Standard"-Branch, wenn du ein neues Repository erstellst. Du solltest aber für die Entwicklung andere Branches verwenden und diese dann in den Master-Branch zusammenführen (mergen). Auch das lernst du später. 132 |
133 |
134 |
135 | Erstelle einen neuen Branch mit dem Namen "feature_x" und wechsle zu diesem:
136 | git checkout -b feature_x
137 | Um zum Master zurück zu wechseln:
138 | git checkout master
139 | Und um den eben erstellten Branch wieder zu löschen:
140 | git branch -d feature_x
141 | Ein Branch ist nicht für andere verfügbar, bis du diesen in dein entferntes Repository hochlädst:
142 | git push origin <branch>
143 |
149 | Um dein lokales Repository mit den neuesten Änderungen zu aktualisieren, verwende:
150 | git pull
151 | in deiner Arbeitskopie, um die Änderungen erst herunterzuladen (fetch) und dann mit deinem Stand zusammenzuführen (merge).
152 | Wenn du einen anderen Branch mit deinem aktuellen (z.B. master) zusammenführen willst, benutze:
153 | git merge <branch>
154 | In beiden Fällen versucht git die Änderungen automatisch zusammenzuführen. Unglücklicherweise ist dies nicht immer möglich und endet in Konflikten.
155 | Du bist verantwortlich, diese Konflikte durch manuelles Editieren der betroffenen Dateien zu lösen.
156 | Bist du damit fertig, musst du das git mit folgendem Befehl mitteilen:
157 | git add <dateiname>
158 | Bevor du Änderungen zusammenführst, kannst du dir die Differenzen auch anschauen:
159 | git diff <quell_branch> <ziel_branch>
160 |
166 | Es wird empfohlen, für Software Releasestags zu verwenden. Dies ist ein bekanntes Konzept, das es schon mit SVN gab. Du kannst einen neuen Tag namens 1.0.0 mit folgendem Befehl erstellen:
167 | git tag 1.0.0 1b2e1d63ff
168 | 1b2e1d63ff steht für die ersten 10 Zeichen der Commit-Id, die du mit deinem Tag referenzieren möchtest. Du erhältst die Liste der Commit-IDs mit:
169 | git log
170 | Du kannst auch weniger Zeichen verwenden, es muss einfach eindeutig sein.
171 |
177 | Falls du mal etwas falsch machst (was natürlich nie passiert ;) ) kannst du die lokalen Änderungen mit:
178 | git checkout -- <filename>
179 | auf den letzten Stand im HEAD zurücksetzen. Änderungen, die du bereits zum Index hinzugefügt hast, bleiben bestehen.
180 |
182 | Wenn du aber deine lokalen Änderungen komplett entfernen möchtest, holst du dir den letzten Stand vom entfernten Repository mit folgenden Befehlen:
183 | git fetch origin
184 | git reset --hard origin/master
185 |
191 | Eingebaute git-GUI:
192 | gitk
193 | Farbige Konsolenausgabe:
194 | git config color.ui true
195 | Eine Zeile pro Commit in der Logausgabe:
196 | git config format.pretty oneline
197 | Interaktives Hinzufügen von Änderungen:
198 | git add -i
199 |
206 |
216 |
just a simple guide for getting started with git. no deep shit ;)
16 | Tweet 17 | 18 | 42 | 43 |
44 | 50 | Download git for OSX 51 |
52 |53 | Download git for Windows 54 |
55 |56 | Download git for Linux 57 |
58 |
63 | create a new directory, open it and perform a
64 | git init
65 | to create a new git repository.
66 |
72 | create a working copy of a local repository by running the command
73 | git clone /path/to/repository
74 | when using a remote server, your command will be
75 | git clone username@host:/path/to/repository
76 |
82 | your local repository consists of three "trees" maintained by git.
83 | the first one is your Working Directory which holds the actual files.
84 | the second one is the Index which acts as a staging area and
85 | finally the HEAD which points to the last commit you've made.
86 |
88 |
93 | You can propose changes (add it to the Index) using
94 | git add <filename>
95 | git add *
96 | This is the first step in the basic git workflow. To actually commit these changes use
97 | git commit -m "Commit message"
98 | Now the file is committed to the HEAD, but not in your remote repository yet.
99 |
105 | Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute
106 | git push origin master
107 | Change master to whatever branch you want to push your changes to.
108 |
109 | If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
110 | git remote add origin <server>
111 | Now you are able to push your changes to the selected remote server
112 |
113 |
119 | Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion. 120 |
121 |
122 |
123 | create a new branch named "feature_x" and switch to it using
124 | git checkout -b feature_x
125 | switch back to master
126 | git checkout master
127 | and delete the branch again
128 | git branch -d feature_x
129 | a branch is not available to others unless you push the branch to your remote repository
130 | git push origin <branch>
131 |
137 | to update your local repository to the newest commit, execute
138 | git pull
139 | in your working directory to fetch and merge remote changes.
140 | to merge another branch into your active branch (e.g. master), use
141 | git merge <branch>
142 | in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts.
143 | You are responsible to merge those conflicts
144 | manually by editing the files shown by git. After changing, you need to mark them as merged with
145 | git add <filename>
146 | before merging changes, you can also preview them by using
147 | git diff <source_branch> <target_branch>
148 |
154 | it's recommended to create tags for software releases. this is a known concept, which also exists in SVN. You can create a new tag named 1.0.0 by executing
155 | git tag 1.0.0 1b2e1d63ff
156 | the 1b2e1d63ff stands for the first 10 characters of the commit id you want to reference with your tag. You can get the commit id by looking at the...
157 |
163 | in its simplest form, you can study repository history using..
164 | git log
165 | You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain author:
166 | git log --author=bob
167 | To see a very compressed log where each commit is one line:
168 | git log --pretty=oneline
169 | Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches:
170 | git log --graph --oneline --decorate --all
171 | See only which files have changed:
172 | git log --name-status
173 | These are just a few of the possible parameters you can use. For more, see
174 | git log --help
175 |
181 | In case you did something wrong, which for sure never happens ;), you can replace local changes using the command
182 | git checkout -- <filename>
183 | this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.
184 |
186 | If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this
187 | git fetch origin
188 | git reset --hard origin/master
189 |
195 | built-in git GUI
196 | gitk
197 | use colorful git output
198 | git config color.ui true
199 | show log on just one line per commit
200 | git config format.pretty oneline
201 | use interactive adding
202 | git add -i
203 |
210 |
220 |
230 |
una guía sencilla para comenzar con git. sin complicaciones ;)
26 | Tweet 27 | 28 | 52 |
53 | 59 | Descarga git para OSX 60 |
61 |62 | Descarga git para Windows 63 |
64 |65 | Descarga git para Linux 66 |
67 |
72 | Crea un directorio nuevo, ábrelo y ejecuta
73 | git init
74 | para crear un nuevo repositorio de git.
75 |
81 | Crea una copia local del repositorio ejecutando
82 | git clone /path/to/repository
83 | Si utilizas un servidor remoto, ejecuta
84 | git clone username@host:/path/to/repository
85 |
91 | Tu repositorio local esta compuesto por tres "árboles" administrados por git.
92 | El primero es tu Directorio de trabajo que contiene los archivos,
93 | el segundo es el Index que actua como una zona intermedia, y el último es el
94 | HEAD que apunta al último commit realizado.
95 |
97 |
102 | Puedes registrar cambios (añadirlos al Index) usando
103 | git add <filename>
104 | git add .
105 | Este es el primer paso en el flujo de trabajo básico. Para hacer commit a estos cambios usa
106 | git commit -m "Commit message"
107 | Ahora el archivo esta incluído en el HEAD, pero aún no en tu repositorio remoto.
108 |
114 | Tus cambios están ahora en el HEAD de tu copia local. Para enviar estos cambios a tu repositorio remoto ejecuta
115 | git push origin master
116 | Reemplaza master por la rama a la que quieres enviar tus cambios.
117 |
118 | Si no has clonado un repositorio ya existente y quieres conectar tu repositorio local a un repositorio remoto, usa
119 | git remote add origin <server>
120 | Ahora podrás subir tus cambios al repositorio remoto seleccionado.
121 |
122 |
128 | Las ramas son utilizadas para desarrollar funcionalidades aisladas unas de otras. La rama master es la rama "por defecto" cuando creas un repositorio. Crea nuevas ramas durante el desarrollo y fusiónalas a la rama principal cuando termines. 129 |
130 |
131 |
132 | Crea una nueva rama llamada "feature_x" y cámbiate a ella usando
133 | git checkout -b feature_x
134 | vuelve a la rama principal
135 | git checkout master
136 | y borra la rama
137 | git branch -d feature_x
138 | Una rama nueva no estará disponible para los demás a menos que subas (push) la rama a tu repositorio remoto
139 | git push origin <branch>
140 |
146 | Para actualizar tu repositorio local al commit más nuevo, ejecuta
147 | git pull
148 | en tu directorio de trabajo para bajar y fusionar los cambios remotos.
149 | Para fusionar otra rama a tu rama activa (por ejemplo master), utiliza
150 | git merge <branch>
151 | en ambos casos git intentará fusionar automáticamente los cambios. Desafortunadamente, no siempre será posible y se podrán producir conflictos.
152 | Tú eres responsable de fusionar esos conflictos
153 | manualmente al editar los archivos mostrados por git. Después de modificarlos, necesitas marcarlos como fusionados con
154 | git add <filename>
155 | Antes de fusionar los cambios, puedes revisarlos usando
156 | git diff <source_branch> <target_branch>
157 |
163 | Se recomienda crear etiquetas para cada nueva versión publicada de un software. Este concepto no es nuevo, ya que estaba disponible en SVN. Puedes crear una nueva etiqueta llamada 1.0.0 ejecutando
164 | git tag 1.0.0 1b2e1d63ff
165 | 1b2e1d63ff se refiere a los 10 caracteres del commit id al cual quieres referirte con tu etiqueta. Puedes obtener el commit id con
166 | git log
167 | también puedes usar menos caracteres que el commit id, pero debe ser un valor único.
168 |
174 | En caso de que hagas algo mal (lo que seguramente nunca suceda ;) puedes reemplazar cambios locales usando el comando
175 | git checkout -- <filename>
176 | Este comando reemplaza los cambios en tu directorio de trabajo con el último contenido de HEAD. Los cambios que ya han sido agregados al Index, así como también
177 | los nuevos archivos, se mantendrán sin cambio.
178 |
180 | Por otro lado, si quieres deshacer todos los cambios locales y commits, puedes traer la última versión del servidor y apuntar a tu copia local principal de esta forma
181 | git fetch origin
182 | git reset --hard origin/master
183 |
189 | Interfaz gráfica por defecto
190 | gitk
191 | Colores especiales para la consola
192 | git config color.ui true
193 | Mostrar sólo una línea por cada commit en la traza
194 | git config format.pretty oneline
195 | Agregar archivos de forma interactiva
196 | git add -i
197 |
204 |
214 |
juste un petit guide pour bien démarrer avec git. no deep shit ;)
33 | Tweet 34 | 43 | 66 |
67 | 73 | Télécharger git pour Mac OSX 74 |
75 |76 | Télécharger git pour Windows 77 |
78 |79 | Télécharger git pour Linux 80 |
81 |
86 | créez un nouveau dossier, ouvrez le et exécutez la commande
87 | git init
88 | pour créer un nouveau dépôt.
89 |
95 | créez une copie de votre dépôt local en exécutant la commande
96 | git clone /path/to/repository
97 | si vous utilisez un serveur distant, cette commande sera
98 | git clone username@host:/path/to/repository
99 |
105 | votre dépôt local est composé de trois "arbres" gérés par git.
106 | le premier est votre espace de travail qui contient réellement vos fichiers.
107 | le second est un Index qui joue un rôle d'espace de transit pour vos fichiers et
108 | enfin HEAD qui pointe vers la dernière validation que vous ayez faite.
109 |
111 |
116 | Vous pouvez proposer un changement (l'ajouter à l'Index) en exécutant les commandes
117 | git add <filename>
118 | git add *
119 | C'est la première étape dans un workflow git basique. Pour valider ces changements, utilisez
120 | git commit -m "Message de validation"
121 | Le fichier est donc ajouté au HEAD, mais pas encore dans votre dépôt distant.
122 |
128 | Vos changements sont maintenant dans le HEAD de la copie de votre dépôt local. Pour les envoyer à votre dépôt distant, exécutez la commande
129 | git push origin master
130 | Remplacez master par la branche dans laquelle vous souhaitez envoyer vos changements.
131 |
132 | Si vous n'avez pas cloné votre dépôt existant et voulez le connecter à votre dépôt sur un serveur distant, vous devez l'ajouter avec
133 | git remote add origin <server>
134 | Maintenant, vous pouvez envoyer vos changements vers le serveur distant sélectionné
135 |
136 |
142 | Les branches sont utilisées pour développer des fonctionnalités isolées des autres. 143 | La branche master est la branche par défaut quand vous créez un dépôt. 144 | Utilisez les autres branches pour le développement et fusionnez ensuite à la branche principale quand vous avez fini. 145 |
146 |
147 |
148 | créer une nouvelle branche nommée "feature_x" et passer dessus pour l'utiliser
149 | git checkout -b feature_x
150 | retourner sur la branche principale
151 | git checkout master
152 | et supprimer la branche
153 | git branch -d feature_x
154 | une branche n'est pas disponible pour les autres tant que vous ne l'aurez pas envoyée vers votre dépôt distant
155 | git push origin <branch>
156 |
162 | pour mettre à jour votre dépôt local vers les dernières validations, exécutez la commande
163 | git pull
164 | dans votre espace de travail pour récupérer et fusionner les changements distants.
165 | pour fusionner une autre branche avec la branche active (par exemple master), utilisez
166 | git merge <branch>
167 | dans les deux cas, git tente d'auto-fusionner les changements. Malheureusement, ça n'est pas toujours possible et résulte par des conflits.
168 | Vous devez alors régler ces conflits
169 | manuellement en éditant les fichiers indiqués par git. Après l'avoir fait, vous devez les marquer comme fusionnés avec
170 | git add <filename>
171 | après avoir fusionné les changements, vous pouvez en avoir un aperçu en utilisant
172 | git diff <source_branch> <target_branch>
173 |
179 | il est recommandé de créer des tags pour les releases de programmes. c'est un concept connu, qui existe aussi dans SVN. Vous pouvez créer un tag nommé 1.0.0 en exécutant la commande
180 | git tag 1.0.0 1b2e1d63ff
181 | le 1b2e1d63ff désigne les 10 premiers caractères de l'identifiant du changement que vous voulez référencer avec ce tag. Vous pouvez obtenir cet identifiant avec
182 | git log
183 | vous pouvez utiliser moins de caractères de cet identifiant, il doit juste rester unique.
184 |
190 | Dans le cas où vous auriez fait quelque chose de travers (ce qui bien entendu n'arrive jamais ;) vous pouvez annuler les changements locaux en utilisant cette commande
191 | git checkout -- <filename>
192 | cela remplacera les changements dans votre arbre de travail avec le dernier contenu du HEAD. Les changements déjà ajoutés à l'index, aussi bien les nouveaux fichiers, seront gardés.
193 |
195 | Si à la place vous voulez supprimer tous les changements et validations locaux, récupérez le dernier historique depuis le serveur et pointez la branche principale locale dessus comme ceci
196 | git fetch origin
197 | git reset --hard origin/master
198 |
204 | Interface git incluse
205 | gitk
206 | utiliser des couleurs dans la sortie de git
207 | git config color.ui true
208 | afficher le journal sur une seule ligne pour chaque validation
209 | git config format.pretty oneline
210 | utiliser l'ajout interactif
211 | git add -i
212 |
219 |
230 |
64 | دانلود گیت برای مک 65 |
66 |67 | دانلود گیت برای ویندوز 68 |
69 |70 | دانلود گیت برای لینوکس 71 |
72 |
77 | پوشۀ جدیدی بسازید؛ واردش شوید و دستورِ
78 | git init
79 | را اجرا کنید تا یک مخزن جدید (Git Repository) ساخته شود.
80 |
86 | با اجرای دستور زیر میتوانید یک نسخۀ کپی از مخزن محلی ایجاد کنید
87 | کپی یا کلون: git clone /path/to/repository
88 | برای کپیِ مخزنی که در سرور قرار گرفته دستور پایین را اجرا کنید:
89 | git clone username@host:/path/to/repository
90 |
96 | مخزن محلی شامل سه «درخت» است که توسط گیت نگهداری میشود:
97 | اولی Working Directory است که مسئول نگهداری فایلهای واقعی پروژه است؛
98 | دومی ایندکس (Index) است که نقش منطقه شروع عملیات (Staging area) را بازی میکند؛
99 | و آخری هِد (HEAD) که به آخرین کامیتِ ارسالی (commit) اشاره میکند.
100 |
102 |
107 | میتوانید با دستور زیر فایلها را به ایندکس اضافه کنید:
108 | git add <filename>
109 | git add *
110 | این اولین قدمِ یک گردش کار ساده در گیت محسوب میشود. برای ارسال واقعی تغییرات از دستور پایین استفاده کنید:
111 | git commit -m "Commit message"
112 | اکنون فایلهای مورد نظر در هِد قرار گرفتهاند؛ ولی هنوز به سرور ارسال نشدهاند.
113 |
119 | برای ارسال تغییرات به سرورِ ریموت دستور زیر را اجرا کنید:
120 | git push origin master
121 | به جای مَستر (master)، اسم شاخهای (branch) را وارد کنید که میخواهید تغییراتش را ارسال کنید.
122 |
123 | اگر هیچ مخزن محلیای را کلون نکرده بودید میتوانید با دستور پایین مخزن محلیتان را به مخزن ریموت متصل کنید:
124 | git remote add origin <server>
125 | حالا میتوانید تغییرات را به کمک ریموت ساخته شده به سرور ارسال نمایید.
126 |
127 |
133 | شاخهها برای افزودن فیچرهای جدید در مسیری مجزا به کار میروند. هنگام ساخت یک مخزن جدید، شاخۀ مستر به عنوان شاخۀ پیشفرض در نظر گرفته میشود. هر شاخه به صورت مجزا توسعه مییابد و بعد از اتمام کار با شاخۀ مستر ترکیب میشود. 134 |
135 |
136 |
137 | با دستور زیر شاخهای به نام "feature_x" ساخته شده و به آن سوئیچ میشود:
138 | git checkout -b feature_x
139 | بازگشت به شاخۀ مستر:
140 | git checkout master
141 | حذف شاخه:
142 | git branch -d feature_x
143 | تا زمانی که شاخهای را به سرور پوش نکنید، سایر افراد به آن دسترسی ندارند.
144 | git push origin <branch>
145 |
151 | برای اینکه مخزن محلی خود را به آخرین کامیت بروز کنید، دستور
152 | git pull
153 | را در پوشه محلی (فولدر پروژه روی سیستمتان) اجرا کنید تا تغییرات مخزن ریموت (واقع روی سرور)،
دریافت (fetch) و ادغام (merge) شوند. برای ادغام یک شاخۀ دیگر با شاخۀ کنونی (مثلاً master)، از دستور زیر استفاده کنید:
154 | git merge <branch>
155 | گیت در هر دو حال تلاش میکند تغییرات را به صورت خودکار ادغام کند ولی این کار همیشه میسر نیست چون ممکن است به تداخل (conflict) منجر شود.
156 | تداخلها را باید خودتان به صورتی دستی برطرف نمایید و سپس عمل ادغام را انجام دهید. پس از ویرایش باید با دستور زیر، آنها را به عنوان «ادغام شده» علامت بزنید:
157 | git add <filename>
158 | قبل از ادغام تغییرات، پیشنمایش آن را میتوانید با دستور زیر ببینید
159 | git diff <source_branch> <target_branch>
160 |
166 | معمولاً به هر نسخه از برنامه، شمارهای اختصاص میدهند که در گیت به آن تگ گفته میشود. این موضوع در سایر سیستمهای کنترل نسخه مانند سابورژن (SVN) نیز وجود دارد.
167 |
168 | میتوانید با دستور زیر برچسبی به نام 1.0.0 بسازید:
169 | git tag 1.0.0 1b2e1d63ff
170 | عبارت 1b2e1d63ff، اولین ده کاراکتر شناسۀ (ID) کامیتی است که میخواهید برچسبگذاری کنید. میتوانید شناسه کامیت را با جستجو در لاگ پیدا کنید...
171 |
177 | در سادهترین حالت، تاریخچه مخزن با دستور زیر نمایش داده میشود:
178 | git log
179 | میتوانید کلی پارامتر دیگر هم به این دستور اضافه کنید تا بشود آن چیزی که میخواهید. دیدن کامیتهای یک شخص خاص:
180 | git log --author=bob
181 | دیدن کامیتها به صورت مختصر؛ هر کدام در یک خط:
182 | git log --pretty=oneline
183 | یا شاید بخواهید درخت اسکی (ASCII) همه شاخهها را که با نام شاخه و برچسبها تزئین شده ببینید:
184 | git log --graph --oneline --decorate --all
185 | فقط مشاهدۀ فایلهای تغییر یافته:
186 | git log --name-status
187 | موارد بالا فقط گوشهای از پارامترها بودند. برای اطلاعات بیشتر، دستور پایین را وارد کنید:
188 | git log --help
189 |
195 | در صورتی که مرتکب اشتباهی شدید، تغییرات محلی را میتوانید با دستور پایین جایگزین کنید:
196 | git checkout -- <filename>
197 | این دستور، تغییرات working directory (فولدر پروژه روی سیستم) را با آخرین محتوایی که هِد به آن اشاره میکند جایگزین میکند. البته فایلهای جدید و تغییراتی که از قبل به ایندکس اضافه شده، دست نخورده باقی میمانند.
198 |
200 | اگر میخواهید همه تغییرات محلی را حذف و بعد کامیت کنید، آخرین تاریخچه را از سرور دریافت و با دستور ریست (با پرچم hard--) شاخه مستر را به آخرین تغییرات دریافتی از سرور اشاره دهید.
201 |
202 | git fetch origin
203 | git reset --hard origin/master
204 |
210 | رابط گرافیکی گیت git:
211 | gitk
212 | نمایش خروجی دستورات به صورت رنگی:
213 | git config color.ui true
214 | نمایش مختصر لاگ، تنها یک کامیت در هر سطر:
215 | git config format.pretty oneline
216 | افزودن فایلها به صورت تعاملی:
217 | git add -i
218 |
225 |
235 |
245 |
sekedar panduan ringkas penggunaan git. gak pake ribet ;)
16 | Tweet 17 | 18 | 42 |
43 | 49 | Unduh git untuk OSX 50 |
51 |52 | Unduh git untuk Windows 53 |
54 |55 | Unduh git untuk Linux 56 |
57 |
62 | buat lah direktori baru, buka dan jalankan
63 | git init
64 | untuk membuat repositori git baru.
65 |
71 | buat lah salinan kerja dari repositori lokal dengan menjalankan perintah
72 | git clone /jalur/ke/repositori
73 | saat menggunakan server jarak-jauh, perintahnya menjadi
74 | git clone namapengguna@host:/jalur/ke/repositori
75 |
81 | repositori lokal kamu terdiri dari tiga bagian pokok yang disebut "trees" dikelola oleh git.
82 | yang pertama adalah Direktori Kerja yang menyimpan berkas aktual.
83 | kedua adalah Indeks yang berperan sebagai pengolah data dan
84 | terakhir HEAD yang mengarah pada komit terakhir.
85 |
87 |
92 | kamu bisa melakukan perubahan (penambahan ke Indeks) menggunakan
93 | git add <namaberkas>
94 | git add *
95 | Ini merupakan langkah awal alur-kerja dasar git. Untuk komit sepenuhnya gunakan
96 | git commit -m "Pesan komit"
97 | Sekarang berkas telah berkomit di HEAD, tapi belum di repositori jarak-jauh.
98 |
104 | Saat ini perubahan telah tersimpan di HEAD salinan kerja lokal kamu. Untuk mengirimkannya ke repositori jarak-jauh, lakukan
105 | git push origin master
106 | Ubah master sesuai cabang yang kamu inginkan.
107 |
108 | Jika repositori yang ada belum dikloning dan ingin dihubungkan ke server jarak-jauh, kamu perlu menambahkan
109 | git remote add origin <server>
110 | Sekarang kamu bisa mengirimkan perubahan ke server jarak-jauh yang dituju
111 |
112 |
118 | percabangan atau branching digunakan untuk mengembangkan fitur-fitur secara terisolasi. Cabang utama atau master merupakan cabang bawaan ketika kamu membuat repositori. Gunakan cabang lain untuk pengembangan, setelah selesai, gabungkan kembali ke cabang utama. 119 |
120 |
121 |
122 | buat cabang baru dengan nama "fitur_x" dan beralih kedalamnya menggunakan
123 | git checkout -b fitur_x
124 | beralih kembali ke master
125 | git checkout master
126 | dan hapus cabang yang tadi dibuat
127 | git branch -d fitur_x
128 | suatu cabang tidak terbuka untuk yang lainnya kecuali jika kamu mengirimkannya ke repositori jarak-jauh.
129 | git push origin <cabang>
130 |
136 | untuk memperbarui repositori lokal ke komit terkini, lakukan
137 | git pull
138 | dari direktori kerja kamu untuk mengambil dan menggabungkan perubahan jarak-jauh.
139 | untuk menggabungkan cabang lain ke cabang aktif (misal master), gunakan
140 | git merge <cabang>
141 | pada kasus diatas, git mencoba menggabungkan perubahan secara otomatis. Sayangnya hal ini tak selalu berjalan mulus dan bisa menyebabkan konflik.
142 | Kamu lah yang bertanggung jawab menggabungkan konflik tersebut
143 | secara manual dengan menyunting berkas yang ditunjukkan git. Setelah itu, kamu perlu memarkahinya dengan
144 | git add <namaberkas>
145 | sebelum penggabungan berlaku, kamu bisa melakukan pratinjau menggunakan
146 | git diff <cabang_asal> <cabang_tujuan>
147 |
153 | sangat dianjurkan membuat penanda atau tags untuk perangkat lunak yang dirilis. Hal ini amat lah lazim, yang juga terjadi di SVN. Kamu bisa membuat penanda baru dengan nama 1.0.0 dengan menjalankan
154 | git tag 1.0.0 1b2e1d63ff
155 | 1b2e1d63ff adalah 10 karakter pertama dari identitas komit yang ingin kamu referensikan ke penanda. Kamu bisa mendapatkan identitas komit dengan melihat...
156 |
162 | dalam bentuknya yang paling sederhana, kamu bisa mempelajari riwayat repositori menggunakan..
163 | git log
164 | kamu bisa menambahkan banyak parameter untuk menampilkan log sesuai keinginan. Untuk melihat komit penulis tertentu:
165 | git log --author=bob
166 | Untuk melihat log yang dimampatkan, satu baris per komit:
167 | git log --pretty=oneline
168 | Atau mungkin kamu ingin melihat pohon ASCII art seluruh percabangan disertai nama dan penandanya:
169 | git log --graph --oneline --decorate --all
170 | Sekedar melihat berkas yang berubah:
171 | git log --name-status
172 | Ini baru sedikit saja dari sekian banyak parameter yang bisa kamu gunakan. Lebih jauh lagi, lihat
173 | git log --help
174 |
180 | Seandainya kamu melakukan kesalahan (yang tentunya tak pernah terjadi ;) kamu bisa mengembalikannya menggunakan perintah
181 | git checkout -- <namaberkas>
182 | perintah di atas mengembalikan perubahan di dalam pokok kerja kamu dengan konten terakhir dari HEAD. Perubahan dan berkas baru yang telah ditambahkan ke indeks akan tetap tersimpan.
183 |
185 | Jika kamu ingin menggugurkan perubahan dan komit lokal seutuhnya, ambil riwayat terakhir dari server dan arahkan ke cabang master lokal seperti ini
186 | git fetch origin
187 | git reset --hard origin/master
188 |
194 | GUI git bawaan
195 | gitk
196 | menggunakan output git penuh warna
197 | git config color.ui true
198 | menunjukkan log satu baris per komit
199 | git config format.pretty oneline
200 | menggunakan penambahan interaktif
201 | git add -i
202 |
209 |
219 |
229 |
Solamente una piccola guida per iniziare con git. Niente di complicato ;)
30 | Tweet 31 | 32 | 55 |
56 | 62 | Scarica git per OSX 63 |
64 |65 | Scarica git per Windows 66 |
67 |68 | Scarica git for Linux 69 |
70 |
75 | crea una nuova directory, entraci ed esegui
76 | git init
77 | per creare un nuovo repository git.
78 |
84 | crea una copia di un repository locale eseguendo il comando
85 | git clone /percorso/del/repository
86 | usando invece un server remoto, il comando sarà
87 | git clone nomeutente@host:/percorso/del/repository
88 |
94 | la tua copia locale del repository è composta da tre "alberi" mantenuti da git.
95 | Il primo è la tua Directory di lavoro che contiene i files attuali.
96 | Il secondo è l'Index che fa da spazio di transito per i files
97 | e per finire l'HEAD che punta all'ultimo commit fatto.
98 |
100 |
105 | Puoi proporre modifiche (aggiungendole all'Index) usando
106 | git add <nomedelfile>
107 | git add *
108 | Questo è il primo passo nel flusso di lavoro in git. Per validare queste modifiche fatte si usa
109 | git commit -m "Messaggio per la commit"
110 | Ora il file è correttamente nell'HEAD, ma non ancora nel repository remoto.
111 |
117 | Quello che hai cambiato ora è nell'HEAD della copia locale. Per inviare queste modifiche al repository remoto, esegui
118 | git push origin master
119 | Cambia master nel branch al quale vuoi inviare i cambiamenti.
120 |
121 | Se non hai copiato un repository esistente, e vuoi connettere il tuo repository ad un server remoto, c'e' bisogno che tu lo aggiunga con
122 | git remote add origin <server>
123 | Ora sarai in grado di inviare le tue modifiche al server remoto specificato
124 |
125 |
131 | I branch ('ramificazioni') sono utilizzati per sviluppare features che sono isolate l'una dall'altra. Il branch master è quello di default quando crei un repository. Puoi usare altri branch per lo sviluppo ed infine incorporarli ('merge') nel master branch una volta completati. 132 |
133 |
134 |
135 | crea un nuovo branch chiamato "feature_x" e passa al nuovo branch usando
136 | git checkout -b feature_x
137 | ritorna di nuovo su master
138 | git checkout master
139 | e cancella il branch creato in precedenza
140 | git branch -d feature_x
141 | il branch non sarà disponibile agli altri fino a quando non verrà inviato al repository remoto
142 | git push origin <branch>
143 |
149 | per aggiornare il tuo repository locale alla commit più recente, esegui
150 | git pull
151 | nella tua directory corrente per fare una fetch (recuperare) ed incorporare(merge) le modifiche fatte sul server remoto.
152 | per incorporare un altro branch nel tuo branch attivo (ad esempio master), utilizza
153 | git merge <branch>
154 | in entrambi i casi git prova ad auto-incorporare le modifiche. Sfortunatamente, a volte questa procedura automatizzata non è possibile, ed in questo caso ci saranno dei conflitti.
155 | Sei tu il responsabile che sistemerà questi conflitti
156 | manualmente modificando i file che git mostrerà. Dopo aver cambiato questi files, dovrai marcarli come 'correttamente incorporati' tramite
157 | git add <nomedelfile>
158 | prima di immettere le modifiche, potrai anche visualizzarne un'anteprima eseguendo
159 | git diff <branch_sorgente> <branch_target>
160 |
166 | È raccomandato creare dei tags nel caso in cui il software venga rilasciato. Questo è un concept già conosciuto, che esiste anche in SVN. Puoi creare un tag chiamato 1.0.0 eseguendo
167 | git tag 1.0.0 1b2e1d63ff
168 | la sequenza 1b2e1d63ff sta per i primi 10 caratteri del commit che si vuol referenziare tramite questo tag. Puoi ottenere l'id della commit tramite
169 | git log
170 | puoi anche utilizzare meno caratteri per l'id della commit, basta che sia unico.
171 |
177 | Nel caso tu abbia fatto qualcosa di sbagliato (ma non capita mai, sicuro ;) puoi sostituire i cambiamenti fatti in locale con il comando
178 | git checkout -- <nomedelfile>
179 | questo rimpiazza le modifiche nell'albero di lavoro con l'ultimo contenuto presente in HEAD. I cambiamenti fatti ed aggiunti all'index, così come i nuovi files, verranno mantenuti.
180 |
182 | Se vuoi in alternativa eliminare tutti i cambiamenti e commits fatti in locale, recupera l'ultima versione dal server e fai puntare il tuo master branch a quella versione in questo modo
183 | git fetch origin
184 | git reset --hard origin/master
185 |
191 | GUI (Interfaccia utente grafica) per git disponibile di default
192 | gitk
193 | colora gli output di git
194 | git config color.ui true
195 | mostra il log in una riga per commit
196 | git config format.pretty oneline
197 | utilizza l'aggiunta interattiva
198 | git add -i
199 |
206 |
216 |
59 | OSX用 Gitをダウンロード 60 |
61 |62 | Windows用 Gitをダウンロード 63 |
64 |65 | Linux用 Gitをダウンロード 66 |
67 |
72 | 新規のリポジトリを作成するには
73 | 新しいフォルダを作って開きます。そして、
74 | git init
75 | を実行します。
76 |
82 | ローカルのリポジトリをクローンするには
83 | git clone /path/to/repository
84 | そして、リモートのリポジトリをクローンするには
85 | git clone username@host:/path/to/repository
86 | を実行します。
87 |
93 | ローカルのリポジトリはGitが管理する三本の"木"からなっています。
94 | 第一はファイルそのものがある Working Directory、
95 | 第二は中間的な位置にあるIndex、そして
96 | 第三は最後のコミットを指すHEAD、
97 | この三本です。
98 |
100 |
105 | 変更されたファイルを選択します。
106 | git add <filename>
107 | git add *
108 | を実行するとIndexに追加されます。
109 | これは基本的な作業の一つです。
110 | 変更を実際に適用するには
111 | git commit -m "Commit message"
112 | を実行します。
変更がHEADに入りましたが、
リモートリポジトリには未だ入っていません。
113 |
119 | この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには
120 | git push origin master
121 | を実行し、masterの代わりに適用のブランチ名を入れます。
122 |
123 | もし既存リポジトリをクローンせずに使用した場合
124 | git remote add origin <server>
125 | を実行すると、リモートリポジトリを登録する事が可能です。
126 | これで変更を特定なリモートリポジトリに送る(push)事ができます。
127 |
133 | ブランチは関連性のない機能を実装するときに使用されるもので、リポジトリを作成する際にデフォルトのブランチはmasterです。ブランチを作って使用を終えたらメインのブランチに戻すようにしましょう。 134 |
135 |
136 |
137 | "feature_x"という名前のブランチを作って スイッチします
138 | git checkout -b feature_x
139 | メインのブランチに戻る
140 | git checkout master
141 | ブランチの削除
142 | git branch -d feature_x
143 | ブランチをリモートリポジトリにプッシュしない限りブランチは他人には見れないようになっていますのでご注意ください。
144 | git push origin <branch>
145 |
151 | 自分のリポジトリを最新のコミットにアップデートするには
152 | git pull
153 | を作業のフォルダで実行するとリモートリポジトリの
最新情報を取得し(fetch)現在の状態とマージ(merge)されます。
154 | 或るブランチを現在の物(master等)にマージするには次の様にします。
155 | git merge <branch>
156 | 両者とも自動的にGitはマージをしようとしますが、
必ず成功する訳ではなく結果的に競合(conflict)が発生します。
157 | 手動でファイルの編集等をする事によって
競合を解決しマージしなければなりません。
158 | ファイルの変更後、下記の様にマージされたとしてマークします。
159 | git add <filename>
160 | マージする前に差分を見る事もできます。
161 | git diff <source_branch> <target_branch>
162 |
168 | SVNでも使用されている概念ですが、バージョンを
リリースする度にタグを作る事が推奨されています。
169 | 新規のタグ1.0.0を作成するには下記を実行します。
170 | git tag 1.0.0 1b2e1d63ff
171 | 尚、1b2e1d63ff はタグが指すコミットIDの10文字です。
コミットIDを見るにはlogを出します。
172 | git log
173 | コミットIDは最後まで書かなくても構いませんが
唯一の値でなければいけません。
174 |
180 | うっかり間違ってしまったとき、ローカルの変更を
次のコマンドで取り消す事ができます。
181 | git checkout -- <filename>
182 | これはHEADの最後のコミットの状態にファイルを戻します。
Indexに追加された変更や新しいファイルは除きます。
183 |
185 | 一方、全ての変更とローカルコミットを捨てる場合、サーバーから最新情報を取得し、masterブランチがそこを指す様にする事ができます。
186 | git fetch origin
187 | git reset --hard origin/master
188 |
194 | Gitの内装GUI
195 | gitk
196 | コンソール上でアウトプットにカラーを付加
197 | git config color.ui true
198 | logでコミット一つに対し一行のみを表示
199 | git config format.pretty oneline
200 | インタラクティブ方式でファイルを追加
201 | git add -i
202 |
209 |
219 |
125 | 폴더를 하나 만들고, 그 안에서 아래 명령을 실행하세요.
126 | git init
127 | 새로운 git 저장소가 만들어집니다.
128 |
134 | 로컬 저장소를 복제(clone)하려면 아래 명령을 실행하세요.
135 | git clone /로컬/저장소/경로
136 | 원격 서버의 저장소를 복제하려면 아래 명령을 실행하세요.
137 | git clone 사용자명@호스트:/원격/저장소/경로
138 |
144 | 여러분의 로컬 저장소는 git이 관리하는 세 그루의 나무로 구성돼있어요.
145 | 첫번째 나무인 작업 디렉토리(Working directory)는
146 | 실제 파일들로 이루어져있고, 두번째 나무인 인덱스(Index)는
147 | 준비 영역(staging area)의 역할을 하며, 마지막 나무인 HEAD는
148 | 최종 확정본(commit)을 나타내요.
149 |
151 |
156 | 변경된 파일은 아래 명령어로 (인덱스에) 추가할 수 있어요.
157 | git add <파일 이름>
158 | git add *
159 | 이것이 바로 git의 기본 작업 흐름에서 첫 단계에 해당돼요.
160 | 하지만 실제로 변경 내용을 확정하려면 아래 명령을 내려야 한답니다.
161 | git commit -m "이번 확정본에 대한 설명"
162 | 자, 이제 변경된 파일이 HEAD에 반영됐어요.
163 | 하지만, 원격 저장소에는 아직 반영이 안 됐답니다.
164 |
170 | 현재의 변경 내용은 아직 로컬 저장소의 HEAD 안에 머물고 있어요.
171 | 이제 이 변경 내용을 원격 서버로 올려봅시다. 아래 명령을 실행하세요.
172 | git push origin master
173 | (다른 가지를 발행하려면 master를 원하는 가지 이름으로 바꿔주세요.)
174 |
175 | 만약 기존에 있던 원격 저장소를 복제한 것이 아니라면,
176 | 원격 서버의 주소를 git에게 알려줘야 해요.
177 | git remote add origin <원격 서버 주소>
178 | 이제 변경 내용을 원격 서버로 발행할 수 있어요.
179 |
185 | 가지는 안전하게 격리된 상태에서 무언가를 만들 때 사용해요.
186 | 여러분이 저장소를 새로 만들면 기본으로 master 가지가 만들어집니다.
187 | 이제 다른 가지를 이용해서 개발을 진행하고, 나중에 개발이 완료되면
188 | master 가지로 돌아와 병합하면 돼요.
189 |
191 |
192 | 아래 명령으로 "feature_x"라는 이름의 가지를 만들고 갈아탑니다.
193 | git checkout -b feature_x
194 | 아래 명령으로 master 가지로 돌아올 수 있어요.
195 | git checkout master
196 | 아래 명령으로는 가지를 삭제할 수 있어요.
197 | git branch -d feature_x
198 | 여러분이 새로 만든 가지를 원격 저장소로 전송하기 전까지는
199 | 다른 사람들이 접근할 수 없어요.
200 | git push origin <가지 이름>
201 |
207 | 여러분의 로컬 저장소를 원격 저장소에 맞춰 갱신하려면
208 | 아래 명령을 실행하세요.
209 | git pull
210 | 이렇게 하면 원격 저장소의 변경 내용이 로컬 작업 디렉토리에
211 | 받아지고(fetch), 병합(merge)된답니다.
212 | 다른 가지에 있는 변경 내용을 현재 가지(예를 들면, master 가지)에
213 | 병합하려면 아래 명령을 실행하세요.
214 | git merge <가지 이름>
215 | 첫번째 명령이든 두번째 명령이든, git은
216 | 자동으로 변경 내용을 병합하려고 시도해요.
217 | 문제는, 항상 성공하는 게 아니라 가끔
218 | 충돌(conflicts)이 일어나기도 한다는 거예요.
219 | 이렇게 충돌이 발생하면, git이 알려주는 파일의 충돌 부분을
220 | 여러분이 직접 수정해서 병합이 가능하도록 해야 하죠.
221 | 충돌을 해결했다면, 아래 명령으로 git에게
222 | 아까의 파일을 병합하라고 알려주세요.
223 | git add <파일 이름>
224 | 변경 내용을 병합하기 전에, 어떻게 바뀌었는지 비교해볼 수도 있어요.
225 | git diff <원래 가지> <비교 대상 가지>
226 |
232 | 소프트웨어의 새 버전을 발표할 때마다 꼬리표를 달아놓으면 좋아요.
233 | (물론 꼬리표는 SVN 등에 이미 존재하는 기능이지요.)
234 | 아래 명령을 실행하면 새로운 꼬리표인 1.0.0을 달 수 있어요.
235 | git tag 1.0.0 1b2e1d63ff
236 | 위 명령에서 1b2e1d63ff 부분은 꼬리표가 가리킬 확정본 식별자입니다.
237 | 아래 명령으로 확정본 식별자를 얻을 수 있어요.
238 | git log
239 | 확정본 식별자의 앞부분 일부만 입력해도 꼬리표를 붙일 수 있지만,
240 | 그 일부분이 반드시 고유하다는 조건이 필요해요.
241 |
247 | 만약 여러분이 (물론 그럴 일은 없겠지만 ;) 실수로 무언가 잘못한 경우,
248 | 아래 명령으로 로컬의 변경 내용을 되돌릴 수 있어요.
249 | git checkout -- <파일 이름>
250 | 위 명령은 로컬의 변경 내용을 변경 전 상태(HEAD)로 되돌려줘요.
251 | 다만, 이미 인덱스에 추가된 변경 내용과
252 | 새로 생성한 파일은 그대로 남는답니다.
253 |
255 | 만약, 로컬에 있는 모든 변경 내용과 확정본을 포기하려면,
256 | 아래 명령으로 원격 저장소의 최신 이력을 가져오고,
257 | 로컬 master 가지가 저 이력을 가리키도록 할 수 있어요.
258 | git fetch origin
259 | git reset --hard origin/master
260 |
266 | git의 내장 GUI
267 | gitk
268 | 콘솔에서 git output을 컬러로 출력하기
269 | git config color.ui true
270 | 이력(log)에서 확정본 1개를 딱 한 줄로만 표시하기
271 | git config format.pretty oneline
272 | 파일을 추가할 때 대화식으로 추가하기
273 | git add -i
274 |
281 |
291 |
300 |
အရိုးအရှင်းဆုံး လမ်းညွှန်ဖြစ်သည်။ ထို့ကြောင့် အသေးစိတ် မပါဝင်။ ;)
28 | Tweet 29 | 30 | 60 |
61 | 67 | OSX အတွက် git Download 68 |
69 |70 | Windows အတွက် git Download 71 |
72 |73 | Linux အတွက် git Download 74 |
75 |
80 | directory အသစ် တစ်ခုတည်ဆောက်ပါ။ ပြီးလျှင် terminal မှာ အောက်ကလို ရိုက်ပါ။
81 |
82 | git init
83 | ဆိုပြီး git repository တစ်ခုကို စတင်ပါ။
84 |
90 | copy အနေနဲ့ ပွားပြီးတော့ အလုပ်လုပ်မယ်ဆိုရင်တော့ အောက်က command ကို အသုံးပြုရပါတယ်။
91 | git clone /path/to/repository
92 | တကယ်လို့ server နဲ့ အလုပ်လုပ်တာဆိုရင်တော့ အောက်ကလို အသုံးပြုရပါတယ်။
93 | git clone username@host:/path/to/repository
94 |
100 | သင့် local repository မှာ git က ထိန်းသိမ်းဆောက်ရွက်တဲ့ ဆင့်ပွား ၃ ခု ရှိပါတယ်။
101 | ပထမ တစ်ခုကတော့ Working Directory ပါ။
102 | သူကတော့ လက်ရှိ file တွေကို သိမ်းထားပေးပါတယ်။
103 | ဒုတိယ တစ်ခုကတော့ Index ပါ။
104 | သူကတော့ staging area ပါ။
105 | နောက်ဆုံးကတော့ HEAD ပါ။
106 | နောက်ဆုံး သင် commit လုပ်ထားတဲ့ နေရာကို ညွှန်ပြထားပါတယ်။
107 |
108 |
110 |
115 | ပြင်ဆင်ထားတာများကို ထည့်သွင်းလိုလည်း အောက်ပါ အတိုင်း အသုံးပြုနိုင်သည်။
116 | git add <filename>
117 | git add *
118 | ဒီ အဆင့်က ပထမ အဆင့်ပါ။ ပြောင်းလဲထားသည်များကို commit လုပ်လိုလျှင်
119 | git commit -m "Commit message"
120 | ပြင်ဆင်ထားသည်များကို HEAD တွင် မှတ်ထားပြီးသားဖြစ်သည်။ သို့သော် remote repository ပေါ်သို့ မရောက်သေးပါ။
121 |
127 | သင်ပြင်ဆင်ထားတာတွေက အခု သင့်ရဲ့ local working copy နေရာက <HEAD> မှာ ရောက်နေပါပြီ။
128 | ပြောင်းလဲထားတဲ့ code တွေကို remote repository ဆီပို့ဖို့ အတွက်
129 |
130 | git push origin master
131 | master ကို သင့်ရဲ့ စိတ်ကြိုက် branch ပြောင်းနိုင်ပါတယ်။ သင် ပို့ချင်တဲ့ branch တစ်ခုခုကိုပေါ့။
132 |
133 | တကယ်လို့ သင်က cloned မလုပ်ချင်ဘူး။ လက်ရှိ ရှိထားတဲ့ code ကို remote server နဲ့ ချိတ်ဆက်ချင်တယ်ဆိုရင်တော့
134 | git remote add origin <server>
135 |
136 | အခု သင်ရဲ့ code ကို သင်ရွေးချယ်ထားတဲ့ remote server ပေါ်တင်လို့ရပါပြီ။
137 |
138 |
144 | Branches တွေကို develop အဆင့်တွေမှာ အသုံးပြုပါတယ်။ 145 | master branch ကတော့ repository အသစ်ဖန်တီးတဲ့အခါမှာ ပုံသေပါလာပါတယ်။ 146 | တကယ်လို့ development အတွက် အြခား branches တွေခွဲထွက်ပြီး အကုန်ပြီးစီးမှသာ master branch နဲ့ ပြန်ပေါင်းပါတယ်။ 147 |
148 |
149 |
150 | "feature_x" ဆိုတဲ့ branch အသစ်ဆောက်ပြီး ထို branch ကို ပြောင်းလဲ အသုံးပြုပုံ
151 | git checkout -b feature_x
152 |
153 | master branch ကို ပြန်ပြောင်းပုံ
154 | git checkout master
155 | branch ကို ဖျက်ခြင်း
156 | git branch -d feature_x
157 |
158 | branch ကို remote repository ကို push လုပ်လိုလျှင်
159 |
160 | git push origin <branch>
161 |
167 |
168 | local repository ကို remote repository တွင် အသစ် commit လုပ်ထားသည်များကို ဆွဲချလိုလျှင်
169 | git pull
170 | pull လို့ ခေါ်တဲ့အခါမှာ working directory ထဲသို့ နောက်ဆုံး ပြောင်းထားသည်များကို fetch နှင့် merge လုပ်သွားပါမယ်။
171 |
172 | လက်ရှိ အလုပ်လုပ်နေသော branch (ဥပမာ။။ master) ထဲကို အခြား branch မှ လာပေါင်းလိုလျှင်
173 |
174 | git merge <branch>
175 |
176 | ထိုအခါ git က အလိုအလျှောက် ပြင်ထားသည်များကို ပေါင်းပေးပါလိမ့်မယ်။
177 | သို့သော်လည်း အမြဲတန်း အဆင်မပြေပါ။ တစ်ခါတစ်လေ conflicts ဖြစ်တာလေးတွေ ရှိတတ်ပါတယ်။
178 |
179 | ထို အခါ conflicts ဖြစ်တာကို ကိုယ့်ဘာသာကိုယ် ပေါင်းဖို့ လုပ်ဆောင်ရပါတော့တယ်။
180 |
181 | conflicts ဖြစ်နေတဲ့ file များကို git တွင်ဖော်ထားပါတယ်။ ထို file များကို ကိုယ့်ဘာသာကိုယ် ပြင်ဆင်ပြီးရင် ပြန်ပြီးတော့ ထည့်ပေးဖို့ လိုပါတယ်။
182 | git add <filename>
183 |
184 | မပေါင်းခင်မှာ အရင်ဆုံး ပြောင်းထားတဲ့ code တွေကို ယှဉ်ကြည့်နိုင်ပါတယ်။
185 | git diff <source_branch> <target_branch>
186 |
192 | software version တစ်ခုကို ထုတ်လိုက်တိုင်းမှာ tag ကို အသုံးပြု အကြံပြုပါတယ်။
193 | ဒါသုံးခြင်းက SVN မှာ ပါပြီးသား အယူအဆ တစ်ခုပါ။
194 | သင့်အနေနဲ့ tag နာမည် အသစ် 1.0.0 ဆိုပြီး ပေးနိုင်ပါတယ်။
195 | git tag 1.0.0 1b2e1d63ff
196 | 1b2e1d63ff ကတော့ သင် tag လုပ်ချင်တဲ့ commit id ရဲ့ ပထမ စာလုံး ၁၀ လုံး ပါ။
197 | သင့် အနေနဲ့ commit id ကို အောက်ကလို ရိုက်ပြီး ရယူနိုင်ပါတယ်။
198 | git log
199 | သင့်အနေနဲ့ commit id ရဲ့ အခြားစာလုံး အနည်းငယ်ကို အသုံးပြုနိုင်ပါတယ်။ သို့ပေမယ့် အဲဒီ id ဟာ ဘယ်သူမှ အသုံးမပြုထားပဲ ကင်းရှင်းဖို့ သို့မဟုတ် unique ဖြစ်ဖို့ လိုပါတယ်။
200 |
206 | တကယ်လို့ တခုခုမှားသွားပြီး local ထဲက file နဲ့ ပြန် အစားထိုးချင်ရင်
207 | git checkout -- <filename>
208 | အခု ပြောင်းလဲလိုက်တာက သင့်ရဲ့ working tree ထဲက HEAD ထဲ က နောက်ဆုံး content မှာ သွားပြီးတော့ အစားထိုးသွားမှာပါ။ ပြောင်းထားတာတွေကိုတော့ index အနေနဲ့ ထည့်ပြီး files အသစ်တွေကိုလည်း သိမ်းထားပါလိမ့်မယ်။
209 |
211 | အကယ်၍ သင့်အနေနဲ့ local changes နှင့် commits တွေကို ဖျက်ချပြီး နောက်ဆုံး server နှင့် master branch က အကုန် ဆွဲယူပြီး အစားထိုးချင်ရင်
212 | git fetch origin
213 | git reset --hard origin/master
214 |
220 | GUI ပါဝင်သော git
221 | gitk
222 | အရောင်များဖြင့် git output
223 | git config color.ui true
224 | commit များကို စာ တကြောင်းစီဖြင့် ကြည့်ရန်။
225 | git config format.pretty oneline
226 | interactive adding ကို အသုံးပြုခြင်း
227 | git add -i
228 |
235 |
245 |
een korte gids om je op weg te helpen met git, no deep shit :)
16 | Tweet 17 | 18 | 42 |
43 | 49 | Download git voor OSX 50 |
51 |52 | Download git voor Windows 53 |
54 |55 | Download git voor Linux 56 |
57 |
62 | maak een nieuwe map, open deze map en voer
63 | git init
64 | uit om een nieuwe repository aan te maken.
65 |
71 | haal een repository lokaal binnen
72 | git clone /path/to/repository
73 | wanneer je git server niet lokaal staat
74 | zal je volgende moeten uitvoeren
75 | git clone gebruikersnaam@host:/path/to/repository
76 |
82 | Je lokale repository bestaat uit 3 verschillende 'trees' beheerd door git.
83 | De eerste is je Working Directory dewelke je bestanden bevatten.
84 | De tweede is de Index dat zich als tussen stadium gedraagt (staging area)
85 | De laatste is de HEAD die verwijst naar de laatste 'commit' die je hebt gemaakt.
86 |
88 |
93 | Je kan aanpassingen aan je files toevoegen aan de Index
94 | git add <bestandsnaam>
95 | of
96 | git add *
97 | Dit is de eerste stap in de basis werkwijze van git.
98 | Om aanpassingen écht door te voeren gebruik je
99 | git commit -m "Commit message"
100 | De aanpassingen zijn nu toegevoegd aan de HEAD,
101 | al zijn ze nog niet toegevoegd aan je repository als deze op een andere lokatie staat.
102 |
108 | Je aanpassingen zitten nu in de HEAD van je lokale werk-repository.
109 | Om deze aanpassingen door te sturen naar je repository op een andere lokatie, voer dan volgend commando uit
110 | git push origin master
111 | Verander master naar de branch-naam
112 | waar je je aanpassingen naar wil sturen.
113 |
114 | Als je lokale werkbestanden niet gesynchroniseerd zijn
115 | met een bestaande repository (op een andere server bijvoorbeeld),
116 | voeg dan de bestaande repository toe aan je lokale repository
117 | git remote add origin <server>
118 | Nu kan je je lokale aanpassingen, en dus ook je lokale repository, synchroniseren met de server die je net hebt toegevoegd.
119 |
125 | Branches worden gebruikt om verschillende features te ontwikkelen in geïsoleerde omgevingen, los van elkaar.
126 | De master branch is de basis of standaard branch wanneer je een nieuwe repository aanmaakt.
127 | Maak nieuwe branches aan wanneer je nieuwe toevoegingen ontwikkelt en voeg ze samen (merge) met de master branch wanneer je klaar bent.
128 |
130 |
131 | maak een nieuwe branch aan met de naam "feature_x"
132 | en ga er onmiddellijk naartoe
133 | git checkout -b feature_x
134 | ga terug naar de master branch
135 | git checkout master
136 | verwijder de branch
137 | git branch -d feature_x
138 | een branch is niet beschikbaar voor anderen
139 | tenzij je ze synchroniseert met de centale repository
140 | git push origin <branch>
141 |
147 | om je lokale repository te updaten naar de laatste versie, voer dan volgend commando uit in je lokale repository
148 | git pull
149 | op die manier kan je de aanpassingen fetchen
150 | en mergen met je lokale bestanden.
151 | om een andere branch samen te voegen met je actieve branch, gebruik je
152 | git merge <branch>
153 | in beide gevallen probeert git de aanpassingen automatisch te mergen.
154 | Jammer genoeg is dit niet altijd mogelijk en resulteert dit soms in een conflict.
155 | Je bent dan zelf verantwoordelijk om de conflicten manueel op te lossen en te mergen.
156 | Na de aanpassingen moet je de aangepaste bestanden opnieuw toevoegen aan je lokale repository
157 | git add <filename>
158 | alvorens je aanpassingen dan terug samen te voegen kan je ook de aangepaste code bekijken door middel van
159 | git diff <source_branch> <target_branch>
160 |
166 | net zoals in SVN is het aangewezen om verschillende releases van je applicatie in een tag te steken. Je kan een nieuwe tag aanmaken met de naam 1.0.0 door volgend commando uit te voeren
167 | git tag 1.0.0 1b2e1d63ff
168 | het 1b2e1d63ff gedeelte van het commando
169 | staat voor de eerste 10 karakters van de commit id die je in een tag wil steken.
De commit id kan je opvragen door volgend commando uit te voegen
170 | git log
171 | het hoeven niet per se de eerste 10 karakters van de commit id te zijn, zolang ze maar uniek zijn.
172 |
178 | In het geval dat je wil terug gaan naar een vorige versie van een bestand (fouten maken kan gebeuren hé) gebruik je
179 | git checkout -- <filename>
180 | dit zal het bestand in je huidige werkmap vervangen door de laatste versie die zich in de HEAD tree bevindt. De aanpassingen die je reeds hebt toegevoegd én de nieuw aangemaakte bestanden blijven behouden.
181 |
183 | Stel nu dat je alle lokale aanpassingen wil vervangen door de laatste versie van de repository die zich op de server bevindt
184 | kan je volgende commando reeks gebruiken
185 | git fetch origin
186 | git reset --hard origin/master
187 |
193 | ingebouwde git GUI
194 | gitk
195 | handige kleuren output voor git
196 | git config color.ui true
197 | toon je log op 1 lijn per commit
198 | git config format.pretty oneline
199 | gebruikte interactieve bestands toevoeging
200 | git add -i
201 |
208 |
218 |
Prosty przewodnik dla początkujących. nic skomplikowanego ;)
16 | Tweet 17 | 18 | 41 |
42 | 48 | Pobierz 50 | git dla OSX 51 |
52 |53 | Pobierz git dla Windows 54 |
55 |56 | Pobierz git 57 | dla Linux 58 |
59 |
64 | utwórz katalog, wejdź do niego i wykonaj
65 | git init
66 | aby utworzyć nowe repozytorium git.
67 |
73 | utwórz kopię roboczą lokalnego repozytorium poprzez polecenie
74 | git clone /path/to/repository
75 | jeśli korzystasz ze zdalnego serwera, użyjesz polecenia
76 | git clone username@host:/path/to/repository
77 |
83 | twoje lokalne repozytorium składa się z trzech "drzew" zarządzanych
84 | przez git.
85 | przerwsze to Katalog Roboczy, który przechowuje
86 | bieżące pliki.
87 | drugie to Index, które działa jak poczekalnia i
88 | ostatnie z nich
89 | to HEAD, które wskazuje na ostatni utworzony commit.
90 |
92 |
97 | Możesz zaproponować zmiany (dodać je do Index) używając
98 | git add <filename>
99 | git add *
100 | To pierwszy krok podczas pracy z gitem.
101 | Aby rzeczywiście
102 | zatwierdzić te zmiany użyj
103 | git commit -m "Commit message"
104 | Teraz plik jest zatwierdzony w HEAD, ale nie w
105 | zdalnym repozytorium.
106 |
112 | Twoje zmiany są obecnie w HEAD twojej kopii roboczej. Aby
113 | wysłać te zmiany do zdalnego repozytorium, wykonaj
114 | git push origin master
115 | Zmień master na dowolną gałąź, której zmiany wysyłasz.
116 |
117 | Jeśli nie sklonowałeś istniejącego repozytorium i chcesz połączyć
118 | je ze zdalnym serwerem, musisz go dodać poprzez
119 | git remote add origin <server>
120 | Teraz masz możliwość wysyłania zmian na wskazany serwer.
121 |
122 |
128 | Gałęzie są używane do rozwijania funkcjonalności odizolowanych od
129 | siebie. Gałąź master jest domyślną gałęzią kiedy
130 | tworzysz repozytorium.
131 | Używaj innych gałęzi do rozwoju projektu, a
132 | kiedy skończysz
133 | scalaj je z powrotem z gałęzią główną.
134 |
136 |
137 | utwórz nową gałąź o nazwie "feature_x" i przełącz się na nią
138 | git checkout -b feature_x
139 | przełącz się z powrotem na master
140 | git checkout master
141 | i usuń gałąź
142 | git branch -d feature_x
143 | gałąź nie jest dostępna dla innych dopóki nie wyślesz jej do
144 | zdalnego repozytorium
145 | git push origin <branch>
146 |
152 | aby zaktualizować lokalne repozytorium do ostatniego commita,
153 | wykonaj
154 | git pull
155 | w swoim katalogu roboczym aby pobrać(fetch) i
156 | scalić(merge) zdalne
157 | zmiany.
158 | aby scalić inną gałąź z gałęzią aktywną (np. master), użyj
159 | git merge <branch>
160 | w obu przypadkach git próbuje scalić zmiany automatycznie. Niestety
161 | nie zawsze jest to możliwe i powoduje konflikty.
162 | Jesteś odpowiedzialny za ich scalenie.
163 | Ręcznie poprzez edycję plików wskazanych przez git. Po zmianie
164 | musisz oznaczyć je jako scalone poprzez
165 | git add <filename>
166 | przed scaleniem zmian, możesz je obejrzeć używając
167 | git diff <source_branch> <target_branch>
168 |
174 | Zaleca się tworzenie tagów dla wersji oprogramowania. To znany
175 | koncept, który istnieje również w SVN. Możesz utworzyć nowy tag
176 | o nazwie 1.0.0 wykonując
177 | git tag 1.0.0 1b2e1d63ff
178 | 1b2e1d63ff to pierwsze 10 znaków numeru commita do którego
179 | odwołuje się ten tag. Możesz uzyskać ten numer patrząc na...
180 |
186 | Możesz przeglądać historię repozytorium w najprostszej formie
187 | używając..
188 | git log
189 | Możesz dodawać dużo parametrów aby uzyskać to czego potrzebujesz.
190 | aby zobaczyć commity konkretnego autora:
191 | git log --author=bob
192 | aby zobaczyć bardziej zwarty rezultat, gdzie commit jest pojedynczą
193 | linią:
194 | git log --pretty=oneline
195 | A może chcesz zobaczyć drzewo w ASCII art wszystkich gałęzi
196 | opatrzone ich nazwami oraz nazwami tagów:
197 | git log --graph --oneline --decorate --all
198 | zobacz tylko te pliki które zostały zmienione:
199 | git log --name-status
200 | To tylko kilka z możliwych parametrów, których możesz użyć. Wiecej
201 | zobaczysz w
202 | git log --help
203 |
209 | Jeśli coś pójdzie nie tak (co oczywiście nigdy się nie zdarza ;)
210 | możesz wycofać lokalne zmiany poprzez
211 | git checkout -- <filename>
212 | zastępując zmiany w katalogu roboczym ostatnią zawartością HEAD.
213 | Zmiany, które zostały już dodane do index, tak jak nowe pliki
214 | zostaną zachowane.
215 |
217 | Jeśli zamiast tego chcesz porzucić wszystkie lokalne zmiany i
218 | commity pobierz ostatnią historię z serwera i ustaw na nią swoją
219 | gałąź lokalną
220 | git fetch origin
221 | git reset --hard origin/master
222 |
228 | wbudowane GUI dla git
229 | gitk
230 | wyjście git z kolorami
231 | git config color.ui true
232 | pokaż log jako pojedyncze linie
233 | git config format.pretty oneline
234 | użyj interaktywnego dodawania
235 | git add -i
236 |
243 |
253 |
263 |
apenas um guia prático para começar com git. sem complicação ;)
16 | Tweet 17 | 18 | 42 |
43 | 49 | Baixe o git para OSX 50 |
51 |52 | Baixe o git para Windows 53 |
54 |55 | Baixe o git para Linux 56 |
57 |
62 | crie uma nova pasta, abra-a e execute o comando
63 | git init
64 | para criar um novo repositório.
65 |
71 | crie uma cópia de trabalho em um repositório local executando o comando
72 | git clone /caminho/para/o/repositório
73 | quando usar um servidor remoto, seu comando será
74 | git clone usuário@servidor:/caminho/para/o/repositório
75 |
81 | seus repositórios locais consistem em três "árvores" mantidas pelo git.
82 | a primeira delas é sua Working Directory que contém os arquivos vigentes.
83 | a segunda Index que funciona como uma área temporária e
84 | finalmente a HEAD que aponta para o último commit (confirmação) que você fez.
85 |
87 |
92 | Você pode propor mudanças (adicioná-las ao Index) usando
93 | git add <arquivo>
94 | git add *
95 | Este é o primeiro passo no fluxo de trabalho básico do git. Para realmente confirmar estas mudanças (isto é, fazer um commit), use
96 | git commit -m "comentários das alterações"
97 | Agora o arquivo é enviado para o HEAD, mas ainda não para o repositório remoto.
98 |
104 | Suas alterações agora estão no HEAD da sua cópia de trabalho local. Para enviar estas alterações ao seu repositório remoto, execute
105 | git push origin master
106 | Altere master para qualquer ramo (branch) desejado, enviando suas alterações para ele.
107 |
108 | Se você não clonou um repositório existente e quer conectar seu repositório a um servidor remoto, você deve adicioná-lo com
109 | git remote add origin <servidor>
110 | Agora você é capaz de enviar suas alterações para o servidor remoto selecionado.
111 |
112 |
118 | Branches ("ramos") são utilizados para desenvolver funcionalidades isoladas umas das outras. O branch master é o branch "padrão" quando você cria um repositório. Use outros branches para desenvolver e mescle-os (merge) ao branch master após a conclusão. 119 |
120 |
121 |
122 | crie um novo branch chamado "funcionalidade_x" e selecione-o usando
123 | git checkout -b funcionalidade_x
124 | retorne para o master usando
125 | git checkout master
126 | e remova o branch da seguinte forma
127 | git branch -d funcionalidade_x
128 | um branch não está disponível a outros a menos que você envie o branch para seu repositório remoto
129 | git push origin <funcionalidade_x>
130 |
136 | para atualizar seu repositório local com a mais nova versão, execute
137 | git pull
138 | na sua pasta de trabalho para obter e fazer merge (mesclar) alterações remotas.
139 | para fazer merge de um outro branch ao seu branch ativo (ex. master), use
140 | git merge <branch>
141 | em ambos os casos o git tenta fazer o merge das alterações automaticamente. Infelizmente, isto nem sempre é possível e resulta em conflitos.
142 | Você é responsável por fazer o merge estes conflitos
143 | manualmente editando os arquivos exibidos pelo git. Depois de alterar, você precisa marcá-los como merged com
144 | git add <arquivo>
145 | antes de fazer o merge das alterações, você pode também pré-visualizá-as usando
146 | git diff <branch origem> <branch destino>
147 |
153 | é recomendado criar rótulos para releases de software. Este é um conhecido conceito, que também existe no SVN. Você pode criar um novo rótulo chamado 1.0.0 executando o comando
154 | git tag 1.0.0 1b2e1d63ff
155 | o 1b2e1d63ff representa os 10 primeiros caracteres do id de commit que você quer referenciar com seu rótulo. Você pode obter o id de commit com
156 | git log
157 | você pode também usar menos caracteres do id de commit, ele somente precisa ser único.
158 |
164 | No caso de você ter feito algo errado (que seguramente nunca acontece ;) ) você pode sobrescrever as alterações locais usando o commando
165 | git checkout -- <arquivo>
166 | isto substitui as alterações na sua árvore de trabalho com o conteúdo mais recente no HEAD. Alterações já adicionadas ao index, bem como novos arquivos serão mantidos.
167 |
169 | Se ao invés disso você deseja remover todas as alterações e commits locais, recupere o histórico mais recente do servidor e aponte para seu branch master local desta forma
170 | git fetch origin
171 | git reset --hard origin/master
172 |
178 | Interface gráfica padrão
179 | gitk
180 | usar saídas do git coloridas
181 | git config color.ui true
182 | exibir log em apenas uma linha por commit
183 | git config format.pretty oneline
184 | fazer inclusões interativas
185 | git add -i
186 |
193 |
203 |
простое руководство по работе с git. Ничего сложного ;)
16 | Tweet 17 | 18 | 42 |
43 | 49 | Скачать git для OSX 50 |
51 |52 | Скачать git для Windows 53 |
54 |55 | Скачать git для Linux 56 |
57 |
62 | Для того чтобы создать новый репозиторий git, необходимо
63 | открыть папку где вы хотите его разместить и выполнить команду
64 | git init
65 |
66 |
72 | Создать локальную рабочую копию репозитория можно командой
73 | git clone /путь/к/репозиторию
74 | когда используется удаленный сервер, команда будет
75 | git clone юзер@хост:/путь/к/репозиторию
76 |
82 | Ваш локальный git репозиторий состоит из трех "сущностей".
83 | Рабочий каталог (Working Directory) содержит файлы.
84 | Индекс (Index) или область подготовленных файлов (Staging Area),
85 | содержит информацию о том, что должно войти в следующий коммит и
86 | HEAD указывает на последний коммит что вы сделали.
87 |
89 |
94 | Чтобы подготовить изменения (добавить их в Индекс), используйте
95 | git add <имя_файла>
96 | git add *
97 | Это первый шаг в основном рабочем процессе. Сделать коммит подготовленных изменений можно командой
98 | git commit -m "Описание коммита"
99 | Теперь изменения закреплены в локальном репозитории, и на них указывает HEAD, но еще не в удаленном репозитории.
100 |
106 | Чтобы отправить эти изменения в ваш удаленный репозиторий, выполните
107 | git push origin master
108 | Можно изменить master на любую другую ветвь, чтобы отправить изменения на неё.
109 |
110 | Если вы еще не клонировали существующий репозиторий и хотите подключить ваш к удаленному, вам нужно добавить его, выполнив
111 | git remote add origin <адрес_сервера>
112 | Теперь вы можете отправлять изменения на удаленный репозиторий
113 |
114 |
120 | Ветки используются для разработки функциональности, изолированной от остальной. Ветка master используется по умолчанию, когда вы создаете репозиторий. 121 | Используйте другие ветки для разработки и слияние в master, когда разработка завершена. 122 |
123 |
124 |
125 | Создать новую ветку с названием "feature_x" и переключиться на неё можно командой
126 | git checkout -b feature_x
127 | переключиться обратно на master
128 | git checkout master
129 | удалить ветку
130 | git branch -d feature_x
131 | ветка не будет доступна тем, кто пользуется с вами удаленным репозиторием, пока вы не отправите её туда
132 | git push origin <имя_ветки>
133 |
139 | Обновить ваш локальный репозиторий можно командой
140 | git pull
141 | которая заберет изменения из удаленного репозитория и проведет слияние с активной веткой.
142 | Для того чтобы слить другую ветку с активной (например master), используйте команду
143 | git merge <имя_ветки>
144 | В обоих случаях git пытается автоматически слить изменения. К сожалению, это не всегда возможно и результатом станет конфликт.
145 | Вы ответственны за разрешение возникших конфликтов,
146 | путем ручного редактирования файлов, указанных git. После изменений вам надо пометить их как слитые
147 | git add <имя_файла>
148 | перед слиянием вы можете предварительно посмотреть на изменения
149 | git diff <имя_ветки> <имя_другой_ветки>
150 |
156 | Рекомендуется использовать метки для закрепления момента выпуска версий. Это популярная практика, которая также используется в SVN. Создать новую метку с именем 1.0.0 можно, выполнив
157 | git tag 1.0.0 1b2e1d63ff
158 | 1b2e1d63ff это первые десять цифр уникального идентификатора (id), с которым будет связана метка. Чтобы посмотреть идентификаторы коммитов, выполните
159 | git log
160 | Можно использовать меньшее количество символов в качестве идентификатора, с учетом того, что он является уникальным.
161 |
167 | В случае, если вы сделали что-то не то, вы можете заменить локальные изменения, используя команду
168 | git checkout -- <имя_файла>
169 | произойдет замена изменений в вашем рабочем каталоге, на то, что сейчас находится в HEAD. Изменения, уже внесенные в индекс, также как и новые файлы, будут сохранены.
170 |
172 | Если же вы хотите удалить все ваши локальные изменения и коммиты, получите (fetch) последние изменения с сервера и укажите локальной ветке master на них вот так
173 | git fetch origin
174 | git reset --hard origin/master
175 |
181 | встроенный в git графический интерфейс
182 | gitk
183 | использовать цветной вывод в терминале
184 | git config color.ui true
185 | выводить в логе коммит на одной строке
186 | git config format.pretty oneline
187 | интерактивный способ добавления в индекс
188 | git add -i
189 |
196 |
206 |
git'e başlamak için basit bir rehber. atla deve değil ;)
16 | Tweet 17 | 18 | 42 |
43 | 49 | OSX için git'i İndir 50 |
51 |52 | Windows için git'i İndir 53 |
54 |55 | Linux için git'i İndir 56 |
57 |
62 | yeni bir depo oluşturmak için, bir klasör oluşturup içerisinde
63 | git init
64 | komutunu çalıştırın.
65 |
71 | yerel deponuzun çalışan bir kopyasını oluşturmak için
72 | git clone /yol/depo
73 | uzak sunucu kullandığımız durumda
74 | git clone kullaniciadi@sunucu:/yol/depo
75 |
81 | yerel deponuz git tarafından yönetilen üç "ağaçtan" oluşur.
82 | birincisi gerçek dosyaları tutan Çalışma Dizini.
83 | ikinci etap Stage ve
84 | sonuncusu yaptığınız son commit'i gösteren HEAD.
85 |
87 |
92 | Değişiklikleri belirtmek (Index'e eklemek) için
93 | git add <dosyaadı>
94 | git add *
95 | Temel git iş akışında bu ilk adımdır. Değişiklikleri depoya eklemek için
96 | git commit -m "Teslim mesajı"
97 | Şimdi dosyalar HEAD'e eklendi, fakat henüz uzak deponuza değil.
98 |
104 | Şimdi değişiklikleriniz yerel deponuzun HEAD'i içerisinde.
Bu değişiklikleri uzak deponuza göndermek için,
105 | git push origin master
106 | Değişiklikleri uzak deponuzdaki göndermek istediğiniz dal'ı master ile değiştirin.
107 |
108 | Henüz uzak bir deponuz yoksa ve uzak depo eklemek istiyorsanız,
109 | git remote add origin <sunucu>
110 | Şimdi değişikliklerinizi uzak sunucuya gönderebilirsiniz
111 |
112 |
118 | Dallar farklı özellikleri ayrı ayrı geliştirmek için kullanılır. Yeni bir depo oluşturduğunuzda master "varsayılan" daldır. Diğer dallar geliştirildikten sonra master'a birleştirilir. 119 |
120 |
121 |
122 | "feature_x" adıyla yeni bir dal oluşturup o dala geçmek için
123 | git checkout -b feature_x
124 | master'a geri geçmek için
125 | git checkout master
126 | ve oluşturduğumuz dalı silmek için
127 | git branch -d feature_x
128 | bir dalı uzak deponuza göndermedikçe
başkaları tarafından kullanılabilir olmaz
129 | git push origin <dal>
130 |
136 | en son değişiklikleri (commit) yerel deponuza almak için
137 | git pull
138 | komutunu çalıştırın. Bu değişiklikleri al (fetch) ve birleştir (merge) yapacaktır.
139 | Aktif dala (örn. master) başka bir dalı birleştirmek için
140 | git merge <dal>
141 | her iki durumda da git değişiklikleri otomatik birleştirmeyi (auto-merge) dener.
142 | Maalesef, bu her zaman mümkün olmaz ve çakışmalarla (conflict) sonuçlanır.
143 | Git tarafından gösterilen dosyaları elle düzenleyerek bu çakışmaları birleştirmek size düşer.
144 | Değişikliklerden sonra, dosyaları eklemek için
145 | git add <dosyaadı>
146 |
147 | değişiklikleri birleştirmeden önce, önizleme yapmak için
148 | git diff <kaynak_dal> <hedef_dal>
149 |
155 | yazılım sürümleriniz için sürüm adı (tag) oluşturmanız tavsiye edilir. bu SVN'de de mevcut olan bilindik bir kavramdır. 1.0.0 adıyla bir sürüm numarası (tag) oluşturmak için
156 | git tag 1.0.0 1b2e1d63ff
157 | buradaki 1b2e1d63ff yayımlanacak yazılım sürümünüzün işlem numarasının ilk 10 karakteridir. İşlem kimlik numaralarını görmek için
158 | git log
159 | tekil olduğu sürece daha az işlem numarası da kullanabilirsiniz.
160 |
166 | Yanlış birşey yapmanız durumunda (tabi ki böyle şeyler hiç olmaz ;)) yerel değişiklikleri geri almak için
167 | git checkout -- <dosyaadı>
168 | bu değişikliklerinizi HEAD içerisindeki son içerik ile değiştirir. Index'e önceden eklenmiş değişiklikler ve yeni dosyalar korunacaktır.
169 |
171 | Eğer tüm yerel değişiklik ve teslimlerinizi iptal etmek istiyorsanız, sunucudan en son kayıtları getirin ve yerel master dalınıza gösterin
172 | git fetch origin
173 | git reset --hard origin/master
174 |
180 | dahili git GUI (Grafiksel Kullanıcı Arayüzü)
181 | gitk
182 | renkli git çıktısı kullanın
183 | git config color.ui true
184 | commit başına sadece tek satır log gösterin
185 | git config format.pretty oneline
186 | interaktif ekleme kullanın
187 | git add -i
188 |
195 |
205 |
Đây là một hướng dẫn đơn giản cho người mới học ;)
16 | Tweet 17 | 18 | 42 |
43 | 49 | Tải git về cho OSX 50 |
51 |52 | Tải git về cho Windows 53 |
54 |55 | Tải git về cho Linux 56 |
57 |
62 | Để tạo 1 repository mới, bạn hãy mở cửa sổ lệnh và gõ dòng lệnh sau
63 | git init
64 |
70 | để clone 1 repository có sẵn ở trên máy cục bộ, bạn hãy sử dụng dòng lệnh sau:
71 | git clone /đường-dẫn-đến/repository/
72 | Nếu repository đó ở máy chủ khác thì bạn hãy gõ dòng lệnh sau:
73 | git clone tênusername@địachỉmáychủ:/đường-dẫn-đến/repository
74 |
80 | thư mục cục bộ của bạn bao gồm ba "trees" được duy trì bởi git.
81 | đầu tiên là Thư Mục Đang Làm Việc (Working Directory) có chứa các tập tin hiện tại.
82 | cái thứ hai là Chỉ Mục (Index) đóng vai trò như staging area và
83 | cuối cùng là HEAD trỏ đến commit gần đây nhất của bạn.
84 |
86 |
91 | Bạn có thể đề xuất thay đổi (thêm nó vào chỉ mục Index) bằng cách
92 | git add <tên-tập-tin>
93 | git add *
94 | Đây là bước đầu tiên trong quy trình git cơ bản. Để thật sự commit những thay đổi, bạn sử dụng
95 | git commit -m "Ghi chú Commit"
96 | Bây giờ thì tập tin đã được commit đến HEAD, nhưng chưa phải trên thư mục remote.
97 |
103 | Thay đổi của bạn hiện đang nằm tại HEAD của bản sao cục bộ đang làm việc. Để gửi những thay đổi đó đến repository remote, bạn thực thi
104 | git push origin master
105 | Thay đổi master bằng bất cứ nhánh nào mà bạn muốn đầy những thay đổi đến.
106 |
107 | Nếu bạn chưa clone một repository hiện có và muốn kết nối repository của bạn đến máy chủ remote, bạn phải thêm nó với
108 | git remote add origin <máy-chủ>
109 | Bây giờ bạn đã có thể đẩy các thay đổi của mình vào máy chủ đã chọn
110 |
111 |
117 | Các nhánh (branches) được dùng để phát triển tính năng tách riêng ra từ những nhánh khác. Nhánh master là nhánh "mặc định" khi bạn tạo một repository. Sử dụng các nhánh khác tri đang trong giai đoạn phát triển và merge trở lại nhánh master một khi đã hoàn tất. 118 |
119 |
120 |
121 | tạo một nhánh mới và đặt tên là "feature_x" và chuyển qua nhánh đó (từ master) bằng cách
122 | git checkout -b feature_x
123 | trở lại nhánh master
124 | git checkout master
125 | và xóa nhánh feature_x đó lần nửa
126 | git branch -d feature_x
127 | một nhánh không có giá trị với các nhánh khác trừ khi bạn đẩy nhánh đó đến remote repository
128 | git push origin <nhánh>
129 |
135 | để cập nhật repository cục bộ của bạn và commit mới nhất, thực thi
136 | git pull
137 | trong thự mục đang làm việc để lấy về (fetch) và trộn (merge) các thay đổi ở remote.
138 | để trộn một nhánh khác vào nhánh đang hoạt động (vd: master), sử dụng
139 | git merge <nhánh>
140 | trong cả hai trường hợp, git cố gắng trộn tự động (auto-merge) các thay đổi. Không may, điều này không phải lúc nào cũng làm được và thường dẫn đến xung đột.
141 | Trách nhiệm của bạn là trộn các xung đột đó
142 | thủ công bằng cách chỉnh sửa các tập tin được hiển thị bởi git. Sau khi thay đổi, bạn phải đánh dấu chúng là đã được trộn (merged) với lệnh
143 | git add <tên-tập-tin>
144 | trước khi trộn các thay đổi, bạn có thể xem trước chúng bằng các
145 | git diff <nhánh_nguồn> <nhánh_mục_tiêu>
146 |
152 | người ta khuyên nên tạo nhãn (tags) khi phát hành phần mềm. đây là khái niệm được biết đến, đã từng có trên SVN. Bạn tạo tag mới tên là 1.0.0 bằng cách
153 | git tag 1.0.0 1b2e1d63ff
154 | chuỗi 1b2e1d63ff là 10 ký tự đầu tiên của mã commit (commit id) mà bạn muốn tham chiếu đến bằng nhãn của bạn. Bạn có thể lấy mã commit với lệnh
155 | git log
156 | bạn cũng có thể sử dụng ít ký tự hơn từ mã commit, nó chỉ cần phải là duy nhất.
157 |
163 | Trong trường hợp bạn làm sai điều gì đó, bạn có thể thay thế các thay đổi cục bộ bằng lệnh
164 | git checkout -- <tên-tập-tin>
165 | lệnh này thay thế những thay đổi trong "tree" đang làm việc với nội dung mới nhất của HEAD. Các thay đổi đã được thêm vào chỉ mục, kể cả các tập tin mới, điều này sẽ được giữ lại.
166 |
168 | Nếu bạn muốn hủy tất cả thay đổi và commit cục bộ, lấy về (fetch) lịch sử gần đây nhất từ máy chủ và trỏ nhánh master cục bộ vào nó như sau
169 | git fetch origin
170 | git reset --hard origin/master
171 |
177 | git GUI tích hợp sẵn
178 | gitk
179 | sử dụng kết quả git với nhiều màu
180 | git config color.ui true
181 | hiện log trên chỉ một dùng mỗi commit
182 | git config format.pretty oneline
183 | sử dụng thêm tập tin tương tác
184 | git add -i
185 |
192 |
202 |
215 |
218 | 219 |49 | 下载 git OSX 版 50 |
51 |52 | 下载 git Windows 版 53 |
54 |55 | 下载 git Linux 版 56 |
57 |
62 | 创建新文件夹，打开，然后执行
63 | git init
64 | 以创建新的 git 仓库。
65 |
71 | 执行如下命令以创建一个本地仓库的克隆版本：
72 | git clone /path/to/repository
73 | 如果是远端服务器上的仓库，你的命令会是这个样子：
74 | git clone username@host:/path/to/repository
75 |
81 | 你的本地仓库由 git 维护的三棵“树”组成。第一个是你的 工作目录，它持有实际文件；第二个是 暂存区（Index），它像个缓存区域，临时保存你的改动；最后是 HEAD，它指向你最后一次提交的结果。
82 |
84 |
89 | 你可以提出更改（把它们添加到暂存区），使用如下命令：
90 | git add <filename>
91 | git add *
92 | 这是 git 基本工作流程的第一步；使用如下命令以实际提交改动：
93 | git commit -m "代码提交信息"
94 | 现在，你的改动已经提交到了 HEAD，但是还没到你的远端仓库。
95 |
101 | 你的改动现在已经在本地仓库的 HEAD 中了。执行如下命令以将这些改动提交到远端仓库：
102 | git push origin master
103 | 可以把 master 换成你想要推送的任何分支。
104 |
105 | 如果你还没有克隆现有仓库，并欲将你的仓库连接到某个远程服务器，你可以使用如下命令添加：
106 | git remote add origin <server>
107 | 如此你就能够将你的改动推送到所添加的服务器上去了。
108 |
109 |
115 | 分支是用来将特性开发绝缘开来的。在你创建仓库的时候，master 是“默认的”分支。在其他分支上进行开发，完成后再将它们合并到主分支上。 116 |
117 |
118 |
119 | 创建一个叫做“feature_x”的分支，并切换过去：
120 | git checkout -b feature_x
121 | 切换回主分支：
122 | git checkout master
123 | 再把新建的分支删掉：
124 | git branch -d feature_x
125 | 除非你将分支推送到远端仓库，不然该分支就是 不为他人所见的：
126 | git push origin <branch>
127 |
133 | 要更新你的本地仓库至最新改动，执行：
134 | git pull
135 | 以在你的工作目录中 获取（fetch） 并 合并（merge） 远端的改动。
136 | 要合并其他分支到你的当前分支（例如 master），执行：
137 | git merge <branch>
138 | 在这两种情况下，git 都会尝试去自动合并改动。遗憾的是，这可能并非每次都成功，并可能出现冲突（conflicts）。
139 | 这时候就需要你修改这些文件来手动合并这些冲突（conflicts）。改完之后，你需要执行如下命令以将它们标记为合并成功：
140 | git add <filename>
141 | 在合并改动之前，你可以使用如下命令预览差异：
142 | git diff <source_branch> <target_branch>
143 |
149 | 为软件发布创建标签是推荐的。这个概念早已存在，在 SVN 中也有。你可以执行如下命令创建一个叫做 1.0.0 的标签：
150 | git tag 1.0.0 1b2e1d63ff
151 | 1b2e1d63ff 是你想要标记的提交 ID 的前 10 位字符。可以使用下列命令获取提交 ID：
152 | git log
153 | 你也可以使用少一点的提交 ID 前几位，只要它的指向具有唯一性。
154 |
160 | 如果你想了解本地仓库的历史记录，最简单的命令就是使用:
161 | git log
162 | 你可以添加一些参数来修改他的输出，从而得到自己想要的结果。 只看某一个人的提交记录:
163 | git log --author=bob
164 | 一个压缩后的每一条提交记录只占一行的输出:
165 | git log --pretty=oneline
166 | 或者你想通过 ASCII 艺术的树形结构来展示所有的分支, 每个分支都标示了他的名字和标签:
167 | git log --graph --oneline --decorate --all
168 | 看看哪些文件改变了:
169 | git log --name-status
170 | 这些只是你可以使用的参数中很小的一部分。更多的信息，参考：
171 | git log --help
172 |
178 | 假如你操作失误（当然，这最好永远不要发生），你可以使用如下命令替换掉本地改动：
179 | git checkout -- <filename>
180 | 此命令会使用 HEAD 中的最新内容替换掉你的工作目录中的文件。已添加到暂存区的改动以及新文件都不会受到影响。
181 |
183 | 假如你想丢弃你在本地的所有改动与提交，可以到服务器上获取最新的版本历史，并将你本地主分支指向它：
184 | git fetch origin
185 | git reset --hard origin/master
186 |
192 | 内建的图形化 git：
193 | gitk
194 | 彩色的 git 输出：
195 | git config color.ui true
196 | 显示历史记录时，每个提交的信息只显示一行：
197 | git config format.pretty oneline
198 | 交互式添加文件到暂存区：
199 | git add -i
200 |
207 |
217 |