Changes between Version 1 and Version 2 of GitCrashCourse
- Timestamp:
- 04/23/10 10:56:34 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GitCrashCourse
v1 v2 3 3 What this means is that you actually download the complete code repository to your own hard drive. This is different from centralised VCS/SCMs, which only have a copy of the files you checked out. With git you get a complete copy of the complete history, locally. This is one of the reasons why git can be very quick. 4 4 5 {{{ 5 6 git clone {repository} [{local name}] 7 }}} 6 8 7 9 The {repository} string can point at a git:// URL, http[s]:// URL or a local file URL. When the cloning is completed, you will automatically have checked out the 'master' branch. … … 11 13 Git should know who you are, as that will be important for the git commit logs. So please enter a directory created by ''git clone'' and do: 12 14 15 {{{ 13 16 git config user.name 'Your name' 14 17 git config user.email 'my@email.com' 18 }}} 15 19 16 20 This will only set these variables locally in this repository. I would probably recommend you to make these changes globally as well, as this can be easy to forget if your do another git clone. 17 21 22 {{{ 18 23 git config --global user.name 'Your name' 19 24 git config --global user.email 'my@email.com' 25 }}} 20 26 21 27 Some might only need to do the latter one, but some might want to use different e-mail addresses for their commits for different projects. … … 27 33 This is highly recommended, as it is easier to read commit logs and patches via the git commands this way. 28 34 35 {{{ 29 36 git config --global color.branch auto 30 37 git config --global color.diff auto … … 33 40 git config --global color.status auto 34 41 git config --global color.pager true 42 }}} 35 43 36 44 Notice that we here force colours when using the pager. This might mean you need to add one more change as well: 37 45 46 {{{ 38 47 git config --global core.pager 'less -X -R -F' 48 }}} 39 49 40 50 === Preparing for sending patches via mail === … … 42 52 If you choose to install the git-send-email package, you can very easily submit patches via e-mail. We will go into these details later on, but some configuration should be done. 43 53 54 {{{ 44 55 git config --global sendemail.chainreplyto false 45 56 git config --global sendemail.smtpserver {your SMTP server} 57 }}} 46 58 47 59 If you're using SSL or TLS against your SMTP server, add this: … … 49 61 50 62 If you're authenticating against the SMTP server, you must add: 63 64 {{{ 51 65 git config --global sendemail.smtpuser {your-username} 66 }}} 52 67 53 68 You can also set your password in the config, by setting sendemail.smtppass - '''but the password will be saved in clear text!''' … … 57 72 Now do this: 58 73 74 {{{ 59 75 cat ~/.gitconfig 60 76 cat .git/config 77 }}} 61 78 62 79 As you can see, the configuration files are not that hard to read. These files may be edited manually if you want to as well. … … 64 81 == Checking the status of the project == 65 82 83 {{{ 66 84 git status 85 }}} 67 86 68 87 This command gives you an overview over all files which have been modified and all new and unregistered files. The output of ''git status'' should be pretty obvious. … … 70 89 == Checking your changes == 71 90 91 {{{ 72 92 git diff [{filename}] 93 }}} 73 94 74 95 This will list all local changes which has not been committed. … … 78 99 All files new files will need to be added to an ''index'' to be prepared for a commit. Consider this as a "pre stage" which needs to be done. This is also different from other VCS/SCMs. But it has it's advantages as well. So if you add or modifies files, you need to do this to add files to the index when you want to commit your changes: 79 100 101 {{{ 80 102 git add {filename/directory} 103 }}} 81 104 82 105 If you have a long list of files under the ''git status'' section called ''Changed but not updated:'', you can do: 83 106 107 {{{ 84 108 git add -u 109 }}} 85 110 86 111 This adds all these files into the index. If you now try to do a ''git diff', you'll see that nothing turns up. And if you modifies one of the files and do ''git diff' again, you'll find that only your last changes is shown. This is normal behaviour. git compares to what's in saved the index and what the local file looks like. … … 88 113 If you want to see the changes from what's in your index and the previously committed version, you'll need to do: 89 114 115 {{{ 90 116 git diff --cached 117 }}} 91 118 92 119 Please also try: 93 120 121 {{{ 94 122 git status 123 }}} 95 124 96 125 Notice the change of the message for the files which you have added. Now, let's commit! 97 126 127 {{{ 98 128 git commit -s 129 }}} 99 130 100 131 Now an editor should turn up, you can enter your commit statement and exit. Notice the ''-s'' argument. That means ''sign-off'. That adds an 'Signed-off-by: ' signature at the end of the commit log. Please do it a habit to always sign-off your commits. That simply means you approve the commit. And this is especially important if you commit work for others. … … 102 133 To change the author of some code in the commit log, you can do that via the commit as well: 103 134 135 {{{ 104 136 git commit -s --author "Authors name <authors@email.com>" 137 }}} 105 138 106 139 This is important to remember if you apply patches from others. This way it is possible to track from whom the different code parts came from. … … 108 141 == Look at the commit log == 109 142 143 {{{ 110 144 git log 145 }}} 111 146 112 147 This is the most basic usage. Other nice usages is to follow a files commit log, and not the complete project's commit history: 148 149 {{{ 113 150 git log --follow {filename} 151 }}} 114 152 115 153 If you also add -p, you can also see the diff. 116 154 117 155 There's also a feature called ''git show''. This shows the contents of a commit or other git objects. If you just do 156 157 {{{ 118 158 git show 119 159 }}} 120 160 it will show the last git commit. But you can give it a commit ID which you can find in the ''git log''. If you give it a branch name or a tag name, you will see the git commit of the branch point or at the commit where the tag points at. 121 161 162 {{{ 122 163 git show 684790552dde0475745015a76762ecc5a11eedab (commit ID) 123 164 git show 684790552dd (partial commit ID) 124 165 git show origin/allmerged (remote branch) 125 166 git show v2.1.1 (tag name) 167 }}} 126 168 127 169 == Creating patch files == 128 170 129 171 When you have done some commits, you probably want to share them. Say you want to pick out the last commit. 172 173 {{{ 130 174 git format-patch HEAD^1 175 }}} 131 176 132 177 This notation might look odd. HEAD is a keyword, which means head of the commit log. It's where the last commit happened. It's because ''git format-patch'' takes ranges. This notation means, from HEAD - 1 commit and to the last commit. If you do just HEAD, the range "distance" will be 0, and no patch file will be created. It's like saying ''from A to A''. But you really want to say, from ''A to B''. To explain that, you can do: 178 179 {{{ 133 180 git format-patch HEAD^1..HEAD 181 }}} 134 182 135 183 So, what happens if you change HEAD^1 to HEAD^3 ... well, you get the 3 top-most commits as patch files. ''git format-patch'' will report the file names it generates on-the-fly. … … 137 185 ''git format-patch'' can also take commit ID's which you find in the commit log, in addition to branch names and tag names. So if you want to have all commits from OpenVPN 2.1_rc15 to OpenVPN 2.1_rc22 ... you can do: 138 186 187 {{{ 139 188 git format-patch v2.1_rc15..v2.1_rc22 189 }}} 140 190 141 191 You can also do this with ''git log''. … … 145 195 If you have installed the git-send-email package and done the configuration steps mentioned above, sending patches to the mailing list is just as easy as creating the patch files. Please note that the ''git send-email'' command expects to get patch file(s). Just do: 146 196 197 {{{ 147 198 git send-email --to {email address} {patch files} 199 }}} 148 200 149 201 and follow the instructions you're given. That's all. … … 152 204 153 205 If you wonder where 'v2.1_rc15' came from in the example above, that's a tag name. And tags can be found by doing: 206 207 {{{ 154 208 git tag -l 209 }}} 155 210 156 211 A tag is just a name of a particular commit ID. Commit ID's can be tricky to remember, and then you can insert tag names which are a bit more descriptive. … … 161 216 162 217 First, let's look at some branches: 218 219 {{{ 163 220 git branch 221 }}} 164 222 165 223 This will list all your local branches. But we also have some remote branches. 224 225 {{{ 166 226 git branch -r 227 }}} 167 228 168 229 Notice the difference between them, where remote branches are prefixed with ''origin/''. This is because git tracks remote branches separately from your local branches. So you can have a master branch which is different from origin/master. Another thing, to be able to do commits on remote branches, you must check them out as a local branch before you can do commit. … … 173 234 174 235 In OpenVPN, there's a branch called ''allmerged''. So to checkout that branch locally, we do: 236 237 {{{ 175 238 git checkout -b allmerged origin/allmerged 239 }}} 176 240 177 241 That's it :) Now you can do commits to your own copy of the ''allmerged'' branch. … … 179 243 If you find out that you want to do some experimental stuff, to see how it works out, just do: 180 244 245 {{{ 181 246 git checkout -b my_test_branch 247 }}} 182 248 183 249 And it will create a new branch, enter it, from the latest commit where you where. You can now even commit into this branch. … … 187 253 If you find out that one branch has some stuff you want to test out with your own stuff in your own branch, it's quite easy. 188 254 255 {{{ 189 256 git merge {branch to merge into your branch} 257 }}} 190 258 191 259 If there are some conflicts, just do a ''git diff'' to see what they are. You need to solve these issues before you then can continue. The conflict blocks are pretty visible and you will hopefully understand what to leave in the file and what to remove. When that's done, it's the same procedure as before - ''git add'' and ''git commit''.
