Closed lizardbird closed 7 years ago
In a normal work environment, this would be a decision that the team would make. Considering that this project is a learning opportunity and may be reviewed by potential employers later, I would advise you to keep your development branches so that you can keep a record of the development history of this app more fully.
Gotcha, will do! Also, somewhat related - I merged my first branch using GitHub, synced up local and remote, and continued working. When I created a second branch for a different set of changes, I merged using CLI to try out those skills. Everything is working and shows up-to-date locally and on the remote, but the remote repo does not show that the second branch has been merged with master (even though it has).
A) Does it matter if GitHub shows this? and if so, B) How do I make sure GitHub reflects the merge? When I tried to click on "pull request" to merge them, it says "There isn’t anything to compare. master and renamereviews are identical."
A.) The commit history of the master branch will show the merging of the feature branch, so technically the development history is still present. B.) You won't be able to do a PR on GitHub because you already did the merge locally (a PR is essentially a merge done via GitHub). The only thing you need to do is to push the feature branch to GitHub:
git push origin <feature-branch>
Perfect, thanks!
Small silly question, and Stack Overflow commenters seem to have differing opinions on the matter:
I created a new branch to remove a set of features so I could protect my master in case something went wrong. I've now completed the fix and successfully merged that branch back with the master. Since I no longer need the "remove feature x" branch, should I delete it? Or would you all prefer for us to leave all branches open/existing as part of the change history? I've read a lot of comments arguing for both rationales, so wanted to check with yall on what you'd prefer to see.
Thanks!