DEV Community: kulsoomzahra

Undoing changes - Git Reset & Git Revert

kulsoomzahra — Mon, 26 Apr 2021 11:41:16 +0000

When you're working on a large opensource project, it is quite obvious for developers to create branches, add files and stage them for commits when they are ready etc.

However, in some cases, you might realize that the changes that you made are not that good or the feature you just added isn't up to the mark.
You modified some files, added and deleted a lot of lines from the code base, but NOW you want to go back and revert the changes.

Don't worry much because, Git has got your back!

Git Revert

The preferred method of undoing shared history is git revert.
A revert is safer than a reset because it will not remove any commits from a shared history. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit.

You should never reset a commit which is pushed to a public repo, as it can cause serious problems for other developers of the project.

Instead use git revert

git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git revert <hash of initial commit>

You can check by running

git status 
git log

Git Reset

It is a versatile tool for developers to use.
git reset is used for undoing changes on a private branch/locally. It has three modes depending upon where you want to reflect changes in Git's internal state management mechanism's. Git has three such state managements: The Commit Tree (HEAD), The Staging Index, and The Working Directory.

--soft

This is the safest reset mode.
--soft resets the head to , just like all modes do.
It does not touch the index file or the working tree at all and leaves all your changed files as "Changes to be committed", as git status would put it.
The Staging Index and the Working Directory are left untouched so changes are not lost in either places. Only Commit Tree is altered.

git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git reset --soft <hash of initial commit>

You can check by running

git status 
git log

--mixed

This is the default operating mode.
--mixed has the following impacts:

The ref pointers are updated.
The Staging Index is reset to the state of the specified commit. Any changes that have been undone from the Staging Index are moved to the Working Directory(you can recover by git add file-1)

git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git reset <hash of initial commit>

You can check by running

git status 
git log

--hard

This is the most DANGEROUS option. Use only when you're sure that you want to delete your work.
--hard has the following impacts

The Commit History ref pointers are updated to the specified commit.
The Staging Index and Working Directory are reset to match that of the specified commit. Any changes made are lost and matches to the state of the specified commit

git log
#This will show the previous commits and their hashes. Copy 6 char hash of initial commit.

git reset --hard <hash of initial commit>

You can check by running

git status 
git log

Here's summing up the three modes, where they render changes.

Branches in Git

kulsoomzahra — Tue, 13 Apr 2021 14:58:43 +0000

Branches are no doubt, one the BEST features of Git. The Master Branch being the default of the repository is automatically created whenever you fork a new repo.
So usually when making commits, we've being committing only to the master branch.
This master branch is the stable version of your code and something you will release that's the reason why we don't really want to try out new code or features on this stable version (master branch) just in case it messes the whole code of your repo.
So we create an isolated space to experiment new code and features. If all goes good and they seem to work well, you can merge this isolated space (i.e branch) into the master branch thus eliminating the risk of messing up with the stable version of your repo.

This is why branches are a massive feature. Saving you right?

Working on a branch

Here's how you can work on branches:

1) Make a new branch
git checkout -b <branch name>

If you want to switch to an existing branch use
git checkout <branch name>

2) Open the editor of your choice and make changes

3) Add the files
git add .

4) Commit the changes and add a commit message
git commit -m "commit message"

5) Finally, push these changes to the origin
git push origin

If error occurs, it's probably because you've not set your remote properly . Try using
git remote set-url origin SSH of your repo
OR
git push --set-upstream origin <branch name>

Congrats! You've merged your branch into the master!

Renaming a branch

Rename a branch while currently not on the branch:
git branch -m oldName newName

Rename the current branch:
git branch -m newName

Deleting a branch

git branch -d <branch name>

Also delete branch from origin using

git push origin --delete <branch name>

Keeping your forked repo in sync with the remote repo

kulsoomzahra — Sat, 03 Apr 2021 20:05:50 +0000

While using Git/Github, there's a need to be updated with the latest commits.

What is a fork and why is it needed?

Forking a repository means creating your own version of the repo where you can make whatever changes you want. It's like a personal copy. It won't affect the original product. With forks, you can change/modify whatever you want and experiment around code freely and fearlessly! Cool right? Forking has nothing to do with Git, it is a feature of Github. Thanks to this awesome feature otherwise we wouldn't be able to play around with code at such individual levels.

Cloning

In cloning, the copy of the repository is made at your local machine unlike fork where the copy is restricted to a repository on Github only. This is the main difference between fork and clone.

Updating your forked repository

You started contributing to a project so you forked it, began working on an issue. In the mean time, other developers of the project pushed changes to the original repo from where you had forked. Now, you're done working and want to open a PR. When you go on Github, you see

This branch is 5701 commits behind original:master

