Working on same file in different branches, keeping branches seperated and clean #21765
-
Dear all I am working on a large scale project that has been messed up by our predecessors. We are planning to clean all **bleep**ty code (maybe by rebuilding it in Laravel), but before that we have to develop the current application further. Otherwise our customer comes to a halt in production. One developer thought of a way to develop each new issue in a new branch. We have 3 main branches: “development” - “acceptation” - “master”. When a new issue arises, we branch off of master to a new branch called “issueX”. Another issue? Make branch off of master “issueY”. But when you work on both issues yourself, and you have changes on the same file code gets intermixed. Say you have made changes to “module.php” within branch issueX. After that you checkout to branch issueY and make other changes to again “module.php”. After committing, branch issueY will contain some code of issueX. Another problem is with hotfixes. I really have to change hotfix code in GitLab with the online IDE editor, because otherwise I definately will commit some development code to the hotfix branch, and therefor be putting some code live in production after deploying the hotfix! How can I checkout to different branches, committing to them without committing code from other branches? I need to be able to get my environment synced with the branch 100%. So even when I have created a new file for issueX, after checking out to issueY that new file must be gone! Probable solution Right now I am thinking of these 2 commands: git checkout issueYgit reset --hardWould that be a good way to go? Or is that a weird strategy? I would love to have your thoughts about this. Thanks a whole lot in advance! BG Maarten |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
“git checkout BRANCH” will already set files to the state they are on that branch, as long as they are “clean” (that is, have no uncommited changes), so you can skip the reset. It will not remove untracked files, but that shouldn’t be a problem as long as you don’t add them on a branch they don’t belong to. The main challenge here seems to be to branch from the right source branch, e.g. to branch both issueX and issueY from master, not issueY from issueX, because otherwise you’ll indeed end up with commits for X in the Y branch. |
Beta Was this translation helpful? Give feedback.
-
Below an example. In this case, although, I used issueA and issueB instead of X/Y. But the problem doesnt change of course. When checking out to another branch I also thought that files would change to that branch. But see above: this is issueA. I just added this line. Committed it and pushed it to that branch: git push origin issueAThis is branch issueB. The line is not there yet. So now I want to work on issueB. git checkout -b issueBgit branchSo I am on the right branch less index.php (the file I just changed)Even when I do # git log I see the commit added to issueA! So why is it mingling with other branches here? Is it because I use origin when pushing to branch issueA in one of the first steps? Thanks. |
Beta Was this translation helpful? Give feedback.
-
It’s because you didn’t change the branch between your work on issueA (including the push) and creating the new branch. If you are on the issueA branch and do $ git checkout -b issueB the issueB branch will start at the latest commit on the issueA branch. That’s the problem. You have two ways to solve that (examples assuming you want to start from master):
Either way your new branch “issueB” will start at the current state of “master”. You can use a commit ID instead of a branch name if you want. |
Beta Was this translation helpful? Give feedback.
-
Thanks so much for enlighting me. This is much appreceated and very valuable to me. Best regard, |
Beta Was this translation helpful? Give feedback.
It’s because you didn’t change the branch between your work on issueA (including the push) and creating the new branch. If you are on the issueA branch and do
$ git checkout -b issueB
the issueB branch will start at the latest commit on the issueA branch. That’s the problem.
You have two ways to solve that (examples assuming you want to start from master):
$ git checkout master
$ git checkout -b issueB
$ git checkout -b issueB master
Either way your new branch “issueB” will start at the current state of “master”. You can use a commit ID instead of a branc…