Git notes

https://habr.com/ru/company/manychat/blog/511946/

https://gitlab.eng.roku.com/dea-looker/looker-foundation-prod/compare/master...PROGDE-803

https://habr.com/ru/post/512490/

 amend
git commit --amend -m "an updated commit message"

git commit --amend --no-edit

 squash
To squash four commits into one:
https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/
https://github.com/todotxt/todo.txt-android/wiki/squash-all-commits-related-to-a-single-issue-into-a-single-commit

https://www.internalpointers.com/post/squash-commits-into-one-git

git log --oneline
git rebase -i HEAD~4 .  - 4 commits it will invoke editor
git rebase -i HEAD~[NUMBER OF COMMITS]

 You mark a commit as squashable by changing the work pick into squash next to it (or s )
Save the file and close the editor. 

pick b1339db Fixed issue #421
squash cc4f2b5 Didn't work, trying something else
squash 7729f48 Fixed typo
squash b7c864c Seriously, #421 is fixed now
 
 If you've already pushed commits to GitHub, and then squash them locally, you will have to force the push to your branch:

$ git push origin branch-name --force 

https://legends2k.github.io/note/git_concepts/
https://zwischenzugs.com/2018/10/30/five-things-i-wish-id-known-about-git/
https://habrahabr.ru/company/playrix/blog/350492/
https://habrahabr.ru/company/playrix/blog/348864/
https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd
https://habr.com/company/flant/blog/419733/

http://www.integralist.co.uk/posts/git-tips/
https://github.com/git-tips/tips
https://github.com/1337/yesterday-i-learned/blob/master/git.md
http://ohshitgit.com/
https://stackoverflow.com/questions/4114095/how-to-revert-git-repository-to-a-previous-commit
https://habrahabr.ru/company/intel/blog/344962/

git config -l
git branch -a
git branch -r

git checkout -b 

 Keep forked in sync with upstream repo 

https://stackoverflow.com/questions/2432579/git-your-branch-is-ahead-by-x-commits/22383148

git remote -v
git remote show origin
git remote add upstream git@github.com:PelionProducts/space-optimizer.git
git remote -v

git fetch upstream
git checkout master
git merge upstream/master
- or -
git rebase upstream/master

git reset --hard origin/master

If you remove the fetch line from your project's .git/config file you'll stop 
seeng the "Your branch is ahead of 'origin/master' by N commits." annoyance from occurring.
/.git/config
```
[remote "origin"]
    url = 
    fetch = +refs/heads/*:refs/remotes/origin/*
```    

git rev-list origin..HEAD
# to see if the local repository is ahead, push needed

git rev-list HEAD..origin
# to see if the local repository is behind, pull needed


Посмотреть, что я добавил в stage:
git diff --cached

Git UI:
http://gitup.co/
Fork  - UI for MacOS

git gui
gittk
tig
https://github.com/jesseduffield/lazygit/

Magit fugitive

git tag -a thetagname
git tag -l
Revert to previous commit:
git-reset --hard HEAD^

git checkout -b
git add -p



alias glod='git log --oneline --decorate'

git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%C(bold blue)<%an>%Creset' --abbrev-commit


https://www.reddit.com/r/Python/comments/9vabpi/lets_share_useful_git_hooks_for_python_projects/

HEAD

HEAD is simply a reference to the current commit (latest) on the current branch.
There can only be a single HEAD at any given time. (excluding git worktree)

The content of HEAD is stored inside .git/HEAD and it contains the 40 bytes SHA-1 of the current commit.

detached HEAD
If you are not on the latest commit - meaning that HEAD is pointing to a prior commit in history its called detached HEAD.
https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting
	git reset --soft moves HEAD but doesn't change the staged snapshot or working directory,
	git reset --mixed updates the staged snapshot to match the commit but doesn't touch the working directory
	git reset --hard updates both staging and the working directory to the commit

Merge staregies
Merge — самый простой вариант. Например, есть две ветки: master и выделенная из нее feature.

Для merge можно использовать fast forward. Это возможно, если с того момента, как была начата работа в feature-ветке, 
в master не было сделано новых коммитов. То есть первый коммит в feature — это последний коммит в master. 

В таком случае указатель фиксируется на ветке master и перемещается на самый последний коммит в ветке feature. 
Таким образом ветвление устраняется через соединение feature-ветки с основным потоком master и удаление ненужной ветки. 
Получается линейная история, где все коммиты следуют друг за другом. 
На практике такой вариант случается нечасто, так как постоянно кто-то сливает коммиты в master.

