Overview:
Chapter 1:
What is Version Control?
By Using the Version Control System you can handle different versions of the same source code file in your test automation project.
Version Control System (Use): -
It is used to keep track of the changes made over time to source code, documentation & configuration files.
Advantages: -
Team collaboration, Integration of your test automation code into a CI/CD Pipeline, fast feedback loop through checking out feature branches for early testing, learning source control concepts can boost your learning journey to other technical skills.
Chapter 2:
An Introduction to Git
Git: -
- It's a version control system that arose out of the development community and in particular, Linus Torvalds.
- Git so popular these days because it is very efficient, version controls the Linux kernel& the huge popularity of github.com.
- It Tracks collaborative work on a project through a beautiful, distributed graph theory tree model.
- Snapshot (tree object)
- files (Blog Object)
- Commit (Commit Object)
SHA-1 (Use): -
To uniquely identity the stored object in the git database.
Modified, Staged, and Committed: -
These three different states are called git where a file can reside in.
Chapter 3.1
Basic Git Concepts
- git --help: give you a full detailed description of that particular command.
git help<commands>
- 2. git -scm.com
- 3. git -config: first set your username and your user email address. Git will then associate every single commit with these two things.
--system/global/local
--system, --global or -- local: Git for which scope on your machine you want to set a specific configuration.
- 4. git status: all the current path differences between working directory, staging index area, local repository, and remote repository if you have configured a remote one.
- 5. git log: all the commits which were created on a branch. It shows you the whole commit history including the hash, the author, and the date of the currently active, which means checked-out local branch.
Initializing with git:
By initializing a Git repository (using git init) a hidden directory named ".git" is created:
This directory contains the index file, the local repository, and all the other information that is necessary for our project. Information about commits, remote repository if available, addresses, a lock which stores the commit history, et cetera.
- You can see the ".git" directory is a bit of a magic place where we put our magic show in.
- If we want to destroy a local repository, we just have to re-delete this folder. That is why this folder is hidden to omit that we accidentally deleted.
- command git init: It initializes a new Git project by creating a local .git folder in the project directory.
- format and the content of a commit message so important Because it is an inevitable piece of documentation for a coding project as it improves the traceability and understandability of changes made to source code.
- git fetch followed by git merge, Git will fetch all the newly added remote branches its objects from the remote repository to the local repository and then merge the changes from the local repository into the current active branch in the working directory.
- command git reflog with the extended configuration options show HEAD output, will output the reference log of the HEAD, which means a log of all the changes made to the branch pointer HEAD.
Adding (git add<file>):
As soon as we have created the new file or modify the file in the working directory, we have to add this file to the staging, also called the index area.
Chapter 3.2:
Commiting and Pushing
Commiting (git commit):
- Simply hitting git commit in a command line here would open up our default Git text editor where we can enter a commit message.
- Or, directly by setting the commit message in the command itself by hitting git commit -m and then followed by a commit message in quotation marks.
Pushing (git push):
- Our commit (or commits, of course), will be sent from the local repository to a remote repository.
Chapter 3.3:
Cloning, Fetching, Merging and Pulling
Cloning a Repository
- Cloning (git clone<url>): git clone clones the remote repository into 2 places — into the working directory and the local repository.
- Fetching (git fetch): By fetching, we get all the data — which means all the remote branches and all their objects, commits, snapshots, files — into the local repository.
- Merging (git merge): Merging, we can merge the changes which we have fetched into our local repository into the current active branch in the working directory, thereby also the staging area, which means our index file is updated accordingly.
- Pulling (git pull): By pulling, we fetch new data from the remote repository into the local repository and also merge all the new things depending on the currently active local branch into the working directory.
- Stashing: To save the current state of changes in the working directory and the index, we can use git stash.
- Git Reference Log: Helpful after some occasions when returning to work and don't exactly remember what we have done in the repository before we left. Or if we just want to find a certain commit in the local Git history.
Chapter 4.1:
Getting Started with Branches
- Branch: It is a pointer that points to the latest commit of a series of commits.
- HEAD pointer used: It is used so that Git knows which branch is the active one to work on.
- Fast-forward merge: It is a merge where the HEAD of the currently active target branch can be simply moved forward to the latest commit of the source (the to be merged) branch. This only happens when the source branch hasn't diverged from the active branch.
- Diamond Shape: When two diverged branches are merged, an additional merge commit is created and causes the commit history of the target branch to look like a diamond shape for that particular merge. If such merge commits happen a lot, it can pollute the target branch.
- Rebasing a replacement for Merging: It is used to change the basis of a specific commit of a branch and can be used to update a branch onto the state of another one.
- -i is the shortcut for –interactive: Used when rebasing, commits can be squashed, edited, reworded, removed, and reordered.
- Thought of changing the history of a branch: one should never rewrite the commit history of a public share branch.
Chapter 4.2:
Rewriting the history of a branch
Chapter 5.1:
Resolving Conflicts
- Detached HEAD: This is when the HEAD pointer doesn't point to a branch but instead points to a specific commit.
- Cherry picking: lets you pick a specific commit from a branch and apply it to another one. when cherry-picking Git will create a new commit with a new hash with the same content and apply it onto another branch.
- Resetting hard is used: Reset the HEAD to a specific commit in the local repository and clean up the staging area and the working directory accordingly.
- --mixed: reset option is the default one (when none is provided)
- Reverting used: It is used to revert a specific commit by applying a new commit with the opposite changes.
Chapter 5.2:
Cherry Picking, Resetting & Reverting
Chapter 6:
Git Branching Strategies
- Git Flow: branching strategy deals with a release and a developed branch
- Git Flow less useful: Continuous Deployment/Delivery
- Principle of the GitHub flow: A local branch is regularly pushed to the same-named branch on the remote repository to have fast feedback from the CI server
- Trunk Based Development:
- Trunk Based Development branching strategy called when you have just one main branch and where you work without Pull Requests.
- It is especially convenient when doing Pair/Mob Programming.
Chapter 7:
The Most Popular Git Repository Managers
The Most Popular Git Repository Managers: -
Pure get cloud hosting services and others are there to be self-hosted git services.
1. Github.com:
- GitHub is a popular Git repository manager is available has hosting service only.
- It is unchallenged and by far the most popular and used git repository manager out there.
- It was acquired by Microsoft in 2018.
- It is written in ruby and uses elastic search in the back to index the millions of code repositories
- It also offers its unique features as a side note the search engine elastic search itself is also hosted on GitHub.
2. gitlab.com:
- It is a complete software development lifecycle tool that provides a wiki and issues tracking CI/CD pipeline and a git repository manager.
- Big companies like IBM Sony Oracle CERNN and Boeing are using the gitlab
- It is written in Ruby on Rails go and view Jas kinome the free open-source desktop environment with its over 400 projects moved in 2018 to git lab.
3. bitbucket.org (Stash) :
- Bitbucket is a Git Repository Manager is also known as Stash.
- It is owned by Atlassian and written in Java.
- Used for code itself and for doing code reviews, good support for documenting code reviews, helpful when working in regulated environments.
- There is also a cloud version of bitbucket written in python using the Django web framework.
4. gitbucket.github.io:
- It is an open-source self-hosted repository manager powered by Scala & running on the JVM.
- Forged pocket exists a few community-driven plugins which can be installed.
5. gogs.io:
- It is an open-source self-hosted repository manager.
- It is written in goal & the code for it is hosted on Github.
6. gitea.io:
- It is an open-source self-hosted service.
- it is a community fork of cox and also written in go.
- It feels lightfast and fresh.
Self-hosted Git service: A Git Repository Manager which is hosted on one own server.
A Git Repository manager is used for: for collaborative development.
Chapter 8:
Further Learning Resources
Further Learning Resources: -
- 1. Pro Git (Second Edition 2014) Book
-
- 2. Collection of interesting links on git: simonberner.com/Git
-
- 3. Tutorials at conferences workshop on how to set up and configure your own git remote repository manager
- When writing a commit message, it is important to consider that the message clearly states, what the committee will do to the code once it is applied.
- A commit message so crucial because it is helpful for the traceability of the changes made to the code and is an important part of the code documentation.
Final tips: -
1. Commit often: small commits with specific intent to solve a problem are much more reproducible than big commits.
2. Don't commit unfinished tests to make them work and then commit them with a proper working commit others can pull it down and take it from there in case you are away before.
3. Before commit, test your tests: it can be quite embarrassing when you have to fix your tests short after you have committed and pushed.
4. Write clear commit messages: Commit messages are the documentation of your work.
5. Agree on a workflow: As a Team define your workflow how you want to collaborate on a project.
Happy Learning 
Processing…
Success! You're on the list.
Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.