Difference between revisions of "Git"

From Ever changing code
Jump to navigation Jump to search
 
(38 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Install=
{{Special:PrefixIndex/Git/}}
sudo apt-get install git


=Terminology=
[[Category:git]]
Git’s collaboration model is based on repository-to-repository interaction. In principle you push or pull commits from one repository to another.
:GitLab - web based interface to your Git repositories (GitHub)
 
:Staging Area - a place where we can group files together before we "commit" them to Git.
:Commit - is a snapshot of our repository. This way if we ever need to look back at the changes we've made (or if someone else does), we will see a nice timeline of all changes.
 
File status
*staged: Files are ready to be committed.
*unstaged: Files with changes that have not been prepared to be committed.
*untracked: Files aren't tracked by Git yet. This usually indicates a newly created file.
*deleted: File has been deleted and is waiting to be removed from Git.
 
:HEAD - is a pointer that holds your position within all your different commits. By default HEAD points to your most recent commit, so it can be used as a quick way to reference that commit without having to look up the SHA.
:Branching - are what naturally happens when you want to work on multiple features at the same time. You wouldn't want to end up with a master branch which has Feature A half done and Feature B half done. Rather you'd separate the code base into two "snapshots" (branches) and work on and commit to them separately. As soon as one was ready, you might merge this branch back into the master branch and push it to the remote server.
 
:Commands - are only relevant to directory that is tracked, it means it has .git/ tracking directory. Each time you use git commit changes are recorded in that directory.
 
=Git settings - pre requisites =
Specify your username and user email as these details are used each time you commit changes
git config --global user.email "piotr@example.com"
git config --global user.name "Piotr"  #name used for all your commits
git config --global --list      #list all of changes you made
 
Unset configuration
git config --global --unset http.proxy
 
=Commands=
== Create new repository in a current directory ==
git init  #creates hidden directory .git/ where changes are recorded all magic happens
git status # show files status
git log --summary #show details of each commit
git diff    #see changes, use HEAD argument for the current position in your commits
 
Create a new repository
 
git clone git@ourgit.example.com:piotr/ansible-training.git
cd ansible-training
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master
 
Existing folder or Git repository
 
cd existing_folder
git init
git remote add origin git@ourgit.example.com:piotr/ansible-training.git
git add .
git commit
git push -u origin master
 
=== Move a repository from GitLab to other GitLab ===
Let's assume you did clone a repo to your local machine. Notice you created --bare repository (can only push/fetch can't commit)
git clone --bare git@old-github.com/yourLogin/repository.git
Then you created an empty repo in the new GitLab called ''yourRepoName'', so you can upload/push to it
git remote add newgitlab git@new-github.com/yourLogin/yourRepoName.git  #add new remote GitLab repository before push
git push --mirror newgitlab        #push all branches and tags to new remote
 
This process also allows to change the project/repository name although you do not need to.
 
=== Create bare repository, central storage, GitLab repo ===
git init --bare project.git  #this will create a folder called ''project.git'' (bare repository)
<code>--bare</code> flag creates a repository that doesn’t have a working directory, making it impossible to edit files and commit changes. Ultimately it creates the central repository for developers to push/commit their changes. GitLab new projects are created this way, become ''remote repository''. Think of --bare as a way to mark a repository as a storage facility, opposed to a development environment.
 
=== Putting the Bare Repository on a Server ===
In preparation, you create a copy of ''project'' folder and place them in ''project.git'' pre-setup <code>--bare</code> folder
piotr@vmgitlab:~/git$ git clone --bare project project.git #project.git is ready to be moved to the server
 
Create a repository/project directory on the server. Need to be own by '''git:git''' user and group.
sudo -u git mkdir /var/opt/gitlab/git-data/repositories/your_gitlab_user
 
Assuming that /var/opt/gitlab/git-data/repositories/ (GitLab Omnibus) exists on that server, you can set up your new repository by copying your bare repository over:
                    local
                    user
scp -r project.git piotr@vmgitlab.home:project.git  #copy repo to the server
sudo mv ~/project.git /var/opt/gitlab/git-data/repositories/piotrek #move to the right GitLab repo store path
 
