├── Alice.txt ├── LICENSE.md ├── README.md └── img ├── add.png ├── add_branch.png ├── after_push.png ├── before_ff_merge.png ├── before_rebase.png ├── branches.png ├── branches_diverge.png ├── checkout_branch.png ├── cherry_branches.png ├── cherry_pick.png ├── cherry_pick_range.png ├── clone.png ├── commit.png ├── components.png ├── diffs.png ├── fetch.png ├── ff_merge.png ├── force_push.png ├── github.png ├── many_dev_environments.png ├── merge.png ├── pull.png ├── push.png ├── rebase.png └── tracking_files.png /Alice.txt: -------------------------------------------------------------------------------- 1 | Hi! I'm Alice. I'm a file someone added to this repository a while ago. 2 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | including for purposes of Section 3(b); and 307 | 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | 429 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Learn `git` concepts, not commands 2 | 3 | **An interactive git tutorial meant to teach you how git works, not just which commands to execute.** 4 | 5 | So, you want to use git, right? 6 | 7 | But you don't just want to learn commands, you want to understand what you're using? 8 | 9 | Then this is meant for you! 10 | 11 | Let's get started! 12 | 13 | --- 14 | 15 | > Based on the general concept from Rachel M. Carmena's blog post on [How to teach Git](https://rachelcarmena.github.io/2018/12/12/how-to-teach-git.html). 16 | > 17 | > While I find many git tutorials on the internet to be too focused on what to do instead of how things work, the most invaluable resource for both (and source for this tutorial!) are the [git Book](https://git-scm.com/book/en/v2) and [Reference page](https://git-scm.com/docs). 18 | > 19 | > So if you're still interested when you're done here, go check those out! I do hope the somewhat different concept of this tutorial will aid you in understanding all the other git features detailed there. 20 | 21 | --- 22 | - [Learn `git` concepts, not commands](#learn-git-concepts-not-commands) 23 | - [- Reading history](#--reading-history) 24 | - [Overview](#overview) 25 | - [Getting a _Remote Repository_](#getting-a-remote-repository) 26 | - [Adding new things](#adding-new-things) 27 | - [Making changes](#making-changes) 28 | - [Branching](#branching) 29 | - [Merging](#merging) 30 | - [Fast-Forward merging](#fast-forward-merging) 31 | - [Merging divergent branches](#merging-divergent-branches) 32 | - [Resolving conflicts](#resolving-conflicts) 33 | - [Rebasing](#rebasing) 34 | - [Resolving conflicts](#resolving-conflicts-1) 35 | - [Updating the _Dev Environment_ with remote changes](#updating-the-dev-environment-with-remote-changes) 36 | - [_Fetching_ Changes](#fetching-changes) 37 | - [_Pulling_ Changes](#pulling-changes) 38 | - [Stashing changes](#stashing-changes) 39 | - [Pulling with Conflicts](#pulling-with-conflicts) 40 | - [Cherry-picking](#cherry-picking) 41 | - [Rewriting history](#rewriting-history) 42 | - [Amending the last Commit](#amending-the-last-commit) 43 | - [Interactive Rebase](#interactive-rebase) 44 | - [Fixing a commit that's further in the past](#fixing-a-commit-thats-further-in-the-past) 45 | - [Public History, why you shouldn't rewrite it, and how to still do it safely](#public-history-why-you-shouldnt-rewrite-it-and-how-to-still-do-it-safely) 46 | - [Reading history](#reading-history) 47 | --- 48 | 49 | ## Overview 50 | 51 | In the picture below you see four boxes. One of them stands alone, while the other three are grouped together in what I'll call your _Development Environment_. 52 | 53 | ![git components](img/components.png) 54 | 55 | We'll start with the one that's on its own though. The _Remote Repository_ is where you send your changes when you want to share them with other people, and where you get their changes from. If you've used other version control systems there's nothing interesting about that. 56 | 57 | The _Development Environment_ is what you have on your local machine. 58 | The three parts of it are your _Working Directory_, the _Staging Area_ and the _Local Repository_. We'll learn more about those as we start using git. 59 | 60 | Choose a place in which you want to put your _Development Environment_. 61 | Just go to your home folder, or wherever you like to put your projects. You don't need to create a new folder for your _Dev Environment_ though. 62 | 63 | ## Getting a _Remote Repository_ 64 | 65 | Now we want to grab a _Remote Repository_ and put what's in it onto your machine. 66 | 67 | I'd suggest we use this one ([https://github.com/UnseenWizzard/git_training.git](https://github.com/UnseenWizzard/git_training.git) if you're not already reading this on github). 68 | 69 | > To do that I can use `git clone https://github.com/UnseenWizzard/git_training.git` 70 | > 71 | > But as following this tutorial will need you to get the changes you make in your _Dev Environment_ back to the _Remote Repository_, and github doesn't just allow anyone to do that to anyone's repo, you'll best create a _fork_ of it right now. There's a button to do that on the top right of this page. 72 | 73 | Now that you have a copy of my _Remote Repository_ of your own, it's time to get that onto your machine. 74 | 75 | For that we use `git clone https://github.com/{YOUR USERNAME}/git_training.git` 76 | 77 | As you can see in the diagram below, this copies the _Remote Repository_ into two places, your _Working Directory_ and the _Local Repository_. 78 | Now you see how git is _distributed_ version control. The _Local Repository_ is a copy of the _Remote_ one, and acts just like it. The only difference is that you don't share it with anyone. 79 | 80 | What `git clone` also does, is create a new folder wherever you called it. There should be a `git_training` folder now. Open it. 81 | 82 | ![Cloning the remote repo](img/clone.png) 83 | 84 | ## Adding new things 85 | 86 | Someone already put a file named `Alice.txt` into the _Remote Repository_. It's kind of lonely there, so let's create a new file and call it `Bob.txt`. 87 | 88 | What you've just done is add the file to your _Working Directory_. 89 | There are two kinds of files in your _Working Directory_: _tracked_ files that git knows about and _untracked_ files that git doesn't know about (yet). 90 | 91 | To see what's going on in your _Working Directory_ run `git status`, which will tell you what branch you're on, whether your _Local Repository_ is different from the _Remote_ and the state of _tracked_ and _untracked_ files. 92 | 93 | You'll see that `Bob.txt` is untracked, and `git status` even tells you how to change that. 94 | In the picture below you can see what happens when you follow the advice and execute `git add Bob.txt`: You've added the file to the _Staging Area_, where you collect all the changes you wish to put into _Repository_. 95 | 96 | ![Adding changes to the staging area](img/add.png) 97 | 98 | When you have added all your changes (which right now is only adding Bob), you're ready to _commit_ what you just did to the _Local Repository_. 99 | 100 | The collected changes that you _commit_ are some meaningful chunk of work, so when you now run `git commit` a text editor will open and allow you to write a message telling everything what you just did. When you save and close the message file, your _commit_ is added to the _Local Repository_. 101 | 102 | ![Committing to the local repo](img/commit.png) 103 | 104 | You can also add your _commit message_ right there in the command line if you call `git commit` like this: `git commit -m "Add Bob"`. But because you want to write [good commit messages](https://chris.beams.io/posts/git-commit/) you really should take your time and use the editor. 105 | 106 | Now your changes are in your local repository, which is a good place for them to be as long as no one else needs them or you're not yet ready to share them. 107 | 108 | In order to share your commits with the _Remote Repository_ you need to `push` them. 109 | 110 | ![Pushing to the local repo](img/push.png) 111 | 112 | Once you run `git push` the changes will be sent to the _Remote Repository_. In the diagram below you see the state after your `push`. 113 | 114 | ![State of all components after pushing changes](img/after_push.png) 115 | 116 | ## Making changes 117 | So far we've only added a new file. Obviously the more interesting part of version control is changing files. 118 | 119 | Have a look at `Alice.txt`. 120 | 121 | It actually contains some text, but `Bob.txt` doesn't, so lets change that and put `Hi!! I'm Bob. I'm new here.` in there. 122 | 123 | If you run `git status` now, you'll see that `Bob.txt` is _modified_. 124 | In that state the changes are only in your _Working Directory_. 125 | 126 | If you want to see what has changed in your _Working Directory_ you can run `git diff`, and right now see this: 127 | 128 | ```Diff 129 | diff --git a/Bob.txt b/Bob.txt 130 | index e69de29..3ed0e1b 100644 131 | --- a/Bob.txt 132 | +++ b/Bob.txt 133 | @@ -0,0 +1 @@ 134 | +Hi!! I'm Bob. I'm new here. 135 | ``` 136 | 137 | Go ahead and `git add Bob.txt` like you've done before. As we know, this moves your changes to the _Staging Area_. 138 | 139 | I want to see the changes we just _staged_, so let's show the `git diff` again! You'll notice that this time the output is empty. This happens because `git diff` operates on the changes in your _Working Directory_ only. 140 | 141 | To show what changes are already_staged_, we can use `git diff --staged` and we'll see the same diff output as before. 142 | 143 | I just noticed that we put two exclamation marks after the 'Hi'. I don't like that, so lets change `Bob.txt` again, so that it's just 'Hi!' 144 | 145 | If we now run `git status` we'll see that there are two changes: the one we already _staged_ where we added text, and the one we just made, which is still only in the working directory. 146 | 147 | We can have a look at the `git diff` between the _Working Directory_ and what we've already moved to the _Staging Area_, to show what has changed since we last felt ready to _stage_ our changes for a _commit_. 148 | 149 | ```Diff 150 | diff --git a/Bob.txt b/Bob.txt 151 | index 8eb57c4..3ed0e1b 100644 152 | --- a/Bob.txt 153 | +++ b/Bob.txt 154 | @@ -1 +1 @@ 155 | -Hi!! I'm Bob. I'm new here. 156 | +Hi! I'm Bob. I'm new here. 157 | ``` 158 | 159 | As the change is what we wanted, let's `git add Bob.txt` to stage the current state of the file. 160 | 161 | Now we're ready to `commit` what we just did. I went with `git commit -m "Add text to Bob"` because I felt that for such a small change writing one line would be enough. 162 | 163 | As we know, the changes are now in the _Local Repository_. 164 | We might still want to know what change we just _committed_ and what was there before. 165 | 166 | We can do that by comparing commits. 167 | Every commit in git has a unique hash by which it is referenced. 168 | 169 | If we have a look at the `git log` we'll not only see a list of all the commits with their _hash_ as well as _Author_ and _Date_, we also see the state of our _Local Repository_ and the latest local information about _remote branches_. 170 | 171 | Right now the `git log` looks something like this: 172 | 173 | ```ShellSession 174 | commit 87a4ad48d55e5280aa608cd79e8bce5e13f318dc (HEAD -> master) 175 | Author: {YOU} <{YOUR EMAIL}> 176 | Date: Sun Jan 27 14:02:48 2019 +0100 177 | 178 | Add text to Bob 179 | 180 | commit 8af2ff2a8f7c51e2e52402ecb7332aec39ed540e (origin/master, origin/HEAD) 181 | Author: {YOU} <{YOUR EMAIL}> 182 | Date: Sun Jan 27 13:35:41 2019 +0100 183 | 184 | Add Bob 185 | 186 | commit 71a6a9b299b21e68f9b0c61247379432a0b6007c 187 | Author: UnseenWizzard 188 | Date: Fri Jan 25 20:06:57 2019 +0100 189 | 190 | Add Alice 191 | 192 | commit ddb869a0c154f6798f0caae567074aecdfa58c46 193 | Author: Nico Riedmann 194 | Date: Fri Jan 25 19:25:23 2019 +0100 195 | 196 | Add Tutorial Text 197 | 198 | Changes to the tutorial are all squashed into this commit on master, to keep the log free of clutter that distracts from the tutorial 199 | 200 | See the tutorial_wip branch for the actual commit history 201 | ``` 202 | 203 | Here we see a few interesting things: 204 | * The first two commits are made by me. 205 | * Your initial commit to add Bob is the current _HEAD_ of the _master_ branch on the _Remote Repository_. We'll look at this again when we talk about branches and getting remote changes. 206 | * The latest commit in the _Local Repository_ is the one we just made, and now we know its hash. 207 | 208 | > Note that the actual commit hashes will be different for you. If you want to know how exactly git arrives at those revision IDs have a look at [this interesting article](https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-git-commit.html). 209 | 210 | To compare that commit and a previous one we can do `git diff ^!` (where the `^!` tells git to compare the commit to the one that came before it). So in this case I run `git diff 87a4ad48d55e5280aa608cd79e8bce5e13f318dc^!`. 211 | 212 | We can also do `git diff 8af2ff2a8f7c51e2e52402ecb7332aec39ed540e 87a4ad48d55e5280aa608cd79e8bce5e13f318dc` for the same result and in general to compare any two commits. Note that the format here is `git diff `, so our new commit comes second. 213 | 214 | In the diagram below you again see the different stages of a change and the corresponding diff commands. 215 | 216 | ![States of a change an related diff commands](img/diffs.png) 217 | 218 | Now that we're sure we made the change we wanted, go ahead and `git push`. 219 | 220 | ## Branching 221 | 222 | Another thing that makes git great, is the fact that working with branches is really easy and integral part of how you work with git. 223 | 224 | In fact we've been working on a branch since we've started. 225 | 226 | When you `clone` the _Remote Repository_ your _Dev Environment_ automatically starts on the repositories main branch, i.e. _master_. 227 | 228 | Most work-flows with git include making your changes on a _branch_, before you `merge` them back into _master_. 229 | Usually you'll be working on your own _branch_, until you're done and confident in your changes which can then be merged into the _master_. 230 | 231 | > Many git repository managers like _GitLab_ and _GitHub_ also allow for branches to be _protected_, which means that not everyone is allowed to just `push` changes there. There the _master_ is usually protected by default. 232 | 233 | Don't worry, we'll get back to all of these things in more detail when we need them. 234 | 235 | Right now we want to create a branch to make some changes there. Maybe you just want to try something on your own and not mess with the working state on your _master_ branch, or you're not allowed to `push` to _master_. 236 | 237 | Branches live in the _Local_ and _Remote Repository_. When you create a new branch, the branches contents will be a copy of the currently committed state of whatever branch you are currently working on. 238 | 239 | Let's make some change to `Alice.txt`! How about we put some text on the second line? 240 | 241 | We want to share that change, but not put it on _master_ right away, so let's create a branch for it using `git branch `. 242 | 243 | To create a new branch called `change_alice` you can run `git branch change_alice`. 244 | 245 | This adds the new branch to the _Local Repository_. 246 | 247 | While your _Working Directory_ and _Staging Area_ don't really care about branches, you always `commit` to the branch you are currently on. 248 | 249 | You can think of _branches_ in git as pointers, pointing to a series of commits. When you `commit`, you add to whatever you're currently pointing to. 250 | 251 | Just adding a branch, doesn't directly take you there, it just creates such a pointer. 252 | In fact the state your _Local Repository_ is currently at, can be viewed as another pointer, called _HEAD_, which points to what branch and commit you are currently at. 253 | 254 | If that sounds complicated the diagrams below will hopefully help clear things up a bit: 255 | 256 | ![State after adding branch](img/add_branch.png) 257 | 258 | To switch to our new branch you will have to use `git checkout change_alice`. What this does is simply move the _HEAD_ to the branch you specify. 259 | 260 | > As you'll usually want to switch to a branch right after creating it, there is the convenient `-b` option available for the `checkout` command, which allows you to just directly `checkout` a _new_ branch, so you don't have to create it beforehand. 261 | 262 | > So to create and switch to our `change_alice` branch, we could also just have called `git checkout -b change_alice`. 263 | 264 | ![State after after switching branch](img/checkout_branch.png) 265 | 266 | You'll notice that your _Working Directory_ hasn't changed and the fact that we've _modified_ `Alice.txt` is not related to the branch we're on yet. Now you can `add` and `commit` the change to `Alice.txt` just like we did on the _master_ before, which will _stage_ (at which point it's still unrelated to the branch) and finally _commit_ your change to the `change_alice` branch. 267 | 268 | There's just one thing you can't do yet. Try to `git push` your changes to the _Remote Repository_. 269 | 270 | You'll see the following error and - as git is always ready to help - a suggestion how to resolve the issue: 271 | 272 | ```ShellSession 273 | fatal: The current branch change_alice has no upstream branch. 274 | To push the current branch and set the remote as upstream, use 275 | 276 | git push --set-upstream origin change_alice 277 | ``` 278 | 279 | But we don't just want to blindly do that. We're here to understand what's actually going on. So what are _upstream branches_ and _remotes_? 280 | 281 | Remember when we `cloned` the _Remote Repository_ a while ago? At that point it didn't only contain this tutorial and `Alice.txt` but actually two branches. 282 | 283 | The _master_ we just went ahead and started working on, and the one I called "tutorial_wip" on which I commit all the changes I make to this tutorial. 284 | 285 | When we copied the things in the _Remote Repository_ into your _Dev Environment_ a few extra steps happened under the hood. 286 | 287 | Git setup the _remote_ of your _Local Repository_ to be the _Remote Repository_ you cloned and gave it the default name `origin`. 288 | 289 | >Your _Local Repository_ can track several _remotes_ and they can have different names, but we'll stick to the `origin` and nothing else for this tutorial. 290 | 291 | Then it copied the two remote branches into your _Local Repository_ and finally it `checkout`ed _master_ for you. 292 | 293 | When doing that, another implicit step happens. When you `checkout` a branch name that has an exact match in the remote branches, you will get a new _local_ branch that is linked to the _remote_ branch. The _remote_ branch is the _upstream branch_ of your _local_ one. 294 | 295 | In the diagrams earlier you can see just the local branches you have. You can see that list of local branches by running `git branch`. 296 | 297 | If you want to also see the _remote_ branches your _Local Repository_ knows, you can use `git branch -a` to list all of them. 298 | 299 | ![Remote and local branches`](img/branches.png) 300 | 301 | Now we can call the suggested `git push --set-upstream origin change_alice`, and `push` the changes on our branch to a new _remote_. This will create a `change_alice` branch on the _Remote Repository_ and set our _local_ `change_alice` to track that new branch. 302 | 303 | > There is another option if we actually want our branch to track something that already exists on the _Remote Repository_. Maybe a colleague has already pushed some changes, while we were working on some related issue on our local branch, and we'd like to integrate the two. Then we could just set the _upstream_ for our `change_alice` branch to a new _remote_ by using `git branch --set-upstream-to=origin/change_alice` and from there to track the _remote_ branch. 304 | 305 | After that went through have a look at your _Remote Repository_ on github, your branch will be there, ready for other people to see and work with. 306 | 307 | We'll get to how you can get other people's changes into your _Dev Environment_ soon, but first we'll work a bit more with branches, to introduce all the concepts that also come into play when we get new things from the _Remote Repository_. 308 | 309 | ## Merging 310 | 311 | As you and everyone else will generally be working on branches, we need to talk about how to get changes from one branch into the other by _merging_ them. 312 | 313 | 314 | We've just changed `Alice.txt` on the `change_alice` branch, and I'd say we're happy with the changes we made. 315 | 316 | If you go and `git checkout master`, the `commit` we made on the other branch will not be there. To get the changes into master we need to `merge` the `change_alice` branch _into_ master. 317 | 318 | Note that you always `merge` a particular branch _into_ the one you're currently at. 319 | 320 | ### Fast-Forward merging 321 | 322 | As we've already `checked out` _master_, we can now `git merge change_alice`. 323 | 324 | As there are no other _conflicting_ changes to `Alice.txt`, and we've changed nothing on _master_, this will go through without a hitch in what is called a _fast forward_ merge. 325 | 326 | In the diagrams below, you can see that this just means that the _master_ pointer can simply be advanced to where the _change_alice_ one already is. 327 | 328 | The first diagram shows the state before our `merge`, _master_ is still at the commit it originally was, and on the other branch we've made one more commit. 329 | 330 | ![Before fast forward merge](img/before_ff_merge.png) 331 | 332 | The second diagram shows what has changed with our `merge`. 333 | 334 | ![After fast forward merge](img/ff_merge.png) 335 | 336 | ### Merging divergent branches 337 | 338 | Let's try something more complex. 339 | 340 | Add some text on a new line to `Bob.txt` on _master_ and commit it. 341 | 342 | Then `git checkout change_alice`, change `Alice.txt` and commit. 343 | 344 | In the diagram below you see how our commit history now looks. Both _master_ and `change_alice` originated from the same commit, but since then they _diverged_, each having their own additional commit. 345 | 346 | ![Divergent commits](img/branches_diverge.png) 347 | 348 | If you now switch back to master (`git checkout master`) and do `git merge change_alice` a fast-forward merge is not possible. Instead your favorite text editor will open and allow you to change the message of the `merge commit` git is about to make in order to get the two branches back together. You can just go with the default message right now. The diagram below shows the state of our git history after we the `merge`. 349 | 350 | ![Merging branches](img/merge.png) 351 | 352 | The new commit introduces the changes that we've made on the `change_alice` branch into master. 353 | 354 | As you'll remember from before, revisions in git, aren't only a snapshot of your files but also contain information on where they came from. Each `commit` has one or more parent commits. Our new `merge` commit, has both the last commit from _master_ and the commit we made on the other branch as its parents. 355 | 356 | ### Resolving conflicts 357 | 358 | So far our changes haven't interfered with each other. 359 | 360 | Let's introduce a _conflict_ and then _resolve_ it. 361 | 362 | Create and `checkout` a new branch. You know how, but maybe try using `git checkout -b` to make your life easier. 363 | I've called mine `bobby_branch`. 364 | 365 | On the branch we'll make a change to `Bob.txt`. 366 | The first line should still be `Hi!! I'm Bob. I'm new here.`. Change that to `Hi!! I'm Bobby. I'm new here.` 367 | 368 | Stage and then `commit` your change, before you `checkout` _master_ again. Here we'll change that same line to `Hi!! I'm Bob. I've been here for a while now.` and `commit` your change. 369 | 370 | Now it's time to `merge` the new branch into _master_. 371 | When you try that, you'll see the following output: 372 | 373 | ```ShellSession 374 | Auto-merging Bob.txt 375 | CONFLICT (content): Merge conflict in Bob.txt 376 | Automatic merge failed; fix conflicts and then commit the result. 377 | ``` 378 | The same line has changed on both of the branches, and git can't handle this on its own. 379 | 380 | If you run `git status` you'll get all the usual helpful instructions on how to continue. 381 | 382 | First we have to resolve the conflict by hand. 383 | 384 | > For an easy conflict like this one your favorite text editor will do fine. For merging large files with lots of changes a more powerful tool will make your life much easier, and I'd assume your favorite IDE comes with version control tools and a nice view for merging. 385 | 386 | If you open `Bob.txt` you'll see something similar to this (I've truncated whatever we might have put on the second line before): 387 | 388 | ```Diff 389 | <<<<<<< HEAD 390 | Hi! I'm Bob. I've been here for a while now. 391 | ======= 392 | Hi! I'm Bobby. I'm new here. 393 | >>>>>>> bobby_branch 394 | [... whatever you've put on line 2] 395 | ``` 396 | 397 | On top you see what has changed in `Bob.txt` on the current HEAD, below you see what has changed in the branch we're merging in. 398 | 399 | To resolve the conflict by hand, you'll just need to make sure that you end up with some reasonable content and without the special lines git has introduced to the file. 400 | 401 | So go ahead and change the file to something like this: 402 | 403 | ``` 404 | Hi! I'm Bobby. I've been here for a while now. 405 | [...] 406 | ``` 407 | 408 | From here what we're doing is exactly what we'd do for any changes. 409 | We _stage_ them when we `add Bob.txt`, and then we `commit`. 410 | 411 | We already know the commit for the changes we've made to resolve the conflict. It's the _merge commit_ that is always present when merging. 412 | 413 | Should you ever realize in the middle of resolving conflicts that you actually don't want to follow through with the `merge`, you can just `abort` it by running `git merge --abort`. 414 | 415 | ## Rebasing 416 | 417 | Git has another clean way to integrate changes between two branches, which is called `rebase`. 418 | 419 | We still recall that a branch is always based on another. When you create it, you _branch away_ from somewhere. 420 | 421 | In our simple merging example we branched from _master_ at a specific commit, then committed some changes on both _master_ and the `change_alice` branch. 422 | 423 | When a branch is diverging from the one it's based on and you want to integrate the latest changes back into your current branch, `rebase` offers a cleaner way of doing that than a `merge` would. 424 | 425 | As we've seen, a `merge` introduces a _merge commit_ in which the two histories get integrated again. 426 | 427 | Viewed simply, rebasing just changes the point in history (the commit) your branch is based on. 428 | 429 | To try that out, let's first checkout the _master_ branch again, then create/checkout a new branch based on it. 430 | I called mine `add_patrick` and I added a new `Patrick.txt` file and committed that with the message 'Add Patrick'. 431 | 432 | When you've added a commit to the branch, get back to _master_, make a change and commit it. I added some more text to `Alice.txt`. 433 | 434 | Like in our merging example the history of these two branches diverges at a common ancestor as you can see in the diagram below. 435 | 436 | ![History before a rebase](img/before_rebase.png) 437 | 438 | Now let's `checkout add_patrick` again, and get that change that was made on _master_ into the branch we are working on! 439 | 440 | When we `git rebase master`, we re-base our `add_patrick` branch on the current state of the _master_ branch. 441 | 442 | The output of that command gives us a nice hint at what is happening in it: 443 | 444 | ```ShellSession 445 | First, rewinding head to replay your work on top of it... 446 | Applying: Add Patrick 447 | ``` 448 | 449 | As we remember _HEAD_ is the pointer to the current commit we're at in our _Dev Environment_. 450 | 451 | It's pointing to the same place as `add_patrick` before the rebase starts. For the rebase, it then first moves back to the common ancestor, before moving to the current head of the branch we want to re-base ours on. 452 | 453 | So _HEAD_ moves from the _0cfc1d2_ commit, to the _7639f4b_ commit that is at the head of _master_. 454 | Then rebase applies every single commit we made on our `add_patrick` branch to that. 455 | 456 | To be more exact what _git_ does after moving _HEAD_ back to the common ancestor of the branches, is to store parts of every single commit you've made on the branch (the `diff` of changes, and the commit text, author, etc.). 457 | 458 | After that it does a `checkout` of the latest commit of the branch you're rebasing on, and then applies each of the stored changed __as a new commit__ on top of that. 459 | 460 | So in our original simplified view, we'd assume that after the `rebase` the _0cfc1d2_ commit doesn't point to the common ancestor anymore in its history, but points to the head of master. 461 | In fact the _0cfc1d2_ commit is gone, and the `add_patrick` branch starts with a new _0ccaba8_ commit, that has the latest commit of _master_ as its ancestor. 462 | We made it look, like our `add_patrick` was based on the current _master_ not an older version of it, but in doing so we re-wrote the history of the branch. 463 | At the end of this tutorial we'll learn a bit more about re-writing history and when it's appropriate and inappropriate to do so. 464 | 465 | ![History after rebase](img/rebase.png) 466 | 467 | `Rebase` is an incredibly powerful tool when you're working on your own development branch which is based on a shared branch, e.g. the _master_. 468 | 469 | Using rebase you can make sure that you frequently integrate the changes other people make and push to _master_, while keeping a clean linear history that allows you to do a `fast-forward merge` when it's time to get your work into the shared branch. 470 | 471 | Keeping a linear history also makes reading or looking at (try out `git log --graph` or take a look at the branch view of _GitHub_ or _GitLab_) commit logs much more useful than having a history littered with _merge commits_, usually just using the default text. 472 | 473 | ### Resolving conflicts 474 | 475 | Just like for a `merge` you may run into conflicts, if you run into two commits changing the same parts of a file. 476 | 477 | However when you encounter a conflict during a `rebase` you don't fix it in an extra _merge commit_, but can simply resolve it in the commit that is currently being applied. 478 | Again, basing your changes directly on the current state of the original branch. 479 | 480 | Actually resolving conflicts while you `rebase` is very similar to how you would do it for a `merge`, so refer back to that section if you're not sure anymore how to do it. 481 | 482 | The only distinction is, that as you're not introducing a _merge commit_ there is no need to `commit` your resolution. Simply `add` the changes to the _Staging Environment_ and then `git rebase --continue`. The conflict will be resolved in the commit that was just being applied. 483 | 484 | As when merging, you can always stop and drop everything you've done so far when you `git rebase --abort`. 485 | 486 | ## Updating the _Dev Environment_ with remote changes 487 | 488 | So far we've only learned how to make and share changes. 489 | 490 | That fits what you'll do if you're just working on your own, but usually there'll be a lot of people that do just the same, and we're gonna want to get their changes from the _Remote Repository_ into our _Dev Environment_ somehow. 491 | 492 | Because it has been a while, lets have another look at the components of git: 493 | 494 | ![git components](img/components.png) 495 | 496 | Just like your _Dev Environment_ everyone else working on the same source code has theirs. 497 | 498 | ![many dev environments](img/many_dev_environments.png) 499 | 500 | All of these _Dev Environments_ have their own _working_ and _staged_ changes, that are at some point `committed` to the _Local Repository_ and finally `pushed` to the _Remote_. 501 | 502 | For our example, we'll use the online tools offered by _GitHub_, to simulate someone else making changes to the _remote_ while we work. 503 | 504 | Go to your `fork` of this repo on [github.com](https://www.github.com) and open the `Alice.txt` file. 505 | 506 | Find the edit button, make a change, and commit it via the website. 507 | 508 | ![github edit](img/github.png) 509 | 510 | In this repository I have added a remote change to `Alice.txt` on a branch called `fetching_changes_sample`, but in your version of the repository you can of course just change the file on `master`. 511 | 512 | ### _Fetching_ Changes 513 | 514 | We still remember that when you `git push`, you synchronize changes made to the _Local Repository_ into the _Remote Repository_. 515 | 516 | To get changes made to the _Remote_ into your _Local Repository_ you use `git fetch`. 517 | 518 | This gets any changes on the remote - both commits and branches - into your _Local Repository_. 519 | 520 | Note that at this point, changes aren't integrated into the local branches and thus the _Working Directory_ and _Staging Area_ yet. 521 | 522 | ![Fetching changes](img/fetch.png) 523 | 524 | If you run `git status` now, you'll see another great example of git commands telling you exactly what is going on: 525 | 526 | ```ShellSession 527 | > git status 528 | On branch fetching_changes_sample 529 | Your branch is behind 'origin/fetching_changes_sample' by 1 commit, and can be fast-forwarded. 530 | (use "git pull" to update your local branch) 531 | ``` 532 | 533 | ### _Pulling_ Changes 534 | 535 | As we have no _working_ or _staged_ changes, we could just execute `git pull` now to get the changes from the _Repository_ all the way into our working area. 536 | 537 | > Pulling will implicitly also `fetch` the _Remote Repository_, but sometimes it is a good idea to do a `fetch` on its own. 538 | > For example when you want to synchronize any new _remote_ branches, or when you want to make sure your _Local Repository_ is up to date before you do a `git rebase` on something like `origin/master`. 539 | 540 | ![Pulling in changes](img/pull.png) 541 | 542 | Before we `pull`, lets change a file locally to see what happens. 543 | 544 | Lets also change `Alice.txt` in our _Working Directory_ now! 545 | 546 | If you now try to do a `git pull` you'll see the following error: 547 | 548 | ```ShellSession 549 | > git pull 550 | Updating df3ad1d..418e6f0 551 | error: Your local changes to the following files would be overwritten by merge: 552 | Alice.txt 553 | Please commit your changes or stash them before you merge. 554 | Aborting 555 | ``` 556 | 557 | You can not `pull` in any changes, while there are modifications to files in the _Working Directory_ that are also changed by the commits you're `pull`ing in. 558 | 559 | While one way around this is, to just get your changes to a point where you're confident in them, `add` them to the _Staging Environment_, before you finally `commit` them, this is a good moment to learn about another great tool, the `git stash`. 560 | 561 | ### Stashing changes 562 | 563 | If at any point you have local changes that you do not yet want to put into a commit, or want to store somewhere while you try some different angle to solve a problem, you can `stash` those changes away. 564 | 565 | A `git stash` is basically a stack of changes on which you store any changes to the _Working Directory_. 566 | 567 | The commands you'll mostly use are `git stash` which places any modifications to the _Working Directory_ on the stash, and `git stash pop` which takes the latest change that was stashed and applies it the to the _Working Directory_ again. 568 | 569 | Just like the [stack commands](https://en.wikipedia.org/wiki/Stack_(abstract_data_type)) it's named after, `git stash pop` removes the latest stashed change before applying these changes to the working directory. 570 | If you want to keep the stashed changes, you can use `git stash apply`, this applies the latest stashed changes to the working directory without removing them from the stash. 571 | 572 | To inspect your current `stash` you can use `git stash list` to list the individual entries, and `git stash show` to show the changes in the latest entry on the `stash`. 573 | 574 | > Another nice convenience command is `git stash branch {BRANCH NAME}`, which creates a branch, starting from the HEAD at the moment you've stashed the changes, and applies the stashed changes to that branch. 575 | 576 | Now that we know about `git stash`, lets run it to remove our local changes to `Alice.txt` from the _Working Directory_, so that we can go ahead and `git pull` the changes we've made via the website. 577 | 578 | After that, let's `git stash pop` to get the changes back. 579 | As both the commit we `pull`ed in and the `stash`ed change modified `Alice.txt` you will have to resolve the conflict, just how you would in a `merge` or `rebase`. When you're done, `add` and `commit` the change. 580 | 581 | ### Pulling with Conflicts 582 | 583 | Now that we've understood how to `fetch` and `pull` _Remote Changes_ into our _Dev Environment_, it's time to create some conflicts! 584 | 585 | Do not `push` the commit that changed `Alice.txt` and head back to your _Remote Repository_ on [github.com](https://www.github.com). 586 | 587 | There we're also going to change `Alice.txt` again and commit the change. 588 | 589 | Now there are actually two conflicts between our _Local_ and _Remote Repositories_. 590 | 591 | Don't forget to run `git fetch` to see the remote change without `pull`ing it in right away. 592 | 593 | If you now run `git status` you will see, that both branches have one commit on them that differs from the other. 594 | 595 | ```ShellSession 596 | > git status 597 | On branch fetching_changes_sample 598 | Your branch and 'origin/fetching_changes_sample' have diverged, 599 | and have 1 and 1 different commits each, respectively. 600 | (use "git pull" to merge the remote branch into yours) 601 | ``` 602 | 603 | In addition we've changed the same file in both of those commits, to introduce a `merge` conflict we'll have to resolve. 604 | 605 | When you `git pull` while there is a difference between the _Local_ and _Remote Repository_ the exact same thing happens as when you `merge` two branches. 606 | 607 | Additionally, you can think of the relationship between branches on the _Remote_ and the one in the _Local Repository_ as a special case of creating a branch based on another one. 608 | A local branch is based on a branches' state on the _Remote_ from the time you last `fetched` it. 609 | 610 | Thinking that way, the two options you have to get _remote_ changes make a lot of sense: 611 | 612 | When you `git pull`, the _Local_ and _Remote_ versions of a branch will be `merged`. Just like `merging` branches, this will introduce a _merge_ commit. 613 | 614 | As any _local_ branch is based on its respective _remote_ version, we can also `rebase` it, so that any changes we may have made locally, appear as if they were based on the latest version that is available in the _Remote Repository_. 615 | To do that, we can use `git pull --rebase` (or the shorthand `git pull -r`). 616 | 617 | As detailed in the section on [Rebasing](#rebasing), there is a benefit in keeping a clean linear history, which is why I would strongly recommend that whenever you `git pull` you do a `git pull -r`. 618 | 619 | > You can also tell git to use `rebase` instead of `merge` as its default strategy when your `git pull`, by setting the `pull.rebase` flag with a command like this `git config --global pull.rebase true`. 620 | 621 | If you haven't already run `git pull` when I first mentioned it a few paragraphs ago, let's now run `git pull -r` to get the remote changes while making it look like our new commit just happened after them. 622 | 623 | Of course like with a normal `rebase` (or `merge`) you'll have to resolve the conflict we introduced for the `git pull` to finish. 624 | 625 | ## Cherry-picking 626 | 627 | > Congratulations! You've made it to the more advanced features! 628 | 629 | > By now you understand how to use all the typical git commands and more importantly how they work. 630 | > 631 | >This will hopefully make the following concepts much simpler to understand than if I just told you what commands to type in. 632 | > 633 | >So let's head right in an learn how to `cherry-pick` commits! 634 | 635 | From earlier sections you still remember roughly what a `commit` is made off, right? 636 | 637 | And how your commits are applied as new commits with the same _change set_ and _message_ when you [`rebase`](#rebasing) a branch? 638 | 639 | Whenever you want to just take a few choice changes from one branch and apply them to another branch, you want to `cherry-pick` these commits and put them on your branch. 640 | 641 | That is exactly what `git cherry-pick` allows you to do with either single commits or a range of commits. 642 | 643 | Just like during a `rebase` this will actually put the changes from these commits into a new commit on your current branch. 644 | 645 | Lets have a look at examples for each `cherry-pick`ing: with one or more commits. 646 | 647 | The figure below shows three branches before we have done anything. Let's assume we really want to get some changes from the `add_patrick` branch into the `change_alice` branch. Sadly they haven't made it into master yet, so we can't just `rebase` onto master to get those changes (along with any other changes on the other branch, that we might not even want). 648 | 649 | ![Branches before cherry-picking](img/cherry_branches.png) 650 | 651 | So let's just `git cherry-pick` the commit _63fc421_. 652 | The figure below visualizes what happens when we run `git cherry-pick 63fc421` 653 | 654 | ![Cherry-picking a single commit](img/cherry_pick.png) 655 | 656 | As you can see, a new commit with the changes we wanted shows up on branch. 657 | 658 | > At this point note that like with any other kind of getting changes onto a branch that we've seen before, any conflicts that arise during a `cherry-pick` will have to be _resolved_ by us, before the command can go through. 659 | > 660 | > Also like all other commands you can either `--continue` a `cherry-pick` when you've resolved conflicts, or decide to `--abort` the command entirely. 661 | 662 | The figure below visualizes `cherry-pick`ing a range of commits instead of a single one. You can simply do that by calling the command in the form `git cherry-pick ..` or in our example below as `git cherry-pick 0cfc1d2..41fbfa7`. 663 | 664 | ![Cherry-picking commit range](img/cherry_pick_range.png) 665 | 666 | ## Rewriting history 667 | > I'm repeating myself now, but you still remember [`rebase`](#rebasing) well enough right? Otherwise quickly jump back to that section, before continuing here, as we'll use what we already know while learning how to change history! 668 | 669 | As you know a `commit` basically contains your changes, a message and few other things. 670 | 671 | The 'history' of a branch is made up of all its commits. 672 | 673 | But lets say you've just made a `commit` and then notice, that you've forgotten to add a file, or you made a typo and the change leaves you with broken code. 674 | 675 | We'll briefly look at two things we could do to fix that, and make it look like it never happened. 676 | 677 | Let's switch to a new branch with `git checkout -b rewrite_history`. 678 | 679 | Now make some changes to both `Alice.txt` and `Bob.txt`, and then `git add Alice.txt`. 680 | 681 | Then `git commit` using a message like "This is history" and you're done. 682 | 683 | Wait, did I say we're done? No, you'll clearly see that we've made some mistakes here: 684 | 685 | * We forgot to add the changes to `Bob.txt` 686 | * We didn't write a [good commit message](https://chris.beams.io/posts/git-commit/) 687 | 688 | 689 | ### Amending the last Commit 690 | One way to fix both of these in one go would be to `amend` the commit we've just made. 691 | 692 | `Amend`ing the latest commit basically works just like making a new one. 693 | 694 | Before we do anything, take a look at your latest commit, with `git show {COMMIT}`. Put either the commit hash (which you'll probably still see in your command line from the `git commit` call, or in the `git log`), or just _HEAD_. 695 | 696 | Just like in the `git log` you'll see the message, author, date and of course changes. 697 | 698 | Now let's `amend` what we've done in that commit. 699 | 700 | `git add Bob.txt` to get the changes to the _Staging Area_, and then `git commit --amend`. 701 | 702 | What happens next is your latest commit being unrolled, the new changes from the _Staging Area_ added to the existing one, and the editor for the commit message opening. 703 | 704 | In the editor you'll see the previous commit message. 705 | Feel free to change it to something better. 706 | 707 | After you're done, take another look at the latest commit with `git show HEAD`. 708 | 709 | As you've certainly expected by now, the commit hash is different. The original commit is gone, and in its place there is a new one, with the combined changes and new commit message. 710 | 711 | > Note how the other commit data like author and date are unchanged from the original commit. You can mess with those too, if you really want, by using the extra `--author={AUTHOR}` and `--date={DATE}` flags when amending. 712 | 713 | Congratulations! You've just successfully re-written history for the first time! 714 | 715 | ### Interactive Rebase 716 | 717 | Generally when we `git rebase`, we `rebase` onto a branch. When we do something like `git rebase origin/master`, what actually happens, is a rebase onto the _HEAD_ of that branch. 718 | 719 | In fact if we felt like it, we could `rebase` onto any commit. 720 | 721 | > Remember that a commit contains information about the history that came before it 722 | 723 | Like many other commands `git rebase` has an _interactive_ mode. 724 | 725 | Unlike most others, the _interactive_ `rebase` is something you'll probably be using a lot, as it allows you to change history as much as you want. 726 | 727 | Especially if you follow a work-flow of making many small commits of your changes, which allow you to easily jump back if you made a mistake, _interactive_ `rebase` will be your closest ally. 728 | 729 | _Enough talk! Lets do something!_ 730 | 731 | Switch back to your _master_ branch and `git checkout` a new branch to work on. 732 | 733 | As before, we'll make some changes to both `Alice.txt` and `Bob.txt`, and then `git add Alice.txt`. 734 | 735 | Then we `git commit` using a message like "Add text to Alice". 736 | 737 | Now instead of changing that commit, we'll `git add Bob.txt` and `git commit` that change as well. As message I used "Add Bob.txt". 738 | 739 | And to make things more interesting, we'll make another change to `Alice.txt` which we'll `git add` and `git commit`. As a message I used "Add more text to Alice". 740 | 741 | If we now have a look at the branch's history with `git log` (or for just a quick look preferably with `git log --oneline`), we'll see our three commits on top of whatever was on your _master_. 742 | 743 | For me it looks like this: 744 | ```ShellSession 745 | > git log --oneline 746 | 0b22064 (HEAD -> interactiveRebase) Add more text to Alice 747 | 062ef13 Add Bob.txt 748 | 9e06fca Add text to Alice 749 | df3ad1d (origin/master, origin/HEAD, master) Add Alice 750 | 800a947 Add Tutorial Text 751 | ``` 752 | 753 | There's two things we'd like to fix about this, which for the sake of learning different things, will be a bit different than in the previous section on `amend`: 754 | 755 | * Put both changes to `Alice.txt` in a single commit 756 | * Consistently name things, and remove the _.txt_ from the message about `Bob.txt` 757 | 758 | To change the three new commits, we'll want to rebase onto the commit just before them. That commit for me is `df3ad1d`, but we can also reference it as the third commit from the current _HEAD_ as `HEAD~3` 759 | 760 | To start an _interactive_ `rebase` we use `git rebase -i {COMMIT}`, so let's run `git rebase -i HEAD~3` 761 | 762 | What you'll see is your editor of choice showing something like this: 763 | 764 | ```bash 765 | pick 9e06fca Add text to Alice 766 | pick 062ef13 Add Bob.txt 767 | pick 0b22064 Add more text to Alice 768 | 769 | # Rebase df3ad1d..0b22064 onto df3ad1d (3 commands) 770 | # 771 | # Commands: 772 | # p, pick = use commit 773 | # r, reword = use commit, but edit the commit message 774 | # e, edit = use commit, but stop for amending 775 | # s, squash = use commit, but meld into previous commit 776 | # f, fixup = like "squash", but discard this commit's log message 777 | # x, exec = run command (the rest of the line) using shell 778 | # d, drop = remove commit 779 | # 780 | # These lines can be re-ordered; they are executed from top to bottom. 781 | # 782 | # If you remove a line here THAT COMMIT WILL BE LOST. 783 | # 784 | # However, if you remove everything, the rebase will be aborted. 785 | # 786 | # Note that empty commits are commented out 787 | ``` 788 | 789 | Note as always how `git` explains everything you can do right there when you call the command. 790 | 791 | The _Commands_ you'll probably be using most are `reword`, `squash` and `drop`. (And `pick` but that one's there by default) 792 | 793 | Take a moment to think about what you see and what we're going to use to achieve our two goals from above. I'll wait. 794 | 795 | Got a plan? Perfect! 796 | 797 | Before we start making changes, take note of the fact, that the commits are listed from oldest to newest, and thus in the opposite direction of the `git log` output. 798 | 799 | I'll start off with the easy change and make it so we get to change the commit message of the middle commit. 800 | 801 | ```bash 802 | pick 9e06fca Add text to Alice 803 | reword 062ef13 Add Bob.txt 804 | pick 0b22064 Add more text to Alice 805 | 806 | # Rebase df3ad1d..0b22064 onto df3ad1d (3 commands) 807 | [...] 808 | ``` 809 | 810 | Now to getting the two changes of `Alice.txt` into one commit. 811 | 812 | Obviously what we want to do is to `squash` the later of the two into the first one, so let's put that command in place of the `pick` on the second commit changing `Alice.txt`. For me in the example that's _0b22064_. 813 | 814 | ```bash 815 | pick 9e06fca Add text to Alice 816 | reword 062ef13 Add Bob.txt 817 | squash 0b22064 Add more text to Alice 818 | 819 | # Rebase df3ad1d..0b22064 onto df3ad1d (3 commands) 820 | [...] 821 | ``` 822 | 823 | Are we done? Will that do what we want? 824 | 825 | It wont, right? As the comments in the file tell us: 826 | 827 | ```bash 828 | # s, squash = use commit, but meld into previous commit 829 | ``` 830 | 831 | So what we've done so far, will merge the changes of the second Alice commit, with the Bob commit. That's not what we want. 832 | 833 | Another powerful thing we can do in an _interactive_ `rebase` is changing the order of commits. 834 | 835 | If you've read what the comments told you carefully, you already know how: Simply move the lines! 836 | 837 | Thankfully you're in your favorite text editor, so go ahead and move the second Alice commit after the first. 838 | 839 | ```bash 840 | pick 9e06fca Add text to Alice 841 | squash 0b22064 Add more text to Alice 842 | reword 062ef13 Add Bob.txt 843 | 844 | # Rebase df3ad1d..0b22064 onto df3ad1d (3 commands) 845 | [...] 846 | ``` 847 | 848 | That should do the trick, so close the editor to tell `git` to start executing the commands. 849 | 850 | What happens next is just like a normal `rebase`: starting with the commit you've referenced when starting it, each of the commits you have listed will be applied one after the other. 851 | 852 | > Right now it won't happen, but when you re-order actual code changes, it may happen, that you run into conflicts during the `rebase`. After all you've possibly mixed up changes that were building on each other. 853 | > 854 | > Just [resolve](#resolving-conflicts) them, as you would usually. 855 | 856 | After applying the first commit, the editor will open and allow you to put a new message for the commit combining the changes to `Alice.txt`. I've thrown away the text of both commits and put "Add a lot of very important text to Alice". 857 | 858 | After you close the editor to finish that commit, it will open again to allow you to change the message of the `Add Bob.txt` commit. Remove the ".txt" and continue by closing the editor. 859 | 860 | That's it! You've rewritten history again. This time a lot more substantially than when `amend`ing! 861 | 862 | If you look at the `git log` again, you'll see that there are two new commits in place of the three that we had previously. But by now you're used to what `rebase` does to commits and have expected that. 863 | 864 | ``` 865 | > git log --oneline 866 | 105177b (HEAD -> interactiveRebase) Add Bob 867 | ed78fa1 Add a lot very important text to Alice 868 | df3ad1d (origin/master, origin/HEAD, master) Add Alice 869 | 800a947 Add Tutorial Text 870 | ``` 871 | 872 | ### Fixing a commit that's further in the past 873 | 874 | So now we know how to easily `amend` the latest commit and how to rewrite commits in general with an interactive `rebase`. 875 | 876 | There is one more helpful feature that makes it easy to fix commits that happened further in the past: `fixup` commits. 877 | 878 | Let's recreate our [example from before](#amending-the-last-commit) and from the main branch, switch to a new branch with `git checkout -b fixup_commits`. 879 | 880 | Now make some changes to `Alice.txt` and add `Bob.txt`, and then `git add Alice.txt`. 881 | 882 | Then `git commit` using a message like "Add important things to Alice and Bob". 883 | 884 | And now let's make another change to `Alice.txt`, `git add Alice.txt` and make another `git commit` with a message of you're choice. 885 | 886 | If you still remember the `amend` example you'll have noticed that we again forgot to add the changes to `Bob.txt` in our first commit. 887 | 888 | Knowing how to do an interactive rebase, we could just add a new commit, rebase, move it before the second commit and squash it into the first. 889 | 890 | But that's a lot of manual work and git has a convenient shorthand for fixing commits. 891 | 892 | First let's find out the hash of that first commit - I like using `git log --oneline` to quickly find the short hash: 893 | 894 | ```sh 895 | > git log --oneline 896 | 20e59b5 (HEAD -> fixup_commits) Add some more changes to Alice 897 | 7acb4bc Add important things to Alice and Bob 898 | e701c3e (origin/master, origin/HEAD, master) made stashing section a little more understandable (#83) 899 | [...] 900 | ``` 901 | 902 | So for me the commit I want to add the `Bob.txt` changes to is `7acb4bc`. 903 | 904 | To do that let's `git add Bob.txt`, and then create a new commit that fixes `7acb4bc`. 905 | 906 | We do that by simply running `git commit --fixup={the commit hash to fix}`. So for me `git commit --fixup=7acb4bc` will do the trick. 907 | 908 | After that my log looks like this: 909 | 910 | ```sh 911 | > git log --oneline 912 | 8b4b1af (HEAD -> fixup_commits) fixup! Add important things to Alice and Bob 913 | 20e59b5 Add some more changes to Alice 914 | 7acb4bc Add important things to Alice and Bob 915 | e701c3e (origin/master, origin/HEAD, master) made stashing section a little more understandable (#83) 916 | [...] 917 | ``` 918 | 919 | As you can see that new commit is special and it's message is simply the one of the commit it's fixing, prefixed with `fixup!`. 920 | 921 | With such `fixup` commits in our history we can simplify the interactive rebase by telling git to `autosquash` them for us. 922 | 923 | So if we run `git rebase -i --autosquash origin/master` now the rebase prompt will look like this: 924 | 925 | ```sh 926 | pick 7acb4bc Add important things to Alice and Bob 927 | fixup 8b4b1af fixup! Add important things to Alice and Bob 928 | pick 20e59b5 Add some more changes to Alice 929 | 930 | # Rebase e701c3e..8b4b1af onto e701c3e (3 commands) 931 | # 932 | # Commands: 933 | # p, pick = use commit 934 | # r, reword = use commit, but edit the commit message 935 | # e, edit = use commit, but stop for amending 936 | # s, squash = use commit, but meld into previous commit 937 | # f, fixup = like "squash", but discard this commit's log message 938 | # x, exec = run command (the rest of the line) using shell 939 | # b, break = stop here (continue rebase later with 'git rebase --continue') 940 | # d, drop = remove commit 941 | # l, label