1.

install git--> sudo apt install git

2. check version --> git --version
3. git help --> git --help
4. create folder name --> mkdir first
5. going inside the folder --> cd first
6. created a file --> vi sample.txt
7. check if it is a git project or not --> ls -ltra
8. if it is a git project inside the folder you should find a .git folder
9. convert your first folder into git project --> git init
10. added user info
$ git config --global user.name "jmstechhome14" | When
you are using a new server/machine add only once
$ git config --global user.email "[email protected]" |
" "

to remove credentials from git

*git config --global --unset-all user.name
*git config --global --unset-all user.email

11. to see where the data is stored --> cat ~/.gitconfig

name =jmstechhome14
[email protected]
12. check git status -->git status
13. git add .
14. git commit -m "message" -a
15. git push origin master --> does not work because we don't have a
destination
16. to check whether we have added origin or not --> git remote -v
17. create GitHub account
18. created a new repo in GitHub --> first
19. copy git remote add origin <url> from the repo first
20. paste it into your machine
it asks for a username password but git removed the option so use a
personal access token instead
21. git push origin master --> It works this time

if you get any ERROR like below

To github.com:swethukrishna/GIT.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'github.com:swethukrishna/GIT.git'

22. git pull --rebase origin master

23. git push --rebase origin master

git diff
git remote -v
# View existing remotes
# origin https://github.com/user/repo.git (fetch)
# origin https://github.com/user/repo.git (push)

git remote set-url origin https://github.com/user/repo2.git

# Change the 'origin' remote's URL

git remote -v
# Verify new remote URL
# origin https://github.com/user/repo2.git (fetch)
# origin https://github.com/user/repo2.git (push)

# git pull --rebase origin master

Generate personal access token
------------------------------
1. Go to github settings--> Develoepr seettings --> personal access token
-->Generate new token
--> enter new personal acctesss token name -->give all or required
permissions -->Generate token
-->make sure to copy token you wont able to see it again
2. use generated token as password as password authuntication was removed
from git
1. create a public key
2. check whether you have any public/private key -->cd ~/.ssh/
3. /ssh --> ls -ltr ---no keys
4. create a public key now -->ssh-keygen
5. it will create one id_rsa file under -->(/home/ec2-user/.ssh/id_rsa)--
>cat enter
6. enter passphrase
7. enter same passphrase again
8. /ssh --> ls -ltr
id_rsa.pub -->public key
id_rsa -->private key
9 . cat id_rsa.pub
10. copy public key
11. go to github settings-->ssh and gpg keys-->new ssh key-->add key
* ssh -T [email protected]
12. check git remote -v
13. previously we have set remote origin for https using --> git remote
add origin <url>
14. now over write the existing remote origin to shh as we have generated
ssh public key for passwordless auth
15. to over write the https to ssh use command --> git remote set-url
origin <url>(we will have the url in the dropdown code option which is in
our master branch floder in github)
16. git push origin master --> works this time

#ssh-keygen -t rsa

https url need to enter password

Git clone copies all files to the local machine
1. create a repository in GitHub
2. add a file to the folder
3. if we create a repository in GitHub it stands on the main branch by
default
4. do not add git init to the entire ec2-user only add git init to the
folder working on the git project
5. now go to the local machine and clone the created new rep --> git
clone <sshurl>
6. when you clone the project from the git hub it is already a git
project
7. make the changes in the existing folder cloned from the git hub
8. now git add .
9. git commit -m "msg"
10. check remote --> git remote -v
11. as we cloned using ssh we are in ssh remote
12. now push the folder to the remote using the branch name
13. check which branch you are standing on --> git branch
14. now push to remote --> git push origin main
15. now the made changes are successfully pushed to remote from the local
machine
*Git fetch command only copies changes into your local Git repo and does
not merge into your working directory (or)git fetch gathers any commits
from the target branch that do not exist in the current branch and stores
them in your local repository. However, it does not merge them with your
current branch. This is particularly useful if you need to keep your
repository updated, but are working on something that might break if you
update your files. To integrate the commits into your current branch, you
must use git merge afterward.
*Git clone copies all files from the Github repo or central repo to the
local machine
*Git pull only copies the modified files of the GitHub repo to the local
machine. (or) git pull tries to automatically merge after fetching
commits. It is context-sensitive, so all pulled commits will be merged
into your active branch. git pull automatically merges the commits
without letting you review them first. You may run into frequent
conflicts if you don’t carefully manage your branches.
*A fork copies the code from the source of open-source public projects on
GitHub
1. when two developers are working on the same project on the same file
on the same line
2. one developer is working on the same file, the same line, then push
the changes to GitHub
3. another developer also working on the same file, same line trying to
push the same changes to GitHub
4. while pushing the GitHub will through the error because the same
reference is already changed in the remote repository
5. that changes are not there in the local repository
6. now download the changes into the local repository -->git pull origin
master
7. if there is an error --> fatal: Need to specify how to reconcile
divergent branches. enter any of these three-->hint: git config pull.
rebase false # merge

