5 Makefile i Git

Makefile


Struktura







Tworzymy plik Makefile
all:    hello
hello:  main.o factorial.o hello.o
 gcc main.o factorial.o hello.o  -o  hello
main.o: main.c
 gcc -c main.c 
factorial.o: factorial.c
 gcc -c factorial.c
hello.o: hello.c
 gcc -c hello.c

gcc -c  tworzy *.o
gcc -o tworzy *.exe

Podany Makefile stworzy plik uruchamialny hello z połączenia
-main.o
-factorial.o
-hello.o

Każdy z nich opisujemy jak ma być skompilowany za pomocą gcc:
main.o: main.c
tab       gcc -c main.c
...
ważne, gcc poprzedzone TABem


W pliku factorial.c mamy funkcje factorial a w pliku hello.c  funkcje print_hallo.
Aby obie były widoczne w main.c trzeba dodać do niego
#include "functions.h"      (w hello.c i factorial.c również)

pliki mają taką zawartość:

functions.h:
void print_hello();
int factorial(int n);


main.c
#include<stdio.h>
#include "functions.h"

int main()
{
print_hello();
printf("Silnia z liczny 4 jest rowna %d\n",factorial(4));
return 0;


}


hello.c
#include<stdio.h>
#include "functions.h"

void print_hello()
{
printf("Hello dupa \n");
}

factorial.c
#include "functions.h"

int factorial(int n)
{ 
 if(n!=1)
 return n*factorial(n-1);
 else
 return 1;

}




Automatyczne nazwy w  makefile:
all: srv cli


srv: srv.c
 gcc -o $@ $<

cli: cli.c
 gcc -o $@ $<

clean:
 -rm -rf *.o srv cli

$@ is the file name of the target.
$< is the name of the first dependency

czyli stworzy dwa niezależne pliki i skasuje *.o
Uruchamianie kompilacji gdy mamy stworzony Makefile
make



Commit – nagrywa zmiany, ale tylko lokalnie


Clone – tworzenie kopi lokalnej


Show – informacje o repozytorium (w jakim katalogu jesteś takie repozytorium) Ważne gdzie sklonowałeś

                Git show

Status – pokazuje czy są zmiany względem repozytorium

                git status

Add – dodaj do listy plików obserwowanych przez git (dodać po zmianach,GIT LS-FILES lista dodanych)

                git add nazwapliku

                git commit   // ale musisz być zalogowany, więc:


                git config --global user.name "JanosikOpryszek"
                git config --global user.email "ahimm44@gmail.com"

i możemy komitować, tu z wiadomoscia message –m

                git commit -m "pierwsza zmiana"
                git commit –a –m „zmiana”  (po zmianie trzeba zrobić add albo commit  –a)

PUSH – po komicie(nagraniu lokalnym) trzeba wypchnąć (nazwa zdalnego tu origin,sprawdzic Git remote –v )

                git push origin master

PUL – ściąga ostatnie zmiany z repozytorium, ale tylko jak masz lokalnie starsze wersje. jak lokalnie masz aktualne ale sobie zmienisz pliki to nie ściągnie na starsze(nazwa zdalnego tu origin,sprawdzic Git remote –v )
    
            Git pull origin master

RM - usunięcie z listy plików które będą komitowane  (sprawdzenie co jest na liście: GIT LS-FILES)
  
                Git rm nazwapliku








Odwracanie zmian


Jak zmienisz i nie dasz ADD (przed commitem) to możesz cofnąć zmiany:
                git checkout filename

dla wszytkich plików:
             git checkout --  .

Usunięcie listy nieśledzonych plików

git clean -f

Usinięcie nieśledzonych katalogów

git clean -f -d

STASH – Jak lokalnie zmienisz dasz add (ale nie skomitujesz) to możesz cofnąć:
git reset HEAD

…albo  zapisać w przechowalni

                Git stash    - zapisze w przechowalni a tobie wróci do ostatniej wersji
Możemy wyświetlić zawartość przechowalni
                Git stash list
Możemy  przywrócić z przechowalni
                Git stash apply   (ewentualnie starsze dodać:  stash@{2}  ) (pop?)


Jak lokalnie zmienisz i skomitujesz! (ale nie zrobisz Push) to pull nie zwróci ci wersji z repozytorium. Jedynym sposobem, żeby cofnąć commita jest:

                git reset --hard HEAD~1   (liczba ile komitów,  nic=ostatni,  1=jeden wstecz przed ostatnim?…)

