There are two types of commits. The first type is the commit you make locally on your laptop with VS Code. The second type of commit is the one you push up to GitHub.
There are a plethora of variations for these two types of commits.
For example, in the case you’ve pushed the commit to GitHub, there is a big difference if there are multiple people working on the same branch or if you are the only person working on the branch.
Let’s say that there are three people working on the branch main. If you commit your code to main and then someone else uses your code, you should not amend your commit. The only way to ensure that no one else uses your code prior to making an amend to your commit is to not amend your public commit.
However, if you’re the only person working on your branch, then it is safe to amend your commit.
commit — amend
Prior to pushing a commit to GitHub, it’s straightforward to use git commit --amend to add additional code to a local commit.
With this technique, it’s easier to justify spending more time on a commit message and breaking the commit message up over multiple lines.
It’s possible that over the summer, we may even move to using a subset of Conventional Commits in an attempt to standardize on commit messages.
Problems start occurring when the commit is already pushed to GitHub and I want to amend a commit that I already pushed up.
push — force-with-lease
One way to handle this is to use git push --force-with-lease to overwrite the last commit.
Additional information is available here.
status, log
There are several other simple commands to help with git commits. Using git status, you can see what files have been modified and not staged.
git log will show a summary of recent commits.
After adding the file, git status will show the file as modified and in green.
I’m still learning what to put into the commit messages. I may need to start using a CHANGELOG.md file. Using git commit with no -m, you can use an editor for the commit message.
There is no formatting on the commit message on GitHub.
Publish new branch on GitHub that only you work on. The name of the branch could include your name.
Example commit
git commit -m "added map from tiled"
[6_tiled 4b02089] added map from tiled
9 files changed, 115 insertions(+), 9 deletions(-)
create mode 100644 .metadata
create mode 100644 assets/images/world/Blue.png
create mode 100644 assets/images/world/Dust Particle.png
create mode 100644 assets/images/world/fruit/pineapple.png
create mode 100644 assets/images/world/terrain_16x16.png
create mode 100644 assets/tiles/level_1.tmxpush to branch 6_tiled on GitHub
git push -u origin 6_tiled
Enumerating objects: 24, done.
Counting objects: 100% (24/24), done.
Delta compression using up to 12 threads
Compressing objects: 100% (14/14), done.
Writing objects: 100% (17/17), 13.11 KiB | 4.37 MiB/s, done.
Total 17 (delta 4), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To github.com:codetricity/charlie_chicken.git
87363c9..4b02089 6_tiled -> 6_tiled
Branch '6_tiled' set up to track remote branch '6_tiled' from 'origin'.Example Branch and Pull Request
using branches more effectively
Although using push — force-with-leasewill work, it likely won’t work in the long-term if there are multiple people committing to the same branch. For example, everyone is committing to main.
From what I can tell, on a small code base, a human manager needs to assign an appropriate set of tasks to another team member and then the team member needs to create a branch that is later merged into the main branch.
Unfortunately, due to our limited experience managing human task assignment, we’ve often encountered merge conflicts. Sadly, people end up committing to the main branch frequently to avoid conflicts.
I know there’s a better way, but it will take more work.
next steps
I hope that better commit messages and organization will help us see what the other team members are doing. Ultimately, it may help with task assignment.