hint: git config pull.rebase true # rebase

hint: git config pull.ff only # fast-forward only

8. while downloading we will get the merge conflicts in the worked file
9. we need to remove the unwanted correctors and rearrange the file in
whatever structure you want then
10. git add .
11. git commit -m "msg"
12. now push the changes -->git push origin master (or) git push -f
origin master

if you get any ERROR like below

To github.com:swethukrishna/GIT.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'github.com:swethukrishna/GIT.git'

13. git pull --rebase origin master

14. git push --rebase origin master

If changes are made in the different files by different developers at the

same time also while pushing it throws an error in this case just
download the GitHub repo files (or) git pull origin master files in the
local repo and the merge will be made by recursive strategy in the local
repo but there will be no merge conflicts as the changes are made in
different files but show error as mentioned above.
Branch: branches allow you to keep different versions of your code
cleanly separated (or) Branches allow developers to work on different
features, issues, or bug fixes without affecting the project's main
codebase.

1. which branch we are standing -->git branch

2. to show all branches -->git branch -a
3. to create a new branch -->git branch feature
4. to switch to feature branch -->git checkout feature
5. to push changes and create a feature branch in the remote repository -
->git push origin feature
6. to check which branch we are standing -->git branch
7. to switch to the master branch -->git checkout master
8. to merge feature branch into master branch -->git merge feature
9. to push changes to remote repository -->git push origin master
10. to delete the branch local repo -->git branch -d feature
11. to delete the branch in the remote repository -->git push origin -d
feature
12. create and switch to a branch with existing data on the master branch
at a time -->git checkout -b hotfix
13. to change git branch name --> git branch -m branchname

To rename the current branch:

git branch -m <newname>

To rename a branch while pointed to any branch:

git branch -m <oldname> <newname>

-m is short for --move.

To push the local branch and reset the upstream branch:

git push origin -u <newname>

To delete the remote branch:

git push origin --delete <oldname>

To create a git rename alias:

git config --global alias.rename 'branch -m'

Git is a powerful version control system that enables developers to
collaborate on projects and manage changes efficiently. One of the key
features of Git is its branching system, which allows developers to
create multiple branches of a codebase, work on them independently, and
then merge them back into the main branch.

the most commonly used Git branching strategies.

1. Gitflow:
-------
Gitflow is a popular branching strategy that uses two main branches:
master and develop.

The master branch contains production-ready code, while the develop

branch contains the latest development code. Feature branches are created
off the develop branch, and when the feature is complete, it is merged
back into the develop branch. When the develop branch is ready for
release, it is merged into the master branch, and a new release is
created.

Gitflow is a robust branching strategy that works well for large projects
with long release cycles, but it can be complicated to set up and
maintain. It also requires strict discipline around feature branch
creation and merging.

2. Feature branching:
-----------------

Feature branching is a simple branching strategy where each new feature

is developed on its own branch. This approach allows for isolated
development and testing of features, making it easier to roll back
changes if necessary. Feature branches are created off the master branch,
and when the feature is complete, it is merged back into the master
branch.

Feature branching is a great option for smaller projects or teams that

want a straightforward branching strategy. However, it can quickly become
unwieldy for larger projects with many developers and features.

3. Release branching:
-----------------

Release branching is a branching strategy that involves creating a new

branch for each release of a project. This approach allows for final
testing and bug fixing on the release branch before it is merged into the
master branch for production.

Release branching is a good option for projects with short release cycles
or when there are specific testing requirements for each release.
However, it can be challenging to manage multiple release branches
simultaneously.

Hotfix Branches:
----------------

