DevOps(3): Git/Github [ Advance ]
This blog consists of different terms used in Git/GitHub/version-control and some important differences.
The credit for this blog => goes to those who uploaded amazing graphical images explaining the workflow of git.
Git vs Github =>
Git is a CLI-based tool that is used for version control and source code management while Github is a cloud-based platform that is based on git and used for managing Git repositories.
Git commit => create a snapshot of the staged changes along a timeline of a Git project's history.
HEAD => this is a pointer that points to the commit ID or the current commit
Branch => A branch is a chain of commits that are on a separate timeline from the master, therefore, they do not have conflicting timelines.
Downloading zip vs cloning of Github repository => when we download the zip of a repository, git files won’t come ( .git, .gitignore, .gitattribute, etc won’t come ), but in case of cloning all the files, including git files will be cloned to local disk.
Git version control =>
Git is a source control software allowing you to take snapshots and distribute your creations & modifications over time.
GitHub is an application allowing you to store and interact with your repository on a remote server, as well as adding more features (eg. Publicity, licensing, collaborators)
Git is the bones and flesh of source control, while GitHub gives you the platform to work with your repository easier.
Basic commands
$ git init ## this command initiate the git repository$ git add <folder1> <folder2> <etc.> ## adding files/folders to git staging area$ git commit -m “Your message about the commit” ## commiting files present in staging area$ git remote add origin https://github.com/yourUsername/yourRepository.git$ git push -u origin master ## pusing to branch master
Workflow
Staging area => The staging area can be described as a preview of your next commit. When you create a git commit, Git takes changes that are in the staging area and makes them a new commit
ADVANCED GIT COMMANDS
Checking status =>
$ git statusAdding and removing files =>
$ git add PATH_OF_THE_FILE## to add all the files present in the current directory
$ git add . ## removing the particular file from the commit$ git rm PATH_OF_FILE ## removing the file from git commit forcefully [ Note: this command will remove the file and also delete the file ]$ git rm -f PATH_OF_FILE## this command will just make the file untracked locally, so it won’t go in git-commit [ recommended ]$ git rm --cached PATH_OF_FILE
Git commit =>
## open a new file commit message file to put the comment in a very beautiful way
$ git commit## when you want to give a one-liner commit$ git commit -m “commit message”## to view all the commits which we have done$ git log
GOING BACK IN TIME
Git checkout => it simply means to switch the head pointer from the current branch to any other commit_id or any other branch. it just does switching and changes the working directory accordingly, it won’t change delete anything, or not make any changes until the user does.
Key points:
- > Head will change
- > Working directory will change accordingly
- > No deletion of commit/files will happen. ( checkout do switching only )
checkout command is used to switch between commits, branches, etc say we want to go back to some commit which we made earlier -> first use git log to check the commit id for that commit, also remember where the HEAD is pointing ( on which branch )
$ git checkout COMMIT_ID
---->>>> now this will make the local repository to that commit, everything will be revert to that commit, files created after that commit will be invisible [ not permanently they will be secure in the .git folder, just for a better view, they will not visible ], and files will hided after that commit will be restored## say we have visited some commit_id using checkout, and we want to restore the present time state then this command is used$ git checkout BRANCH_NAME
--->>> this same command can also be used to switching head between branches
we can also git checkout to create a new branch and switch to it
$ git checkout -b NEW_BRANCH_NAME
--->>> this will create a branch with name NEW_BRANCH_NAME and swith head to that branchGit Revert => git revert current to move the head pointer to the targeted commit_id and make its current state, which means the entire commit history created after that commit_id will be removed( deleted ).
Key points:
- > head will change
- > working directory will change accordingly
- > deletion of commits and data is there ( but not permanent, can be reverted )
$ git revert COMMIT_ID
------>>>>>>> ## this command will revert and delete all the changes which are made between this commit_ID and its previous commit idReverting the git revert
## if we want to revert the actions done by the revert command accidentally, then revert also done in form of commit, we can revert the revert commit by using revert commit id only$ git revert REVERT_COMMIT_ID
Git reset =>
This wants to create a new commit like git revert or it is not just visiting the past like git checkout, it is a one-way path, if you reset to a commit, then your current stage becomes that commit, and all the commit is done after that commit will be deleted, no way to go back
Note: git reset is very dangerous, use it with care
There are three kinds of git reset
- soft: only changes HEAD, but doesn’t change staged files in index or working files.
- mixed: moves HEAD and updates the index with the contents of the revision to which HEAD now points.
- hard: moves HEAD and updates the index and working directory — this is the only version of reset that can cause data loss.
$ git reset --hard commit_id
--->>> this is for hard reset, similar commands are their for mixed and softDifference: git reset vs git revert => actions done in git revert can be undone, but action done in reset can not be reversed.
.gitignore =>
This file contains the path of the files/folder which should not include in any git commit.
create a file with the name .gitignore
and add the path of files or directory you want to ignore, and don’t want to include in any commit
Note: do not add the completed os path, just add the path from the current directory
example of .gitignore file =>
# you can add a comment in .gitignore files with # in the beginning
log.txt
test/testing/
test/testing2/viraj.txt
Removing cached files from the git =>
If any file is being tracked even after putting it into .gitignore, then may there is some cached left of it, to remove the cache give below command
$ git rm -r --cached .
$ git add -ANote: if you are adding a file in .gitignore, which is already committed once, then it will be kept tracked by git, since its cache is present there, for this you must remove the cached and after that
$ git add . So that the file will be checked freshly from the .gitignore file and will be ignored
working with branches
creating a new branch =>
$ git branch devcreating a new branch and switching to it
## say we are currently in the master branch, then after executing this command, we will move to bugs and bugs will have all the commits done in master$ git checkout -b bugs
listing all available branches =>
$ git branch -a ## the star one is the current oneDeleting a branch =>
$ git branch -d branch_name ## this will delete the branch locally only$ git push origin --delete BRANCH_NAME ## this will create a commit which will delete the BRANCH_NAME
Note: commit of one branch will be different in all the branches, say we created a file, then that file will reflect in all the branches which present currently, but after we add this file in any of the branches' commits, it will be shown in that branch only, it won’t reflect in other branches.
Merging two branches =>
Initial stage =>
After merging =>
Say we merge the dev branch to the master branch then
-> all commits of the dev branch will be merged to the master branch too.
-> if in the master branch some extra commits are present, which are done on files from dev or the files having the same name as dev, then there will be a conflict, all if the files if branches have different changes, then they will be merged with the comments left for you to check, commit will be failed, and the respective merge will be put in the unstaged area so after you can check the comments and balance the code from both the branches and then you can add the files to the staged area and commit them.
In the above screenshot, you can see the master branch has some commits of the dev branch with the same commit_id, that’s how merging works. here I merged the dev branch into the master.
Note: If one single file has a different commit in both the branches then while merging, commits from both the branches will be present in the file with a proper comment, only the commit will fail on purpose, and the purpose is that you cross-check the merged happened in the file which has committed in both the branches and do the final commit after the confirmation.
## below command will merge the dev branch to the current branch
$ git remote dev --->>> say we are currently in master branch, and we want to merge the dev branch to master , then use above command to do so,
Git automatically tries to merge the separate histories when creating a merge commit. In case it comes across data that is altered in both histories, user intervention is required.
WORKING ON REMOTE REPOSITORY
Adding remote repository =>
This means we are specifying the remote repository, where we want to put our data
$ git remote add origin “URL_WITH_GIT”$ git remote -v ## list all added origin
Git pull =>
$ git pull ## to pull the current branch$ git pull origin master ## to pull the master branch
Git push =>
pushing a recent commit to the GitHub
$ git push -u origin branch_nameRebasing two branches =>
In case of rebasing, the commits of the source branch are freshly committed to the head of the destination branch.
$ git rebase branch_name_the_source_one
Diff: git rebase vs git merge => In merging commits on the source branch will be merged to the destination branch, with the same hash id, and the time of commit will be the same on both the branches while in the case of rebasing commits of source branch will be freshly committed to destination branch, means hash id will be different with different commit time.
For more CTFs and bug bounty writeup, or content related to ethical hacking, android penetration testing. follow me on:
Medium: https://hackpeas.medium.com
Youtube: https://www.youtube.com/channel/UC17W_Ircv7EmIIdbJeOQ_BQ
Instagram: https://www.instagram.com/hackpeas/
Linkedin: https://www.linkedin.com/in/viraj-vaishnav-19b0a61aa/
Twitter: https://twitter.com/VirajVaishnav16
Thank You..
