├── .gitattributes ├── LICENSE └── README.md /.gitattributes: -------------------------------------------------------------------------------- 1 | *.md linguist-vendored=false 2 | *.md linguist-generated=false 3 | *.md linguist-documentation=false 4 | *.md linguist-detectable=true 5 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 Armia Joseph 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ArmaGit - Your Gateway to Git Mastery 2 | Welcome to [ArmaGit](https://github.com/Armaritto/ArmaGit) , your ultimate Git guide! Whether you're a beginner or a pro, find everything you need to know about Git commands. Dive into the cheat sheets, tips, and tutorials to master version control, collaborate efficiently, and manage projects effectively. Let's unlock the secrets to seamless Git mastery together!
3 | Thanks [learngitbranching.js](https://learngitbranching.js.org/), my understanding of Git has significantly improved. 4 | 5 | ## Git Commits 6 | - ### Git Add 7 | Used in Git to stage changes for commit. When you make modifications to files in your working directory, `git add` allows you to selectively choose which changes to include in the next commit. 8 | ``` 9 | git add [file.extenstion] 10 | ``` 11 | To stage all changes in the current directory 12 | ``` 13 | git add . 14 | ``` 15 | - ### Git Commit 16 | Records a snapshot of all the (tracked) files in your directory. It's like a giant copy and paste. 17 | ``` 18 | git commit -m "[your_commit_message]" 19 | ``` 20 | To combine `git add` and `git commit` in a single command, you can use the `-a` flag with git commit. However, this command won't stage new files that haven't been previously tracked by Git. 21 | ``` 22 | git commit -a -m "[your_commit_message]" 23 | ``` 24 | - ### Git Log 25 | To view a history of commits in your repository and see the details of each commit, including the commit message, author, timestamp, and the changes made. 26 | ``` 27 | git log 28 | ``` 29 | To show the commits on branch1 and not in branch2 30 | ``` 31 | git log branch2..branch1 32 | ``` 33 | To show the commits that changed a file, even across renames 34 | ``` 35 | git log --follow -- [file.extension] 36 | ``` 37 | - ### Git Diff 38 | Display the differences of what is changed but not staged 39 | ``` 40 | git diff 41 | ``` 42 | Display the differences of what is staged but not yet commited 43 | ``` 44 | git diff --staged 45 | ``` 46 | Display the differences of what is in branch1 and not in branch2 47 | ``` 48 | git diff branch2..branch1 49 | ``` 50 | - ### Git Stash 51 | Temporarily store modified files in order to change branches 52 | ``` 53 | git stash 54 | ``` 55 | List stack-ordered of stashed file changes 56 | ``` 57 | git stash list 58 | ``` 59 | Write working from the top of the stash stack 60 | ``` 61 | git stash pop 62 | ``` 63 | Discard the changes from the top of the stack list 64 | ``` 65 | git stash drop 66 | ``` 67 | - ### Git Status 68 | Staged in Git refers to the state of changes that have been marked for inclusion in the next commit, allowing for selective preparation and organization of commit snapshots. 69 | Staged changes will appear under the "Changes to be committed" section after running: 70 | ``` 71 | git status 72 | ``` 73 | - ### Git Reset 74 | To Clear staged area and rewrite working tree from a specified commit we use 75 | ``` 76 | git reset --hard [commit] 77 | ``` 78 | - ### Detaching HEAD 79 | `HEAD` is the symbolic name for the currently checked out commit -- it's essentially what commit you're working on top of.
80 | `Detaching HEAD` refers to when the HEAD reference in a Git repository points directly to a commit hash instead of pointing to a branch name.
81 | ``` 82 | git checkout [commit_hash] 83 | ``` 84 | you'll end up in a detached HEAD state because you're directly checking out a specific commit. 85 | ``` 86 | git checkout [branch_name] 87 | ``` 88 | you'll be on the branch and HEAD will point to the branch reference.

89 | In summary, detaching HEAD is a temporary state that allows you to inspect and work with a specific commit directly. However, it's important to switch back to a branch or create a new branch if you intend to make further changes to avoid losing your work. 90 | - ### Cherry-Pick 91 | Lets you copy a single commit from one branch to another, allowing you to apply specific changes without merging entire branches. 92 | ``` 93 | git cherry-pick [commit1-hash] [commit-hash-2] ... 94 | ``` 95 | ## Git Branches 96 | - ### Git Create Branches 97 | Allow you to work on multiple versions of your project simultaneously, keeping changes isolated until they're ready to be merged. 98 | ``` 99 | git branch [branch name] 100 | ``` 101 | - ### Git Checkout 102 | Lets you switch between different branches or revert files to previous states within your repository effortlessly. 103 | ``` 104 | git checkout [branch name] 105 | ``` 106 | To make a new branch and checkout on it in one shortcut you can use 107 | ``` 108 | git checkout -b [branch name] 109 | ``` 110 | 115 | - ### Git Merge 116 | A command used in Git to integrate changes from one branch into another. It combines the changes made in a source branch with the target branch, creating a new merge commit if necessary. 117 | ``` 118 | git merge [branch name] 119 | ``` 120 | - ### Git Rebase 121 | Rebasing essentially takes a set of commits, copies them, and plops them down somewhere else. It allows you to rewrite the commit history of your branch by moving, combining, or altering commits, providing a cleaner and more linear history for your project. 122 | ``` 123 | git rebase [branch name] 124 | ``` 125 | #### Merge vs Rebase 126 | `git merge` preserves the original branching structure, while `git rebase` creates a cleaner, linear history by rewriting commit history. The choice between the two depends on the project's collaboration workflow and the desired commit history structure.

127 | Imagine you clone a repository on Monday and start dabbling on a side feature. By Friday you are ready to publish your feature -- but oh no! Your coworkers have written a bunch of code during the week that's made your feature out of date (and obsolete). They've also published these commits to the shared remote repository, so now your work is based on an old version of the project that's no longer relevant. 128 | 129 | In this case, the command `git push` is ambiguous. If you run `git push`, should git change the remote repository back to what it was on Monday? Should it try to add your code in while not removing the new code? Or should it totally ignore your changes since they are totally out of date? 130 | 131 | Because there is so much ambiguity in this situation (where history has diverged), git doesn't allow you to push your changes. It actually forces you to incorporate the latest state of the remote before being able to share your work. 132 | 133 | How do you resolve this situation? It's easy, all you need to do is `base` your work off of the most recent version of the remote branch. 134 | ``` 135 | git pull --rebase 136 | git push 137 | ``` 138 | Let's check out the same thing but with merge instead. 139 | 140 | Although git merge doesn't move your work (and instead just creates a merge commit), it's a way to tell git that you have incorporated all the changes from the remote. This is because the remote branch is now an ancestor of your own branch, meaning your commit reflects all commits in the remote branch. 141 | ``` 142 | git pull 143 | git push 144 | ``` 145 | ## Relative Refs 146 | Shortcuts or references that allow you to identify commits relative to their current position in the commit history. They provide a convenient way to specify commits without needing to know or remember their full commit hashes. 147 | - ### Caret `^` Operator 148 | Moving upwards one commit at a time with `^` 149 | ``` 150 | git checkout main^ 151 | ``` 152 | - ### Tilde `~` Notation 153 | Moving upwards a number of times with `~` 154 | ``` 155 | git checkout HEAD~3 156 | ``` 157 | ## Git Remote 158 | - ### Git Clone 159 | A command to create a copy of an existing Git repository on your local machine. 160 | ``` 161 | git clone [URL] 162 | ``` 163 | - ### Git Fetch 164 | Downloads new data from the remote repository but does not integrate it into your working branch. It updates your local copy of remote branches, tags, and commits, allowing you to see what changes have occurred in the remote repository. 165 | ``` 166 | git fetch 167 | ``` 168 | - ### Git Pull 169 | Integrates new data into your current working branch. 170 | ``` 171 | git pull [remote_name] [branch_name] 172 | ``` 173 | While there is a shortcut to `pull` from the current repository `origin` and merge in the `current branch` 174 | ``` 175 | git pull 176 | ``` 177 | - ### Fetch vs Pull 178 | `git pull` is essentially a combination of `git fetch` followed by `git merge`.
179 | `git fetch` when you want to see what changes have been made in the remote repository without integrating them into your local branch immediately. It's useful for reviewing changes before merging or rebasing.
180 | `git pull` when you want to fetch changes from the remote repository and automatically merge them into your current working branch. It's convenient for quickly updating your local branch with changes from the remote repository. 181 | - ### Main Commits Rejection 182 | If you work on a large collaborative team and you commit directly to main locally and try pushing you will be greeted with a message similar to this: 183 | ``` 184 | ! [remote rejected] main -> main (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.) 185 | ``` 186 | The remote rejected the push of commits directly to main because of the policy on main requiring pull requests to instead be used. 187 | So the solution is to create another branch called feature and push that to the remote. Also reset your main back to be in sync with the remote. 188 | ``` 189 | git checkout -b feature 190 | git add . 191 | git commit -m "Implemented feature" 192 | git push origin feature 193 | git checkout main 194 | git fetch origin 195 | git reset --hard origin/main 196 | ``` 197 | However, if you don't have write access to the repository you should do the following instead: 198 | 1- Create a fork of the repository on your GitHub account. 199 | 2- Run the above commands. 200 | 3- Create a pull request as a contribution to the main repository. 201 | 202 | ## Git Origins 203 | `Origin` in Git is a convenient label for the default remote repository from which you cloned your local repository, allowing you to interact with it easily using Git commands.
204 | `origin/main`: This type of branch is called a remote branch; remote branches have special properties because they serve a unique purpose.
205 | Remote branches reflect the state of remote repositories (since you last talked to those remote repositories). They help you understand the difference between your local work and what work is public -- a critical step to take before sharing your work with others.
206 | Remote branches have the special property that when you check them out, you are put into detached HEAD mode. Git does this on purpose because you can't work on these branches directly; you have to work elsewhere and then share your work with the remote (after which your remote branches will be updated). 207 | 208 | To be clear: Remote branches are on your local repository, not on the remote repository.
209 | Lets check out a remote branch, make a commit and see what happens. 210 | ``` 211 | git checkout origin/main 212 | git commit 213 | ``` 214 | git put us into detached HEAD mode and then did not update `origin/main` when we added a new commit. This is because `origin/main` will only update when the remote updates. 215 | 216 | ### Git Bisect 217 | Use binary search to find the commit that introduced a bug 218 | 219 | Basic bisect commands: start, bad, good 220 | As an example, suppose you are trying to find the commit that broke a feature that was known to work in version v2.6.13-rc2 of your project. You start a bisect session as follows: 221 | ``` 222 | git bisect start 223 | git bisect bad # Current version is bad 224 | git bisect good v2.6.13-rc2 # v2.6.13-rc2 is known to be good 225 | ``` 226 | Once you have specified at least one bad and one good commit, git bisect selects a commit in the middle of that range of history, checks it out, and outputs something similar to the following: 227 | 228 | Bisecting: 675 revisions left to test after this (roughly 10 steps) 229 | You should now compile the checked-out version and test it. If that version works correctly, type 230 | ``` 231 | git bisect good 232 | ``` 233 | If that version is broken, type 234 | 235 | ``` 236 | git bisect bad 237 | ``` 238 | Then git bisect will respond with something like 239 | 240 | Bisecting: 337 revisions left to test after this (roughly 9 steps) 241 | Keep repeating the process: compile the tree, test it, and depending on whether it is good or bad run git bisect good or git bisect bad to ask for the next commit that needs testing. 242 | 243 | 244 |

245 | ### I'm still in the process of learning Git! Whenever I pick up something new, I jot it down right here. Stay tuned for updates! 246 | --------------------------------------------------------------------------------