Tag git

 Reply

Have you looked at git reflog? It shows a log of all operations on your local repo and allows you to do exactly that - find commit hashes to go back to, which you could then git reset --hard

 Bookmark

A good read - I've found that too many PRs then ends up difficult as you're constantly rebasing them to remove the constant merge commits, so am happy with a larger PR with lots of atomic commits that allow reviewing them in isolation

Recommended read: How to Scope Down PRs https://www.netlify.com/blog/2020/03/31/how-to-scope-down-prs/

 Reply

A number of Git hosting tools (GitLab and GitHub at least) use origin/HEAD to denote primary branch on the upstream so you could probably do something with that

 Bookmark

I think the general rule of thumb is "try not to support anything other than the latest version in Production and the latest development version, and even then reduce the time that there are two versions as much as possible" but with things like user-managed software, or where your path to production is slower, it can be difficult to say that.

Recommended read: Trello Android's Git Branching Strategy https://blog.danlew.net/2020/11/11/trello-androids-git-branching-strategy/

 Reply

I don't think so but https://github.com/forgefed/forgefed is a standard that's being worked on to make it possible to federated across providers for this reason

 Reply

From me it's a no - I see why some people want it, but would rather prefer they stay out of the already limited space in the commit message title, and there's a level of arguable subjectivity of what an emoji means especially as different teams, projects and cultures have views on it.

But then again, so does written language, but I feel that is at least more known?

 Bookmark

GitHub always have a great recap of the new Git releases, and this is another - I'm particularly interested in some of the changes around git checkout

Recommended read: Highlights from Git 2.23 https://github.blog/2019-08-16-highlights-from-git-2-23/