Git Tutorial, Conflict Resolving and Best

Practices
------------------------------------------------------------------

 Introduction to Git:
Git is a distributed version control system used to track changes in source
code during software development. It allows multiple developers to collaborate
on projects efficiently.

 Key Concepts:
=> Repository(Repo): A collection of files and their revision
history.

=> Commit: A snapshot of changes made of repository.

=> Branch: A parallel version of the repository which allows

developers to separate lines of development.

=> Merge: Combining changes from different branches.

 Installing Git:
=> Git installation is important for the availability of Git
compatible version and all its functions and features.

=> Git installation steps may differ for different operating

systems.

=> Refer for more information:

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

 Configuring Git:
=> Now that you have Git on your system, you’ll want to do a few things to
customize your Git environment. You should have to do these things only once on
any given computer; they’ll stick around between upgrades. You can also change
them at any time by running through the commands again.

=> On Windows systems, Git looks for the .gitconfig file in the $HOME
directory (C:\Users\$USER for most people). It also still looks for
[path]/etc/gitconfig, although it’s relative to the MSys root, which is wherever
you decide to install Git on your Windows system when you run the installer.

=> You can view all of your settings and where they are coming from using:
$ git config --list --show-origin

=> You can set username and email in git configs using:

$ git config --global user.name "Username"

$ git config --global user.email email@example.com

$ git config --global user.password "Password"

=> Refer for more information:

https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup

 Basic Git Commands:

=> Initializing a Repository: git init

=> Cloning a Repository: git clone <repository_url>

=> Tracking changes: git status , git diff

=> Commiting changes: git add <file_name>

git commit -m "commit message"

=> Branching and Merging: git branch <branch_name>

git checkout <branch_name>

git merge <branch_name>

=> Pushing and Pulling Changes: git push origin <branch_name>

git pull origin <branch_name>

=> Other frequently used commands:

git fetch (Fetching downloads remote branches)

git log (Displays the committed snapshots)

git rebase

git reset (Undoes changes to files in the working directory)

git revert (Undoes a committed snapshot)

 git checkout <branch_name>

 Conflicts:
=> Merge Conflict: When Git is unsure what changes to apply, so it
leans on developer for help and notifies them for a merge conflict.
Developer's job then becomes to help git determine which proposed change is
most accurate and up to date.

 Why merge conflicts happen?:

I. When more than one person changes the same line in a file and tries to merge
the change to the same branch

II.When a developer deletes a file, but another developer edits it, and they
both try to merge their changes to the same branch.

III.When a developer deletes a line, but another developer edits it, and they
both try to merge their changes to the same branch

IV.When a developer is cherry-picking a commit, which is the act of picking

a commit from a branch and applying it to another

V. When a developer is rebasing a branch, which is the process of moving a

sequence of commits to a base commit

 Ways to prevent merge conflicts:

=> Make small commits & frequently review pull requests:

Large commits usually discourages teams while reviewing and makes it

difficult to be confident over the code merging.

Small commits in greater number is far better than large commits in

comparatively lesser number of commits.

=> Avoid working on same module/component/service etc:

There is a high probability that when two developers or more works on same
module, conflict will definitely occur.

Git usually gets confused in this scenario.

If it is needed to work on same module for multiple developers, then try

to avoid merging at same time. For instance; when one developer is done with
changes, he/she pushes the changes to remote branch and then other developer starts
working in same remote branch.
 => Pay attention and communicate:

Good software developers communicate with teammates. Keep your team aware of
what files you will be touching and coordinate with your Product Manager and SCRUM Master
to avoid working on features that conflict with other features.

Even if you are working alone, pretend you are working on a team by:

-> Creating branches for different features.

-> Creating pull requests.

-> Mandate it as a practice for approvals of all team members before merging
any Merge/Pull Request.

-> Avoid allowing pull requests(PR) to become stail by informing team on regular
basis that your PR is ready to merge.

-> Avoid changing same lines of code before merging a prior change.

 Best Practices:
=> Use Meaningful Commit Messages: Describe the purpose of each commit concisely.

=> Branching Strategy: Adopt a clear branching model (e.g., GitFlow) for managing feature
development and releases.

=> Regular Commits: Commit small, logical units of change frequently.

=> Git Ignore: Utilize .gitignore files to exclude unnecessary files from version control.

=> Pull Requests: Use pull requests for code review and integration of changes.

=> Code Reviews: Conduct thorough code reviews to maintain code quality and catch errors
early.

=> Branch Protection: Protect important branches from accidental changes.

=> Use Aliases: Define Git aliases for frequently used commands.

=> Interactive Rebase: Squash or reorganize commits before merging into the main branch.

=> Stash: Temporarily store changes that are not ready to be committed.

=> Remote Repositories: Always push changes to remote repositories for backup.

=> Branch Protection: Protect important branches from accidental changes.

Transform from a Git-User to a Git-Tator

(Git + Dictator)