NAME<\/a> giteveryday \u2212 A useful minimum set of commands for Everyday Git<\/p>\n Everyday Git With 20 Commands Or So<\/p>\n Git users can broadly be grouped into four categories for the purposes of describing here a small set of useful command for everyday Git.<\/p>\n \u2022 Individual Developer (Standalone) commands are essential for anybody who makes a commit, even for somebody who works alone.<\/p>\n \u2022 If you work with other people, you will need commands listed in the Individual Developer (Participant) section as well.<\/p>\n \u2022 People who play the Integrator role need to learn some more commands in addition to the above.<\/p>\n \u2022 Repository Administration commands are for system administrators who are responsible for the care and feeding of Git repositories.<\/p>\n A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the following commands.<\/p>\n \u2022 git-init<\/b>(1) to create a new repository.<\/p>\n \u2022 git-log<\/b>(1) to see what happened.<\/p>\n \u2022 git-switch<\/b>(1) and git-branch<\/b>(1) to switch branches.<\/p>\n \u2022 git-add<\/b>(1) to manage the index file.<\/p>\n \u2022 git-diff<\/b>(1) and git-status<\/b>(1) to see what you are in the middle of doing.<\/p>\n \u2022 git-commit<\/b>(1) to advance the current branch.<\/p>\n \u2022 git-restore<\/b>(1) to undo changes.<\/p>\n \u2022 git-merge<\/b>(1) to merge between local branches.<\/p>\n \u2022 git-rebase<\/b>(1) to maintain topic branches.<\/p>\n \u2022 git-tag<\/b>(1) to mark a known point.<\/p>\n Examples<\/b> $ tar zxf frotz.tar.gz 1.<\/b> add everything under the current directory. Create a topic branch and develop.<\/p>\n $ git switch \u2212c alsa\u2212audio (1)<\/b> 1.<\/b> create a new topic branch. A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in addition to the ones needed by a standalone developer.<\/p>\n \u2022 git-clone<\/b>(1) from the upstream to prime your local repository.<\/p>\n \u2022 git-pull<\/b>(1) and git-fetch<\/b>(1) from “origin” to keep up\u2212to\u2212date with the upstream.<\/p>\n \u2022 git-push<\/b>(1) to shared repository, if you adopt CVS style shared repository workflow.<\/p>\n \u2022 git-format-patch<\/b>(1) to prepare e\u2212mail submission, if you adopt Linux kernel\u2212style public forum workflow.<\/p>\n \u2022 git-send-email<\/b>(1) to send your e\u2212mail submission without corruption by your MUA.<\/p>\n \u2022 git-request-pull<\/b>(1) to create a summary of changes for your upstream to pull.<\/p>\n Examples<\/b> $ git clone git:\/\/git.kernel.org\/pub\/scm\/…\/torvalds\/linux\u22122.6 my2.6 1.<\/b> checkout a new branch mine<\/b> from master. Push into another repository.<\/p>\n satellite$ git clone mothership:frotz frotz (1)<\/b> mothership$ cd frotz 1.<\/b> mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine. Branch off of a specific tag.<\/p>\n $ git switch \u2212c private2.6.14 v2.6.14 (1)<\/b> 1.<\/b> create a private branch based on a well known (but somewhat behind) tag. git format\u2212patch \u2212k \u2212m \u2212\u2212stdout v2.6.14..private2.6.14 | git am \u22123 \u2212k<\/b><\/p>\n An alternate participant submission mechanism is using the git request\u2212pull<\/b> or pull\u2212request mechanisms (e.g as used on GitHub (www.github.com) to notify your upstream of your contribution.<\/p>\n A fairly central person acting as the integrator in a group project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these commands in addition to the ones needed by participants.<\/p>\n This section can also be used by those who respond to git request\u2212pull<\/b> or pull\u2212request on GitHub (www.github.com) to integrate the work of others into their history. A sub\u2212area lieutenant for a repository will act both as a participant and as an integrator.<\/p>\n \u2022 git-am<\/b>(1) to apply patches e\u2212mailed in from your contributors.<\/p>\n \u2022 git-pull<\/b>(1) to merge from your trusted lieutenants.<\/p>\n \u2022 git-format-patch<\/b>(1) to prepare and send suggested alternative to contributors.<\/p>\n \u2022 git-revert<\/b>(1) to undo botched commits.<\/p>\n \u2022 git-push<\/b>(1) to publish the bleeding edge.<\/p>\n Examples<\/b> $ git status (1)<\/b> 1.<\/b> see what you were in the middle of doing, if anything. In this example, the ko<\/b> shorthand points at the Git maintainer\u2019s repository at kernel.org, and looks like this:<\/p>\n (in .git\/config) A repository administrator uses the following tools to set up and maintain access to the repository by developers.<\/p>\n \u2022 git-daemon<\/b>(1) to allow anonymous download from repository.<\/p>\n \u2022 git-shell<\/b>(1) can be used as a restricted login shell<\/i> for shared central repository users.<\/p>\n \u2022 git-http-backend<\/b>(1) provides a server side implementation of Git\u2212over\u2212HTTP (“Smart http”) allowing both fetch and push services.<\/p>\n \u2022 gitweb<\/b>(1) provides a web front\u2212end to Git repositories, which can be set\u2212up using the git-instaweb<\/b>(1) script.<\/p>\n update hook howto<\/font><\/b> [1]<\/font><\/small> has a good example of managing a shared central repository.<\/font><\/p>\n In addition there are a number of other widely deployed hosting, browsing and reviewing solutions such as:<\/font><\/p>\n \u2022 gitolite, gerrit code review, cgit and others.<\/font><\/p>\n Examples<\/b> $ grep 9418 \/etc\/services Run git\u2212daemon to serve \/pub\/scm from inetd.<\/font><\/p>\n $ grep git \/etc\/inetd.conf The actual configuration line should be on one line.<\/font><\/p>\n Run git\u2212daemon to serve \/pub\/scm from xinetd.<\/font><\/p>\n $ cat \/etc\/xinetd.d\/git\u2212daemon Check your xinetd(8) documentation and setup, this is from a Fedora system. Others might be different.<\/font><\/p>\n Give push\/pull only access to developers using git\u2212over\u2212ssh.<\/font><\/p>\n e.g. those using: $ git push\/pull ssh:\/\/host.xz\/pub\/scm\/project<\/b><\/font><\/p>\n $ grep git \/etc\/passwd (1)<\/b> 1.<\/b> log\u2212in shell is set to \/usr\/bin\/git\u2212shell, which does not allow anything but git push<\/b> and git pull<\/b>. The users require ssh access to the machine. CVS\u2212style shared repository.<\/font><\/p>\n $ grep git \/etc\/group (1)<\/b> 1.<\/b> place the developers into the same git group. Part of the git<\/b>(1) suite<\/font><\/p>\n 1.<\/font><\/p>\n<\/td>\n update hook howto<\/font><\/p>\n<\/td>\n file:\/\/\/usr\/share\/doc\/git-doc\/howto\/update-hook-example.html<\/font><\/p>\n giteveryday \u2212 A useful minimum set of commands for Everyday Git <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[971],"tags":[973,1037,972],"class_list":["post-3945","post","type-post","status-publish","format-standard","hentry","category-7-miscelanea","tag-973","tag-giteveryday","tag-man7"],"gutentor_comment":0,"_links":{"self":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/3945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/comments?post=3945"}],"version-history":[{"count":0,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/3945\/revisions"}],"wp:attachment":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/media?parent=3945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/categories?post=3945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/tags?post=3945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
SYNOPSIS<\/a>
DESCRIPTION<\/a>
INDIVIDUAL DEVELOPER (STANDALONE)<\/a>
INDIVIDUAL DEVELOPER (PARTICIPANT)<\/a>
INTEGRATOR<\/a>
REPOSITORY ADMINISTRATION<\/a>
GIT<\/a>
NOTES<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
DESCRIPTION <\/a> <\/h2>\n
INDIVIDUAL DEVELOPER (STANDALONE) <\/a> <\/h2>\n
Use a tarball as a starting point for a new repository.<\/p>\n
$ cd frotz
$ git init
$ git add . (1)<\/b>
$ git commit \u2212m “import of frotz source tree.”
$ git tag v2.43 (2)<\/b><\/p>\n
2.<\/b> make a lightweight, unannotated tag.<\/p>\n
$ edit\/compile\/test
$ git restore curses\/ux_audio_oss.c (2)<\/b>
$ git add curses\/ux_audio_alsa.c (3)<\/b>
$ edit\/compile\/test
$ git diff HEAD (4)<\/b>
$ git commit \u2212a \u2212s (5)<\/b>
$ edit\/compile\/test
$ git diff HEAD^ (6)<\/b>
$ git commit \u2212a \u2212\u2212amend (7)<\/b>
$ git switch master (8)<\/b>
$ git merge alsa\u2212audio (9)<\/b>
$ git log \u2212\u2212since=’3 days ago’ (10)<\/b>
$ git log v2.43.. curses\/ (11)<\/b><\/p>\n
2.<\/b> revert your botched changes in curses\/ux_audio_oss.c<\/b>.
3.<\/b> you need to tell Git if you added a new file; removal and modification will be caught if you do git commit \u2212a<\/b> later.
4.<\/b> to see what changes you are committing.
5.<\/b> commit everything, as you have tested, with your sign\u2212off.
6.<\/b> look at all your changes including the previous commit.
7.<\/b> amend the previous commit, adding all your new changes, using your original message.
8.<\/b> switch to the master branch.
9.<\/b> merge a topic branch into your master branch.
10.<\/b> review commit logs; other forms to limit output can be combined and include \u221210<\/b> (to show up to 10 commits), \u2212\u2212until=2005\u221212\u221210<\/b>, etc.
11.<\/b> view only the changes that touch what\u2019s in curses\/<\/b> directory, since v2.43<\/b> tag.<\/p>\nINDIVIDUAL DEVELOPER (PARTICIPANT) <\/a> <\/h2>\n
Clone the upstream and work on it. Feed changes to upstream.<\/p>\n
$ cd my2.6
$ git switch \u2212c mine master (1)<\/b>
$ edit\/compile\/test; git commit \u2212a \u2212s (2)<\/b>
$ git format\u2212patch master (3)<\/b>
$ git send\u2212email \u2212\u2212to=”person
$ git switch master (5)<\/b>
$ git pull (6)<\/b>
$ git log \u2212p ORIG_HEAD.. arch\/i386 include\/asm\u2212i386 (7)<\/b>
$ git ls\u2212remote \u2212\u2212heads http:\/\/git.kernel.org\/…\/jgarzik\/libata\u2212dev.git (8)<\/b>
$ git pull git:\/\/git.kernel.org\/pub\/…\/jgarzik\/libata\u2212dev.git ALL (9)<\/b>
$ git reset \u2212\u2212hard ORIG_HEAD (10)<\/b>
$ git gc (11)<\/b><\/p>\n
2.<\/b> repeat as needed.
3.<\/b> extract patches from your branch, relative to master,
4.<\/b> and email them.
5.<\/b> return to master<\/b>, ready to see what\u2019s new
6. git pull<\/b> fetches from origin<\/b> by default and merges into the current branch.
7.<\/b> immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in.
8.<\/b> check the branch names in an external repository (if not known).
9.<\/b> fetch from a specific branch ALL<\/b> from a specific repository and merge it.
10.<\/b> revert the pull.
11.<\/b> garbage collect leftover objects from reverted pull.<\/p>\n
satellite$ cd frotz
satellite$ git config \u2212\u2212get\u2212regexp ‘^(remote|branch).’ (2)<\/b>
remote.origin.url mothership:frotz
remote.origin.fetch refs\/heads\/*:refs\/remotes\/origin\/*
branch.master.remote origin
branch.master.merge refs\/heads\/master
satellite$ git config remote.origin.push
+refs\/heads\/*:refs\/remotes\/satellite\/* (3)<\/b>
satellite$ edit\/compile\/test\/commit
satellite$ git push origin (4)<\/b><\/p>\n
mothership$ git switch master
mothership$ git merge satellite\/master (5)<\/b><\/p>\n
2.<\/b> clone sets these configuration variables by default. It arranges git pull<\/b> to fetch and store the branches of mothership machine to local remotes\/origin\/*<\/b> remote\u2212tracking branches.
3.<\/b> arrange git push<\/b> to push all local branches to their corresponding branch of the mothership machine.
4.<\/b> push will stash all our work away on remotes\/satellite\/*<\/b> remote\u2212tracking branches on the mothership machine. You could use this as a back\u2212up method. Likewise, you can pretend that mothership “fetched” from you (useful when access is one sided).
5.<\/b> on mothership machine, merge the work done on the satellite machine into the master branch.<\/p>\n
$ edit\/compile\/test; git commit \u2212a
$ git checkout master
$ git cherry\u2212pick v2.6.14..private2.6.14 (2)<\/b><\/p>\n
2.<\/b> forward port all changes in private2.6.14<\/b> branch to master<\/b> branch without a formal “merging”. Or longhand<\/p>\nINTEGRATOR <\/a> <\/h2>\n
A typical integrator\u2019s Git day.<\/p>\n
$ git branch \u2212\u2212no\u2212merged master (2)<\/b>
$ mailx (3)<\/b>
& s 2 3 4 5 .\/+to\u2212apply
& s 7 8 .\/+hold\u2212linus
& q
$ git switch \u2212c topic\/one master
$ git am \u22123 \u2212i \u2212s .\/+to\u2212apply (4)<\/b>
$ compile\/test
$ git switch \u2212c hold\/linus && git am \u22123 \u2212i \u2212s .\/+hold\u2212linus (5)<\/b>
$ git switch topic\/one && git rebase master (6)<\/b>
$ git switch \u2212C seen next (7)<\/b>
$ git merge topic\/one topic\/two && git merge hold\/linus (8)<\/b>
$ git switch maint
$ git cherry\u2212pick master~4 (9)<\/b>
$ compile\/test
$ git tag \u2212s \u2212m “GIT 0.99.9x” v0.99.9x (10)<\/b>
$ git fetch ko && for branch in master maint next seen (11)<\/b>
do
git show\u2212branch ko\/$branch $branch (12)<\/b>
done
$ git push \u2212\u2212follow\u2212tags ko (13)<\/b><\/p>\n
2.<\/b> see which branches haven\u2019t been merged into master<\/b> yet. Likewise for any other integration branches e.g. maint<\/b>, next<\/b> and seen<\/b>.
3.<\/b> read mails, save ones that are applicable, and save others that are not quite ready (other mail readers are available).
4.<\/b> apply them, interactively, with your sign\u2212offs.
5.<\/b> create topic branch as needed and apply, again with sign\u2212offs.
6.<\/b> rebase internal topic branch that has not been merged to the master or exposed as a part of a stable branch.
7.<\/b> restart seen<\/b> every time from the next.
8.<\/b> and bundle topic branches still cooking.
9.<\/b> backport a critical fix.
10.<\/b> create a signed tag.
11.<\/b> make sure master was not accidentally rewound beyond that already pushed out.
12.<\/b> In the output from git show\u2212branch<\/b>, master<\/b> should have everything ko\/master<\/b> has, and next<\/b> should have everything ko\/next<\/b> has, etc.
13.<\/b> push out the bleeding edge, together with new tags that point into the pushed history.<\/p>\n
[remote “ko”]
url = kernel.org:\/pub\/scm\/git\/git.git
fetch = refs\/heads\/*:refs\/remotes\/ko\/*
push = refs\/heads\/master
push = refs\/heads\/next
push = +refs\/heads\/seen
push = refs\/heads\/maint<\/p>\nREPOSITORY ADMINISTRATION <\/a> <\/h2>\n
We assume the following in \/etc\/services<\/font><\/p>\n
git 9418\/tcp # Git Version Control System<\/font><\/p>\n
git stream tcp nowait nobody
\/usr\/bin\/git\u2212daemon git\u2212daemon \u2212\u2212inetd \u2212\u2212export\u2212all \/pub\/scm<\/font><\/p>\n
# default: off
# description: The Git server offers access to Git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = \/usr\/bin\/git\u2212daemon
server_args = \u2212\u2212inetd \u2212\u2212export\u2212all \u2212\u2212base\u2212path=\/pub\/scm
log_on_failure += USERID
}<\/font><\/p>\n
alice:x:1000:1000::\/home\/alice:\/usr\/bin\/git\u2212shell
bob:x:1001:1001::\/home\/bob:\/usr\/bin\/git\u2212shell
cindy:x:1002:1002::\/home\/cindy:\/usr\/bin\/git\u2212shell
david:x:1003:1003::\/home\/david:\/usr\/bin\/git\u2212shell
$ grep git \/etc\/shells (2)<\/b>
\/usr\/bin\/git\u2212shell<\/font><\/p>\n
2.<\/b> in many distributions \/etc\/shells needs to list what is used as the login shell.<\/font><\/p>\n
git:x:9418:alice,bob,cindy,david
$ cd \/home\/devo.git
$ ls \u2212l (2)<\/b>
lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD \u2212> refs\/heads\/master
drwxrwsr\u2212x 2 david git 4096 Dec 4 22:40 branches
\u2212rw\u2212rw\u2212r\u2212\u2212 1 david git 84 Dec 4 22:40 config
\u2212rw\u2212rw\u2212r\u2212\u2212 1 david git 58 Dec 4 22:40 description
drwxrwsr\u2212x 2 david git 4096 Dec 4 22:40 hooks
\u2212rw\u2212rw\u2212r\u2212\u2212 1 david git 37504 Dec 4 22:40 index
drwxrwsr\u2212x 2 david git 4096 Dec 4 22:40 info
drwxrwsr\u2212x 4 david git 4096 Dec 4 22:40 objects
drwxrwsr\u2212x 4 david git 4096 Nov 7 14:58 refs
drwxrwsr\u2212x 2 david git 4096 Dec 4 22:40 remotes
$ ls \u2212l hooks\/update (3)<\/b>
\u2212r\u2212xr\u2212xr\u2212x 1 david git 3536 Dec 4 22:40 update
$ cat info\/allowed\u2212users (4)<\/b>
refs\/heads\/master alice|cindy
refs\/heads\/doc\u2212update bob
refs\/tags\/v[0\u22129]* david<\/font><\/p>\n
2.<\/b> and make the shared repository writable by the group.
3.<\/b> use update\u2212hook example by Carl from Documentation\/howto\/ for branch policy control.
4.<\/b> alice and cindy can push into master, only bob can push into doc\u2212update. david is the release manager and is the only person who can create and push version tags.<\/font><\/p>\nGIT <\/a> <\/h2>\n
NOTES <\/a> <\/h2>\n
\n
\n <\/td>\n \n <\/td>\n \n <\/td>\n<\/tr>\n<\/table>\n
\n","protected":false},"excerpt":{"rendered":"