Lista zmian na Hedzie

git reflog

Jak lokalnie zmienisz i skomitujesz i wypchniesz do zdalnego repozytorium to cofasz lokalne zmiany (jak powyżej) i wykonujesz force-push do zdalnego repozytorium (musi być dozwolona modyfikacja historii repozytorium (odznaczona opcja Prevent rewriting history). Warto tutaj również wspomnieć, iż nie zalecane jest stosować tej praktyki na głównym branchu, lecz tylko na feature branchach.
                git push -f origin

Ale lepiej utworzyć commita odwracającego i cofającego zmiany
                Git revert  HEAD
I zrobić push (jeśli był wypchnięty do zdalnego repo)
                Git push

Lista plików
Git ls-files


Amend -- Poprawka commita (np. zmiana komentarza, dodanie plików, wzięcie z poczekalni)
$ git commit -m 'initial commit'  /commit z zapomnianym plikiem
$ git add forgotten_file
$ git commit --amend


Resetowanie mastera:

git checkout -B master origin/master
If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is reset.

albo:
$ git checkout master

# remember where the master was referencing to
$ git branch previous_master

# Reset master back to origin/master
$ git reset --hard origin/master

merge --squash

Say your bug fix branch is called bugfix and you want to merge it into master:


git checkout master
git merge --squash bugfix
git commit
Explanation:
git checkout master
Switches to your master branch.
git merge --squash bugfix
Takes all the commits from the bugfix branch and merges it with your current branch.
git commit
Creates a single commit from the merged changes.

Różnica pomiędzy samym merge a merge --squash



Stash (schowek) (żonglowanie pomiędzy branchami)

Komenda „stash” wrzuca zmiany do schowka, ale nie dotyczy to plików w stanie „untracked”.

„List”  pozwala prześledzić nasze „stash-commity” w schowku. Posiadają one swoje numerki 0,1,2,..,x, gdzie 0 to ostatnio dodane zmiany do schowka.

Te numerki wykorzystujemy, gdy chcemy prześledzić jakich plików dotyczą konkretne zmiany („stash show stash@{x}”).

Nakładanie zmian ze schowka na obecny stan HEAD odbywa się przy pomocy „stash apply”. Nie podając parametru „–index” powodujemy, że zmiany nie znajdą się w przechowalni i konieczne jest jawne ich dodanie przez „git add …” lub „git commit -a …”. Oczywiście „apply” możemy zastosować do konkretnego „stash-commita”.



git stash
git stash list
git stash show stash@{x}
git stash apply
git stash apply --index
git stash apply stash@{x} --index
git stash branch
git stash drop stash@{x}
git stash pop
git stash clear



Gałęzie, tworzy tylko w repozytorium, w folderze mamy dalej te same pliki

Branch – tworzenie nowej (ale nie przełączy na nią)

               Git branch  nazwa

Tworzy i przełącza:

               Git checkout –b nazwa

Wyświetlanie gałęzi

               Git branch –all

Przełączanie

               Git checkkout nazwa

Stworzenie gałęzi w zdalnym repozytorium

               git push --set-upstream origin kolejna


N  E  W  !  !

WIZUALNE

gitk
git gui

git log --graph --decorate



Git checkout 

git commit -am  (git add + git commit)

git fetch  my_repo master    (pull to tak naprawde fetch + merge)

czyli
można pobrać zmiany na nową gałąź, obejrzec i dopiero zmergować mastera z nową

git fetch my_repo master1

------------------------------------------------ oderwana glowa
git log - pokazuje commity i możemy się przełączać

git checkout xxxx   (wystarcza 4 pierwsze znaki) 

nadanie TAG

git tag Nazwa xxxx

i teraz

git checkout Nazwa

Tworzenie Brancha na podstawie commita 

git checkout -b MyBranch xxxx

usuwanie brancha:

git branch -d MyBranch
                 -D

usuwanie taga

git tag -d MyTag


Porównanie pliku pomiedzy jedna a druga gałęzia


git diff mybranch master -- myfile.cs

Konflikty 

KDIFF3  (zainstalować i dopisać w user(home) plik  .gitconfig

[merge]
   tool : KDIFF3
[mergetool  "kdiff3"]
   patch=c:/user/eblzmrc....

uruchomic
git mergetool

Ignore

(np powstałe w kodiff pliki orig)

.gitignore
i dopisac
*.orig


Rebase

git reset --mixed  HEAD1
                soft                ~2 (przesuniecie o jeden)
                hard

mixed  cofa  add i committ
soft      cofa   commit
hard    cofa   całość (znika commit)


przykład:
głowa ustawiona na starszym commicie, Przerzucenie zmian z niego na mastera:
  555  git stash               - zapisze w przechowalni a tobie wróci do ostatniej wersji

  558  git checkout master      -przełacz na mastera
  559  git pull                  -pulluj
  560  git log
  561  git reset --soft HEAD~2    -cofnij commita 1 w tył
  562  git pull
  567  git log
  568  git reset --hard HEAD~5     -znika comit 4 w tył
  569  git pull
  570  git log
  571  git stash apply          -  przywrócić z przechowalni
  572  git status               - wychodzi, ze trzeba zmergować
  573  vim nazwapliku.cpp         -mergowanie
  575  git add -u
  577  git commit -m "komentarz"
  578  git push origin HEAD:refs/for/master


git rebase   - czysci mergecommity, zmienia bazowego commita z którego wychodzą

git pull --rebase origin master

jak sciąga i robi merga to nie widać mergecommitów


Lista zmian na Headzie

git reflog



KTO ?

git blame a.txt

RÓŻNICA

git diff XXX YYY

git diff  HEAD   - working directory (czerwone) z headem

git diff --staged  - working directory ze staged

git diff --name-only XXX YYY pokazuje tylko liste zmienionych plików

jak mam brancha i chcemy zobaczyc co zmienial, ale aktualny master jest duzo nowszy, to trzeba porownac naszego brancha ze starszym comitem z naszego brancha (ktory znajdujemy got log)


USUWANIE

git rm  --cached  a.txt   - untrack ale tylko ze sledzenia (fizycznie istnieje)

git rm  --a.txt                  - usuwa ze sledzenia ale i fizycznie


do geritta zawsze merge --squash

git merge --squash  branchname

jeśli mergujemy bez dodanego --squash przerzuci pośrednie commity, a z nim tylko zmerguje ostatnia finalna wersje, czysciej na gitk







Nowe repozytorium na githubie można stworzyć na stronie i ściągnąć jego lokalną wersję. Ale można stworzyć na stronie a następnie połączyć z nowym projektem w katalogu:

Będąc w katalogu projektu zainicjować go

                Git init

Dodać pliki z powyższego folderu do lokalnego repozytorium

               Git add *

Zakomitować lokalnie

               Git commit –m „First”

Dodać adres nowego repozytorium(stworzonego na stronie)
  
              Git remote add originX  https://github.com/JanosikOpryszek/testowe3.git

Można zweryfikować

               Git remote –v

Zpushować zmiany

               Git push originX master

Skasowanie ukrytego Katalogu w którym było repozytorium (żeby usunąć Katalog repozytorium)

                RM –rf .git 





SSH

generowanie klucza:

$ ssh-keygen -o -t rsa -C "adres@email.com" -b 4096

tworzy 2 pliki:
klucz
klucz.pub

treść publicznego wkleić do konfiguracji programu z którym się łaczymy, kopiowac z:
cat ~/.ssh/id_rsa.pub

prywatny dodać w systemie operacyjnym z którego się łączymy (przy tworzeniu dodaje):
$ ssh-add klucz


Windows git bash(Mingw):

save key to HOME\.ssh\id_rsa. After you have the key at that location, Git Bash will recognize the key and use it.

Note: Comments indicate that this doesn't work in all cases. You may need to copy the OpenSSH key to Program Files\Git\.ssh\id_rsa (or Program Files (x86)\Git\.ssh\id_rsa).

....
If you're using msysgit with the OpenSSH tools, you need to either create ~/.ssh/id_rsa, or create a Git configuration in ~/.ssh/config which points to your key.
Here's an example of a Git configuration for Bitbucket that will use the correct username, and a key other than the default key (in case you maintain one key for SSH connections, and another for Git accounts).
~/.ssh/config:
Host bitbucket.org
    Hostname bitbucket.org
    User git
    IdentityFile /C/keys/yourkey.key