Quote:
Originally Posted by Barrin6
Haha I always get super guilty just wasting paper. I don't remember the name of it, but there is a product out there that you can easily write and rewrite on a notebook with a special pen that they sell. It's not suppose to smear.
Anyways, I have been spending a great deal of time learning to use git. Had trouble with my commits since they were having merge conflicts. Each time the project gets updated, I had to learn how to rebase my commits rather than pulling. Supposedly you are suppose to keep your patches on top of master? Rather than using "git pull" you are suppose to "git fetch" and rebase somehow.
My pull request is still opened but the owners asked that I squash my messages since I had way too many commits. Here is what the tree looks like.
A-Master
B-- my commit
C
D
E-- my commit that should be squashed
F-- my commit that should be squashed
G-- my commit that should be squashed
H
I
I feel like I got myself in a huge pickle by not having my commits up at the top of the tree. Anyways going to have to rebase interactively to see if I can shift everything up. I have to admit though, it's kind of scary doing all this.
Create a backup first. That's as simple as git checkout -b mybranchbackup
Then do any rebasing on the original branch.
so far I haven't seen a great use case for rebasing. It gains very little unless you're working in the same section of files as the rest of your team. Someone correct me if I'm wrong or missing something
There are definitely a lot of nits out there with regard to commit messages syntax, structure, number etc