In Gitflow, hotfix branches are created from the master branch when a
critical bug needs to be fixed in the production release. Once the hotfix
is complete, it is merged back into the master and develop branches.
This approach is used to quickly fix critical bugs that are found in the
production release. It’s a way to separate the bug-fixing work from the
ongoing development work and keep the master branch stable.

Let’s try to understand with a real-time scenario:

For Example, if you are working on a software development project:

You will start by creating a master branch. This will be the main branch
for production releases.
As the development work progresses, new features and bug fixes are added
to the master branch, and new releases are created.
Let’s say, at some point, a critical bug is found in the production
release. So, a hotfix branch will be created from the master branch.
Let’s call it hotfix1.
The hotfix1 branch is used to fix the bug. This includes coding, testing,
and debugging.
Once the hotfix is complete, it is merged back into the master and
develop branches.
Finally, the hotfix1 branch is deleted
Overall, hotfix branches are used to fix critical bugs that are found in
production quickly, without disrupting the ongoing development work. It
is useful, If you have a long release cycle, you can use hotfix branches
to fix bugs that are found in production

4. Trunk-based development: (or)

-----------------------

Trunk-based development is a branching strategy where developers work on

a single branch, often the master branch, and use feature flags to
isolate new features until they are ready for release. This approach
allows for continuous integration and delivery and can be an excellent
option for teams that want to move quickly and frequently release
updates.

Trunk-based development requires a high level of discipline and

communication between developers to avoid conflicts and ensure that new
features are properly isolated. It can also be challenging to maintain
backward compatibility with older releases.

In conclusion, Git branching strategies are essential for managing

development projects effectively. Each strategy has its pros and cons,
and the right one for your team will depend on your project’s size,
release cycle, and development process.

By understanding the different options available, you can choose a

branching strategy that works best for your team’s needs and set your
project up for success.

Architecture Overview:
---------------------

1. Gitflow architecture diagram:

The master branch is the stable production-ready branch.

The develop branch is the integration branch where new features are added
and tested.
Feature branches are created off the develop branch and merged back into
it when complete.
Release branches are created off the develop branch for final testing
before merging into master for production.
Hotfix branches are created off the master branch to address critical
production issues.

2. Feature branching architecture diagram:

The master branch is the stable production-ready branch.

Feature branches are created off the master branch for developing new
features.
Once the feature is complete, it is merged back into the master branch.

3. Release branching architecture diagram:

The master branch is the stable production-ready branch.

Release branches are created off the master branch for final testing and
bug fixing before merging into master for production.

4. Trunk-based development architecture diagram:

The master branch is the main development branch where all new features
are added and tested using feature flags.
When a feature is ready for release, the feature flag is removed, and the
feature is released.
Hotfixes are added directly to the master branch.
In today’s fast-paced software development environment, the ability to
quickly and effectively develop and release software is vital. However,
managing code changes and merging them in a timely and organized manner
can be a challenging task, especially when working with a large team of
software engineers.

To overcome this, teams need to have a well-defined process in place to

handle multiple code changes concurrently. Implementing an efficient
branching strategy is crucial for these teams in order to maintain a
streamlined workflow and avoid confusion or conflicts.

There are different branching strategies followed in the industry today,

depending on the team and organization. However, some of the most popular
strategies among developers and QA teams are:

Git Flow
GitHub Flow
Trunk Based Development
1. GitFlow:
--------
Git flow is a popular branching strategy that uses a central repository
to maintain different branches for development, releases, and hotfixes.

In Gitflow, there are two main branches: the develop branch and the
master branch. The develop branch is used for ongoing development work,
while the master branch is used for production releases.

Alongside the main branches, there are multiple supporting branches to

handle different stages of development. It includes feature branches,
release branches, and hotfix branches for specific tasks. This strategy
is well suited for larger, more complex projects.

Feature Branching:
-----------------

This strategy involves creating a separate branch for each feature or

bugfix that is being worked on. When the work is completed, the feature
branch is merged back into the main development branch.

It’s well suited for teams that are working on multiple features at the
same time and want to keep their codebase stable. However, it’s also
important to have a process in place to merge and review the feature
branches before they’re merged into the main branch to avoid conflicts

Let’s try to understand with a real-time scenario:

For Example, you are working on a software development project:

