1GITEVERYDAY(7)                    Git Manual                    GITEVERYDAY(7)
2
3
4

NAME

6       giteveryday - A useful minimum set of commands for Everyday Git
7

SYNOPSIS

9       Everyday Git With 20 Commands Or So
10

DESCRIPTION

12       Git users can broadly be grouped into four categories for the purposes
13       of describing here a small set of useful commands for everyday Git.
14
15       •   Individual Developer (Standalone) commands are essential for
16           anybody who makes a commit, even for somebody who works alone.
17
18       •   If you work with other people, you will need commands listed in the
19           Individual Developer (Participant) section as well.
20
21       •   People who play the Integrator role need to learn some more
22           commands in addition to the above.
23
24       •   Repository Administration commands are for system administrators
25           who are responsible for the care and feeding of Git repositories.
26

INDIVIDUAL DEVELOPER (STANDALONE)

28       A standalone individual developer does not exchange patches with other
29       people, and works alone in a single repository, using the following
30       commands.
31
32git-init(1) to create a new repository.
33
34git-log(1) to see what happened.
35
36git-switch(1) and git-branch(1) to switch branches.
37
38git-add(1) to manage the index file.
39
40git-diff(1) and git-status(1) to see what you are in the middle of
41           doing.
42
43git-commit(1) to advance the current branch.
44
45git-restore(1) to undo changes.
46
47git-merge(1) to merge between local branches.
48
49git-rebase(1) to maintain topic branches.
50
51git-tag(1) to mark a known point.
52
53   Examples
54       Use a tarball as a starting point for a new repository.
55
56               $ tar zxf frotz.tar.gz
57               $ cd frotz
58               $ git init
59               $ git add . (1)
60               $ git commit -m "import of frotz source tree."
61               $ git tag v2.43 (2)
62
63            1. add everything under the current directory.
64            2. make a lightweight, unannotated tag.
65
66       Create a topic branch and develop.
67
68               $ git switch -c alsa-audio (1)
69               $ edit/compile/test
70               $ git restore curses/ux_audio_oss.c (2)
71               $ git add curses/ux_audio_alsa.c (3)
72               $ edit/compile/test
73               $ git diff HEAD (4)
74               $ git commit -a -s (5)
75               $ edit/compile/test
76               $ git diff HEAD^ (6)
77               $ git commit -a --amend (7)
78               $ git switch master (8)
79               $ git merge alsa-audio (9)
80               $ git log --since='3 days ago' (10)
81               $ git log v2.43.. curses/ (11)
82
83            1. create a new topic branch.
84            2. revert your botched changes in curses/ux_audio_oss.c.
85            3. you need to tell Git if you added a new file; removal and
86               modification will be caught if you do git commit -a later.
87            4. to see what changes you are committing.
88            5. commit everything, as you have tested, with your sign-off.
89            6. look at all your changes including the previous commit.
90            7. amend the previous commit, adding all your new changes,
91               using your original message.
92            8. switch to the master branch.
93            9. merge a topic branch into your master branch.
94           10. review commit logs; other forms to limit output can be
95               combined and include -10 (to show up to 10 commits),
96               --until=2005-12-10, etc.
97           11. view only the changes that touch what’s in curses/
98               directory, since v2.43 tag.
99

INDIVIDUAL DEVELOPER (PARTICIPANT)