Now, you need to update your forked repo
(Assuming you've cloned already)

Switching to the master branch
git checkout master
Checking remote versions
git remote -v
Adding/Setting remote
git remote add upstream link
link is of the original repo from where you forked!
upstream is the master branch of the original repo
OR
git remote set-url origin SSH of original repo
Fetching all the changes from the upstream
git fetch upstream
Merging
git merge upstream/master
Finallyy pushing your changes
git push

You're all set to open that PR!

Git - Squash

kulsoomzahra — Fri, 05 Mar 2021 18:43:52 +0000

Using git/github for your personal projects is pretty easy but when you're a part of an organisation or a large scale project with thousands of users you might get a tough time. One wrong move can cause mess or make the commit tree dirty or anything you don't want which in turn may fuel your Impostor Syndrome!
So hey, HANG ON! You can do it.

A Clean Commit Tree

Squashing your commits can help so here we go

Switch to the branch where the commit tree is
git checkout <branch name>
Make sure everything on your local is pushed to the branch
git add .
git commit -m "Commit message"
git push origin <branch name>
Squash n previous commits
(n is the no.of commits you want to squash)
git rebase -i HEAD~3

Now, change pick to s or squash in the last 2 commits
Press
a) Ctrl + O to write out
b) Enter to save changes
c) Ctrl + X to exit

Now you can edit the final commit message .
Repeat a,b,c

Don't forget to PUSH your changes on to the branch
git push origin <branch name>

If this doesn't work force push your changes
git push origin <branch name> -f

You're Done! Now you have a clean commit tree.

Tor - The Onion Router

kulsoomzahra — Mon, 22 Feb 2021 07:16:52 +0000

What is Tor?

Tor is a network of virtual tunnels that allows you to improve your privacy and security on the Internet.

Privarcy is a human right. We at Tor advance human rights and defend your privacy online through free software and open networks

Tor works by sending your traffic through three random servers (also known as relays) in the Tor network. The last relay in the circuit (the exit relay) then sends the traffic out onto the public Internet.

The image above illustrates a user browsing to different websites over Tor. The green middle computers represent relays in the Tor network, while the three keys represent the layers of encryption between the user and each relay.

It protects you by bouncing your communications around a distributed network of relays run by volunteers all around the world, it prevents somebody watching your Internet connection from learning what sites you visit and it prevents the sites you visit from learning your physical location.

This collection of volunteer relays is called the Tor network.

The way most people use Tor is with the Tor Browser, which is based on Firefox ESR and comes bundled with privacy enhancing & anti-fingerprinting features.

So is Tor a VPN?

Nope. Tor is NOT a VPN and furthermore it is not recommended to use Tor and VPN together.
These are fundamentally very different. In the case of VPN, you're just transferring your trust from your internet service provider (ISP) to the VPN provider.
The VPN provider can log any data while you use their network and anyone snooping on the VPN connection can also easily gain knowledge of your activities.
While using Tor, your connection is made to the website by bouncing the connection through three different relays so the website you're connecting to can only see the IP address of the 'exit' relay

Some more about Tor

The Tor Browser furthermore comes bundled with features like: a different circuit of every different domain, i.e. a new circuit for every website you're connecting to so as to mitigate cross-site tracking; 'Security Settings' with which you can also disable most of the harmful JavaScript.

The noteworthy part is that the idea is not to hide that you're using the Tor network but to anonymize your activities on the Tor network.

Tor is an essential tool for privacy and anonymity on the internet. It is a tool used by millions of people all around the globe - from journalists to human rights activists to ordinary people

Challenges

Direct access to the Tor network may sometimes be blocked by your Internet Service Provider or by a government. Tor Browser includes some circumvention tools for getting around these blocks. These tools are called pluggable transports.

I'll talk more about this in incoming blogs so stay tuned!

Getting started with GPG(GnuPG)

kulsoomzahra — Mon, 15 Feb 2021 16:53:38 +0000

GNU Privacy Guard (GPG or GnuPG) can be used to encrypt files for confidentiality and also sign files for authenticity.

What is a GPG or GnuPG?

GnuPG, is a tool that is made in accordance with the OpenPGP Internet standard . It is used primarily for secure communication and data storage. It is a tool that adds encryption and signs data.

Package repositories are downloaded round the world. Digital signatures are used to ensure that you get an exact copy from the original packager and not a malicious version from a compromised site.
OpenPGP programs such as GPG are used to sign and verify those packages ensuring the authenticity of the source.

There is local disk encryption which protects data at rest. However, if you wish that only the intended recipient can open a file you send by email or drop into a shared folder, you need to encrypt that individual file.
OpenPGP products like GPG can encrypt a file with a shared symmetric key or with asymmetric key pairs.

Using GnuPG

GnuPG comes installed with most Linux distributions.
To check your current version

$ yum list gnupg*

The first time you run any gpg command, a configuration directory and keyring will be created in your home directory. For example, if you run

gpg --list-keys

to display keys you may see the following message:

$ gpg --list-keys
gpg: directory '/home/bestuser/.gnupg' created
gpg: keybox '/home/bestuser/.gnupg/pubring.kbx' created
gpg: /home/bestuser/.gnupg/trustdb.gpg: trustdb created

Encrypting a file with a shared secret

You're all good to encrypt a file if the GnuPG is installed. For symmetric encryption, use the -c or --symmetric option and pass the file you want to encrypt. Here I'm encrypting example.txt.

$ gpg -c example.txt

The encrypted file will have a gpg extension i.e example.txt.gpg
This encrypted file can now be sent to a remote location.

Decryption

To decrypt the file, use the -d or --decrypt option.

$ gpg -d sample1.txt.gpg

Determining how to share the passphrase to decrypt it is a separate issue.