You will start by creating a develop branch from the master branch. This
will be the main branch for ongoing development work.
Next, you will create a new branch from the develop branch to implement a
new feature. Let’s call it feature1.
Then, you will work on feature1 in the feature branch. This can include
coding, testing, and debugging.
Once feature1 is complete, it is merged back into the develop branch.
This can be done using a pull request.
Repeat steps 2–4 for each new feature that needs to be implemented.
Once all features are complete, the feature branches would be merged back
into the develop branch using a pull request and eventually into the
master when it is ready for release.
Overall, feature branching is a simple strategy that allows for a high
degree of flexibility and parallel development. It’s well suited for
teams that are working on multiple features at the same time and want to
keep their codebase stable.

Release branches:
----------------

In Gitflow, a release branch is created from the develop branch when a

release is approaching. Only bug-fixing and release-related tasks are
done on this branch. Once the release is shipped, the release branch is
deleted and development continues on the develop branch.

It’s a way to separate the ongoing development work from the release
management. It is mainly used to isolate the release management work from
the ongoing development work and keep the master branch stable. This
allows the team to work on new features while also allowing for a stable
release branch for testing and QA.

Let’s try to understand with a real-time scenario:

For Example, my team is preparing for a new software release.

They will start by creating a develop branch from the master branch. This
will be the main branch for ongoing development work.
As the development work progresses, new features and bug fixes are added
to the develop branch.
When it’s time to release a new version of the software, a release branch
is created from the develop branch. Let’s call it release1.
The release1 branch is used to test and prepare the release. This
includes testing, bug fixing, and finalizing documentation.
Once the release is ready, it is merged into the master branch. This
creates a new production release.
Finally, the release1 branch is deleted, and development continues on the
develop branch.
Overall, release branches are used to isolate the release management work
from the ongoing development work and keep the master branch stable. The
base of a release branch is typically the development branch or the
develop branch, which contains all of the latest features and changes
that have been implemented.

It’s useful when you have a long release cycle, you can use release
branches to keep track of the progress of a release.

Hotfix Branches:
----------------

In Gitflow, hotfix branches are created from the master branch when a
critical bug needs to be fixed in the production release. Once the hotfix
is complete, it is merged back into the master and develop branches.

This approach is used to quickly fix critical bugs that are found in the
production release. It’s a way to separate the bug-fixing work from the
ongoing development work and keep the master branch stable.

Let’s try to understand with a real-time scenario:

For Example, if you are working on a software development project:

You will start by creating a master branch. This will be the main branch
for production releases.
As the development work progresses, new features and bug fixes are added
to the master branch, and new releases are created.
Let’s say, at some point, a critical bug is found in the production
release. So, a hotfix branch will be created from the master branch.
Let’s call it hotfix1.
The hotfix1 branch is used to fix the bug. This includes coding, testing,
and debugging.
Once the hotfix is complete, it is merged back into the master and
develop branches.
Finally, the hotfix1 branch is deleted
Overall, hotfix branches are used to fix critical bugs that are found in
production quickly, without disrupting the ongoing development work. It
is useful, If you have a long release cycle, you can use hotfix branches
to fix bugs that are found in production

2. GitHub Flow:
------------
GitHub Flow is a branching strategy that is similar to Gitflow but it is
simpler, lightweight, and more focused on continuous deployment. It is
designed for smaller teams and projects that require faster release
cycles.

In GitHub Flow, there are two main branches: the master branch and the
feature branch. The master branch is used for production releases, and
all new code is committed to this branch. Feature branches are created
off of the master branch and are used to implement new features.

Once a feature is complete, it is merged back into the master branch and
is immediately deployed to production.

Let’s try to understand with a real-time scenario:

For Example, if you are working on a software development project:

You will start by creating a master branch. This will be the main branch
for production releases.
Next, you will create a feature branch from the master branch. This
branch will be used to implement a new feature. Let’s call it feature1.
Now, you work on feature1 in the feature branch. This can include coding,
testing, and debugging.
Once feature1 is complete, it is merged back into the master branch. This
can be done using a pull request.
The code is immediately deployed to production after being merged into
the master branch.
Finally, the feature branch can be deleted
Overall, GitHub Flow is a simple and effective strategy that is well-
suited for smaller teams and projects that have a need for faster release
cycles. This strategy is focused on continuous deployment, which allows
teams to deploy new features and bug fixes to production as soon as they
are ready

