git

git clone

Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch --remotes), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch.

Table of Contents

git gui

Git GUI is started by running gitk, then selecting File>Start git gui.

git GUI

After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any (this is untrue when "--single-branch" is given; see below).

master changed to main in 2020

origin” is not special Just like the branch name “master” does not have any special meaning in Git, neither does “origin”. While “master” is the default name for a starting branch when you run git init which is the only reason it’s widely used, “origin” is the default name for a remote when you run git clone. If you run git clone -o booyah instead, then you will have booyah/master as your default remote branch.

Remote-tracking branch names take the form <remote>/<branch>

For instance, if you wanted to see what the master branch on your origin remote looked like as of the last time you communicated with it, you would check the origin/master branch. If you were working on an issue with a partner and they pushed up an iss53 branch, you might have your own local iss53 branch, but the branch on the server would be represented by the remote-tracking branch origin/iss53.

Downstream vs. Upstream

|--------------------------- time -----------------------------> 
|--- master ---- downstream -------> ------- upstream --------->
|            |                                              ^
|            +--> remote _clone_     from master _pull_ --> +
|                 [maybe need to]    from remote _push_ --> +
|                 [_fetch/merge_]
|                 [other people's]
|                 [commits]

Git remote repository access

Create a bare repo, no working files

There are two types of repos, one is 'bare' in that it contains no files that you can work with, only git indexed objects. It is suitable for sharing between other 'working files' repos.

  • Create a sharing git repository on a system with raid disks and network access.
$ mkdir backups/forest.git
$ cd    backups/forest.git
$ git init --bare
  • On working hosts where you want to track files, create a working repo, populate it with files, ane push it to the sharing repo.
$ mkdir ~/forest
$ cd    ~/forest
$ git init 
#
$ [copy your files into the new directory]
# Then add them to your local git repo
$ git add .
$ git commit
# Push them to the sharing repo, with the ```--set-upstream``` option
$ git push --set-upstream git+ssh://nas.example.com:/mnt/vol002/nfs2_share/backups/forest.git master

Enumerating objects: 12507, done.
Counting objects: 100% (12507/12507), done.
Delta compression using up to 2 threads
Compressing objects: 100% (6304/6304), done.
Writing objects: 100% (12507/12507), 95.18 MiB | 12.71 MiB/s, done.
Total 12507 (delta 6643), reused 9514 (delta 5966), pack-reused 0
remote: Resolving deltas: 100% (6643/6643), done.
To git+ssh://nas.example.com:/mnt/vol002/nfs2_share/backups/forest.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'git+ssh://nas.example.com:/mnt/vol/backups/forest.git’.

You can see the sharing repo definition here:

File: .git/config

[branch "master"]
    remote = git+ssh://nas.example.com:/mnt/vol/backups/forest.git
    merge = refs/heads/master
  • Pushing commits to a remote repository

Run git push origin main to push your local changes to your online repository. (push )

  • Pulling commits from a remote repository

Run git pull origin to pull other committed changes to your local repository. (pull )

  • Getting everything from a remote repository

For new hosts you can grab all the files by using git clone *remotename*. This will create a 'working directory' on your local machine.

  • Summary
$ git remote add progit https://github.com/progit/progit2.git # [1]
$ git fetch progit                                            # [2]
$ git branch --set-upstream-to=progit/master master           # [3]
$ git config --local remote.pushDefault origin                # [4]
  1. Add the source repository and give it a name. Here, I have chosen to call it progit.
  2. Get a reference on progit’s branches, in particular master.
  3. Set your master branch to fetch from the progit remote.
  4. Define the default push repository to origin.

Once this is done, the workflow becomes much simpler:

$ git checkout master # [1]
$ git pull            # [2]
$ git push            # [3]
  1. If you were on another branch, return to master.
  2. Fetch changes from progit and merge changes into master.
  3. Push your master branch to origin.

Reference:

Multiple remote git repositories

  1. John and Jessica both clone into their remotes
$ git clone john@githost:simplegit.git
...
$ git commit -am 'Remove invalid default value'
  [master 738ee87] Remove invalid default value
......
$ git clone jessica@githost:simplegit.git
...
 $ git commit -am 'Add reset task'
  [master fbff5bc] Add reset task
   1 files changed, 1 insertions(+), 0 deletions(-)
  1. Jessica makes changes, commits into her remote, the pushes to the server
$ git commit -am 'Add reset task'
[master fbff5bc] Add reset task

$ git push origin master
...
To jessica@githost:simplegit.git
1edee6b..fbff5bc master -> master
  1. John makes changes, commits into his remote, then tries to push them to the same server
$ git commit -am 'Remove invalid default value'
  [master 738ee87] Remove invalid default value
   1 files changed, 1 insertions(+), 1 deletions(-)
...
$ git push origin master
...
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'john@githost:simplegit.git

John must first fetch Jessica’s upstream changes and merge them into his local repository before he will be allowed to push.

  1. As a first step, John fetches Jessica’s work [fbff5] (this only fetches Jessica’s upstream work, it does not yet merge it into John’s work):
$ git fetch origin
...
From john@githost:simplegit
+ 049d078...fbff5bc master -> origin/master

John's
Master
commit
  |
[738ee] -> [1edee] -> [4b078]
              ^
[fbff5] ------+
  |
Origin Master
  1. Now John's work [738ee] can merge with Jessica’s work [fbff5] that he fetched into his own local work:
$ git merge origin/master

Origin
 Master
   |        John
[72bbc] -> [738ee] -> [1edee] -> [4b078]
   |                     ^
   |       Jessica       |              
   +-----> [fbff5] ------+              
              |                         
          Origin Master
  1. At this point, John might want to test this new code to make sure none of Jessica’s work affects any of his and, as long as everything seems fine, he can finally push the new merged work up to the server:
$ git push origin master
...
To john@githost:simplegit.git
fbff5bc..72bbc59 master -> master

Reference:

links

social