tripleblep
tripleblep

Reputation: 540

Not sure about Git pull

I'm still fairly new to Git, so please excuse my idiocy.

I ran into an issue with pulling changes from the remote repository. I had previously done alot of changes to a particular file and a team member pushed some changes that wouldn't work at all. What confuses me is how would I prevent his changes from altering what I did? Is it as simple as undoing the last commit and going from there?

Upvotes: 1

Views: 87

Answers (2)

Bijendra
Bijendra

Reputation: 10053

What you can do is

  • Commit your code locally and then take a pull
  • Rather better option is do a git fetch which will show you which files are going to be merged
  • There is a possibility that both of you have worked on some files in common, still if you guys have worked on different lines then they are merged recursively with no conflicts.
  • In case there are conflicts, resolve them considering which is correct and then then again commit the resolved files. Then finally push the code and you changes are successfully pushed.

Upvotes: 0

Michael Durrant
Michael Durrant

Reputation: 96614

As git is a distributed version control system, it depends on which trust model you use. As you and they have probably both changed master in this case and you are both (probably) doing git pull origin master. When you do this (or the git fetch and git merge that it actually comprises of) you are basically saying that you trust any changes that other people have made, i.e. other people who have been given access to write to the repository. So this is probably where you are today.
I would recommend you consider doing an interactive rebase (e.g. git rebase -i HEAD~10) which would also let you simply delete commits ot of the history. I say this rather than just undoing the last commit because you'll need to commit your changes, and pull his which will now be older commits and harder to reach. But use rebase interactive with great caution. I recommend you back the entire project up to another directory when learning to do such things. Examine the results carefully before committing and pushing them.

There are lots of options going forward so that it doesn't happen again, here are some:

  • Work in branches

  • Do git fetch first and examine the changes that are brought down into your origin tracking branch before merging them in.

  • Appoint one person to review and approve changes

For more info on your options, please see the fetch merge and rebase options in:
git branch, fork, fetch, merge, rebase and clone, what are the differences?

Upvotes: 1

Related Questions