3. Trunk-Based Development:
------------------------
The trunk-based development is a simpler branching model that uses a
single trunk or master branch for all development. New features and bug
fixes are committed directly to the trunk, with no additional branches
required. This strategy is more suitable for smaller projects or teams
that prefer a simpler workflow.
This strategy involves working directly on the main development branch,
with developers/QA’s committing their changes frequently and relying on
automated testing and continuous integration to catch any issue

Let’s try to understand with a real-time scenario:

For Example, If you are working on a software development project and you
want to implement TBD, then you can follow the below steps :

You will start by creating a master branch called trunk or master. This
will be the branch that contains the latest stable version of the
codebase. This branch will be used as the base for all new development
work, and you can merge your code changes into this branch.
Next, you will create a new branch for each change, and make your code
changes on that branch.
Before opening a pull request, make sure you run the tests locally to
ensure that the code changes don’t break the application.
When all the test case passes, you can open a pull request to merge your
changes into the master branch. This triggers the CI pipeline, which
automatically builds and tests the code changes.
Now, other team members should review your code changes and provide
feedback or suggestions. If any issues are found, you can fix them and
push the changes to the branch.
Once the code changes have been reviewed and tested, the pull request is
approved and merged into the main branch. The changes are automatically
deployed to a staging environment for further testing.
By following the above process, you can catch and fix issues early,
before they become a problem. You can also deploy new features and bug
fixes to production more frequently, which allows you to deliver value to
users more quickly.

Note, Trunk-based development is not always suitable for every project

and organization, as it does have some limitations and trade-offs. For
example, it may not be well-suited for projects that have long-lived
branches or require extensive testing before deployment.

It is also not recommended for projects where a high level of stability

is required, as trunk-based development can lead to more frequent
deployments, which can make it more difficult to maintain stability.

In terms of deployment, the Trunk-Based Development approach utilizes

feature flags to control the changes made in the shared main branch
(trunk)

Feature flags

Feature flags(also known as feature toggles or feature switches) are a

technique used in software development to control the release of new
features or changes to a codebase.

They allow teams to deploy code changes to a production environment

without immediately making those changes visible or available to users.

This is especially useful in trunk-based development (TBD) where all

development work is done on the trunk, the main branch of the code
repository, and the codebase is continuously integrated and deployed.

Using feature flags in TBD, teams can toggle portions of code on or off
for the build process, and deploy only the necessary code in production
environments. This allows teams to deploy new code changes and features
to production while keeping them hidden from users.

Once the code changes have been thoroughly tested and are deemed stable,
the feature flags can be turned on, making the changes available to
users.

Feature flags are particularly useful in the following scenarios:

A/B testing: allows teams to test new features with a subset of users
before rolling them out to the entire user base.
Gradual rollouts: allows teams to gradually roll out new features to
users, rather than releasing them all at once.
Canary releases: allows teams to test new features with a small subset of
users before releasing them to the entire user base.
Rollbacks: allows teams to quickly rollback a new feature or change if it
causes issues in production.
Using feature flags, you can deploy code changes to production with
confidence, knowing that you can quickly revert or disable any changes
that cause problems. It also allows you to work on multiple features or
bugs in parallel and deploy them independently of each other.

Overall, Feature Flags is a powerful technique that allows teams to

manage the complexity and risk of deploying new code changes and features
in a trunk-based development environment, also allows teams to release
new features and changes faster and with more confidence.
1. git tags The main idea is that we can tag particular commits so we can
label commits by creating a tag, a reference to a moment in time.
2. tags are pointers that refer to particular points in the git history.
we can mark a particular moment in time with a tag.
3. tags are most often used to mark version releases in projects
(v1.1,v1.2, etc)
4. think of tags as branch references that do not change. once a tag is
created, it always refers to the same commit. It is just a label for a
commit.
5. git tags are of two types
i. lightweight tag -- just simply creating a git tag version number - it
a pointer to a commit
ii. annotated tagging -- it stores extra information while creating a git
tag version number including the author's name, email, and date just like
the commit message.
6. generally it is recommended to create an annotated tag.
7. to create a lightweight tag -->git tag v1.1
8. to create an annotated tag -->git tag -a v1.0 -m "Hello guys this is
the first release"
9. to list the tags created -->git tag -l
10. to push one tag to the remote repository -->git push origin v1.1
11. to push all tags to a remote repository at a time -->git push origin
--tags
12. to push multiple tags to the remote repository at a time -->git push
origin v1.1 v1.2
13. to delete a specific tag -->git tag -d v1.0
14. to add a tag to the past commits -->git tag v0.1 55ac23b(log file
first seven digits) known as later tagging
15. to delete a tag in remote -->git push origin -d v1.0
16. to display the git log output as one commit per line --> git log --
oneline
 git checkout (undo)
