/docs/MyDocs

To get this branch, use:
bzr branch http://darksoft.org/webbzr/docs/MyDocs

« back to all changes in this revision

Viewing changes to SCM/rcs/git/git.txt

  • Committer: Suren A. Chilingaryan
  • Date: 2017-04-03 02:45:17 UTC
  • Revision ID: csa@suren.me-20170403024517-dwzj0z0k1cmhxm7u
Restructuring, OpenShift, Ansible, Git

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Setup
 
2
-----
 
3
 There is 3 configurations: repository local, user global, and the system
 
4
    git config --[local/global/system] --edit   
 
5
 
 
6
 - Standard options
 
7
    git config --global user.name "Suren A. Chilingaryan"
 
8
    git config --global user.email "csa@suren.me"
 
9
    git config --system core.editor mcedit
 
10
 
 
11
 - List all settings in the current context
 
12
    git config --list
 
13
 
 
14
Init
 
15
----
 
16
 - The recommended way is to first init empty remote repository and, then, clone it locally and copy .git to the 
 
17
 project directory.
 
18
    ssh darksoft.org
 
19
        (cd /repo/csa/git ; git init --bare my-project.git)
 
20
    git clone git clone ssh://darksoft.org/repo/csa/git/my-project.git
 
21
 Alternatively, the local directory can be initiated, remote configured, and tracking/association of master branch requested
 
22
    git init
 
23
    git remote origin ssh://darksoft.org/repo/csa/git/my-project.git
 
24
    git checkout -b master origin/master
 
25
  
 
26
 - Configuring repository
 
27
    * As of git 1.6.1, it will not add symlinks pointing outside of git tree. Otherwise
 
28
    git add .                                                           - both adds new files and marks files for the next commit (its called staging in Git terminology)
 
29
    git status -s                                                       - current status (-s makes a dense summary)
 
30
    git commit -m "Comment"
 
31
 
 
32
 
 
33
Branches, tags, revisions, and refspecs
 
34
---------------------------------------
 
35
 - Revision is uniquely indentified by SHA1 checksum. It is uniq not only within the branch, but also within repository
 
36
 and all remote bracnhes (see bellow). Each revision (excpet initial one) is associated with one or more parrent revisions
 
37
    * If you commit new revision, the current revision will become the parent of the newly commited one.
 
38
    * If you merge two (or more) revisions, both will become the parent revisions.
 
39
 
 
40
 
 
41
 - The branch is a direct line of changes. Multiple branches may include the same revision. Actually, they will if they 
 
42
 have common history or were merged at some point.
 
43
        git branch                                                      - list of existing branches
 
44
        git checkout <branch>                                           - change currently active branch
 
45
        git branch <name>                                               - create a new branch
 
46
        git branch -b <name> <tag_name>                                 - branch from a specific tagged revision
 
47
 - Tags just a named reference of the specific revision.
 
48
        git tag [-l '1.5*']                                             - list existing tags
 
49
        git checkout <tag>                                              - changes the source tree to the specific revision
 
50
        git tag -a <name> [revision]                                    - tags current or the specified revision
 
51
        git tag -a <name> -m "description"                              - creates annotated tag (with description, signature, etc.), simple tags just an reference and nothign more
 
52
 - 'Refs' is  just an general term for various way to reference the specific revision. It includes tags, heads of local
 
53
    branches, SHA1. When referencing the revision, Git will normally automatically determin which type of reference is used.
 
54
    But it also possible to specify it explicitey:
 
55
        HEAD                                                            - specifying the HEAD of repository acrross multiple branches
 
56
                                                                        for developer repositories, this is the branch/tag/revision which currently checked out
 
57
                                                                        for bare branches it will point to the head of upstream branch (head of the master normally)
 
58
        refs/tags/<tag-name>                                            - specify specific tag
 
59
        refs/heads/<branch-name>                                        - specify the head of the specific branch
 
