SW Deploy Git

Deployment is a process consisting of steps necessary to create, change, and push contents, e.g., code, text, images, and data, to a platform that provides access for a set of users. The process is almost always accompanied by tools that support those steps.

2.0 Git Code Management

This page focuses on the code management tool git. Git is a part of many widely used deployment processes. Git supports both local control and distributed code management.

Figure 1. Git Commit History

It consists of a local repository of code and hooks to push and pull code from remote repositories. Git manages one or more branches consisting of code snapshot commits with a "Head" pointer to the latest commit on the current branch.

Figure 1. shows a git commit history. It resulted from actions shown in the annotated dropdown, below:

Annotated Creation of git History

A Rust project directory tree was created with cargo for demonstrating git actions.

Figure 2. Rust Project
The Rust project directory tree was initialized with "git init".

Figure 3. Git Repo Init
If you place a file named .gitignore in the git repository root and name each file or folder that you don't want tracked, that will avoid putting a lot of temporary files into the repository.

Figure 4. .gitignore contents
Figure 5 shows the current state of git's working tree. The git root, demo1 contains a hidden directory .git that contains all of the repository's private working folders and files.

Figure 5. git Repository Tree
The files in demo1 were staged for commit with the command "git add -A".

Figure 6. Staging files with "git add -A"
The files in demo1 were commited with the command "git commit -m<commit #1>". That results in commit #1 on the default "main" branch. That saves a snapshot of all changed files in the git repository.

Figure 7. Commit Files to git Repository
The results of this first commit are shown by cargo run.

Figure 8. cargo run
Next, we edit main.rs to display a new message and commit.

Figure 9. Edit main.rs and commit

Figure 10. git log after second commit

git logs can be compressed using the "--oneline" option.

Figure 11. Compressed Log
Created a new "test" branch:

Figure 12. Creating a new Branch

git Log shows new branch.

Figure 13. Created Branch test

Switch to branch test with "git checkout test".

Figure 14. Switch to test branch
On branch test, factored out display.rs file, as new module.

Figure 15. Running refactored test
git status shows the modified and new files.

Figure 16. git status after refactoring
Now add and commit. The test code snapshot is shown in Figure 20.

Figure 17. add on test branch

Figure 18. Commit #3 on test branch

Figure 19. Latest git history

Figure 20. Code on test Branch
Switching back to main branch, git replaces code in working tree with that of main.

Figure 21. Switching to main branch

Figure 22. Code on main Branch
The git reflog display shows everything we've done so far.

Figure 23. Code on main Branch
Now, we're ready to accept the test configuration and merge back into main.

Figure 24. Checking status before merging
The command git diff lets us evaluate conditions for merge.

Figure 25. branch differences
Here's the (successful) merge command.

Figure 26. git merge <src> <tgt>
Now, one last edit to add comments to the merged files. Then add and commit.

Figure 27. Add comments, add, and commit on main branch

Figure 28. Current git History

Figure 29. Final Code with Comments

Summarizing, in this demo we:

Created a project directory tree with the Rust tool Cargo
In the project directory, demo1, we initialized a git repository, then viewed git status, added the project files, and make the first commit, commit #1.
Then modified the program's message text, added then commited to create commit #2.
We created a test branch, and on that branch refactored the project code into a main.rs file and a module display.rs.
That was added and commited to create commit #3.
We were satisfied with the test change, so decided to merge test and main.
The process consisted of making sure the working tree was clean, displayed a diff of the two branches, and then merged them.
The last step was to clean up the merged code by adding comments.

The intent of all this is to show, with images and a small amount of text, how git supports code management.

Git is associated with a directory tree that contains all the files from the Head commit. If any of those are changed, they are visible to git, but need to be staged with an add command and commited to update git's repository.

Users can add branches and start committing to a new branch without affecting the main branch's code. When switching branches, git replaces code from the source branch with code from the target branch. That is a repeatable process.

It is important to commit any changes before adding or merging branches. Merges can fail and can be successfully reverted only if everything was committed before the merge attempt.

Users can change the Head pointer to another branch with "git checkout <branch> or move backward in the commit history with the command "git reset [--soft | --hard] <commit id>". That movement will cause the code within the git directory tree to change to match that of the commit referenced by Head.

The --soft option makes code from the source commit untracked while removing all commits after the target commit. So, a subsequent add command and commit will create a commit with the same contents as the original source without the removed commits. The --hard option permanently deletes all code modified or created after the reset target.

3.0 Selected git Commands

Command	Description
git init	Create a git repository rooted at the current directory. The repositor's contents are stored in a hidden .git folder. A .gitigore file defines file types that should not be tracked, using a pattern for each one on a single line.
git status	displays any files or folders that have been created, modified, or deleted
git add -A	stages all changes for commit
git commit -m"message"	Captures a snapshot of all the current files in the working directory tree.
git commit -m"message" -- <file1>, ..	Captures a snapshot of one or more specific files in the working directory tree.
git branch <name>	Creates a branch site at the commit pointed to by Head.
git checkout branchname	Switches to the named branch, changing all code in the working tree to match the latest commit on that branch. This process is reversible. Before checkout commit to a clean working tree.
git log [--graph \| --oneline]	Display all commits. The option --oneline provides a compact display with less information. Option --graph shows a compressed graph with separate branches. To view all relevant details use git log --stat --summary
git reflog	Display commits, checkouts, resets, ...
git reset [--soft \| --hard] <commit id>	Moves Head backward in history to the named commit. That changes code in the directory tree to that of the named commit. The --soft option makes the original Head code unstaged, so that can be added and committed. The result is removing the intervening commits. The --hard option permanently deletes all additions, modifications, and deletions after the target commit.
git diff <src branch> <tgt branch>	Displays differences between code in those branches. Use this to set code for successful merges.
git merge <src bran> <tgt bran>	Attempts to merge code from the two branches. This may fail. If you committed both branches to a clean state before merging, then the command "git reset --merge" will return to the pre-merge state. References: How does git merge work?
git remote add <name> <url>	Establishes connection string for push and pull commands.
git push <remote name> <branch name>	Pushes local changes to remote repository.
git pull <remote name> <branch name>	Pulls changes from remote repository.

4.0 References

joshnh Git-Commands (github)
lat git-tutorial (github)
datacamp tutorial
getting-started-with-git (github)
How does git merge work?