Difference between revisions of "Git"

From neil.tappsville.com
Jump to navigationJump to search
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
=Everyday=
 
=Everyday=
 +
 +
Markdown https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
 +
 
Stage and Add are the same.
 
Stage and Add are the same.
 
  git add <filename>   
 
  git add <filename>   
Line 54: Line 57:
  
 
===Branch===
 
===Branch===
 +
 +
Existing Branch
 +
$ git checkout --track origin/blah
 +
 +
New Branch
 +
 +
$ git checkout -b feature/myFeature origin/dev
 +
Creates MyFeature branch off dev. Do your work and then
 +
 
Create branch y from x
 
Create branch y from x
 
  git branch y x
 
  git branch y x
 +
Remember to checkout the new branch
 +
 +
Remember to push the new branch back to origin
 +
git push origin feature/y
 +
 +
Set the upstream repo
 +
git push --set-upstream <remote> <branch>
  
 
===Merge===
 
===Merge===
Line 139: Line 158:
 
  git rebase --interactive origin/develop
 
  git rebase --interactive origin/develop
 
Change the commit to e for edit
 
Change the commit to e for edit
  git reset HEAD~
+
  git reset HEAD^    some say git reset HEAD~    
 
  git diff
 
  git diff
 
commit the single change as many changes
 
commit the single change as many changes
Line 147: Line 166:
 
Deal with any Merge conflicts due to the order of things being changed potentially
 
Deal with any Merge conflicts due to the order of things being changed potentially
 
  git push --force origin feature/feature_name
 
  git push --force origin feature/feature_name
 +
 +
=Standard Workflow=
 +
* Branch from develop
 +
* Work in Branch
 +
* Rebase branch against remote/develop
 +
* Merge Branch into Develop - Squash Commits, Delete Branch
 +
* Merge Develop into Production (Production will be x commits ahead as it has all the dev->prod merges that develop does not have)
 +
  
 
=Less Common=
 
=Less Common=
Line 158: Line 185:
  
 
===Updating a forked repo===
 
===Updating a forked repo===
 +
 +
 
https://help.github.com/en/articles/syncing-a-fork
 
https://help.github.com/en/articles/syncing-a-fork
 
<pre>
 
<pre>
Line 176: Line 205:
 
git merge upstream/master  <---- merge this into the branch we have checked out
 
git merge upstream/master  <---- merge this into the branch we have checked out
 
</pre>
 
</pre>
 +
 +
 +
====Make the forked repo match the origin====
 +
Blow away everything local + what is in our 'remote' repo
 +
git remote -v
 +
git fetch upstream
 +
git fetch upstream
 +
find the commit we want to sync to
 +
git reset --hard cb0034d6a
 +
git push --force origin
 +
 +
====Update a Forked Repo using the Web GUI only!====
 +
N.B this will cause there to be an additional pull in the local repo - thus will be one commit ahead of the original
 +
https://github.com/KirstieJane/STEMMRoleModels/wiki/Syncing-your-fork-to-the-original-repository-via-the-browser
 +
 +
* Open Repo
 +
* Select compare
 +
* Change Base Fork to your repo (aka the copy)
 +
* Change the head Fork to the upstream repo (aka the original)
 +
**  There should be a list of commits
 +
* Create a Pull Request (this goes to your repo for you to approve)
 +
* Merge and have a beer
  
 
== Disaster has struck ==
 
== Disaster has struck ==
 
Rollback the last change (merge, commit) locally
 
Rollback the last change (merge, commit) locally
 
  git reset --hard HEAD~1
 
  git reset --hard HEAD~1
 +
 +
If the branch has been rebased (by someone else) and pushed to origin - blow away our version of the world
 +
git reset --hard origin/branch
  
 
Find what commit made something break
 
Find what commit made something break
Line 186: Line 240:
 
Install meld - then its used if there is a non-ff merge where humans are required.
 
Install meld - then its used if there is a non-ff merge where humans are required.
 
  git mergetool
 
  git mergetool
 +
 +
Reset local repo to match upstream/origin
 +
git reset --hard origin/feature/branch

Revision as of 03:12, 28 May 2021

Everyday

Markdown https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

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

Existing Branch

$ git checkout --track origin/blah

New Branch

$ git checkout -b feature/myFeature origin/dev

Creates MyFeature branch off dev. Do your work and then

Create branch y from x

git branch y x

Remember to checkout the new branch

Remember to push the new branch back to origin

git push origin feature/y

Set the upstream repo

git push --set-upstream <remote> <branch>

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/develop   <--- where to rebase to - where are we going to re-start this branch from


# 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

then need to push this to the remote

git push --force origin feature/branchname


Split a commit

git rebase --interactive origin/develop

Change the commit to e for edit

git reset HEAD^    some say git reset HEAD~     
git diff

commit the single change as many changes

 git add xyz
 git commit 
git rebase --continue

Deal with any Merge conflicts due to the order of things being changed potentially

git push --force origin feature/feature_name

Standard Workflow

  • Branch from develop
  • Work in Branch
  • Rebase branch against remote/develop
  • Merge Branch into Develop - Squash Commits, Delete Branch
  • Merge Develop into Production (Production will be x commits ahead as it has all the dev->prod merges that develop does not have)


Less Common

Revert a commit

This adds a new commit which undoes something from the past, history is not-rewritten!

git revert [commit_id]

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


Make the forked repo match the origin

Blow away everything local + what is in our 'remote' repo

git remote -v
git fetch upstream
git fetch upstream

find the commit we want to sync to

git reset --hard cb0034d6a
git push --force origin

Update a Forked Repo using the Web GUI only!

N.B this will cause there to be an additional pull in the local repo - thus will be one commit ahead of the original https://github.com/KirstieJane/STEMMRoleModels/wiki/Syncing-your-fork-to-the-original-repository-via-the-browser

  • Open Repo
  • Select compare
  • Change Base Fork to your repo (aka the copy)
  • Change the head Fork to the upstream repo (aka the original)
    • There should be a list of commits
  • Create a Pull Request (this goes to your repo for you to approve)
  • Merge and have a beer

Disaster has struck

Rollback the last change (merge, commit) locally

git reset --hard HEAD~1

If the branch has been rebased (by someone else) and pushed to origin - blow away our version of the world git reset --hard origin/branch

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

Reset local repo to match upstream/origin git reset --hard origin/feature/branch