60
        refs/remotes/<remote-name>/*                                    - referring the refs (HEAD, tags, heads, etc.) fetched from the remote repositories
 
61
 
 
62
 - Addressing specific revisions and branches
 
63
    refs1..refs2                                                        - revision range between two refs (if there is a path)
 
64
                                                                        if diverged, will include all commits in refs2 history which are not in refs1 history 
 
65
                                                                            -> plainly speaking all revisions from the divergence point (in most cases)
 
66
    refs1...refs2                                                       - xor (all revisions which are in the history of refs1 or refs2, but not in their common)
 
67
    refs1 refs2 ^refs3 --not refs4                                      - all commits of refs1 & refs2 which are not in the history of both refs3 and refs4
 
68
    
 
69
    ref^#                                                               - references the #'th parent of the specified merge
 
70
    ref~#                                                               - #'th generation ancestor of the specified revision (following first parents)
 
71
 
 
72
    branch@{upstream}                                                   - configured remote branch of the specified branch (i.e. branch.<branch>.remote)
 
73
    branch@{push}                                                       - configured branch where we will push (i.e. branch.<branch>.push)
 
74
 
 
75
 - Revision logs
 
76
        git describe <branch>                                           - gives closest tag and number of revisions since
 
77
        git log --pretty=oneline                                        - revision history of current branch
 
78
        git log --pretty=formate:"%h %s" --graph                        - include branching/merging structure
 
79
        git log -p -10 --since=2.weeks                                  - limit to 2 revisions and last 2 weeks, includes also diffs
 
80
        git log -L 10,12:zlib.c                                         - history related to the specified lines of the file
 
81
        git blame -L/-C 12,22 zlib.c                                    - Quick summary about who was last modifying the specified lines (-L limited to file, -C tries to see if the code was copied from other files)
 
82
        git log -L :git_deflate_bound:zlib.c                            - history related to specific function
 
83
        git log rev1..rev2                                              - only difference between two revisions
 
84
            git log master~1..master                                    - the last commit on the master branch (may include multiple commits if merged)
 
85
 
 
86
 - History: git maintains few histories about major operations on the repository like bracnhes, merges, HEAD changes, etc.
 
87
        git reflog                                                      - shows history about major operations on git (branches, merges, etc.) (alternatively git log -g)
 
88
        git status branch@{yesterday}                                   - reports position of the branch yesterday or any specific date
 
89
                                                                        Dates: # month/week/day/hour/second ago, 1979-02-26 18:30:00
 
90
                                                                        Number of changes back @{#}
 
91
 
 
92
Working with Git
 
93
----------------
 
94
 - Ignoring files
 
95
    * List of recommended ignores: 
 
96
        https://github.com/github/gitignore
 
97
    * Managing repository ignores just by editing 
 
98
        .gitignore
 
99
    * Removing newly ignored file
 
100
        git rm --cached FILENAME                                        - the file will not be removed
 
101
    * Ignoring files globally for all projects on this computer
 
102
        git config --global core.excludesfile ~/.gitignore_global
 
103
    * Format
 
104
        - Standard globbing patterns
 
105
        - Start with '/' to mention a specific file, not a pattern for all directories
 
106
        - Otherwise 'a/b' will select all files 'b' residing in directory 'a', i.e. 'docs/README' will exclude both 'src/docs/README' and 'lib/docs/README'
 
107
        - 'a/**/b' reffers to any number (or none) of directories between a and b, i.e. 'a/b' also matched
 
108
        - If end with '/' to consider directories only
 
109
        - !something excludes some ignored pattern
 
110
 
 
111
 
 
112
 - Working with changes
 
113
    git add <dir/file>                                                  - marks files as staged for future commit
 
114
        git reset HEAD <dir/file>                                       - unmark files
 
115
        git add -A <dir>                                                - will try to fix moved subdirectory (should be called from the parent of moved subdirectory)
 
116
        git add --patch                                                 - stage individual patches from the file
 
117
        git add -i                                                      - interactively select that to update and that not (possible to select individual patches as well)
 
118
    git commit -m "chages"                                              - commits staged files
 
119
      git commit --ammend                                               - allows to modify the last commit (uses currently staged files instead of ones selected during the original commit)
 
120
      git commit -S                                                     - make a gpg-signed commit
 
121
 
 
122
 - Fixing wrong commits and optimizing                                  - remove commits, edit messages, reorder, squash multiple commits in one, and split commit into the multiple ones
 
123
    git rebase -i HEAD~3                                                - will allow change last 3 commits by actually rebasing (see bellow), '-i' allows to interactively select action for each commit
 
124
    git filter-branch --tree-filter 'rm -f passwords.txt' HEAD          - batch mode, executes command on each revision tree in the branch
 
125
    git reset --soft|mixed|hard HEAD~                                   - move branch head one revision back, but keep the last revision (as kind of dangling, not belonging to any branches)
 
126
                                                                        both the working directory and the staging are are kept in soft mode and reset in hard mode (files destroyed). In Mixed only index reseted
 
