Git

When ready working on a feature branch in a project that uses GitHub, GitLab or anything else like them, one generally do git push -u origin <branch_name> and then goes to the web interface to open a pull request. Pretty much all of these platforms provide the URL to go in order to spare a few clicks. For instance: ❯ git push -u origin baba Enumerating objects: 1, done. Counting objects: 100% (1/1), done. Writing objects: 100% (1/1), 181 bytes | 181.00 KiB/s, done. Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'baba' on GitHub by visiting: remote: https://github.com/user/project_name/pull/new/baba remote: To github.com:user/project_name.git * [new branch] baba -> baba A few years ago Rado Stankov wrote a great post about a few git aliases and scripts he uses to automate things: Git Tricks . I took literally all of the tricks he shows there in my dotfiles and strongly suggest for you to do the same. ...

git bisect provides easy to use binary search approach in order to find a bad commit. This tip assumes you know how it works is in general, but always forget what the commands are precisely. Prepare a single command that tries to reproduce the bug (e.g. script, test) off tree. Bisect is about to start jumping around, so it can’t be in the tree. git bisect start: begin the bisect session. git bisect bad: mark current HEAD as a bad commit (i.e. the bug is reproducible). git bisect good <commit-ref>: some known commit in the past, where the bug does not exist. You get dropped at a given commit. Try the command/test/script from step 1 and: if the bug exists: git bisect bad if the bug does NOT exist: git bisect good Repeat until the initial bad commit is found. git bisect reset. ...