search

metal3d / bashsimplecurses

A simple curses library made in bash to draw terminal interfaces
BSD 3-Clause "New" or "Revised" License
902 stars 117 forks source link

Git Rebasing Concerns #66

Open terminalforlife opened 1 year ago

terminalforlife commented 1 year ago

Sorry to make an Issue about this — I've nowhere else to really post it.

What's this project's stance on rebasing? I've used Git and GitHub for years, but I've never really rebased in Git before, until now. I'm actually really happy I discovered how to do it, but from looking online, it seems it can be very destructive if not done properly. That's why I'm posting here, to double-check.

I made 3 commits to my local fork of BSC, in preparation for another PR. These changes have not been pushed. I realised I missed something from the 1st commit, so I rebased back to the first commit, made the changes, then amended those changes to the commit. There were no conflicts and everything seemed to work successfully.

My concern is mainly that it'll somehow cause issues for y'all, since I don't yet properly understand rebasing. It strikes me that it'd be fine, because they were local changes and I didn't rebase to or before someone else's changes, but I'm not certain.

I'd rather be annoying and ask, than be quiet and make a mess. 😄

In order of events:

  1. Made changes. Made a commit.
  2. Made changes. Made a 2nd commit.
  3. Made changes. Made a 3rd commit.
  4. Realised I missed something in 1.
  5. Rebased to 1: git rebase -i SHA^
  6. In Vim, edited 'pick' to 'edit' for SHA.
  7. Made changes, then amended to commit: git commit --amend
  8. Continued the rebase: git rebase --continue

Maybe that'll help, in-case I didn't explain clearly.

I've looked online and git-rebase(1), but I either can't find anything concrete, or I frankly just don't understand.

metal3d commented 1 year ago

Right, I didn't gave contribution doc. I'll do it.

For now, the "master" branch is the main code base.

What to do to contribute:

Then, ensure that you're up to date with master on your side and rebase to master:

git fetch upstream master:master
git rebase -i master

Squash what you want to squash... Then push your base:

git push origin feat-name-here

And propose the PR.

At this time, the codebase is a lot messy and I didn't take the time to create de "devel" branch. I also want to add tests (probably with bats).

I prefer "one big commit" in PR than several. This is my preference, maybe others prefer several commits in PR... I don't know what is the recommendations.

I will creat a doc page to contribute, and give some recommendations.

terminalforlife commented 1 year ago

I recently successfully pushed rebased changes to one of my own repositories, confident it would've been fine. There doesn't seem to have been any repercussions. Given that and what you've said above, I will squash my commits, summarise the changes, then send the PR.

Interesting that you say to create a separate branch on the fork. I've never done that when contributing. When I fork, I bring in master, then work on that. When I've committed stuff, I just send the master branch of the fork as a PR. If you pull in the changes, you presumably pull to the desired branch anyway.

I prefer "one big commit" in PR than several. This is my preference, maybe others prefer several commits in PR... I don't know what is the recommendations.

It strikes me that there are 3 main problems with this approach.

However, apparently a lot of big projects successfully take this approach, so I suppose it can work out in the end. I don't mind squashing commits from my PRs to BSC, if that's preferred. Sometimes I do commit a ton of changes in one hit, but in those cases I usually list the changes in the commit message.

None of my repositories have a 'CONTRIBUTING.md' file or anything like that. I just add a message to the bottom of the main 'README.md' file about contributing. I guess that's me being lazy. 😆 I don't get many PRs, so I guess it doesn't matter too much.