1

Let me explain what is going on... We are working with small team of 3 people on one project. But for last week 2 new people was helping us. Because the real team is only 3 person, we didn't create a branches or something like this. So every time when someone need to make a push follows this scenario:

  1. Add files to index.
  2. Commit
  3. Pull
  4. Fix conflicts and mark as marged
  5. Commit again if needed and push

And right now we have a problem. For one of these new people Git behaves very strangely. Sometimes pull doesn't create any problems and sometimes like yesterday, it thinks that he modified a lot of files, which is not true... The modifications, which it see are the old version of files, which pull should update to new version... He didn't add them to index and didn't commit them, but somehow in Git repository are old files...

Someone decided to fix this problem by adding an empty line to files, having the correct version of files, because nothing else didn't want to work. But it's not entirely correct and right now is huge mess on repository. So he created a recover branch, but everyone were working on master.

How to make this new branch the current master? Also we need include local commits of other people in this new branch. Or maybe you could recommend something else? And why is this happening and only to one person??

Lui
  • 594
  • 3
  • 10
  • 23

1 Answers1

1

How to make this new branch the current master?

This solution requires that everyone on your team delete their old local master branch.

You (and only you):

  1. Backup old master branch (optional)

    git checkout master
git checkout -b master-bk

  2. Delete your local master branch

    git branch -D master

  3. Make your new branch the master branch (locally)

    git checkout newmasterbranch
git checkout -b master

  4. Force push the new master to your repository

    git push origin master -f

All your team members after you do the previous steps:

  1. Create a master backup locally (for the old master branch)

    git checkout -b master-bk-teammembername

  2. Delete local master branch

    git branch -D master

  3. Fetch new master branch from remote

    git fetch --all

  4. Checkout to new master

    git checkout master

Also we need include local commits of other people in this new branch.

Checkout this answer on cherry-pick.

Edit 1: Basically you can look at the master backup, then list the commits:

git checkout master # make sure you are on the new master branch
git log master-bk
git log master-bk --stat # to show stats on files changed
git log master-bk -p # to show actual changes

Then use the hash of the commits you want and apply them to your master branch using cherry-pick

git cherry-pick <COMMIT-HASH>

If you want to apply the changes but without a commit, add the -n flag.

git cherry-pick -n <COMMIT-HASH>

*Make sure to check the results with your team.

Other advanced solutions are available such as rebasing the branch iteratively to pick the commits you want, but be aware that modifying the history of a remote branch can turn into a mess if someone just pull the rebased branch without deleting the old one.

There is plenty of tutorials of that online, I particularily like this one

There are other tooks you can use to visualize your commit history like gitk, sourcetree, gitkraken

Julio Daniel Reyes
  • 5,489
  • 1
  • 19
  • 23
  • Ok, but what about making the new branch the master branch on git repository? What is more, why this did happen? Why only one person is causing this problem? Because it happened second time, but the first time we reverted the push, because he was only one who made some changes then. – Lui Oct 24 '17 at 13:18
  • I described the steps that you and your team members need to do to make your `newmasterbranch` the new master branch, the step 4 will push will replate the master branch on the remote repo – Julio Daniel Reyes Oct 24 '17 at 14:18
  • My guest is that, this one person was really far behind in the history when he commited changes. Pulling changes more frequently may avoid this kinds of confusions, also merge commits may be confusing, specially with conflicts resolutions. – Julio Daniel Reyes Oct 24 '17 at 14:23
  • Perhaps is time your team start to use branches? there are a lot of good tutorials on the internet, [this one](https://www.atlassian.com/git/tutorials/using-branches) helped me a lot when I started to use git. – Julio Daniel Reyes Oct 24 '17 at 14:25
  • Yeah, thanks for describing this, but I asked for this, because it was only idea. Maybe there is something better to do in our case? About branches, probably we should start using them, because team is getting bigger. – Lui Oct 24 '17 at 14:58
  • My team for instance use a branch per feature, pull requests (merge request in gitlab) for code review, and before merging they make sure their changes are up to date with the master branch by doing a rebase on their feature branches. – Julio Daniel Reyes Oct 24 '17 at 15:08
  • And what about situation if you would like to get some files from pushed files, add them to my local repo, revert some pushes on remote, and then push my local master? What I and others need to do? – Lui Oct 25 '17 at 08:12
  • In the steps for your team members, a local backup branch was created, `master-bk-teammembername` that branch still contains those commits, so they can switch to those branches (`git checkout master-bkteammembername`) to see the commit history (`git log`) once they find the commit hash they want, switch back to master and apply those commits using cherry pick – Julio Daniel Reyes Oct 25 '17 at 09:08
  • Added a bit more info on cherry-picks on the answer – Julio Daniel Reyes Oct 25 '17 at 12:32