Git: Difference between revisions
(32 intermediate revisions by the same user not shown) | |||
Line 160: | Line 160: | ||
git branch -m master main | git branch -m master main | ||
git config --add --local init.defaultBranch main | git config --add --local init.defaultBranch main | ||
</syntaxhighlight> | |||
==Switching branch== | |||
They recommend git switch but I always use git checkout | |||
<syntaxhighlight lang="bash"> | |||
git switch branch2 | |||
# Same thing | |||
git checkout branch2 | |||
git pull branch2 | |||
</syntaxhighlight> | </syntaxhighlight> | ||
Line 179: | Line 187: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Looking at the output we can see parent and tree. The parent will be the previous commit and the tree is a reference to the branch | Looking at the output we can see parent and tree. The parent will be the previous commit and the tree is a reference to the branch | ||
==Merging== | |||
Given a main branch with commits A, B, C and your branch with two commits D and E, we want to merge our changes onto the main branch. Most the time we would do a Pull Request but here is how to do it without doing that<br> | |||
Here we have two branches with two commits on the second branch<br> | |||
[[File:Merge branch.png|300px]]<br> | |||
We can merge E and C to conceptually F with the merge command and the current branch with D and E commits is merged to the parent branch. When doing this you are prompted to add a message<br> | |||
<syntaxhighlight lang="bash"> | |||
git merge <branch> | |||
</syntaxhighlight> | |||
We can see a rather dodgy graph with this | |||
<syntaxhighlight lang="bash"> | |||
git log --oneline --decorate --graph --parents | |||
</syntaxhighlight> | |||
In the picture below we can see commit e447ac9 and 7a088e8 are merged together<br> | |||
[[File:Git Merge graph.png| 400px]]<br> | |||
==Fast Forward Merge== | |||
This is here in case I forget (as if). It we make a branch called new_feature and no changes have occurred on the main branch then you merge you new_feature branch as above, then this is a '''fast forward merge'''. So it is a term that refers to the mechanics of git. | |||
==git rebase== | |||
Never done this. I have pulled my stuff from the main branch to keep up. So here is a picture of rebasing to help anne oldman (see what I did there) out. Before out feature branch was branched a A<br> | |||
[[File:Rebase1.png | 200px]]<br> | |||
We decide we want to move and '''rebase''' at C.<br> | |||
[[File:Rebase 2.png| 200px]]<br> | |||
===09 Dec 2024=== | |||
Well finally started using this as the code reviews are so so slow. In this scenario we are wanting to base featureB on featureA code | |||
<syntaxhighlight lang="bash"> | |||
# Make new branch | |||
git branch featureB | |||
# Switch to branch | |||
git switch featureB | |||
# Pull the repos in case | |||
git pull | |||
# Rebase from featureA Code | |||
git rebase --onto origin/featureA featureB | |||
</syntaxhighlight> | |||
You should now be able to see featureA code in your source and also be on the featureB branch. | |||
==git reset== | |||
With git rest there are two choices, hard and soft, | |||
*soft will untrack your changes but will not change your files | |||
*hard will reset all of your changes (the files will be reverted and nothing will be tracked). '''This does not include your untracked files, these will remain''' | |||
==Git Fetch== | |||
Possibly we think of the remote repository as github. Remote repositories can be local if we felt like it. It is just not our repository. | |||
<syntaxhighlight lang="bash"> | |||
git remote add origin ../localrepo | |||
git fetch | |||
</syntaxhighlight> | |||
We use origin the default name git fetch will use. You could, but probably shouldn't set this to something else with | |||
<syntaxhighlight lang="bash"> | |||
git branch --set-upstream-to=github/master | |||
</syntaxhighlight> | |||
==git reflog== | |||
This is different to git log as it gits all of the history. This is useful for changes you thought lost | |||
<syntaxhighlight lang="bash"> | |||
git reflog | |||
# git --no-pager reflog | |||
# for no paging and works on other commands too | |||
</syntaxhighlight> | |||
The commits are shown and you are free to example checkout, reset etc<br> | |||
[[File:Reflog example.png | 400px]]<br> | |||
It we could use git merge to get our code back | |||
<syntaxhighlight lang="bash"> | |||
git merge HEAD@{15} | |||
</syntaxhighlight> | |||
==HEAD== | |||
'''HEAD''' is the current branches latest commit and will always appear on top when resolving merges. '''However''' when you do a git rebase you are taking the main branch and replaying your commits on top. This means that HEAD is now the from the main branch and not yours. | |||
==Squashing== | |||
Never heard this before but the idea is that if you have n number of commits, maybe it would be better to squash them into one commit. That way should something go wrong, you can rollback changes easier. This relies on the git rebase command to work. If you remember to rebase you and go n number of commit back | |||
<syntaxhighlight lang="bash"> | |||
# HEAD 3 makes it go back 3 commits | |||
# i makes it interactive mode | |||
git rebase i HEAD 3 | |||
</syntaxhighlight> | |||
Now we are presented with the commit<br> | |||
[[File:Git squash 1.png | 300px]]<br> | |||
With the three changes noted with the '''pick''' we can replace the last two with an s to combine the commit<br> | |||
[[File:Git squash 2.png | 300px]]<br> | |||
==git stash== | |||
This is used to | |||
*stash current work, | |||
*do some other stuff, | |||
*bring my new stuff back | |||
===General Use=== | |||
This is pretty easier to do, on your current work | |||
<syntaxhighlight lang="bash"> | |||
git stash -m "you can have a message too" | |||
# List your stash with this | |||
git stash list | |||
</syntaxhighlight> | |||
You can now do your other stuff. Once finished you can get your work back | |||
<syntaxhighlight lang="bash"> | |||
git pop | |||
</syntaxhighlight> | |||
Other/Extended commands are | |||
<syntaxhighlight lang="bash"> | |||
# apply 3 stash | |||
git stash apply stash@{3} | |||
# Delete a stash | |||
git stash drop stash@{3} | |||
</syntaxhighlight> | |||
===Move Stash to Different PC=== | |||
You can move a stash to another PC by making a patch file with | |||
<syntaxhighlight lang="bash"> | |||
git stash show -p stash@{0} > stash.patch | |||
</syntaxhighlight> | |||
And applying it with | |||
<syntaxhighlight lang="bash"> | |||
git apply /path/to/stash.patch | |||
</syntaxhighlight> | |||
==git cherry-pick== | |||
Ezzy Pezzy. Not done this ever but it is easy just use the command with the commit ids you want. | |||
<syntaxhighlight lang="bash"> | |||
git cherry-pick <commit id> | |||
</syntaxhighlight> | |||
==git bisect== | |||
This is a tool to try and track down where a commit caused a problem between to point. You need to know a good point and a bad point. <br> | |||
[[File:Git bisect.png| 400px]]<br> | |||
There are seven steps | |||
<syntaxhighlight lang="txt"> | |||
1. Start the bisect with git bisect start | |||
2. Select a "good" commit with git bisect good <commitish> (a | |||
commit where you're sure the bug wasn't present) | |||
3. Select a bad commit via git bisect bad! <commitish> (a commit | |||
where you're sure the bug was present) | |||
4. Git will checkout a commit between the good and bad commits for you to | |||
test to see if the bug is present | |||
5.Execute git bisect good or git bisect bad tosay the current | |||
commit is good or bad | |||
6. Loop back to step 4 (until git bisect completes) | |||
7. Exit the bisect mode with git bisect reset | |||
</syntaxhighlight> | |||
==git revert== | |||
This allows you to take on commit and remove it whilst keeping all of the history. | |||
<syntaxhighlight lang="bash"> | |||
git revert <commit id> | |||
</syntaxhighlight> | |||
==Quick Tips== | |||
Show Contents of previous commit | |||
<syntaxhighlight lang="bash"> | |||
git log --oneline -1 -p | |||
</syntaxhighlight> | |||
Change previous commit message | |||
<syntaxhighlight lang="bash"> | |||
git commit --amend | |||
</syntaxhighlight> | |||
An alternative to this to change the message is to reset soft the local repository and recommit | |||
<syntaxhighlight lang="bash"> | |||
# ~1 is one commit, ~2 is two commits | |||
git reset --soft HEAD~1 | |||
git commit -m "My better commit message" | |||
</syntaxhighlight> | |||
See previous commit | |||
<syntaxhighlight lang="bash"> | |||
git diff HEAD~1 | |||
</syntaxhighlight> |
Latest revision as of 21:10, 8 December 2024
Helpful commands
Test
int main(int a, char* args[]) {
// Test
return 0;
}
Getting stuff from other branch
git remote add live <other branch>
git pull live master
Commit
git commit -m "This is a great check in"
git push
Checking out a branch
git clone <address>
git fetch origin
git checkout <branch name>
Setting Credentials
git config --global credential.helper store
Show non pushed changes
git diff origin/master..HEAD
Put a cloned project into gitlab
git init
git remote set-url origin http://gitlab.com/bibble235/project.git
git commit -m "copy of project"
git push
Compare Branches
$ git diff branch1..branch2
Show Which Branch
git branch
Merging
This is how to merge from main to mybranch
// clone the source
git clone blahhhh
// checkout the branch
git checkout mybranch
// merge changes into main
git merge main
// Go into vs code
// Take the version you care about
git commit -m 'Merge code to main'
git push
View Deleted Files
# List all deleted files
git log --diff-filter D --pretty="format:" --name-only
# Find last commit
git log -n 1 --pretty=format:%H -- src/services/__test__/myFile.test.tsx
Setting up new Repo from CLI
cd /path/to/repo
# Make sure you need this line, maybe you did it wrong the first time
rm -rf .git
git init
git branch -m main
git remote add origin https://gitlab.com/<user>/<repo_name>
git add .
git commit -m "first commit"
git push -u origin main
Making a Branch for Change
git branch 123xx
git checkout 123xx
git add .
git commit -m "Blah"
git push
# Make a pull request
# If request rejected you can reset what you have
git reset ^HEAD
# Recommit your stuff
git add .
git commit -m "Blah"
git push
Fixing Merge Conflict on Pull Request when main has changed
When someone makes a change on main whilst you are working on a branch, you can run this on your branch and remove the offending file
git pull --no-rebase origin main
Merge Remote Feature Branch to Local Branch
This is when you are waiting for PR 30441 to be processed and you depend on their code. To put remote PR code onto your local branch
git merge origin/30441
July 2023
Update local Main Branch (main) to remote (main) branch
// Make sure you have not modified this prior to starting (unless you wanted to)
// In the local copy directory
git pull origin main
// Check all good git diff should be empty (unless you have made changes)
git diff
Update local non-Main Branch (DEV) from remote (main) branch
This is the way I currently do it
git fetch origin main
git merge origin/main
Brush Up
This is a quick refresh where I might redo this page
Config
This is where it lives and how to look from cli
# View
cat ~/.gitconfig
# List
git config --list
# Change default branch
git config --add --global init.defaultBranch blakes7
We can set values locally for just the project we are in with
# List config
git const --list --local
# Set Values in Local
git config --add --local mysection.mykey myKeyValue1
git config --add --local mysection.mykey myKeyValue2
You can rename a local branch which might have master as the default branch and set the default with
git branch -m master main
git config --add --local init.defaultBranch main
Switching branch
They recommend git switch but I always use git checkout
git switch branch2
# Same thing
git checkout branch2
git pull branch2
Cat File
This allows you to see the internals of git
# You only need maybe first four characters
git cat-file -p <hash>
# Example
git cat-file -p 223ab5b7
tree 927baa9ae05483c2446c482955cec508ed200120
parent ae62e2083838bfbd6f6b929db09430d08e62e9ef
author Bill Wiseman <bill.wiseman@ihc.org.nz> 1729131283 +1300
committer Bill Wiseman <bill.wiseman@ihc.org.nz> 1729131283 +1300
#30441 Fix|Added updating of error when no ServiceRate Found
Looking at the output we can see parent and tree. The parent will be the previous commit and the tree is a reference to the branch
Merging
Given a main branch with commits A, B, C and your branch with two commits D and E, we want to merge our changes onto the main branch. Most the time we would do a Pull Request but here is how to do it without doing that
Here we have two branches with two commits on the second branch
We can merge E and C to conceptually F with the merge command and the current branch with D and E commits is merged to the parent branch. When doing this you are prompted to add a message
git merge <branch>
We can see a rather dodgy graph with this
git log --oneline --decorate --graph --parents
In the picture below we can see commit e447ac9 and 7a088e8 are merged together
Fast Forward Merge
This is here in case I forget (as if). It we make a branch called new_feature and no changes have occurred on the main branch then you merge you new_feature branch as above, then this is a fast forward merge. So it is a term that refers to the mechanics of git.
git rebase
Never done this. I have pulled my stuff from the main branch to keep up. So here is a picture of rebasing to help anne oldman (see what I did there) out. Before out feature branch was branched a A
We decide we want to move and rebase at C.
09 Dec 2024
Well finally started using this as the code reviews are so so slow. In this scenario we are wanting to base featureB on featureA code
# Make new branch
git branch featureB
# Switch to branch
git switch featureB
# Pull the repos in case
git pull
# Rebase from featureA Code
git rebase --onto origin/featureA featureB
You should now be able to see featureA code in your source and also be on the featureB branch.
git reset
With git rest there are two choices, hard and soft,
- soft will untrack your changes but will not change your files
- hard will reset all of your changes (the files will be reverted and nothing will be tracked). This does not include your untracked files, these will remain
Git Fetch
Possibly we think of the remote repository as github. Remote repositories can be local if we felt like it. It is just not our repository.
git remote add origin ../localrepo
git fetch
We use origin the default name git fetch will use. You could, but probably shouldn't set this to something else with
git branch --set-upstream-to=github/master
git reflog
This is different to git log as it gits all of the history. This is useful for changes you thought lost
git reflog
# git --no-pager reflog
# for no paging and works on other commands too
The commits are shown and you are free to example checkout, reset etc
It we could use git merge to get our code back
git merge HEAD@{15}
HEAD
HEAD is the current branches latest commit and will always appear on top when resolving merges. However when you do a git rebase you are taking the main branch and replaying your commits on top. This means that HEAD is now the from the main branch and not yours.
Squashing
Never heard this before but the idea is that if you have n number of commits, maybe it would be better to squash them into one commit. That way should something go wrong, you can rollback changes easier. This relies on the git rebase command to work. If you remember to rebase you and go n number of commit back
# HEAD 3 makes it go back 3 commits
# i makes it interactive mode
git rebase i HEAD 3
Now we are presented with the commit
With the three changes noted with the pick we can replace the last two with an s to combine the commit
git stash
This is used to
- stash current work,
- do some other stuff,
- bring my new stuff back
General Use
This is pretty easier to do, on your current work
git stash -m "you can have a message too"
# List your stash with this
git stash list
You can now do your other stuff. Once finished you can get your work back
git pop
Other/Extended commands are
# apply 3 stash
git stash apply stash@{3}
# Delete a stash
git stash drop stash@{3}
Move Stash to Different PC
You can move a stash to another PC by making a patch file with
git stash show -p stash@{0} > stash.patch
And applying it with
git apply /path/to/stash.patch
git cherry-pick
Ezzy Pezzy. Not done this ever but it is easy just use the command with the commit ids you want.
git cherry-pick <commit id>
git bisect
This is a tool to try and track down where a commit caused a problem between to point. You need to know a good point and a bad point.
There are seven steps
1. Start the bisect with git bisect start
2. Select a "good" commit with git bisect good <commitish> (a
commit where you're sure the bug wasn't present)
3. Select a bad commit via git bisect bad! <commitish> (a commit
where you're sure the bug was present)
4. Git will checkout a commit between the good and bad commits for you to
test to see if the bug is present
5.Execute git bisect good or git bisect bad tosay the current
commit is good or bad
6. Loop back to step 4 (until git bisect completes)
7. Exit the bisect mode with git bisect reset
git revert
This allows you to take on commit and remove it whilst keeping all of the history.
git revert <commit id>
Quick Tips
Show Contents of previous commit
git log --oneline -1 -p
Change previous commit message
git commit --amend
An alternative to this to change the message is to reset soft the local repository and recommit
# ~1 is one commit, ~2 is two commits
git reset --soft HEAD~1
git commit -m "My better commit message"
See previous commit
git diff HEAD~1