Instead of seeing all the individual commits contained in a Pull Request, you only see one commit, and in the PR merge process you can write a detailed and dedicated commit message and description. GitHub can do that for you automatically when you are merging a Pull Request, and it’s a workflow I’ve been using a lot on public Open Source repositories in the past. You want to do one thing before that: squashing your commits. You might do a series of quick commits where the message is “ok”, “trying this”, or “fix dumb mistake”.īut at some point you need to converge to a stable state and commit the changes back to master, or to any branch you want. Committing early and often is a great advantage because you can work on your code with the confidence that you can always return back to a working state, or at least to a state you know that something worked. This is also the default when working on a team-based or open source project. In some cases however I do not use this approach, and instead I create a branch for a big feature. For example if I’m doing a simple change, or adding a new post to the blog. In projects where I’m the only developer, which means all my personal projects, I do tend to work on master when I can. Two things I do however use sometimes are cherry-picking and squashing commits. I almost never use Git in the command line, and use GitHub Desktop which is the simplest and nicest Git client ever. It can be very complex, and I tend to avoid all that complexity. The advanced things that Git can do blow my mind. I consider myself a Git fan, but …I’m not an expert of Git.Ĭommit, fetch origin, pull origin, push to origin. I use Git every day and I wrote a Git guide and a Git Cheat Sheet in the past.
0 Comments
Leave a Reply. |