Git

From neil.tappsville.com
Revision as of 22:11, 16 February 2020 by Gonzo (talk | contribs)
Jump to navigationJump to search

Everyday

Stage and Add are the same.

git add <filename>  
 git status
 On branch mediatorLogging
 Your branch is up to date with 'origin/mediatorLogging'.

nothing to commit, working tree clean
gitk GUI version - for the current branch

gitk --all GUI version showing everything we know about (locally)

git diff --staged   <-- see what changes we have made locally (pre-commit)
git commit 
git diff HEAD <-- see what changes we have committed (but not pushed)
git push

Note: Tags are not explicitly pushed by default Local change history

git reflog

Repository change history

git log

A change to an existing commit (that has not been pushed)

git commit --amend

Local Changes vs Repo

git log origin/master..HEAD

You can also view the diff using the same syntax

git diff origin/master..HEAD

Diff between the current branch and develop (origin of this branch hopefully) aka diff source and then current branch

git diff develop..feature/[branch_name]

If working in master (no branches used)

git diff origin/master...HEAD

Wipe all local changes and get the latest from the repo

git reset --hard        or       git checkout -- <file name>
git rebase origin/master

Or to store changes and re-apply them after pulling

git stash
git pull
git stash pop

Note opposite of push is fetch, Pull does fetch + local merge

git push origin master
git merge origin/master

Branch

Create branch y from x

git branch y x

Merge

Ensure the following are selected:

  • Delete source branch when merge request is accepted
  • Squash commits when merge request is accepted


https://stackoverflow.com/questions/4470523/create-a-branch-in-git-from-another-branch

$ git checkout -b myFeature dev

Creates MyFeature branch off dev. Do your work and then

$ git commit -am "Your message"

Now merge your changes to dev without a fast-forward

$ git checkout dev
$ git merge --no-ff myFeature

Now push changes to the server

$ git push origin dev
$ git push origin myFeature

Merge another branch upto a particular commit

git merge <id of commit>

Cherry pick a single commit and merge it

git cherry-pick <id of commit>

Merging Branches

https://dev.to/maxwell_dev/the-git-rebase-introduction-i-wish-id-had

Submitted a merge request - and it comes up with - this branch is x commits behind target_branch.

Gitlab helps you by showing how much the version of the branch you updated is behind the remote branch.

Being behind will not set any hindrance to the act of merging, but it is a common practice to rebase your commits on top of the branch your merging into. This will make your merge request updated by putting your commits chronologically after the ones that already are in that branch. That approach makes the work of the person responsible for the merge easier because the commiter himself has already resolved any conflicts that would have happened.

To do a rebase following the scenario you proposed would be like this:

  1. Add a remote named `upstream` pointing to the original repository

git remote add upstream https://gitlab.example.com/example/your_project.git

  1. Fetch the latest commmits from `upstream`

git fetch upstream

  1. Checkout our branch-A

git checkout branch-A

  1. Rebase our branch on top of the `upstream/develop` branch

git rebase upstream/develop

  1. If needed fix any conflicts that may have appeared and then `git rebase --continue`
  1. Push the changes to the branch of your merge request

git push --force origin branch-A

Rebase and Squash

git rebase --interactive origin/master


# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Forking to pull workflow

https://gist.github.com/Chaser324/ce0505fbed06b947d962

Updating a forked repo

https://help.github.com/en/articles/syncing-a-fork

git remote add upstream https://github.com/wanduow/openli.git

$ git fetch upstream
remote: Enumerating objects: 62, done.
remote: Counting objects: 100% (62/62), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 85 (delta 56), reused 60 (delta 54), pack-reused 23
Unpacking objects: 100% (85/85), done.
From https://github.com/wanduow/openli
 * [new branch]      develop    -> upstream/develop
 * [new branch]      master     -> upstream/master

git checkout master     <---- go into master -- we will merge something into here.
git diff HEAD..upstream/master <--- see what we are missing
git merge upstream/master   <---- merge this into the branch we have checked out

Disaster has struck

Rollback the last change (merge, commit) locally

git reset --hard HEAD~1

Find what commit made something break

git bisect

Install meld - then its used if there is a non-ff merge where humans are required.

git mergetool