I started my first github repo this week, connected with visual studio, committing changes to feature branches, and merging pull requests into 'main'.
I'm bad at seeing code typos immediately after I do a pull request, correcting them too quickly, and inadvertently editing the code in main without pulling it current first. Then I stumble through how to resolve the terminal errors. It's scary to mess that up and then have github automatically edit (delete!) my local code. Whenever that happens, I'm using "git merge origin/main" to clear out the errors. Is that reasonable?
I'm also bad at naming my commits and pull requests in a useful way. The naming seems tedious. Does anyone use automation to auto-generate names and descriptions?
Top comments (2)
It's not common for a
git mergeorgit pullto delete your local code automatically. It either fails because there are uncommitted local changes or some committed changes turn into a "conflict" 🧨My recommendation would be to always do a
git pull origin mainwhen standing on yourmainbranch and then creating a new feature branch withgit checkout -b feat/new-feature😄Then after you commit some changes on your feature branch, you can always pull the latest changes from the
mainbranch with anothergit pull origin main. Always test that your new code works together with your newly pulledmainbranch code. Finally you can push your newly tested code to Github withgit push origin feature/new-featureto review it and merge it using the Github's web interface to spot any unwanted changes or potential new mistakes 👍Regarding Commit naming:
Hope this helps!