Search for a command to run...
I am currently pursuing a bachelor's degree in Electronic, Communication and Information Engineering at Pashchimanchal Campus(WRC), IOE, Tribhuvan University. I am passionate about Cybersecurity, Software Development and Data Science.
No comments yet. Be the first to comment.
Overview HackThisSite.org is an online platform that provides a legal and safe environment for individuals to improve their cyber security skills through a variety of challenges and Capture the Flag (CTF) events. level 1 Vulnerability Description: H...
Have you ever forget your password? Unfortunately, I have forgotten my password recently and have hacked my way back in. At first, I thought I might have to reinstall the whole thing and start my setup over again, but there was another way to get int...
The LinkVortex is the machine from hack the box lab created by 0xyassine. In this walkthrough, I will demonstrate how I obtained complete ownership of this machine. https://www.hackthebox.com/machines/LinkVortex I have owned link vortex from hack th...
As part of TechParva3.0, the Innovative Computer Engineering Students’ Society(i-CES) of WRC, Pokhara, hosted an exciting BabyPWN CTF(Capture the Flag) competition for beginners. I had an incredible opportunity to design a few challenges for this eve...
TechParva 3.0, organized by i-CES (Innovation Club of Electronics and Software), is a flagship technology event designed to inspire and empower tech enthusiasts, innovators, and learners. This premier gathering serves as a vibrant platform to explore...
A commit in git repository records a snapshot of all the tracked files in your directory.
It’s like gaint copy and paste but even better
to solve
Solution
$ git commit
$ git commit
Branches in Git are incredibly lightweight as well.
They simply point to a specific commit.
To solve
Solution
$ git checkout -b bugFix
Merge combines the work from two different branches together.
This will allow us to branch off, develop new features and then combine them back in.
To solve
Solution
$ git checkout -b bugFix
$ git commit
$ git checkout main
$ git commit
$ git merge bugFix
This is the second way of combining work between branches
Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else.
To solve
Solution
$ git checkout -b bugFix
$ git commit
$ git checkout main
$ git commit
$ git checkout bugFix
$ git rebase main
HEAD is the symbolic name for the currently checked out commit -- it's essentially what commit you're working on top of.
HEAD always points to the most recent commit which is reflected in the working tree.
To solve,
Solution
$ git checkout c4
Hashes are usually a lot longer in the real Git world as well.
Moving upwards one commit at a time with ^
Moving upwards several times with ~<num>
So saying main^ is equivalent to "the first parent of main".
main^^ is the grandparent (second-generation ancestor) of main
To solve
$ git checkout C4^
The tilde operator (optionally) takes in a trailing number that specifies the number of parents you would like to ascend.
To solve,
$ git checkout HEAD~1
$ git branch -f main C6
$ git branch -f bugFix C0
git reset reverses changes by moving a branch reference backwards in time to an older commit.
To reverse changes and share those reversed changes with others, we need to use git revert.
To solve,
$ git branch -f local C1
$ git checkout pushed
$ git revert pushed
The first command in this series is called git cherry-pick. It takes on the following form:
git cherry-pick <Commit1> <Commit2> <...>To solve,
$ git cherry-pick C3 C4 C7
Git cherry-pick is great when you know which commits you want
But what about the situation where you don't know what commits you want? Thankfully git has you covered there as well! We can use interactive rebasing for this
All interactive rebase means Git is using the rebase command with the -i option.
For "real" git, the UI window means opening up a file in a text editor like vim
rebase -i HEAD~
$ git rebase -i HEAD~4
$ git checkout main
$ git cherry-pick C4
OR
$ git rebase -i HEAD~3
$ git checkout main
$ git merge bugFix
We will re-order the commits so the one we want to change is on top with git rebase -i
We will git commit --amend to make a slight modification
Then we will re-order the commits back to how they were previously with git rebase -i
Finally, we will move main to this updated part of the tree to finish the level (via the method of your choosing)
To solve,
$ git rebase -i HEAD~2
$ git commit --amend
$ git rebase -i HEAD~2
$ git checkout main
$ git merge caption
OR
$ git rebase -i HEAD~2
$ git commit --amend
$ git rebase -i HEAD~2
$ git rebase caption main
$ git checkout main
$ git cherry-pick C2
$ git commit --amend
$ git cherry-pick C3
Branches are easily mutated, often temporary, and always changing.
To solve,
$ git checkout HEAD~1
$ git tag v1
$ git tag v0 C1
Because tags serve as such great "anchors" in the codebase, git has a command to describe where you are relative to the closest "anchor" (aka tag). And that command is called git describe!
To solve,
motive is to learn about git describe
git commit but let’s check the git describe command and view the output$ git describe main
$ git describe side
$ git describe bugFix
$ git commit
$ git rebase main bugFix
$ git rebase bugFix side
$ git rebase side another
$ git rebase another main
Rather than specifying the number of generations to go back (what ~ takes), the modifier on ^ specifies which parent reference to follow from a merge commit.
To solve,
$ git branch bugWork main^^2^
$ git rebase C2 three
$ git checkout one
$ git cherry-pick C4 C3 C2
$ git checkout two
$ git cherry-pick C5 C4 C3 C2
git clone in the real world is the command you'll use to create local copies of remote repositories
To solve,
$ git clone
The first thing you may have noticed is that a new branch appeared in our local repository called o/main. This type of branch is called a remote branch
Remote branches have the special property that when you check them out, you are put into a detached HEAD mode.
if you look at a branch named o/main, the branch name is main and the name of the remote is o.
To solve,
$ git commit
$ git checkout o/main
$ git commit
git fetch performs two main steps, and two main steps only. It:
downloads the commits that the remote has but are missing from our local repository, and...
updates where our remote branches point (for instance, o/main)
git fetch essentially brings our local representation of the remote repository into synchronization with what the actual remote repository looks like (right now).
git fetch, however, does not change anything about your local state. It will not update your main branch or change anything about how your file system looks right now.
To solve,
$ git fetch
git pull is equivalent to the two command git fetch and git merge
For e.g: git fetch and git merge o/main is equivalent to git pull
To solve,
git fetch and git merge o/main or,$ git pull
pull down changes that were introduced in the remote.
That means we need to essentially "pretend" that the remote was updated by one of your coworkers/friends / collaborators, sometimes on a specific branch or a certain number of commits. That can be done using the command git fakeTeamwork
To solve,
$ git clone
$ git fakeTeamwork
$ git fakeTeamwork
$ git commit
$ git pull
the way to upload shared work is the opposite of downloading shared work. And what's the opposite of git pull? git push!
git push is responsible for uploading your changes to a specified remote and updating that remote to incorporate your new commits.
To solve,
$ git commit
$ git commit
$ git push
$ git clone
$ git fakeTeamwork
$ git commit
$ git pull --rebase
$ git push
The remote rejected the push of commits directly to the main because of the policy on the main requiring pull requests to instead be used.
You meant to follow the process of creating a branch then pushing that branch and doing a pull request, but you forgot and committed directly to the main. Now you are stuck and cannot push your changes.
To solve,
$ git reset --hard o/main
$ git checkout -b feature C2
$ git push origin feature
$ git fetch
$ git rebase o/main side1
$ git rebase side1 side2
$ git rebase side2 side3
$ git checkout main
$ git merge side3
$ git push
$ git fetch
$ git checkout o/main
$ git merge side1
$ git merge side2
$ git merge side3
$ git checkout main
$ git merge C11
$ git push
In this level, we learn about how to make the main unchanged in remote where we will be using git checkout -b foo o/main by which the main remains unchanged and work is done in the foo branch.
To solve,
$ git checkout -b side o/main
$ git commit
$ git fetch
$ git rebase o/main side
$ git push
git push <remote> <place> E.g. git push origin main
By specifying main as the "place" argument, we told git where the commits will come from and where the commits will go. It's essentially the "place" or "location" to synchronize between the two repositories.
To solve,
$ git push origin main
$ git push origin foo
If we want the source and destination to be different to do so, we simply join two places separated by the semi-colon git push origin <source>:<destination>. If the branch is absent it creates a new one
To solve,
$ git push origin foo^:foo
$ git push origin foo^2:main
$ git push origin foo:main
$ git push origin main^:foo
So similar to push argument can be fetch as well? fetch the argument is similar to the push argument.
It is the same type of concept but applied in the opposite direction
The <place> parameter will go to the branch, grab all the commits and then plop them down to the o/<place> branch locally.
This <souce>:<destination> is also true.
To solve,
$ git fetch origin C3:foo
$ git fetch origin C6:main
$ git checkout foo
$ git merge main
Git abuses the <source> parameter in two weird ways. These two abuses come from the fact that you can technically specify "nothing" as valid source for both git push and git fetch.
To solve,
$ git push origin :foo
$ git fetch origin :bar
$ git fetch origin C3:foo
$ git merge foo
$ git fetch origin C2:side
$ git merge side
OR,
$ git pull origin C3:foo
$ git pull origin C2:side