This is what I have learned from my colleague few days back.
My general workflow with git:
Git pull origin Dev-5.0
Then I would have worked for a day or two
Now, I want to push my changes for last 2 days. But, in mean time many people in my team also would have pushed the code.
Git commit “last 2 days commits message”
Git pull origin Dev-5.0 -> get the latest code from server again
Git push origin Dev-5.0 -> push your committed changes to the server
But, this is creating a very bad hierarchy tree in git(gitk). Like below
The problem here is, while I am committing my code I don't have the latest code from central repository. This would create a different tree hierarchy in git from my last state, and only when I push my code it will merge your local branch with the central repository. Then it will connect your local branch tree node to the central tree node.
Below is the approach which has worked out for us.
Git pull origin Dev-5.0
Then you might be working for few days
Now you want to commit your changes.
Git stash -> stash your current changes in local repository
Git pull origin Dev-5.0 -> Get the latest changes from the central repository
Now your local repository has latest changes
Apply your stashed changes on latest changes which we have pulled from central repository.
Git stash pop -> This will apply stashed changes to current changes.
If any merge conflicts, resolve them
Git commit “my changes”
Git push origin Dev-5.0 => This would fail, if somebody else has pushed the code in mean time after your last pull, so we need to pull the code again and proceed with the push.
This is how it looks, if we maintain the above procedure.
