51–60 of 201 posts
>I also push often because I'm forever aware disks can fail. In the 20+ years that I've been using computers, and ≈15 or so that I've been writing software, I've never experienced a drive failure.
Git is crazy complicated under the hood which is awesome when you mess up and need to recover something, but in general my goal is to use as few git commands as possible and keep everything as clean as possible.
That way, you won't be afraid to lose your recent work by messing something up, because you have the stash, and won't be afraid to lose your whole project/progress because you have a recente backup of it.
For instance, I have a backup script that runs everytime I shutdown my work computer so I won't have to worry if suddenly my hard drive gives up on everything.
Android is a little weird in that a build may take 6 min on the production app though. So a lot of code is written and tested on an external repo where it might take 20 sec instead and then copied in when complete. Looking clean/complete isn't the intent but that's how it ends up.
Half my PR's probably have a commit that just says "mashed potatoes", or 5 commits in a row that say "maybe it works now?". It doesn't matter, its going to get rebased/squashed to a single commit in the merge process anyway (which IMO everyone should be doing, true merges from feature branches to mainline are bad).
[0] https://nvie.com/posts/a-successful-git-branching-model/
- new features tend to be one clean PR since there's so much experimentation on what will work and lots of commits tends to slow things down -- a nominal disk backup is helpful, or even just a commit when taking a break on a branch of your own, no PRs until clean
- refactoring tends to be lots of test / experimental / ugly branches with incremental PRs, since tends to be easier to say, ok, change this one thing
- been experimenting with some third in-between mode, say add X with a bit more of a planning / sprint mindset vs. oh wow, let's see if this works
- feels like this approach is more of works for startups, probably harder to do in enterprise / large teams?
1.a. a lot of dirty commits/wip commits
1.b. a few of clean commits, when I spot changes that I know they are already a commit by itself
Before opening the PR:
2. `git log -p`: I inspect the commits I've done and I decide what should go together, what should be edited and what can stay as it is
3. `git rebase -i`: I apply the changes I've decided during 2
4. repeat 2 and 3 until I'm happy with the results
5. the last `git rebase -i`: reword almost every commit, as almost all the commits at this point have placeholder descriptions
I'm very happy with this strategy. It requires some time to get used to it but at the end my PRs are very clean and well-thought.
Here's how I address this problem. When I'm developing, but before I create a PR, I'll create a bunch of stream-of-consciousness commits. This is stuff like "Fix typo" or "Minor formatting changes" mixed in with actual functional changes. Right before I create the PR, or push up a shared branch, I do an interactive rebase (git rebase -i). This allows me to organize my commits. I can squash commits, amend commits, mov…
The only problem I have with this workflow in the command line is that I would like to be able to split changes to the same file across multiple commits. I think some GUI tools enable this, anyone know about it?
Only the keybindings are a bit weird if you're not accustomed to Vim bindings:
- Open tig
- Change into the staging view with `s`
- Select your file using the arrow or `j` and `k` keys
- Press Return to show the diff
- Navigate to the line(s) in question with `j` and `k` (arrow keys will switch files)
- Stage parts with `1` (single line), `2` (chunk parts), `u` (chunks) or split chunks with `\`
- "Leave" the diff with `q`
- You can find the keybindings with `h` in the help screen, which also uses Vim keys -- like manpages usually do