-------------------
1.if we have done some changes into an existing file(future.txt) at
multiple lines and saved now (not added and commited)you realise those
changes are not correct and you dont remenber the lines you changed then
to undo those changes.
2.before git add. ;we can roll bach changes
3.we need to do --> git checkout future.txt(checkout is used to change
the branch and undo changes)
3. if we need to change all the files -->git checkout

git reset
---------
1.git reset is of three types
-->git soft -- go to staging area
-->git mixed -- go to workspace
-->git Hard -- undo changes in workspace
1.Remove the commits but keep their changes staged--> git reset --soft
HEAD~1 (or) git reset --soft cd767s6(if you want to reset latest commit
give the previos commit id)
2.Remove the commits but keep their changes in the working directory
(unstaged) --> git reset --mixed HEAD~1 or git reset --mixed(default)
3.Remove the commits and remove all their changes from your working
directory --> git reset --hard HEAD~1
4.git reset --hard HEAD~1 (or) git reset --hard HEAD~2 you can change the
numbers depending upon the number of latest commits you want to reset.
5.git reset --soft HEAD~1 (or) git reset --soft HEAD~2 you can change the
numbers depending upon the number of latest commits you want to reset.

git revert
----------
1.when the incorrect changes are pushed into remote repository if we want
to revert changes from remote repository we use git revert
2.copy the commit id of the file which you want to revert --> git revert
cd767s6
3.it shows reverting these file then exit
4.now go to git log you will see the existing commit and aslo you will
see a new extra commit msg called revert "existing commit msg"
5.now push the changes to remote --> git push origin master
6.you will see the incorect changes are reverted in remote repository.

To edit latest commit message in git --> git commit --amend -m "edit
commit message"
------------------------------------vi h
1. to edit the latest commit message --> git commit --amend -m "edited
message"
2. The commit message is edited
3. if you want to edit 3rd commit message in git log --> git rebase -i
HEAD~3
4. now last 3 commit commits will open where you will see the last three
commit messages
-->pick 5td567q "commit message"
-->pick 5td567q "commit message1"
-->pick 5td567q "commit message1"
5. now you will see the commit messages count from last as 1 2 3
6. now in 3rd commit replace pick with reword then save and exit(ctrl+O--
>ENTER-->ctrl+X-->edit message-->ctrl+O-->ENTER-->ctrl+X)
7. now you will see your 3rd commit message which you want to edit. edit
it then save the exit
8. now the changes in the 3rd commit message are edited.
9. to push the edited commit messages --> git push -f origin master
(force push)
1. git squash is used to make multiple commits into one commit
2. if you want to squash the first four commits into one commit we have
to add the previous commit also to give the number of commits needed to
squash
3. to squash the first 4 commits into one --> git rebase -i head~5
4. here in the above command we have given no of commits as 5 to squash
the 4 commits
5. you cannot squash without the previous commit
6. to squash the first four commits into one --> git rebase -i head~5
7. now last 5 commit commits will open there you will see the last five
commit messages in reverser order(git log 4,3,2,1,o) (git rebase
0,1,2,3,4)format.
-->pick 5td567q "commit message"
-->pick 5td567q "commit message1"
-->pick 5td567q "commit message2"
-->pick 5td567q "commit message3"
-->pick 5td567q "commit message4"
8. you can't squash the previous "commit message" line it will throw an
error.
9. now replace pick with squash to fist four lines(from down)
"msg1,msg2,msg3,msg4" then save and exit.
10. now you will see the commits messages edit them all to one commit
message then save and exit.
11. to check the squash status -->git log
12 You will see the multiple commits into one commit.
1. If you are working on a new feature in your project?
2. for that you have created a separate branch(future) for that purpose.
3. if you want to add these changes to the master branch?
4. Then MERGE or REBASE can be helpful
Scenario:
-------
1.a devoloper1 added two commits in master branch m1,m1
2.then he switched to a new branch(future) and added new commits fm3,fm4
3. now devoloper2 in the master branch added another new commit m3,m4
4. if devoloper1 wants to add future branch commits to the master branch
then we use git merge, git rebase

