Let's get one thing out of the way first: rewriting Git history just for the sake of having a pretty tree, especially with public repositories, is ...
For further actions, you may consider blocking this person and/or reporting abuse
I'm always use this line to merge from another branch:
If you have conflicts and you trust in the changes of
feature_branch, I mean you know the changes in thefeature_branchare the correct, you can tell to git that take this confidence changes over the master or another branch where you need to apply the merge:In the other side:
And continue with the normal flow....
This is called "Strategy option"
Curiosity: In the event you have two branches you’ve been handed via a new project, which one can you trust as the source of truth? Typically I’ve trusted the most recent branch, but found that older branches have some better days than newer ones. Thoughts?
I look at the contents. In the event that I'm unable to reach a verdict which one is better, I trust neither
If you want some colors in the
git plogdisplay, update the--prettyflag with this instead:While I totally agree with this, your article has taught me some techniques that make me want to go rewrite my Git histories right now!
Thanks for the amazing article.
git commit --amendto add changes to the previous commit message. Hope you can give the better explanation on this.Sure thing! Any other Git commands that everyone might like to see in plain English? I'll fold them into a future post. :)
If folks are using GitHub they can use squash-and-merge to merge a PR to get the “git merge —squash” behaviour. Then the PR lands as a single commit with two parents. On the branch you merged into the git log shoes a single clean commit. In the PR brach the git log shows all the original commits which can be noisy such as making minor changes due to code review.
So this squash thing got our production Admin JWT Token out of the public repository's history, so it is a cool reason to go ahead and fix your history.
Awesome article, that I will surely check back on to, when a squash will seem appropriate, of course.
Keep in mind, it's not the squash (you could have edited the borked commit alone and kept the rest).
Also, once published the blobs will be in all clones' object databases for some time (until garbage collect). So, in all honesty this seems like a bad fix for a security risk. Instead, just revoke the admin token and generate a brand-new one.
How do you fixed the merge conflicts?
git mergetool
Run that at the command line and it will launch whatever mergetool specified in your git config. You may need to install a mergetool first, some people use kdiff3, some hate it.
Nice tips!
Rewrite histories only on commits that have not been pushed to remote repo yet, and you must make sure that it will not cause troubles to others.