└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Git Guide 2 | 3 | After reading this tutorial you should understand the basic git commands. 4 | 5 | ## Git 6 | ### What is git? 7 | Git is a VCS (Version Control System) which is used for two main purposes: 8 | 1. To store a back-up of your work in case something goes wrong. 9 | 2. To work with multiple developers on the same project without destroying others work. 10 | 11 | ### Installation 12 | You start by [downloading](https://git-scm.com/downloads) and [installing](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) git for your operating system. 13 | 14 | Verify that you've installed git correctly by open a command line and type the following command. 15 | ```bash 16 | $ git --version 17 | ``` 18 | 19 | This command should return the installed git version. 20 | 21 | If you prefer using a graphical user interface (GUI), you can download one from [this website](https://git-scm.com/downloads/guis). 22 | 23 | ### New git repository 24 | While on the command line you can navigate to the desired folder in order to initiate git and start keeping track of all your changes. After navigating to the desired folder location, use the following command to start git. This will create a hidden .git folder which will store all git information. You can safely ignore this hidden .git folder. 25 | ```bash 26 | $ git init 27 | ``` 28 | 29 | ### Commit 30 | Following the creation of the new git repository, we can start coding and save the code within the above mentioned folder. After writing some lines of code, it is important to commit you changes. This will make a snapshot of your current work and when you make a mistake, you can reset your code to this snapshot. To make a snapshot you first have to define which files should be snapshotted by one of the following commands, this is called staging. 31 | ```bash 32 | $ git add . # Adds all changed documents to the snapshot 33 | $ git add #Adds only the defined files to the snapshot 34 | ``` 35 | Finally the staged files should be snapshotted with the following command. Every snapshot should have a commit message that describes the changes. This message is given by the `-m` parameter. 36 | 37 | ```bash 38 | $ git commit -m "" 39 | ``` 40 | After you've committed your changes, a message will display the number of changed files, deleted files and the inserted files. Besides this there will also be a unique git commit hash. This hash will be of great importance when you want to go back to this snapshot. 41 | 42 | If you aren't ready to commit yet, but want an overview of the current status of your git project, you can do so by typing the following command. 43 | ```bash 44 | $ git status 45 | ``` 46 | This will display the modified files, the staged file and the current branch you're working on. (Branches will be explained below) 47 | 48 | ### Checkout 49 | Besides getting an overview of the current status, it is useful the get some information about the status of previous snapshots. This can be retrieved with the following command. 50 | ```bash 51 | $ git log 52 | ``` 53 | This will display a complete list of all previous changes on this branch. It will display the author, the commit message and most important the git hash. 54 | 55 | In order to go back to a previous snapshot you have to use the checkout command together with the git hash as retrievable with the `git log` command. 56 | ```bash 57 | $ git checkout #e.g. $ git checkout da232268df22f3077ce8665ba16bc6efaf49c41f 58 | ``` 59 | After this command all files within the git folder should have been changed to their original state as they were when this snapshot was originally made. 60 | Going back to the last commit can be done in a similar way where the git hash should be replaced with the branch name (mostly main). 61 | ```bash 62 | $ git checkout main 63 | ``` 64 | 65 | **Going back to a previous commit by entering a git hash can be dangerous** and it is only advised to do so when you want to visibly see what you've done at this commit. This is because when you start to commit again from this point onwards, the new commits won't be saved on a branch. When you again checkout to you last commit with `git checkout master`, you wont be able to go back to the commits made from the previous point when you forgot the exact hash. 66 | 67 | ### Branches 68 | A branch is used during development to develop separate parts of a program independently from each-other. When a certain part of your code is working, you can chose to merge the branches together meaning that code from branch A will be included in branch B. This can be extremely useful if you need to have a consistently working application. For example say we have a branch called deployment which contains only working code and another branch called development. During development of the code we only work on the development branch, or even on another branch created from the development branch. When the new update is fully working, we can merge the development branch into the deployment branch keeping only working and finished parts in the deployment branch. 69 | 70 | Creating a branch is done with the `branch` command or with the same `checkout` command as going back to a previous snapshot. Using the `checkout` command with the `-b` makes a new branch from the current snapshot and is safe to use. You can also make a branch starting from a previous commit by first going to a specific commit using the git hash followed by creating a branch with the command below. 71 | ```bash 72 | #Both commands are equivalent 73 | $ git branch #Branch from the current state 74 | $ git checkout -b #Branch from the state with corresponding git-hash. 75 | ``` 76 | 77 | If you want to show an overview of all branches you can use the following command without any branch name. 78 | ```bash 79 | $ git branch 80 | ``` 81 | If you try this command yourself you see that the result will show a branch called master. This is the main branch and in previous chapter we actually used this to go to the latest commit on the master branch. 82 | 83 | You can delete a branch with the following command. 84 | ```bash 85 | $ git branch -d #Safe delete: only possible if the branch is fully merged 86 | $ git branch -D #Unsafe delete: Always possible 87 | ``` 88 | 89 | Merging branches can be a bit tricky because you have to be careful which branch you merge into which branch. Retaking the previous example of a deployment and development branch. First you go to the deployment branch because this branch has to include code from another branch, namely the development branch. Then you use the following command to include code from the development branch into deployment branch. 90 | 91 | ```bash 92 | $ git checkout #$ git checkout deployment 93 | $ git merge #$ git merge development 94 | ``` 95 | This command will fail if changes were made and committed in both the development and the deployment branch and those changes cannot be resolved automatically. If this occurs you are obligated to go to your source code. The source code will contain some new lines with `<<<<<<< HEAD`, `=======` and `>>>>>>>`. This is the place where the conflict occurred and you have to manually remove the wrong code. After resolving the conflicts you have to make a new commit and the merge will finish successfully. 96 | 97 | 98 | ### .gitignore 99 | Sometimes you don't want to keep track of all the files in your project. (e.g: files containing sensitive information or passwords) This can be done by creating a .gitignore file which contains information about the files that should **not** be tracked. 100 | Some useful .gitignore patterns are shown below: 101 | | Pattern | explanation | 102 | | ------------- | ------------- | 103 | | \*\*/foo | Don't track the folder foo anywhere in the structure | 104 | | \*.foo | Don't track files with extention .foo | 105 | | \foo.foo | Don't track the file foo with extention .foo in the root folder | 106 | | fo?.foo | A questionmark marks exactly one character | 107 | | foo[1-3].foo | square brackets match any character | 108 | 109 | It is important to include files in the .gitignore before your first commit after creating this file. If you create a file, make a commit and after commiting changes the .gitignore, the newly created file will still be tracked in subsequent commits. 110 | 111 | ## Github 112 | Git and github are not the same. 113 | Git is a version control system that can be locally used while Github on the other hand is an online storage platform where you can upload and download your git work. This can be extremely useful if you are working with others on the same project or in case you want to share your final code with others. 114 | 115 | In order to link your local repository with the remote repository you have to add the online repository url in the following command. This url will be saved in the .git folder and will be used whenever you want to upload or download your progress online. 116 | ```bash 117 | $ git remote add origin .git 118 | ``` 119 | 120 | ### Push 121 | Pushing means that you want your local git repository to be uploaded onto the remote repository. The first time you do this you have to specify which remote repository you want to use by the following command. 122 | ```bash 123 | $ git push -u origin master 124 | ``` 125 | After the upstream is determined, you dont have to specify it every time and you can just use the following command to upload your code. 126 | ```bash 127 | $ git push 128 | ``` 129 | 130 | ### Pull 131 | Pulling is the opposite from pushing, meaning that you are downloading code from the remote repository onto the local repository. This is not useful if you are developing as a single developer using a single desktop. But if you are working with multiple developers at the same time, some developers have already pushed new code that needs te be pulled before you can push your newly written code onto the branch. 132 | ```bash 133 | $ git pull 134 | ``` 135 | 136 | ### Clone 137 | On Github or other remotes, some repositories are publicly accessible, just like this repository is publically available. This means that any user can download the repository. You can either download this repository as a zip file using the github gui or you can use the command line to clone the repository into the desired location. The clone command can also be used to make a local copy of another local repository at a different location. Meaning that with clone you can download repositories from online or move local repositories. 138 | ```bash 139 | $ git clone #download remote repository 140 | $ git clone #Copy local repository 141 | ``` 142 | 143 | ## Cheat sheet 144 | 145 | ### Git 146 | ```bash 147 | $ git --version #Displays the installed git version on this machine 148 | $ git init #Initialize a new git repository. Can only start from an empty folder. 149 | $ git add . # Stage all changed documents 150 | $ git add #Stage only the defined files 151 | $ git commit -m "" #Commit the staged files 152 | $ git status #Displays the status of the current commit, including branch, modified files, staged files 153 | $ git log #Displays a complete list of previous commits with hash, author details and commit message 154 | $ git checkout #Retrieve your work at the given git-hash 155 | $ git checkout master #Retrieve your work at the latest commit on the master branch 156 | $ git branch #Create a new branch with name 157 | $ git checkout -b #Create a new branch with name 158 | $ git branch #Display all branches by name 159 | $ git branch -d #Safe delete branch: only possible if the branch is fully merged 160 | $ git branch -D #Unsafe delete branch: Always possible 161 | $ git fetch origin # Fetch all existing branches from the remote repository 162 | $ git merge #Merge the named branch into the current branch. Possibly resulting in conflicts. 163 | ``` 164 | ### Github 165 | ```bash 166 | $ git remote add origin .git # Save the remote git url as variable name origin 167 | $ git push -u origin master #Explicitly push your git commits to the remote git url with variable name origin, only obligated the with the first push 168 | $ git push #Push your git commits to the remote git url with previous defined origin 169 | $ git pull #Pull git commits from the remote git url with previous defined origin 170 | $ git clone #download remote repository 171 | $ git clone #Copy local repository 172 | 173 | ``` 174 | ### .gitignore 175 | | Pattern | explanation | 176 | | ------------- | ------------- | 177 | | \*\*/foo | Don't track the folder foo anywhere in the structure | 178 | | \*.foo | Don't track files with extention .foo | 179 | | \foo.foo | Don't track the file foo with extention .foo in the root folder | 180 | | fo?.foo | A questionmark marks exactly one character | 181 | | foo[1-3].foo | square brackets match any character | 182 | 183 | 184 | 185 | --------------------------------------------------------------------------------