2 Source Code Management (SCM) and it's great. Check out https://git-scm.com/ for
3 details. Maybe also https://githowto.com/ could be interesting.
5 # Init - do it once per repository
6 You may clone it like `git clone URL` or create one from a folder by `git
9 Also, just after first commit, you may be asked to set up your name and email
10 address with `git config ...` command. If `--global` is used the name and/or
11 email will be automatically used for all the commits.
13 ## Command `git clone`
14 Copy existing repository that is available online from some server to local
17 git clone ssh://git@rtime.felk.cvut.cz/hubacji1/oneflow.git
21 Initialize directory to be able to use git commands.
26 ## Command `git config`
27 Setting up your name and email address is required at minimal.
29 git config user.name "Your Name"
30 git config user.email you@example.com
33 If the name and email should persist as default for any other git repository:
35 git config --global user.name "Your Name"
36 git config --global user.email you@example.com
39 # Explore the repository history
40 The command that show the whole history is `git log`. The history is build from
41 commits - changes to files in row scale.
43 The changes of the commit can be shown by `git show COMMIT_ID`. Where the
44 `COMMIT_ID` is the identifier obtained from `git log` command.
47 Show the commited history changes in descending order.
52 There is some useful parameters that may be combined:
60 Use the change stored in history.
65 # What is repository current state
66 The status of the repository can be checked by `git status` command. This
67 allows you to see *new files* that are not yet tracked, *changed files* whose
68 changes are not yet ready to be commited to the log history and *changed files*
71 The `git diff` command shows *changes* in not-yet-ready files and `git diff
72 --cached` shows *changes* that are ready to be committed.
74 ## Command `git status`
75 Show information about files in repository.
80 There are 3 states for file changes (let's call them *patches*) before stored
81 to git history: *untracked*, *unstaged*, and *staged*. Note that the whole file
82 may be patch. Also, `git status` command does not show patches, but files
83 containing these patches.
85 *Untracked* means that patch was not stored by git yet.
87 *Unstaged* files has older version stored in git history but patches are not
88 ready to be stored in git history.
90 *Staged* files has older version stored in git and patches will be stored to
91 git history as soon as `git commit` command is used.
94 The patches (file changes) may be shown by `git diff` command (because `git
95 status` show files not patches).
97 Unstaged patches can be seen by:
102 And staged patches by:
107 # Build repository history
108 Use `git commit` to store staged patches to git history. Moving patches and
109 files between states described above is done by `git add` and `git reset`
113 To stage patches in file (it means to take untracked or unstaged patches and
114 mark them as staged):
119 To stage all the patches in file use:
124 ## Command `git reset`
125 To remove patches from staged state (remove from staging area is also used):
127 git reset -p FILENAME
130 Or again for all the patches in file:
135 ## Command `git commit`
136 When sure that staged changes should be commited to the history, use:
138 git commit -m'COMMIT MSG'
141 Command without parameters will open text editor to let type the commit
147 Default text editor is `vim`. It can be closed by sequence `<Esc>:q!<Enter>`.
149 Please, keep these [The seven rules of a great Git commit message][1] when
150 writing the git commit messages:
151 - Separate subject from body with a blank line.
152 - Limit the subject line to 50 characters.
153 - Capitalize the subject line.
154 - Do not end the subject line with a period.
155 - Use the imperative mood in the subject line.
156 - Wrap the body at 72 characters.
157 - Use the body to explain what and why vs. how.
159 If still it's lot to remember, the heuristics is that a properly formed Git
160 commit subject line should always be able to complete the following sentence:
162 **If applied, this commit will your subject line here**
164 [1]: https://chris.beams.io/posts/git-commit/
167 Use `git COMMAND --help` for showing the help!
172 - `git config user.name "Your Name"`
173 - `git config user.email you@example.com`
174 - `git config --global user.name "Your Name"`
175 - `git config --global user.email you@example.com`
180 - `git log --oneline`
181 - `git log --decorate`
187 - `git diff --cached`
192 - `git reset -p FILE`
194 - `git commit -m'COMMIT MSG'`