101       A developer working as a participant in a group project needs to learn
102       how to communicate with others, and uses these commands in addition to
103       the ones needed by a standalone developer.
104
105git-clone(1) from the upstream to prime your local repository.
106
107git-pull(1) and git-fetch(1) from "origin" to keep up-to-date with
108           the upstream.
109
110git-push(1) to shared repository, if you adopt CVS style shared
111           repository workflow.
112
113git-format-patch(1) to prepare e-mail submission, if you adopt
114           Linux kernel-style public forum workflow.
115
116git-send-email(1) to send your e-mail submission without corruption
117           by your MUA.
118
119git-request-pull(1) to create a summary of changes for your
120           upstream to pull.
121
122   Examples
123       Clone the upstream and work on it. Feed changes to upstream.
124
125               $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
126               $ cd my2.6
127               $ git switch -c mine master (1)
128               $ edit/compile/test; git commit -a -s (2)
129               $ git format-patch master (3)
130               $ git send-email --to="person <email@example.com>" 00*.patch (4)
131               $ git switch master (5)
132               $ git pull (6)
133               $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)
134               $ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)
135               $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)
136               $ git reset --hard ORIG_HEAD (10)
137               $ git gc (11)
138
139            1. checkout a new branch mine from master.
140            2. repeat as needed.
141            3. extract patches from your branch, relative to master,
142            4. and email them.
143            5. return to master, ready to see what’s new
144            6. git pull fetches from origin by default and merges into
145               the current branch.
146            7. immediately after pulling, look at the changes done
147               upstream since last time we checked, only in the area we
148               are interested in.
149            8. check the branch names in an external repository (if not
150               known).
151            9. fetch from a specific branch ALL from a specific
152               repository and merge it.
153           10. revert the pull.
154           11. garbage collect leftover objects from reverted pull.
155
156       Push into another repository.
157
158               satellite$ git clone mothership:frotz frotz (1)
159               satellite$ cd frotz
160               satellite$ git config --get-regexp '^(remote|branch)\.' (2)
161               remote.origin.url mothership:frotz
162               remote.origin.fetch refs/heads/*:refs/remotes/origin/*
163               branch.master.remote origin
164               branch.master.merge refs/heads/master
165               satellite$ git config remote.origin.push \
166                          +refs/heads/*:refs/remotes/satellite/* (3)
167               satellite$ edit/compile/test/commit
168               satellite$ git push origin (4)
169
170               mothership$ cd frotz
171               mothership$ git switch master
172               mothership$ git merge satellite/master (5)
173
174            1. mothership machine has a frotz repository under your home
175               directory; clone from it to start a repository on the
176               satellite machine.
177            2. clone sets these configuration variables by default. It
178               arranges git pull to fetch and store the branches of
179               mothership machine to local remotes/origin/*
180               remote-tracking branches.
181            3. arrange git push to push all local branches to their
182               corresponding branch of the mothership machine.
183            4. push will stash all our work away on remotes/satellite/*
184               remote-tracking branches on the mothership machine. You
185               could use this as a back-up method. Likewise, you can
186               pretend that mothership "fetched" from you (useful when
187               access is one sided).
188            5. on mothership machine, merge the work done on the
189               satellite machine into the master branch.
190
191       Branch off of a specific tag.
192
193               $ git switch -c private2.6.14 v2.6.14 (1)
194               $ edit/compile/test; git commit -a
195               $ git checkout master
196               $ git cherry-pick v2.6.14..private2.6.14 (2)
197
198
199            1. create a private branch based on a well known (but
200               somewhat behind) tag.
201            2. forward port all changes in private2.6.14 branch to master
202               branch without a formal "merging". Or longhand
203
204               git format-patch -k -m --stdout v2.6.14..private2.6.14 |
205               git am -3 -k
206
207       An alternate participant submission mechanism is using the git
208       request-pull or pull-request mechanisms (e.g. as used on GitHub
209       (www.github.com) to notify your upstream of your contribution.
210

INTEGRATOR

212       A fairly central person acting as the integrator in a group project
213       receives changes made by others, reviews and integrates them and
214       publishes the result for others to use, using these commands in
215       addition to the ones needed by participants.
216
217       This section can also be used by those who respond to git request-pull
218       or pull-request on GitHub (www.github.com) to integrate the work of
219       others into their history. A sub-area lieutenant for a repository will
220       act both as a participant and as an integrator.
221
222git-am(1) to apply patches e-mailed in from your contributors.
223
224git-pull(1) to merge from your trusted lieutenants.
225
226git-format-patch(1) to prepare and send suggested alternative to
227           contributors.
228
229git-revert(1) to undo botched commits.
230
231git-push(1) to publish the bleeding edge.
232
233   Examples
234       A typical integrator’s Git day.
235
236               $ git status (1)
237               $ git branch --no-merged master (2)
238               $ mailx (3)
239               & s 2 3 4 5 ./+to-apply
240               & s 7 8 ./+hold-linus
241               & q
242               $ git switch -c topic/one master
243               $ git am -3 -i -s ./+to-apply (4)
244               $ compile/test
245               $ git switch -c hold/linus && git am -3 -i -s ./+hold-linus (5)
246               $ git switch topic/one && git rebase master (6)
247               $ git switch -C seen next (7)
248               $ git merge topic/one topic/two && git merge hold/linus (8)
249               $ git switch maint
250               $ git cherry-pick master~4 (9)
251               $ compile/test
252               $ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)
253               $ git fetch ko && for branch in master maint next seen (11)
254                   do
255                       git show-branch ko/$branch $branch (12)
256                   done
257               $ git push --follow-tags ko (13)
258
259            1. see what you were in the middle of doing, if anything.
260            2. see which branches haven’t been merged into master yet.
261               Likewise for any other integration branches e.g.  maint,
262               next and seen.
263
264
265            3. read mails, save ones that are applicable, and save others
266               that are not quite ready (other mail readers are
267               available).
268            4. apply them, interactively, with your sign-offs.
269            5. create topic branch as needed and apply, again with
270               sign-offs.
271            6. rebase internal topic branch that has not been merged to
272               the master or exposed as a part of a stable branch.
273            7. restart seen every time from the next.
274            8. and bundle topic branches still cooking.
275            9. backport a critical fix.
276           10. create a signed tag.
277           11. make sure master was not accidentally rewound beyond that
278               already pushed out.
279           12. In the output from git show-branch, master should have
280               everything ko/master has, and next should have everything
281               ko/next has, etc.
282           13. push out the bleeding edge, together with new tags that
283               point into the pushed history.
284
285       In this example, the ko shorthand points at the Git maintainer’s
286       repository at kernel.org, and looks like this:
287
288           (in .git/config)
289           [remote "ko"]
290                   url = kernel.org:/pub/scm/git/git.git
291                   fetch = refs/heads/*:refs/remotes/ko/*
292                   push = refs/heads/master
293                   push = refs/heads/next
294                   push = +refs/heads/seen
295                   push = refs/heads/maint
296

REPOSITORY ADMINISTRATION

298       A repository administrator uses the following tools to set up and
299       maintain access to the repository by developers.
300
301git-daemon(1) to allow anonymous download from repository.
302
303git-shell(1) can be used as a restricted login shell for shared
304           central repository users.
305
306git-http-backend(1) provides a server side implementation of
307           Git-over-HTTP ("Smart http") allowing both fetch and push services.
308
309gitweb(1) provides a web front-end to Git repositories, which can
310           be set-up using the git-instaweb(1) script.
311
312       update hook howto[1] has a good example of managing a shared central
313       repository.
314
315       In addition there are a number of other widely deployed hosting,
316       browsing and reviewing solutions such as:
317
318       •   gitolite, gerrit code review, cgit and others.
319
320   Examples
321       We assume the following in /etc/services
322
323               $ grep 9418 /etc/services
324               git             9418/tcp                # Git Version Control System
325
326       Run git-daemon to serve /pub/scm from inetd.
327
328               $ grep git /etc/inetd.conf
329               git     stream  tcp     nowait  nobody \
330                 /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
331
332           The actual configuration line should be on one line.
333
334       Run git-daemon to serve /pub/scm from xinetd.
335
336               $ cat /etc/xinetd.d/git-daemon
337               # default: off
338               # description: The Git server offers access to Git repositories
339               service git
340               {
341                       disable = no
342                       type            = UNLISTED
343                       port            = 9418
344                       socket_type     = stream
345                       wait            = no
346                       user            = nobody
347                       server          = /usr/bin/git-daemon
348                       server_args     = --inetd --export-all --base-path=/pub/scm
349                       log_on_failure  += USERID
350               }
351
352           Check your xinetd(8) documentation and setup, this is from a Fedora
353           system. Others might be different.
354
355       Give push/pull only access to developers using git-over-ssh.
356           e.g. those using: $ git push/pull ssh://host.xz/pub/scm/project
357
358               $ grep git /etc/passwd (1)
359               alice:x:1000:1000::/home/alice:/usr/bin/git-shell
360               bob:x:1001:1001::/home/bob:/usr/bin/git-shell
361               cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
362               david:x:1003:1003::/home/david:/usr/bin/git-shell
363               $ grep git /etc/shells (2)
364               /usr/bin/git-shell
365
366            1. log-in shell is set to /usr/bin/git-shell, which does not
367               allow anything but git push and git pull. The users
368               require ssh access to the machine.
369            2. in many distributions /etc/shells needs to list what is
370               used as the login shell.
371
372       CVS-style shared repository.
373
374               $ grep git /etc/group (1)
375               git:x:9418:alice,bob,cindy,david
376               $ cd /home/devo.git
377               $ ls -l (2)
378                 lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
379                 drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
380                 -rw-rw-r--   1 david git    84 Dec  4 22:40 config
381                 -rw-rw-r--   1 david git    58 Dec  4 22:40 description
382                 drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
383                 -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
384                 drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
385                 drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
386                 drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
387                 drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
388               $ ls -l hooks/update (3)
389                 -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
390               $ cat info/allowed-users (4)
391               refs/heads/master       alice\|cindy
392               refs/heads/doc-update   bob
393               refs/tags/v[0-9]*       david
394
395            1. place the developers into the same git group.
396
397            2. and make the shared repository writable by the group.
398            3. use update-hook example by Carl from Documentation/howto/
399               for branch policy control.
400            4. alice and cindy can push into master, only bob can push
401               into doc-update. david is the release manager and is the
402               only person who can create and push version tags.
403

GIT

405       Part of the git(1) suite
406

NOTES

408        1. update hook howto
409           file:///usr/share/doc/git/howto/update-hook-example.html
410
411
412
413Git 2.43.0                        11/20/2023                    GITEVERYDAY(7)
Impressum