= Git basics! Apostolos rootApostolos@swarmlab.io // Metadata: :description: Git instructions :keywords: git basics ifndef::env-browser[] :data-uri: endif::[] :images-cdn: http://localhost:3080/images :toc: right :toc-title: Table of contents :toclevels: 4 :source-highlighter: highlight :no-header-footer: :nofooter: :last-update-label!: :icons: font :sectnums: :url_mongodb: https://en.wikipedia.org/wiki/MongoDB :hardbreaks: {empty} + {empty} :!hardbreaks: == Edit .Lifecycle [.float-group] -- [.right] image::images/lifecycle.png[lifecycle,390,role=right] As you *edit* files, Git sees them as *modified*, because you’ve changed them since your last commit. As you work, you selectively *stage* these modified files and then *commit* all those staged changes, and the *cycle repeats*. -- [NOTE] ==== .tracked vs untracked Each file in working directory can be in *one of two states*: * tracked * untracked. *Tracked files* are files that were in the last snapshot; they can be: * unmodified * modified * staged TIP: *tracked* files are files that Git knows about. ==== == Staging .Staging Area [.float-group] -- [.right] image::images/indexx.png[staging,390,role=right] *stage* some of your files and commit them without committing all of the other modified files in working directory. This allows you to stage only portions of a modified file. -- [TIP] ==== Git has something called the *"staging area"* or *"index"*. This is an *intermediate area* where commits can be formatted and reviewed before completing the commit. ==== == Tagging .Staging Area Tag specific points in a repository’s history as being important. Typically, people use this functionality to mark release points (v1.0, v2.0 and so on) === Listing Your Tags .list in alphabetical order [source,bash] ---- git tag ---- [NOTE] ==== Listing tag wildcards requires -l or --list option If you want just the entire list of tags, running the command git tag implicitly assumes you want a listing and provides one; the use of -l or --list in this case is optional. If, however, you’re supplying a wildcard pattern to match tag names, the use of -l or --list is mandatory. ==== === Creating Tags Git supports two types of tags: * lightweight * annotated .annotated [source,bash] ---- git tag -a v1.4 -m "my version 1.4" ---- The -m specifies a tagging message, which is stored with the tag .lightweight [source,bash] ---- git tag v1.4-lw ---- To create a lightweight tag, don’t supply any of the -a, -s, or -m options, just provide a tag name [NOTE] ==== A *lightweight* tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit. *Annotated* tags, however, are stored as full objects in the Git database. They’re checksummed; *contain* the _tagger name_, _email_, and _date_; have a _tagging message_; and can be _signed and verified with GNU Privacy Guard (GPG)_. TIP: It’s generally *recommended that you create annotated tags* so you can have all this information; ==== === Sharing Tags By default, the *git push command* doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them. This process is just like sharing remote branches .sharing tags [source,bash] ---- git push origin v1 ---- [NOTE] ==== .git push pushes both types of tags *git push --tags* will push both * lightweight and * annotated tags. TIP: There is currently *no option to push only lightweight tags* TIP: git push --follow-tags will *only annotated tags will be pushed* to the remote. ==== === Deleting Tags To delete a tag on your local repository, you can use git tag *-d * Remove our lightweight tag above as follows: .remove tag [source,bash] ---- git tag -d v1.4-lw ---- TIP: Note that this does not remove the tag from any remote servers. ==== remove from server .remove the tag from any remote servers [source,bash] ---- git push origin --delete ---- === Checking out Tags If you want to view the versions of files a tag is pointing to, you can do a git checkout of that tag, although this puts your repository in “detached HEAD” state, which has some ill side effects: [source,bash] ---- git checkout v2.0.0 ---- [NOTE] ==== In *“detached HEAD”* state * if you make changes and then create a commit, the tag will stay the same, *but your new commit won’t belong to any branch and will be unreachable*, except by the exact commit hash. * Thus, if you need to make changes — say you’re fixing a bug on an older version, for instance — you will generally want to *create a branch*: [source,bash] ---- git checkout -b version2 v2.0.0 ---- .new branch 'version2' TIP: If you do this and make a commit, your version2 *branch will be slightly different than your v2.0.0* tag since it will move forward with your new changes, so do *be careful*. ==== ==== One of the more helpful options is -p or --patch, which shows the difference (the patch output) introduced in each commit. "Pro Git book" by Scott Chacon and Ben Straub , used under CC BY-NC-SA 3.0 / Desaturated from original