So let say I am working on a feature, X
I worked directly from the
mainor default branch and even made commits and pushed to GitHub. This is so wrong and unacceptable, especially when I had been told to create a new branch from the
main. The worse part was when I had admin privileges.
Always create a new branch from the main before you touch the code.
Pull and merge the
mainbranch to the branch you are working on before you push. This will be done by the maintainer mostly when merging
mainbranch. So why did I say you have to pull and merge? Well, there could be some changes made to the
mainbranch and such changes (merged to
featureX) gladly reduces merge conflicts.
Make a lot of commits, reasonable ones, as such. So for
featureX, let say we break the implementation into about 4 steps. Then I'd encourage you to make a commit after each phase.
Always initialize git in the root directory of your application. You have the application developed already but you want to push it to GitHub. You then initialize git in one of the folders in the application root directory - massive dramatic human error. You then realize only part of your application exists on GitHub, magic.
Add and always put the
.gitignorefile in the root directory of your application. Deleting unwanted files or binaries is so not awesome until you delete a file you should not have had deleted. There is the trash can but for
shift + delguys, there is not.
Always, at least, scan through your code before pushing. It sucks during a review, the reviewer asks you if you can not spell. This is unavoidable on it own as we type but try to. This can affect you is a fun way.
If you messed up with a branch, a commit will save you if you have been making frequent meaningful commits. Do not delete the whole project because of a mistake on a branch and trying to clone a new copy of the project. You can just create a new branch from the
mainand start working again.
Have a backup of your
.envfile paths are usually added to
.gitignore. So when the project is deleted from your pc, there won't be a
.envfile when you clone the project again.
I used to do
git branch featureYfrom the
git checkout featureY, which could be done straight away as,
git checkout -b featureY.
Sometimes doing a pull after a fetch resolves a lot of conflicts. What was the simple way you solved a merge conflict?
Git push on branch
git push featureZ, does not work since there is nowhere remotely does branch for
featureZexit. I had to do,
git push --set-upstream origin featureZ. I learnt and often use,
git push origin featureZ, and it works. Well, is there any difference between the two commands and what is it?
Fixing merge conflict remotely (on Github) is quicker compared to locally. I learnt that say, I want to merge
main. Locally I would fetch any changes with
git fetch. Secondly, checkout into
featureX. I then merge
featureX, fix any conflicts if there exists any. I checkout into
mainif everything works out fine. I finally, merge
git merge --no-ff featureXand push to Github. What is the use of