Merge: you will lose the proper development history

-----
1. if you want to merge the future branch changes to the master branch as
discussed in the above scenario
2. then we have to stand on master --> git checkout master
3. now merge future changes to master -->git merge future(we need to
resolve merge conflicts in this case we will get a new commit as we fixed
merge conflicts and saved)
4. now check whether the commits have merged -->git log
5. you will see a newly added commit along with the merged commits
6. check the order of the commits you will see --> extra
commit,m4,m3,fm4,fm3,m2,m1(check one practically)
7. using the merge command we can merge the two branches but if the
scenario is as in the above case we will lose the proper development
history
8. extra commit will be added

rebase: you will get a proper development history

------
1. if you want to merge the future branch changes to the master branch as
discussed in the above scenario
2. get the latest up-to-date code to future branch
3. for that first we need to stand on the future branch -->git checkout
future
4. now execute a command -->git rebase master
--> Remove merge conflicts in file |
-->git add. | While working in a single file
-->git rebase --continue |
5. now to merge the future branch to the master branch
6. stand on master branch -->git checkout master
7. now execute a command -->git rebase future
8. now check whether the commits have merged -->git log
9. check the order of the commits you will see -->
fm4,fm3,m4,m3,m2,m1(check one practically)
10. using the rebase command in the above scenario you will get the
proper development history

NOTE:(REBASE):
git rebase master
*Auto-merging hello.txt
CONFLICT (content): Merge conflict in hello.txt
error: could not apply 586fd52... f1
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git
rebase --abort".
Could not apply 586fd52... f1
now resolve merge conflicts
*vi hello.txt
1
2
<<<<<<< HEAD(delete)
5
6
=======(delete)
3
>>>>>>> 586fd52 (f1)(delete)

~
in above txt line 4 is missing ignore it and resolve conflicts save and
exit
*git status
ERROR
-----
interactive rebase in progress; onto 7d5702c
Last command done (1 command done):
pick 586fd52 f1
Next command to do (1 remaining command):
pick 5c8f937 f2
(use "git rebase --edit-todo" to view and edit)
You are currently rebasing branch 'feature' on '7d5702c'.
(fix conflicts and then run "git rebase --continue")
(use "git rebase --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)

Unmerged paths:
(use "git restore --staged <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: hello.txt
*now
*git add .
*git rebase --continue
*it will open a nano terminal
*try not to change the commit message
save and exit

* if you want to add future branch changes to the master branch without
commit messages in the above scenario then use--> git merge --squash
future

(or)

--> git merge future --squash

Differences between Merge and Rebase

-------------------------------------
Merge
------
1. It is a single step process
git checkout master
git merge feature
2. Merge preserves history of all commits.
3. The commits can have more than one
parent and history is non-linear.
4. In merge, there may be a chance of
conflicts.
5. We can aware which changes are coming
from which branch.
6. We can use merge on public repositories.
Note:
-----
Rebase is very dangerous operation and it is never recommended to use on
public
repositories because it rewrites history

Rebase
-------
1. It is a two-step process
git checkout feature
git rebase master
git checkout master
git merge feature
2. Rebase clears history of feature branch.
3. Every commit has only one parent and
history is linear.
4. In Rebase, there is no chance of conflicts.
5. We can not aware which changes are
coming from which branch.
6. It is not recommended to use rebase on
public repositories.
cherrypick: picking a specific commit from one branch and applying that
commit to another branch
----------
1. we have two branches master and future
2. in master we have 3 commit files one two three
3. in the future we have 2 commit files four and five
4. I want to merge one of the commits from the future branch to the
master as the other commit needs some changes so we are merging only one
commit
5. in this case we do cherry-pick
6. now stand on master branch -->git checkout master
7. then check commits -->git log --oneline
8. copy the commit-shah(4d5568c) from the future branch which you want to
merge into the master branch
9. now do cherrypick --> git cherry-pick 4d5568c
10. now check the commit using -->git log --oneline
11. you will see the specific commit is merged into the master branch

NOTE: if you pick the latest commit from another branch the other commits
before which are not merged are also picked
till the latest automatically so the merge conflicts occur resolve them
and fix
git ignore: The purpose of git ignore files is to ensure that certain
files untracked by Git remain untracked or ignored.
----------
(or)
git ignore file is used in a git repository to ignore the files and
directories that are unnecessary to the project this will be ignored by
the git once the changes as been committed to the Remote repository.

1)To ignore some files to track in a git repository

i) -> Create a text file named ".gitignore" using the command (if not
exist): touch .gitignore
ii)-> Add the name of the file to be ignored in the .gitignore file

