The core technologies of Iterative Development are Git, GitHub central project repository controlled by the project gatekeeper, and a content delivery network, like Cloudflare, deploying private Preview Internet websites, production websites, and individual team members private Preview websites.
GitHub is a Distributed Version Control Systems enabling multiple teams to work separately on the same project without having an impact on the work of others. GitHub manages an online web hosted central project repository containing all project files. It is a unified source of truth. It helps teams collaborate and maintain the entire history of project file changes.
It helps answer the questions for the lifetime of the project who changed what, where, when, and why?
Team members use the Website Development Stack to develop and deploy websites to the Internet.
The GitHub Workflow
GitHub workflow is centered on Pull Requests. The GitHub workflow works with collaborating tightly-knit team members contributing to the central project repository using the Forks. It is centered on the topic Branches workflow.
A summary of GitHub workflow for each team member is:
- Fork the central project repository creating a local project repository in individual team members GitHub account
- Clone the forked local project repository in team member GitHub account to workstation
- Creates a topic branch off the cloned local project repository develop branch
- Make topic edits and commits
- Push after each commit to the cloned local project repository in GitHub account
- Periodicity Pull from the central project repository. The develop branch will have merged accepted Pull Request
- Deploy local project repository to a private Preview website periodically for stake holders viewing. This reduces the Pull Request evaluation time because stake holders interested in topics can see how they are progressing and working with the website.
- Open a Pull Request on the GitHub local project repository to begin the process of integrating the local project repository with the central project repository
- Team members discuss, and optionally continue committing on Pull Requests.
The project gatekeeper merges or closes Pull Requests to the central project repository, and deploys the central project repository to a private Preview website website for stack holders viewing. The teams and gatekeeper continues the GitHub workflow process until stack holders agree the central project repository is ready for release to the public internet
Teams may Pull the central project repository at anytime to view and test other topic branches.
Basic Git Commands
A fork is a copy of the project repository in a team member's GitHub account. Forks let team members make changes to a project without affecting the original repository or other team members. Team members can fetch updates from the project repository with a pull command
Forks are used to either propose changes to someone else's project to which you do not have write access, or to use someone else's project as a starting point for your own idea. You can fork a repository to create a copy of the repository and make changes without affecting the upstream repository
Forking a repository is similar to copying a repository, with two major differences:
You can use a pull request to suggest changes from your user-owned fork to the original repository in its GitHub instance, also known as the upstream repository.
You can bring changes from the upstream repository to your local fork by synchronizing your fork with the upstream repository.
A clone is a full copy of a repository, including all logging and versions of files, copied from the team member GitHub account to team member workstation.
Commits keep the team member local project repository up to date on the workstation and on GitHub. If the workstation copy is damaged, the latest commit can be cloned from GitHubto the workstation.
Creating a branch is to safely diverge from a line of development and continuing on another. An example is creating a branch create a feature or to test a radical idea
Branching enables working on different parts of a project without impacting other branches. Work on a branch can be merged with other project branches.
Switching between branches and work on different projects without them interfering with each other. Branching in Git is lightweight and fast!
switches to a new branch
A quick way of switching branch on Git is to use the “git switch” command and specify the name of the branch you want to switch to.
If the destination branch does not exist, you have to specify the “-c” option (for “create branch“), otherwise you will get an error message when switching to that branch.
$ git switch <existing_branch>
$ git switch -c <non_existing_branch> Again, as an example, let’s say that you want to switch to the “feature” branch from the “master” branch.
In order to switch from the “master” branch to the “feature” branch, use the “git switch” command and specify the destination branch (which is “feature” in this case)
$ git switch feature switch branch using git switch On the other hand, if you try to switch to a non existing branch, you will get the following error message
$ git switch non-existing-branch
fatal: invalid reference: non-existing-branch To solve this error, make sure to append the “-c” option to the “git switch” command to specify that you want to switch to a new branch.
$ git switch -c non-existing-branch
Switched to a new branch 'non-existing-branch' Congratulations, you have now successfully switched to another branch and you can start working on it.
One of the core functions of Git is the concepts of the Staging Environment, and the Commit. Staged files are files that are ready to be committed to the repository.
Commits keep track of project changes. A message is required. Who changed what, where, when, and why is logged to the project history.
Commit messages matter. Here's How to Write a Git Commit Message .
Git Push to GitHub
Pull requests let teams tell others about changes that have been pushed to a branch in their GitHub account forked project repository. Once a pull request is opened by the project team gatekeeper, teams can discuss and review the potential changes with collaborators and add follow-up commits before changes are merged into the website central project repository.
The VScode development environment has several of these and other Git command built-in
restores a previous version of a file while staying on the same branch