Git: Difference between revisions

From XPUB & Lens-Based wiki
No edit summary
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=install Git=
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
https://git-scm.com/downloads
==Mac==
Git is installed when you install [https://developer.apple.com/xcode/ Xcode]
to check if it is installed run in the command line:
git --version
If it responds with a version number, Git is installed
=Start Git: init=
To start using Git, you need:
* a dedicated folder for you project, where all files and sub-folders of the project live
* navigate with the command line to that folder: <code>cd path/to/folder</code>
* initialize Git: <code>git init</code>
The last step with create a hidden <code>.git/</code> folder where all the Git data will be stored. 
=3 Git moments=
http://codingdomain.com/git/partial-commits/git-staging-area.png
For local (in your computer) Git operations, there are 3 main moments:
* working: editing files 
* stage: adding (tracking) files to git
* commit: span-shooting the changes performed on files
==Stage==
Staging refers to the action of making files ready for commit.
* <code>git add</code> when run for the 1st time on file or folder, it ask Git to start tracking it
** on a file that is being tracked, but has since changed, it include those changes to be commited
** There might be files you might not want to track and therefore you don't add them
* <code>git status</code> overview or staged moment:
** displays ''tracked'' and ''untracked'' files
Trick: If you wanna ''stage'' from files which Git is tracking run: <code>git add -u</code>
==Commit==
A commit is version of your project. When you complete some part of the work, you commit!
* <code>git commit -m "message about what happened in that commit"</code> creates a version or ''commit'' of your project. A accompanying message describes what happen in that ''commit''.
* <code>git log</code> show the ''history of commits'', where each commit is shows an author, date, message and hash (a long string of letter and numbers that identifies the commit)
=Undoing things=
==unstage==
Unstage, means bring added changes out or the stage moment.
In other words, before commiting, the changes you made to a file, then <code>git add that.file</code>, can be undone by running:
<code>git reset HEAD file.name</code>
Warning: those changes will be lost!
==checkout a specific commit==
The state of files in a specific commit can be checked out using:
<code>git checkout commit-hash</code>
This command will detach the HEAD (like the reading head of a K7) from the latest commit. In other words, it will let you go back in time to a previous commit.
To keep it simple, you can't do much there, but look around, copy content from files and save them in new (untracked) files. 
When you are done, you can return the head to the latest commit by running
<code>git checkout master</code>
==reverts==
Reverts the head to a previous commit:
<code>git revert commit-hash</code>
But instead of erasing history, creates a new commit
-----
=resources=
[http://ndpsoftware.com/git-cheatsheet.html#loc=index; Git Cheatsheet]
[http://git-scm.com/ Git home]
[https://wubthecaptain.eu/articles/why-i-dont-support-github.html blog on Github Terms of Services]
http://eagain.net/articles/git-for-computer-scientists/
http://eagain.net/articles/git-for-computer-scientists/


== Trees, Branches, and Blobs ==
 
=Remotes / collaboration=
 
Git facilitates the coordination of contributions from different collaborators in a project.
 
Each contributor has a local repository, that is a ''''clone'''' of the ''remote repository''.
 
 
'''The remote repository acts as the central node from which all the users will receive - ''pull'' - and send - ''push'' contributions.'''
 
 
 
 
----
 
 
= git commands: Trees, Branches, and Blobs =


  git init
  git init
Line 148: Line 247:
Contrast with creating branch for each person ?!
Contrast with creating branch for each person ?!


== Recipes ==
= Recipes =
 


== Cloning from git.xpub.nl ==
== Cloning from git.xpub.nl ==
* Use the https address
* Choose a repository to clone from https://git.xpub.nl/
* When prompted, enter your username + password for logging into gitea.
* copy the ssh address of the repository: i.e ssh://git@git.xpub.nl:2501/XPUB/issue.xpub.nl.git
* <code>cd</code> your terminal window to where you want the to-be-cloned repository to go
* clone. ie <code>git clone ssh://git@git.xpub.nl:2501/XPUB/issue.xpub.nl.git</code>


=== Pusing a folder to git.xpub.nl ===
=== Pushing changes to git.xpub.nl ===
If you
* are the owner, collaborator, or belong to one of the [https://git.xpub.nl/org/XPUB/teams XPUB teams] with rights over over a git.xpub.nl repository,
* your ssh public keys is in your [https://git.xpub.nl/user/settings/keys profile settings]
you can push your commits onto the existing repository in git.xpub.nl


This recipe requires that you know some things such as:
clone:  
 
git clone ssh://git@git.xpub.nl:2501/XPUB/address.of.remote.git
* USERNAME: your username to ssh to [http://git.xpub.nl git.xpub.nl]. You will also need to know your password or (better) have already copied an ssh key to the server
make your changes
* SOMEFOLDER: the folder on your laptop (local computer) that you want to push
...
* NAMEOFREPO: the name for the repo on the server... typically the same as the name of the folder but it shouldn't be the same as another repo.
add the changes done to tracked files
 
git add -u 
==== Step 1: SSH to the server and run the bash script "newrepos.sh" ====
if you create a new file, add it
 
git add newfilename
    ssh USERNAME@git.xpub.nl
write a commit message
    cd /var/www/git.xpub.nl
git commit -m "the changes i made in this comit"
    ./newrepos.sh NAMEOFREPO "Description of my great project"
push your commit(s) to git.xpub.nl
 
git push origin master
This spits out a message like:
    ALL GOOD!
    push URL: git.xpub.nl:/var/www/git.xpub.nl/repos/NAMEOFREPO.git
 
You can logout now.
 
==== Step 2: Turn your folder into a git repository ====
 
You can skip this step, if your folder is already a git repo.
 
    cd path/to/SOMEFOLDER
    git init
 
You may want to make and add a ".gitignore" file to avoid adding files you *don't* want in the repo.
And then add things with


    git add myproject.py
=FAQ=
    git add subfolder
    ...


And commit them
* '''git fetch''': git fetch is the command that tells the local repository that there are changes available in the remote repository without bringing the changes into the local repository. ([https://git-scm.com/docs/git-fetch more info])
* '''git pull rebase''': is very similar to git merge. There is no difference in the end result, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. ([https://git-scm.com/book/en/v2/Git-Branching-Rebasing source])
* '''git push --force''': The git push --force command uploads content from a local repository to a remote repository. Normally, Git only allows changes to be pushed if the commit history of your local branch is up to date with the remote repository branch. Using --force disables some of the checks git does before you can push, so this command can cause the remote repository to lose commits that are made in between your latest pull and now; use it with care.([https://git-scm.com/docs/git-push#Documentation/git-push.txt---force more info])
* '''git stash''': Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit. ([https://git-scm.com/docs/git-stash source])
* '''git pop''': Use this to place a stash back. Or in more difficult phrasing: "Remove a single stashed state from the stash list and apply it on top of the current working tree state." ([https://git-scm.com/docs/git-stash#Documentation/git-stash.txt-pop--index-q--quietltstashgt source])
* '''HEAD''': In Git, HEAD refers to the currently checked-out branch's latest commit.
* '''origin''': The word origin is an alias that Git created to replace the remote URL of a remote repository. It represents the default branch on a remote and is a local ref representing a local copy of the HEAD in the remote repository.


    git commit -m "First commit"
=Git GUI clients=


==== Step 3: Add the repo as a "remote" to your repo ====
There are different Graphical User Interface (GUI) tools around that you can use to work with git through a visual interface.


    cd path/to/SOMEFOLDER
In one of the prototyping sessions in 2023 we looked into [https://gitnuro.jetpackduba.com/ Gitnuro] (Linux/Mac/Windows). It's a bit cryptic at first, but it could help a lot to understand git in a visual way.
    git remote add pzi USERNAME@git.xpub.nl:/var/www/git.xpub.nl/repos/NAMEOFREPO.git


Note that you should add your USERNAME for ssh'ing to git.xpub.nl
More git GUI tools: https://git-scm.com/downloads/guis


Now finally you can push and "set the upstream" to that remote as the default...
These look interesting and are cross-platform:


    git push -u pzi master
* https://gitnuro.jetpackduba.com/
* https://murmele.github.io/Gittyup/
* https://git-cola.github.io/

Latest revision as of 12:05, 13 March 2023

install Git

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

https://git-scm.com/downloads

Mac

Git is installed when you install Xcode

to check if it is installed run in the command line:

git --version

If it responds with a version number, Git is installed

Start Git: init

To start using Git, you need:

  • a dedicated folder for you project, where all files and sub-folders of the project live
  • navigate with the command line to that folder: cd path/to/folder
  • initialize Git: git init

The last step with create a hidden .git/ folder where all the Git data will be stored.

3 Git moments

git-staging-area.png

For local (in your computer) Git operations, there are 3 main moments:

  • working: editing files
  • stage: adding (tracking) files to git
  • commit: span-shooting the changes performed on files

Stage

Staging refers to the action of making files ready for commit.

  • git add when run for the 1st time on file or folder, it ask Git to start tracking it
    • on a file that is being tracked, but has since changed, it include those changes to be commited
    • There might be files you might not want to track and therefore you don't add them
  • git status overview or staged moment:
    • displays tracked and untracked files

Trick: If you wanna stage from files which Git is tracking run: git add -u

Commit

A commit is version of your project. When you complete some part of the work, you commit!

  • git commit -m "message about what happened in that commit" creates a version or commit of your project. A accompanying message describes what happen in that commit.
  • git log show the history of commits, where each commit is shows an author, date, message and hash (a long string of letter and numbers that identifies the commit)

Undoing things

unstage

Unstage, means bring added changes out or the stage moment. In other words, before commiting, the changes you made to a file, then git add that.file, can be undone by running:

git reset HEAD file.name

Warning: those changes will be lost!

checkout a specific commit

The state of files in a specific commit can be checked out using:

git checkout commit-hash

This command will detach the HEAD (like the reading head of a K7) from the latest commit. In other words, it will let you go back in time to a previous commit.

To keep it simple, you can't do much there, but look around, copy content from files and save them in new (untracked) files.

When you are done, you can return the head to the latest commit by running

git checkout master

reverts

Reverts the head to a previous commit: git revert commit-hash

But instead of erasing history, creates a new commit



resources

Git Cheatsheet

Git home

blog on Github Terms of Services

http://eagain.net/articles/git-for-computer-scientists/


Remotes / collaboration

Git facilitates the coordination of contributions from different collaborators in a project.

Each contributor has a local repository, that is a 'clone' of the remote repository.


The remote repository acts as the central node from which all the users will receive - pull - and send - push contributions.





git commands: Trees, Branches, and Blobs

git init
git add *
git commit -m 'hello git'


init, clone

git init
git clone git://...

status, add, diff

tracked/untracked "staged"

file status lifecycle, p. 20 gitbok

git status

Add a file called ".gitignore" to ignore "temporary" or other files you don't want to track.

*.[oa]
*~
*.pyc


git diff

Shows changes to unstaged files only

git diff --cached

Show what you've staged so far

commit

git commit -m 'added new quote'
git commit -a -m 'edited links'

Stages every file (that's being tracked) -- ie "auto add"

git commit --amend

Add forgotten changes to last commit.

rm

git rm readme.txt
git rm --cached readme.txt

Remove from the stage, but not the file! (untrack)

git mv

(technically git "sees" these movements already, same as mv, remove, add: but the command is there for convenience)

log

git log
git log -p -2
git log --stat
git log --pretty=oneline
git log --graph

remote

git remote
git remote -v
git add remote remote-name URL

Where remote-name is whatever you want it to be called, and the URL is a remote git URL.

git remote show origin
git fetch remote-name

pull

pull = fetch + merge

push

git push [remote-name] [branch-name]
git push origin master

tags

Show SMW ?!


<!?> Find/link workflow article for git + web

Auto-Completion

contrib/completion/git-completion.bash

Add to .bashrc:

source ~/.git-completion.bash

(or)

cp git-completion.bash /etc/bash_completion.d/

(linux)

cp git-completion.bash /opt/local/etc/bash_completion.d/

(mac)

branch

git checkout -b iss53

create + checkout a branch, short for:

git branch iss53
git checkout iss53
git checkout master
git checkout -b fix
git commit -a -m 'fixed something'
git checkout master
git merge fix
git branch -d fix

"Fast-forward" reflects that the changes were "upstream" of the current working state.


conflict

Generally, you want to commit all your changes before switching branches (checkout)


If we each write to master -- lots of conflicts? Contrast with creating branch for each person ?!

Recipes

Cloning from git.xpub.nl

Pushing changes to git.xpub.nl

If you

  • are the owner, collaborator, or belong to one of the XPUB teams with rights over over a git.xpub.nl repository,
  • your ssh public keys is in your profile settings

you can push your commits onto the existing repository in git.xpub.nl

clone:

git clone ssh://git@git.xpub.nl:2501/XPUB/address.of.remote.git

make your changes

...

add the changes done to tracked files

git add -u  

if you create a new file, add it

git add newfilename

write a commit message

git commit -m "the changes i made in this comit"

push your commit(s) to git.xpub.nl

git push origin master

FAQ

  • git fetch: git fetch is the command that tells the local repository that there are changes available in the remote repository without bringing the changes into the local repository. (more info)
  • git pull rebase: is very similar to git merge. There is no difference in the end result, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. (source)
  • git push --force: The git push --force command uploads content from a local repository to a remote repository. Normally, Git only allows changes to be pushed if the commit history of your local branch is up to date with the remote repository branch. Using --force disables some of the checks git does before you can push, so this command can cause the remote repository to lose commits that are made in between your latest pull and now; use it with care.(more info)
  • git stash: Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit. (source)
  • git pop: Use this to place a stash back. Or in more difficult phrasing: "Remove a single stashed state from the stash list and apply it on top of the current working tree state." (source)
  • HEAD: In Git, HEAD refers to the currently checked-out branch's latest commit.
  • origin: The word origin is an alias that Git created to replace the remote URL of a remote repository. It represents the default branch on a remote and is a local ref representing a local copy of the HEAD in the remote repository.

Git GUI clients

There are different Graphical User Interface (GUI) tools around that you can use to work with git through a visual interface.

In one of the prototyping sessions in 2023 we looked into Gitnuro (Linux/Mac/Windows). It's a bit cryptic at first, but it could help a lot to understand git in a visual way.

More git GUI tools: https://git-scm.com/downloads/guis

These look interesting and are cross-platform: