Source Control and Git

Source Control and Git

• Source Control (Version Control) is important for software development.
• It tracks source code changes over time using a Version Control System (VCS)
• It facilities collaborative codebase work with a detailed history allowing reversion
• It integrates with IDEs, CI/CD platforms and support documentation, configuration files etc
• Popular SCM systems include Git, Subversion, Mercurial, Perforce, and CVS.
• Git is a distributed version control system used for tracking changes in source code.
• Git enables collaboration between multiple developers.
• Users can branch, merge changes, and revert to previous versions using snapshots.

VCS Types

• Local
• Central
• Distributed

Git States

• Modified files have been changed but not committed.
• Staged files are marked for the next commit snapshot.
• Committed files are safely stored in the local database (repository).

Git Getting Started

• Obtain a Git repository by initializing a local directory or cloning an existing repository.
• Initialize a local directory using the command git init.
• Staging files uses the command git add
• Committing files uses the command git commit
• Clone an existing repository using the command git clone
• Check the repository status with the command git status

Git File Status Lifecycle

• Files start as untracked, then can be staged, then committed
• Add the file, edit the file and stage the file for commit
• Remove the file to revert to unmodified
• Commit the changes

Git Tracking Files

• To track new files: git add
• A short status report can be generated with the command git status -s
• To view changes use the command git diff (--staged)
• Commit changes with the command git commit (-m)
• Push the changes to GitHub with command git push
• Move a file using the command git mv
• Remove a file using the command git rm
• Use .gitignore to ignore files (log files, temporary files, etc.).
• A collection of .gitignore templates is online at https://github.com/github/gitignore.

Git Undoing

• Undoing things can be complex, with some actions being irreversible.
• git commit --amend corrects the most recent commit, overriding the previous commit.
• git reset HEAD <file> unstages a staged file, and is considered a dangerous command.
• git checkout -- <file> discards all changes made since the last commit.
• git restoreis a new Git command introduced in version 2.23.0, providing an alternative to git reset
• git restore --staged <file> unstages a staged file.
• git restore <file> is another, dangerous, way to unmodify a modified file.

Useful Git Commands

• git log: View commit history.
• git config --global user.name "Name Surname": Set the Git user's full name.
• git config --global user.name: Get the Git user's full name.
• git config --global user.email "[email protected]": Set the Git user's email.
• git config --global user.email: Get the Git user's email.

Git Branching

• Branching results in diverting from the main line of development .
• Branching allows work without disrupting the main line.
• Git branching has lightweight operations and fast switching between branches.
• Git stores data as a series of snapshots.
• A Git commit creates a commit object which has
  • Pointers to staged content.
  • Author name and email.
  • Message entered.
  • Pointers to parent commits
    • 0 parents for the initial commit.
    • 1 parent for a normal commit.
    • 2+ parents for a merge of two or more branches.
• Initial commit commands git add README LICENSE text.rb and git commit -m "Initial commit".
• Each next commit is linked to their parent.
• A branch in Git is simply a lightweight movable pointer to a commit.
• The default branch name in Git is master, but on GitHub, it is called main.
• Creating a new branch uses the command git branch testing
• Git uses a HEAD pointer to know the current branch.

Git Branching Switching & Commands

• Change branches git checkout
• Example: git checkout testing
• The HEAD branch moves forward when a commit is made.
• Switching back to the master branch means local files change to the master branch state.
• Additional changes in the project repo create divergent history.
• Divergent history changes are visible in the logs
  • git log --oneline --decorate --graph --all
• A branch in Git is simply a file containing a 40 character SHA-1 checksum of the commit.
  • Creating a new branch has low overhead
• Create a new branch and switch to it with git checkout -b <newbranchname>
• New syntax for command since Git 2.23 is git switch <branchname> or git switch -c <newbranchname>

Real World Branching Merging Scenario

• Development starts with a functional software product on the master branch in production.
• A branch (iss53) is created to work on issue #53.
• An urgent fix is required on the master branch due to a client-reported software bug.
• Switch back to the master branch (checkout).
• Create a new branch (hotfix) for the quick bug fix.
• After fixing on the hotfix branch, and testing, merge the hotfix branch back into master: git checkout master git merge hotfix
• This is a simple "fast-forward" merge because there's direct line between commits
• Delete hotfix now that master points to the same snapshot
• Issue 53 workflow: the iss53 branch is continued, changes merged into master (git merge iss53) create a 3-way merge
• Git creates a new snapshot that results from this three-way merge and automatically creates a merge commit with more than one parent when there isn't a fast-forward merge
• Merge Conflicts will arise during merging changes to the same part of the same file

Git Branching Merge Management

• When a merge conflict happensgit commit runs manually to resolve conflict
• Git adds conflict-resolution markers to problematic files in order to help with correcting the conflicts
• Need to resolve the conflict, then run git commitmanually
• The status can be validated via git status
• Changes resolved and committed

GitHub Collaboration Workflows

• Forking is required to contribute to an existing project on GitHub without direct push access.
• GitHub copies the project.
• Contribute changes back through a Pull Request.
• The Pull Request opens a thread for code review with which code review, the owner and the contributor can communicate about the change, then merges
• GitHub workflow: Fork, branch, commit, push, request, discuss, merge, sync.

Git Conclusion Points

• Git enables collaboration, automation, continuous integration/deployment.
• Developers can work on different branches.
• Git integrates seamlessly with other DevOps tools.
• Mastering Git improves software development quality, reliability, and efficiency.
• Project Prep workflow involves creating a remote repository, developing a CRUD API, and managing branches..
• Experiment with merging branches and conflict resolution.

Git Homework

• Git repo assignements:
  • Create a GitHub account and personal access token OR SSH key pair.
  • Clone locally to Add new content, stage, commit, and push GitHub changes.
  • Create develop, test and production branches.
  • Then merge it into the other two branches
  • When complete push changes to GitHub. merge main then push to GitHub.
• Collaborating with another repo steps:
  • Fork colleague's GitHub repo
  • Create a new branch
  • Commit and push changes
  • Create a pull request via GitHub
  • Request they merge pull request and close issue