Git and GitHub 2023 CLI
Software code version control
1 Overview: how with CLI create local and remote repo and commit/push
In the fast-paced world of software development, collaborating with remote teams and utilizing version control systems like GitHub has become an indispensable part of the process of software devolopment.
Working with a remote repository and daily commits via CLI is vital in modern software development. It fosters collaboration, streamlines version control, and encourages best practices.
- Collaboration: Remote repos enable seamless teamwork by providing a shared codebase.
- Version Control: Daily commits maintain a clear history, aiding debugging and change tracking.
- Backup: The remote repo serves as a backup, safeguarding your work.
- Code Quality: Regular commits promote modular, well-documented code and best practices.
- CI/CD: Automated testing and deployment are triggered by code commits.
- Remote Work: Facilitates remote work and flexible development.
- Documentation: Commit messages document changes and aid in understanding code history.
- Code Review: Daily commits simplify code reviews and collaboration.
- Learning: A consistent opportunity for learning and growth through commit history analysis.
2 Set up tools
3 Create local/remote repos and first commit/push
In these six steps, you’re setting up and pushing a project to a remote GitHub repository.
- Firstly, you initialize a local Git repository with git init, creating a version control system.
- Then, you stage all changes with git add –all, preparing them for commit.
- In step 3, you use the GitHub CLI to create a new public repository on GitHub.
- Step 4 involves committing your changes with git commit –all, accompanied by a commit message.
- In step 5, you set up a connection to the remote repository using git remote add origin.
- Finally, you push your local changes to GitHub with git push origin master, effectively syncing your local and remote repositories.
3.1 Step1: Initialization local repo
albert@albert-virtual-machine:~/Desktop/git$ git init
Initialized empty Git repository in /home/albert/Desktop/git/.git/In this initial step, you’re initializing a new Git repository on your local machine.
The command git init is used to create an empty Git repository. After executing this command, Git responds with a message indicating that it has successfully initialized an empty repository in the specified directory, which in this case is /home/albert/Desktop/git/.git/.
This means you’ve set up a local Git repository on your computer where you can start tracking and versioning your project.
3.2 Step2: Adding Files
--all or dot (.)
add . or add * indexes all the new and modified files and stages them for a commit, except for the files that have been removed.
add -u stages all modified and removed files for a commit, except for the new files created.
add -A or add –all is a combination of both add . & add -u. It will add all new files, modified files and removed files, for staging.
In this step, you’re using the git add –all command to stage all the changes in your working directory for the next commit.
Staging means you’re telling Git which files you want to include in the next commit.
By using the –all option, you’re adding all changes, including new files, modifications, and deletions, to the staging area.
3.3 Step3: GitHub remote Repo
albert@albert-virtual-machine:~/Desktop/git$ gh repo create testcli --public
✓ Created repository AlbertProfe/testcli on GitHubHere, you’re creating a new GitHub repository named “testcli” and making it public using the GitHub CLI (gh).
The command gh repo create testcli –public initiates the repository creation process.
After successful execution, you receive a confirmation message that the repository “AlbertProfe/testcli” has been created on GitHub.
3.4 Step4: Commit
git commit --all
[master (root-commit) 0afa074] hi
1 file changed, 2 insertions(+)
create mode 100644 person.mdWith this step, you’ve committed your changes to the local Git repository.
The command git commit –all has committed your staged changes with a commit message “hi.”
The response from Git shows that one file was changed, adding two insertions, and a new file named “person.md” was created.
3.5 Step5: Link Local to Remote
albert@albert-virtual-machine:~/Desktop/git$ git remote add origin https://github.com/AlbertProfe/testcli.gitYou’re setting the remote repository for your local Git repository.
The command git remote add origin https://github.com/AlbertProfe/testcli.git associates your local Git repository with the GitHub repository you created earlier.
This allows you to push your local commits to the remote repository on GitHub.
3.6 Step6: Push
albert@albert-virtual-machine:~/Desktop/git$ git push origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 218 bytes | 109.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/AlbertProfe/testcli.git
* [new branch] master -> masterIn the final step, you’re pushing your local commits to the remote repository on GitHub. The command git push origin master sends your changes to the “master” branch of the remote repository.
Git enumerates the objects, counts them, and writes them to the remote repository, effectively updating the GitHub repository with your local changes.
The output shows the progress and confirms that the “master” branch on GitHub has been updated with the changes from your local repository.
4 pull/fetch
git pull and git fetch are two commonly used commands for updating your local repository with changes from a remote repository. They serve similar purposes but work in slightly different ways.
4.1 git pull
git pull is a combination of two operations: git fetch followed by git merge.
When you run git pull, Git fetches the changes from the remote repository and then automatically merges them into your local branch.
This can be convenient for a quick update but may lead to automatic merges, potentially resulting in conflicts that you need to resolve.
4.2 git fetch
git fetch only fetches changes from the remote repository but does not automatically merge them into your local branch.
This is useful when you want to inspect the changes before integrating them into your branch. It allows you to review the changes and decide when and how to merge them.