Default remote repo path used by GitLab Omnibus installation
  git:x:998:998::/var/opt/gitlab:/bin/sh
  git user home path              <span style="color: green">GitLab repos store</span> 
    |                            <span style="color: green">/</span>
  /var/opt/gitlab/<span style="color: green">git-data/repositories</span>/piotrek
                                          |
                          this is a namespace equals a username or group project name
                          all projects .git folders are stored here
 
sudo chown -R git:git /var/opt/gitlab/git-data/repositories/piotrek/ #each file need to be owned by git:git
 
Add repo to GitLab, below command for Omnibus Installation. It will search, add and process all git repositories.
piotr@vmgitlab:~$ sudo gitlab-rake gitlab:import:repos
Processing piotrek/project.git
  <span style="color: green">* Created gittest (piotrek/project.git)</span>  <- repo has been added
Processing piotrek/ansible.git
  * ansible (piotrek/ansible.git) exists
Processing piotrek/ansible.wiki.git
  * Skipping wiki repo
 
You will find the new project on the web interface of GitLab where it can be cloned from.
 
== Add a file to a staging area for changes to be tracked ==
git add octocat.txt
git add .            #. means current directory and all subdirectories
git add -A            #add all files, even file deletions are included
git add '*.txt'      #add files using a wildcard, notice that quotes are required
git reset <filename>  #remove a file from staging area, the file and its changes will not be tracked
 
== Committing (taking a snapshot of the repository) ==
The files are in the Staging Area, are not in a repository yet. To store our staged changes we run:
git commit -m "Description of what we changed"
 
== Add local repository to remote GitHub server ==
                creates repo    on remote GitHub
                name            server and repository
git remote add origin          <nowiki>https://vmgitlab.home/yourgitspace/gitrepo.git</nowiki>  #uses https connection
git remote add origin          git@vmgitlab.home:<span style="color: green">piotrek</span>/<span style="color: blue">ansible.git</span> #SSH connection; this need to be created in first place via Gitlab, create/add new project
                                                                      #Gitlab Omnibus server path for repos is  /var/opt/gitlab/git-data/repositories/<span style="color: green">piotrek</span>
                                                                      #containing relevant directories: <span style="color: blue">ansible.git</span> and <span style="color: blue">ansible.wiki.git</span>
git remote -v    #shows remote 'origin' repo path
    origin git@vmgitlab.home:piotrek/ansible.git (fetch)
    origin git@vmgitlab.home:piotrek/ansible.git (push)
 
==Push to remote server==
git push -u origin master        #push commits to '''origin''' repo '''master''' branch, -u stores these parameters
 
= Updating a local repo from a Remote Repository =
== Fetch changes from the remote repository ==
''git fetch'' doesn’t touch a working tree at all but updates tracking system allowing you to decide what you want to do next
git fetch    #download changes to local repo from remote 'origin/master' branch
git diff master origin/master  #compare local 'master' branch with remote 'origin/master' branch
git merge origin/master  #while working on 'master' (after a git checkout master) merge in the changes that you’ve just got from 'origin'
 
== Pull changes and automagicly merge ==
 
git pull origin master      #from the 'origin' remote repository its master branch
git stash        # to stash your not committed changes before pull
git stash apply  # to re-apply your changes after your pull
 
Preview changes of your staged files
git diff --staged
 
== Working with branches ==
=== Revert a file version from the last commit ===
git checkout -- filename.txt
git checkout $commit-id path/to/file
 
Create a new branch space to work for us
git branch branchname-newcode
git branch -d branchname-newcode      #deletes branch
git branch -D branchname-newcode      #forces delete since you cannot delete a branch that has not been merged, -D is equivalent -d -f
 
=== Change branch ===
git branch #list branches, one with asterisks it active current branch
git checkout branchname-newcode    #change to new branch
 
== Remove files ==
git rm '*.txt'
git rm -r folder_of_cats  #remove folders recursively
git commit -am "Delete stuff"    #-a auto removes deleted files within commit
 
== Merge other branch with the current active branch ==
git merge branchname-newcode
 
= Git config - configuration =
Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
 
