question about Git :

I'm usually doing this when working with git and I would like to know if it's a bad thing or not. So bascially when I'm working on my dev branch and do some change, sometimes i'm committing things directly and sometimes not.

Then before doing a pull request I have to create a new branch with my current changes and also the committed ones so I use this command : git checkout -b MyNewBranch this should take all my current changes and create a new branch with this changes but also with the commited changes (i'm not quiet sure for the commited changes but it seems to appear in the pull request anyway, can someone confirm for that please ?).

So is it bad to work like this or not ? What about the commited changes in dev branch ? Do they still stay in the dev branch locally , I would say Yes. And when I do a pull request from my dev branch, after the pull request has been accepted and completed, the commits I had locally in my dev branch would be "replaced" by the ones coming from the server as long as they are the same ?

Thanks.

CodePudding user response：

1. Yes, doing git checkout -b MyNewBranch creates a new branch from your current HEAD, so that commit you are currently at, and takes all the uncommitted changes as well. You can also see it differently. There is no need to take the changes, HEAD will only point to a different branch. So nothing happens to your workspace.

2. This questions is of course opinion-based. If you feel satisfied with this process then it is a good process for you. I sometimes do the same process. After submitting a pull request I often go back to the dev branch and sync to the commits the server has, but that is not necessary. That would work like this: (git stash &&) git checkout devBranch && git reset (--hard) origin/devBranch. Regarding the commits being "replaced" I would read a couple of tutorials regarding git pull, e.g. this one.