2)To ignore every file based on the extension

ii) -> Write *.<extension> in the .gitignore file
example: if we want to ignore all files having .log extension
open the .gitignore file and add " *.log " in that file.

3)To ignore folder inside a git repository

ii) -> Write <foldername>/ in the .gitignore file
example: if we want to ignore all folders named "dir" inside a git
repository
open the .gitignore file and add " dir/ " in that file.

4)To ignore the outer folder inside a git repository

ii) -> Write /<foldername>/ in the .gitignore file
example: if we want to ignore an outer folder named "dir" inside a
git repository
open the .gitignore file and add " /dir/ " in that file.
git stash: git stash will remind you where you left the work
---------
1. in a file we have added some extra code
2. the added extra code is incomplete and the file should be saved. so
that after some we can work. it should not be moved to a staging area
3. in this case we use git stash
4. for incompleted files check status -->git status
5. it will be in the working area
6. now do stash for that file -->git stash
7. check status -->git status
8. we can see the working tree clean
9. now check the file the added extra incomplete code is also not
visible in the file
10. check the number of files in the git stash -->git stash list
11. to come back to the incomplete file we need to do -->git stash pop
12. you will see the stash file which is incomplete now open the file and
work from where you left save add. then commit the changes.
Githun Actions
---------------
GitHub Actions is a continuous integration and continuous delivery
(CI/CD) platform that allows you to automate your build, test, and
deployment pipeline. You can create workflows that build and test every
pull request to your repository, or deploy merged pull requests to
production.

-name:Run a one-line script

run: echo Hello,world!
-name: java version
run : java -version
-name: maven version
run: mvn --version
-name:python version
run: python --version
-name: docker version
run:docker -v
-name: terraform version
runn: terraform version

how to use git hub actions

-------------------------
go to repository
go to actions
new workflow
setup a workflow yourself (or) can use the suggested repository (or)
other repos accouding to your requirement
now name the file as .yml file
write jobs
example
---------
# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the workflow will run

on:
# Triggers the workflow on push or pull request events but only for the
"master" branch
push:
branches: [ "master" ]
pull_request:
branches: [ "master" ]

# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially
or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest

# Steps represent a sequence of tasks that will be executed as part

of the job
 steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job
can access it
- uses: actions/checkout@v3

# Runs a single command using the runners shell

- name: Run a one-line script
run: echo Hello, world!

# Runs a set of commands using the runners shell

- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.

apply commit to master branch (or) create a new branch and commit the
code there
now check actions you can see the created .yml file is build in actions

now go to settings to connect you machine to github

in settings under actions you will see runners
select new self hosted runner
go to your linux machine ,create a folder and switch to the created
folder
mkdir actions-runner; cd actions-runner
# Create a folder
$ mkdir actions-runner && cd actions-runner# Download the latest runner
package
$ curl -o actions-runner-linux-x64-2.298.2.tar.gz -L
https://github.com/actions/runner/releases/download/v2.298.2/actions-
runner-linux-x64-2.298.2.tar.gz# Optional: Validate the hash
$ echo "0bfd792196ce0ec6f1c65d2a9ad00215b2926ef2c416b8d97615265194477117
actions-runner-linux-x64-2.298.2.tar.gz" | shasum -a 256 -c# Extract the
installer
$ tar xzf ./actions-runner-linux-x64-2.298.2.tar.gz

configure
---------
# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/swethukrishna/GIT --token
AWLF5VSD2NLPCYKKT3CNWULDIX7SM# Last step, run it!
$ ./run.sh
github will be connected to your instance

Using your self-hosted runner

# Use this YAML in your workflow file for each job
runs-on: self-hosted

sample code
-----------

name: Java CI with Maven

on:
push:
branches: [ master ]

jobs:
build:
 runs-on: self-hosted

steps:
- uses: actions/checkout@v2
- name: Build with Mavens
run: mvn package

// Remove the runner or disconnect from linux machine

--------------------------------------------------------
./config.sh remove --token AWLF5VTWC4OWNIULBCFTWHDDIYBNI