Source Control with Git

Source Control with Git

• Source control, also known as version control, is crucial for the software development lifecycle.
• It enables tracking of code changes, collaboration, detailed history, and reversion to prior versions.
• Source control integrates with tools like IDEs, build automation, and CI/CD platforms.
• It is applicable to code, documentation, and configuration files.
• Git, Subversion, Mercurial, Perforce, and CVS are popular SCM systems.

Types of VCS

• Version Control Systems can be local, central, or distributed.

Git Overview

• Git is a Distributed Version Control System (DVCS) for tracking code changes in software development
• It facilitates collaboration, branching, merging, and reverting.
• Git operates using snapshots rather than deltas.
• Files can be in three states: modified, staged, or committed.
• Modified files have been changed but not committed to the database.
• Staged files have been marked to go into the next commit snapshot.
• Committed data is safely stored in the local database.

Git Getting Started

• A Git repository is obtained by initializing a local directory or cloning an existing repository.
• To initialize a repository in an existing directory, use command git init
• Files are Staged using the git add command.
• Files are committed to a repository with the command, git commit.
• An existing repository is cloned using the git clonecommand.
• The command git status reports the status of the repo.
• A file's status lifecycle starts as untracked, then moves to unmodified, modified, and staged.
• New files are tracked using the git add command.
• Modified existing files are staged also using the git add command.
• git status -s provides a short status report.
• Changes are viewed using git diff (--staged).
• Changes are committed using git commit (-m).
• Use the command git push to push changes to GitHub
• To move a file use git mv commmand
• To remove a file use git rm a file

Git Ignore

• The .gitignore file ignores files not needed in the repository, such as log files, build files, & temporary files.
• Simplified regular expressions are used, using #, *, ?, [0-9], and [abc].
• Many .gitignore templates available on GitHub.

Undoing, Correcting and Restoring

• Some undos cannot be undone in Git.
• A commit is corrected using git commit --amend.
• A staged file is unstaged with git reset HEAD <file>.
• A modified file is un-modified using the command git checkout -- <file>.
• The command git restore, introduced in Git version 2.23.0, is an alternative to git reset
• A staged file can be unstaged using the command git restore --staged <file>
• A modified file can be un-modified using git restore <file>

Important Commands

• git log command views the commit history
• git config --global user.name "Name Surname" command sets the Git user full name.
• git config --global user.name command gets the Git user full name.
• git config --global user.email "[email protected]" command sets the Git user email
• git config --global user.email gets the Git user email

Git Branching

• Branching creates a divergence from the main line of development safely.
• Git branching is lightweight, with near-instantaneous operations and fast switching.

How Git Branching Works

• Git stores data as a series of snapshots and commit objects.
• Each Git commit creates a pointer to the staged content's snapshot.
• Commits include the author's name, email, and a message.
• Commits include a pointer(s) to the parent commit(s).
  • 0 parents: initial commit
  • 1 parent: normal commit
  • 2+ parents: result of merge of 2+ branches
• An initial commit to a new repository is created using the git add README LICENSE test.rb command and the git commit -m "Initial commit" command.
• There is a link to a parent commit in each next commit.
• A branch in Git is a lightweight, movable pointer to a commit.
• The default branch name in Git is master (or main on GitHub).
• Creating a new branch is done using the git branch command, e.g., git branch testing.
• HEAD is a special pointer that knows what branch you're currently on.
• The command git checkout <branch> switches to another branch.
• The HEAD branch moves forward when a commit is made.
  • nano test.rb
  • git commit -a -m "made a change"
• A new command since Git 2.23 is the command git switch
• git switch <branchname>
• git switch -c <newbranchname>

Git Branching and Merging In Practice

• A real-world scenario starts with a working software product on the master branch and a separate branch for issue #53 (iss53)
• Checkout the master branch to begin to fix an urgent bug.
• Create a new hotfix branch from the master branch.
• Test that everything works as intended; the fix is complete in the hotfix branch.
• Merge the hotfix branch back into the master branch.
  • This uses the commands -git checkout master -git merge hotfix
• You can go back to the iss53 branch, and continue the development.
• It is possible to delete the hotfix branch now that the master points to the same snapshot.
• Merge the work from issue #53 now that it is complete into your master branch by:
  • First, check out the branch you wish to merge into (master);
  • Run the git merge command
    • In cases of no direct line of ancestry, Git does a three-way merge using the two snapshots pointed to by the branch tips (C4 & C5) and the common ancestor of the two (C2); Also called a merge commit
    • Then, it automatically creates a new commit that points to it;
  • Merge Conflicts Sometimes, merge process do not go smoothly.
    • Merge conflicts may occur if you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly
      • Git adds conflict-resolution markers in conflicted files to identify and correct problematic sections. Then run git commit manually

Collaboration and GitHub Workflows

• If there is no push access to an existing GitHub project, fork it to contribute
• A fork creates a copy in your namespace where changes can be pushed.
• Contribute changes back via a Pull Request to discuss code review.
• The owner can merge Pull Request once the change is agreed on.

GitHub Flow

• Fork the project.
• Create a topic branch from master.
• Commit to improve the project
• Push this branch to your GitHub project.
• Open a Pull Request on GitHub.
• Discuss, and optionally continue committing.
• The project owner merges or closes the Pull Request.
• Sync the updated master back to your fork.

Conclusion

• DevOps practices are implemented via Git in software development for collaboration, automation, continuous integration, and deployment.
• Working on different codebase branches provides parallel development that is integrated by Git.
• Continuous integration and deployment pipelines integrate seamlessly with Git for fast and reliable software delivery.
• Quality, reliability, and efficiency of software development processes are improved by mastering and incorporating Git into DevOps workflows.

Hands on project

1. Create a remote repository for the project on github.com
2. Connect the repository with a local repository
3. Develop a simple TO DO application CRUD API on the main branch (using back-end framework of choice). Commit the code on the main branch. a) Create/Update task b) List all tasks c) Delete tasks
4. Open a new branch named frontend and switch to the branch
5. Develop a front-end application which will communicate with the back-end (display tasks, add/edit tasks on the UI)
6. Create a pull/merge request to merge the branch to the main branch
7. Switch to the main branch locally
8. Modify the back-end code to include one new property to the tasks (e.g. LastModifiedTimestamp)
9. What will happen if you try to merge the branch frontend?

Assignment

• Create a GitHub account. Add an SSH key pair to GitHub or create a personal access token.
• Clone a new GitHub repository locally.
• Add new content, stage files, commit, and push changes.
• Create develop, test, and production branches.
• Commit changes to develop, merge into other branches, and push.
• Merge to main, commit, and push when done.
• Contribute to another Git repository on GitHub by forking a colleague's repository, create a new branch, making changes, creating a pull requests, and asking them to merge.

References

• Git Flow: https://nvie.com/posts/a-successful-git-branching-model/
• GitHub Flow: https://guides.github.com/introduction/flow/
• GitLab Flow: https://docs.gitlab.com/ee/topics/gitlab_flow.html