В случае с rebase Git считывает все коммиты в feature, временно сохраняет, а затем пересоздает в том же порядке в master. 
После rebase изначальные коммиты пропадают, а поверх master появляются новые коммиты с тем же контентом. 
Тут возникают проблемы. При попытке сделать rebase ветки, с которой работают другие люди, можно поломать репозиторий. 
Например, если кто-то начал свою ветку из коммита, который был в feature, а вы этот коммит уничтожили и пересоздали. 
Rebase подходит больше для локальных веток.

https://goiabada.blog/git-tricks-avoiding-merge-when-dealing-with-remote-conflicts-52c175e526e6


git push :  unexpected message appears: "! [rejected]". 
The reason: "Updates were rejected because the tip of your current branch is behind its remote counterpart. 
Integrate the remote changes (e.g. hint: ‘git pull …’) before pushing again.".

git pull --rebase

http://www.integralist.co.uk/posts/git-merge-strategies/

https://medium.freecodecamp.org/git-rebase-and-the-golden-rule-explained-70715eccc372

https://dev.to/karaluton/explain-like-i-m-five-git-rebase-vs-merging-1k69

https://git-rebase.io/
https://hackernoon.com/dont-fear-the-rebase-bca683888dae
https://habr.com/post/432420/ . merge vs rebase
https://hackernoon.com/dont-fear-the-rebase-bca683888dae
git rebase: merges another branch into the branch where you are currently working,
and move all of the local commits that are ahead of the rebased branch to the top of the history on that branch.

To get the changes from master into your work branch, do:
 git rebase remote/master

To merge some_branch into master:

1) git checkout master
2) git pull origin master //Get all latest commits of master branch
3) git merge some_branch

Another option:
git checkout master && git pull && git branch -b  && git merge <СтараяВеткаГдеМногоКомитов> --squash

Origin HEAD remote ...

git push origin branchname
origin  is an alias on your system for a particular remote repository.

Git has the concept of "remotes", which are simply URLs to other copies of your repository. When you clone another repository, git automatically creates a remote named "origin" and points to it.

You can see more info about the remote by typing

git remote show origin

Remotes are simply an alias that store the url of repositories. You can see what url belongs to each remote by using:

git remote -v
In the push command, you can use remotes or you can simply use a url directly. An example that uses the url

git push git@github.com:git/git.git master

remotes/origin/master is a branch named master on the remote named origin. You can refer to this as either origin/master, as in:

git diff origin/master..master

origin/master is "where master was over there last time I checked"
master is "where master is over here based on what I have been doing"

origin/master = backup of remote machine, updated last time you checked master = your copy of origin/master


git fetch really only downloads new data from a remote repository - but it doesn't integrate any of this new data into your working files. Fetch is great for getting a fresh view on all the things that happened in a remote repository.
Due to it's "harmless" nature, you can rest assured: fetch will never manipulate, destroy, or screw up anything.

git pull, in contrast, is used with a different goal in mind: to update your current HEAD branch with the latest changes from the remote server. This means that pull not only downloads new data; it also directly integrates it into your current working copy files.

 Git Links 
Sync
https://learngitbranching.js.org/
Cheat Sheet 1
Cheat Sheet 2
https://habrahabr.ru/company/mailru/blog/340558/  Rebase
Pull vs pull -rebase
Merge vs Rebase
when-to-merge-vs-when-to-rebase
Git tips

gitref.org
sixrevisions.com
Git rebase
From stackoverflow.com
Cheat Sheet 3


GitHub
  GitHub documentation
  https://hackernoon.com/12-cool-things-you-can-do-with-github-f3e0424cf2f0
  Git Bash For Windows

- Create account on GitHub
- Install Git Client for Windows
- Set up SSH keys SSH
- Create Git project on PC using Git Bash:

mkdir C:\GITHUB\mlubinsky.github.com
cd C:\GITHUB\mlubinsky.github.com
git init
create and edit the file index.html
git add index.html
git commit -m "first commit"
git remote add origin git@github.com:mlubinsky:mlubinsky.github.com.git
git push -u origin master

To get local copy of git repo:
git clone git://github.com/mlubinsky/mlubinsky.github.com.git
GitHub Troubleshooting 
Make sure your github repository host has the contents   of ~/.ssh/id_rsa.pub
ssh -vT git@github.com  - this command is helpful for git debugging

Example of file ./git/config (pay attention to url = line) 
[core]
	repositoryformatversion = 0
	filemode = false
	bare = false
	logallrefupdates = true
	symlinks = false
	ignorecase = true
	hideDotFiles = dotGitOnly
[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:mlubinsky/mlubinsky.github.com.git
[branch "master"]
	remote = origin
	merge = refs/heads/master