127
    git reset --mixed|hard <file|directory>                             - reset the file in staging area (and working directory in hard-mode) to the version HEAD is pointing     
 
128
 
 
129
 - Analyzing
 
130
    git diff --staged <dir/file>                                        - diff between the last revision and currently staged files without --staged with all the changes in the tree (--cached = --staged)
 
131
        git diff --check                                                - check for some formatting errors
 
132
    
 
133
    git checkout -- <file>                                              - discard the changes in the file
 
134
    git grep -n -p --break --heading                                    - n for line number, p for functions, the rest is formatting
 
135
 
 
136
 
 
137
 - Merging
 
138
    git merge <branch>                                                  - merge from the branch
 
139
        -Xignore-all-space or -Xignore-space-change                     - first ignores all spaces enterily, the second assumes arbitrary number of spaces as 1.
 
140
        -Xours / -Xtheirs                                               - resolve all conflicts in favor of  the specified revision
 
141
        --abort                                                         - cancel
 
142
    git mergetool                                                       - calls 3rd party mergetool to resolve conflicts
 
143
 
 
144
    git checkout --conflict=merge/diff3 <file>                          - see conflicts
 
145
    git revert -m <parent_number> HEAD                                  - commits a special commit efficiently canceling last merge
 
146
    git show :#:file                                                    - # is 1 for common ancestor, 2 local version, 3 for MERGE_HEAD
 
147
    git merge-file ours base theirs                                     - generate on stdout a merged file from 3 sources (possibly modified)
 
148
    git diff --ours|--theirs                                            - compare current version against parrents
 
149
 
 
150
    git branch -d <branch>                                              - remove merged branch if not needed any more
 
151
    
 
152
 - Rebasing [ SHOULD ONLY BE USED for merging revision available only localy! ]
 
153
    Rebase is alternative merging strategy. The result is the same, but history will look different (cleaner)
 
154
    - We will run 'rebase' from our current feature branch and incorporate all the changes from the master (or other branch we are 
 
155
    rebasig to). Basically, git will
 
156
        *) Find all revisions in the master which are not yet integrated in the feature branch.
 
157
        *) For each revision, it will generate a patch and re-apply this patch to current feature branch (makign a new revision)
 
158
        *) Will mark the master branch as direct parrent of the current feature branch
 
159
    i.e.
 
160
        *) All real revisions specific to the feature branch will be removed
 
161
        *) The master branch can be fast-forwarded to the feature branch if need be
 
162
        *) New history is simple and linear. The development history is lost.
 
163
        
 
164
    - More complex scenario is two features which are sharing some revisions. We already want to get one feature into the master,
 
165
    but avoid including any code from another. So, we would
 
166
        *) Find all revisions in the feature1 since it diverged from the feature2
 
167
        *) For the first found revision, generate a patch and apply it to the master. 
 
168
        *) Move feature2 onto generated revision and mark master as it direct parrent
 
169
        *) Reapply the rest of revisions, one after another
 
170
 
 
171
    git rebase master                                                   - Merge and make master head, the direct parent of the curret branch
 
172
    git rebase --onto master <exclude> <branch>                         - Takes branch, finds all revisions since its diverged from exclude and reply the patches on the master branch
 
173
 
 
174
    
 
175
 - Cherry-picking                                                       
 
176
    git cherry-pick <revision>                                          - Re-applies to current HEAD the specified commit (only single commit whatever the history) 
 
177
 
 
178
 
 
179
 
 
180
 - Saving current changes without really commiting them
 
181
    git stash                                                           - set aside changes to the current tree, and revert all the changes in the working tree (saved as patch against current revision)
 
182
    git stash list                                                      - list such stashes
 
183
    git stash apply [stash_id]                                          - can be preformed on different revison or branch. may produce conflicts ;)
 
184
    git stash branch <branch_name>                                      - create a new branch from the stash
 
185
 
 
186
 
 
187
Debugging
 
188
---------
 
189
    git bisect start                                                    - helps to identify the problematic revision
 
190
        git bisect bad                                                  - mark current revision as bad
 
191
        git bisect good <tag>                                           - marks last known good revision
 
192
        ... run the tests and mark the proposed revision as good or bad ...
 
193
 
 
194
Cleaning and packaging
 
195
----------------------
 
196
    git clean                                                           - remove all that is not part of repo
 
197
    
 
 
b'\\ No newline at end of file'