* <code>/etc/gitconfig</code> contains values for every user on the system and all their repositories. Option '''--system''' reads this file
* <code>~/.gitconfig</code> or <code>~/.config/git/config</code> specific to your user, '''--global''' option writes to this file
* <code>.git/config</code> config file in the Git directory of whatever repository you’re currently using: option '''--local''' is specific to that single repository.
 
Each level overrides values in the previous level, so values in <.git/config trump those in /etc/gitconfig.
 
On Windows systems, Git looks for the '''.gitconfig''' file in the '''$HOME''' directory (C:\Users\$USER for most people). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. If you are using Git for Windows 2.x or later, there is also a system-level config file at C:\Documents and Settings\All Users\Application Data\Git\config on Windows XP, and in C:\ProgramData\Git\config on Windows Vista and newer. This config file can only be changed by git config -f <file> as an admin.
 
= Roles =
Roles are automation around include directives. Therefore directories like '''tasks, handlers, vars and meta''' are automatically included as long the 'main.yml' file is there. There is no need to reference them using referenced or absolute paths, they are automatically available and included in plays.
 
The main.yml file contains all directives relevant to the uppper directory it is in, can contain a list of tasks, handles or vars.
 
Let's assume you have structure like this
site.yml
webservers.yml  <- eg. master control file recalls 'roles' named as a directory in roles/<span style="color: green">rolename</span>
fooservers.yml
roles/
    <span style="color: green">common/          webservers/</span>         
      files/            files/        - files used locally or transferred to a remote node   
      templates/        templates/    - Jinja2 templates
      tasks/            tasks/        - (include) individual tasks that play will do something
      handlers/        handlers/      - (include) eg. server restarts, shared among tasks
      vars/            vars/          - (vars) binary values something equals something else
      defaults/        defaults/      - default settings
      meta/            meta/          - (vars) roles dependencies
 
In a playbook (eg. webservers.yml), it would look like this:
---
- hosts: webservers
  roles:
      <span style="color: green">- common
      - webservers</span>
 
This designates the following behaviors, for each role '''<span style="color: green">'x'</span>''':
 
*If <tt>roles/'''<span style="color: green">x</span>'''/tasks/main.yml</tt> exists, tasks listed therein will be added to the play
*If <tt>roles/'''<span style="color: green">x</span>'''/handlers/main.yml</tt> exists, handlers listed therein will be added to the play
*If <tt>roles/'''<span style="color: green">x</span>'''/vars/main.yml</tt> exists, variables listed therein will be added to the play
*If <tt>roles/'''<span style="color: green">x</span>'''/meta/main.yml</tt> exists, any role dependencies listed therein will be added to the list of roles
**Any copy, script, template or include tasks (in the role) can reference files in <tt>roles/'''<span style="color: green">x</span>'''/{files,templates,tasks}/</tt> (dir depends on task) without having to path them relatively or absolutely
 
=== Execution order ===
In a play any roles always execute before tasks. To manipulate the flow you can use pre_ and post_ directives
 
---
- hosts: awsweb
  <span style="color: green">pre_tasks:</span>
    - name: When the ROLE start
      raw: date > role_start-end.log
  roles:
    - webservers
  <span style="color: green">post_tasks:</span>
    - name: When the ROLE end
      raw: date >> role_start-end.log
 
= Add an empty directory to a repository =
Although it's not supported by design to track an empty directories you can add .ignore file
find . -name .git -prune -o -type d -empty -exec touch {}/.gitignore \;
with this content inside, however I've tested and an empty file did the job.
# Ignore everything in this directory
*
# Except this file
!.gitignore
Remember to remove or alter the .ignore file if you want to start tracking new files within such directory.
 
=Resources=
*[https://git-scm.com/book/en/v2 Pro Git book written by Scott Chacon] v2
*[https://git-scm.com/blog Git workflow]
*[https://try.github.io/wrap_up Git training]
*[https://www.codeschool.com/users/2384618 My profile at Code School]
*[http://longair.net/blog/2009/04/16/git-fetch-and-merge/ git: fetch and merge, don’t pull]
*[https://atom.io/ Atom cross platform text editor that syncs with Git]
*[http://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model] Git flow diagram

Latest revision as of 10:19, 7 November 2019

Retrieved from ‘http://wiki.ciscolinux.co.uk/index.php?title=Git&oldid=4861’