Hacker News Reader

Comment by jancsika | Hacker News Reader

> - rediscover the arcanes required to save only what you want. Maybe I should branch and commit. Or stash. Or reset and add. Or do an interactive thingy ?

Here's something I'm trying:

1. Always branch and commit.

2. Push branch as a work in progress.

3. When branch seems ready to merge, make a new branch from that branch.

4. In the new branch, go crazy. Squash, reorder, whatever the heck.

5. If you screw something up royally in #4, delete that new branch and go back to step #3.

6. If CI succeeded for new branch, merge new branch.

7. Delete work-in-progress branch.

What kind of situations aren't covered by this approach?

View on HN

Once you're comfortable with the destructive commands, you could even drop the temporary branch and rely just on reflog for the undo. But I understand how this could be easier at the beginning.

> Once you're comfortable with the destructive commands, you could even drop the temporary branch and rely just on reflog for the undo. But I understand how this could be easier at the beginning.

Ideally, we'd make each of these "feature" branches as short and straightforward as possible but then we are out of git territory and into some kind of project management territory?

The one thing I don't like about destructive commands is that once you publish to a branch that others are working on, you should rarely* use them.

* I'd say never but I usually don't like talking in absolutes.

The point is not to get comfortable with the destructive commands. You have one WIP branch that is essentially just cloud backup. Then when you're ready to open your branch up to the world you create a new branch that you've squashed and pruned to your liking-- on Gitlab, this would be the branch for which you submit a merge request.

That new branch is the one that receives comments and revisions from all developers-- ideally none of that gets squashed or rebased.

The danger is that you silently drop data when trying to make the new branch pretty. But even in that case you still have the old WIP branch as backup, at least until you do a release. And hopefully by that time you've tested the code and had other people look at it and use it.

I really like this. I get overwhelmed by the options and want to be prudent yet have freedom to screw up.

The other benefit is that this flow encourages you to push the WIP branch to remote as early as possible. Otherwise I find I'll work too long exclusively on the local repo getting things "just right", and creating an unnecessary risk of data loss.

Specifically, for step 5:

    git reset .
    git clean -df
    git checkout -f wip
    git branch -D final

Work in progress branch can't be named the same as final branch. That's inconvenient.

reseting back based on reflog is more straightforward in terms of preparation.

Read the comment again, it's not about what can or can't be done.

Reply on news.ycombinator.com