Man, these git commands. I don't think I will ever master them.
this post was submitted on 03 Jan 2024
22 points (95.8% liked)
Git
2882 readers
4 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
founded 1 year ago
MODERATORS
Yeah it's rough. I'm having a hard time staying committed.
You just have to push through
but don't squash your feelings
Pick cherries when you can
Surely those cherries come from a remote origin.
Then check-out their due date, specially if they have been left out in a stack for too long, before you pop one out.
I suspect the answer for most people is habbit. It is what they are used to and have always done.
Personally I lean towards more linear history as it creates a cleaner commit graph and is close enough to what really happened and the exact details of small meaningless commits and merges that were created during development of something don't matter that much. If anything they add a lot of noise to commit graphs that make it harder to see what actually happened and when. I have seen code bases where the git commit graph takes up more than a full screen to render because of all the merging and it is not fun to navigate to understand what happened at some point.
Far nicer to just step back in a mostly linear history that jump around back and forth on various difference branches and merge commits. Even if it is not technically what really happened during development - as generally I only care what happened when something was merged into master, not on individual branches.
But I also prefer to work on small feature sets at a time and frequently merge back into master and not spend weeks or months working on a different branch that contains loads of changes not yet in master. My goto command for pulling from upstream is git pull --rebase=interactive --autostash origin master (no need to fetch with a pull, though my local master tends to get behind origin - not that it matters) and I will quite often git commit --amend or squash/reorder/edit things to give a simpler history before creating a PR.
But at the same time, on smaller projects it really does not matter that much. Follow the conventions of the projects you work on and do whatever you want on your own projects.
I rebase for small things, specially if no changes have happened on the "main" branch. I merge feature branches or stuff that has suffered changes in both branches, so as to have a commit that basically shows what had to be done to successfully merge them.