CODEWITHSUNDEEP
gitgithub
user8363
user8363

Reputation: 155

Pushing changes based on old commit, how to resolve?

I just went through all the available exercises at http://learngitbranching.js.org/ and i feel very confident right now. I understood all of it and did each exercise without having to think too much. Obviously these are just beginner exercises and I am just a Git novice right now, but it felt good to understand something. Now i can properly version control my work instead of relying on copying files of working versions.

Anyway, I have a question regarding merging back into a remote that might introduce a bug/

Consider this scenario:

I check out the latest master branch on the remore repo on monday and branch it locally to work on a new feature. This feature let's say interacts with some class methods in a custom defined class,

Now on tuesday my friend checks out the master branch and he branches it locally and decides he has a better way for the same class to operate. So he goes ahead and makes changes to the class, maybe deleting some methods inside it and writing different ones. Lets say he commits these changes and pushes them back into origin/master on the remote on wednesday.

Now its thursday and i just spent the last three days writing new features that interact with a class that was updated. Let's say my features require some of the class methods that my friend deleted when he updated how the class works. I do a pull and push and what happens?

I assume what happens is that when i pull my files will update with the latest version of the class and methods inside it, and my feature that might be a separate file will merge with the new master thus including a file that references a now-obsolete version of the class. So when i push i just pushed features that won't work and will have bugs (or worse not even compile) because it references methods that don't exist.

Is this common? How is this resolved in production? Do you just need to verbally communicate to your team work when a particular class has changed and that anyone working on a feature related to that class needs to base their features on the new class?

Upvotes: 2

Views: 350

Answers (3)

Pandya M. Nandan
Pandya M. Nandan

Reputation: 682

Is this common? How is this resolved in production? Do you just need to verbally communicate to your team work when a particular class has changed and that anyone working on a feature related to that class needs to base their features on the new class?

Yes, it is common as it may sound and also it is not git who can do anything here. We as developer need to make sure that we test our code on regular basis (periodically like an hr or daily basis).

I believe this is what you should try for:

  1. cook code and run test
  2. rebase and run test
  3. send for review rebase and run test
  4. merge to master branch and test again
  5. deploy on dev server and smoke test the feature, along with other functions if possible
  6. recheck on stage run test and then prepare for deploy
  7. deploy to prod and be happy

Upvotes: 2

Sergio Tulentsev
Sergio Tulentsev

Reputation: 230386

I'd say, it's on you to make sure that your feature works. Yes, better team communication will help in determining such conflicts, but ultimately, it'd be you who pushed broken code.

After you pull and resolve merge conflicts (if any), make sure that the feature works. Run tests (you have tests, right?). Push if you are confident that it works.

Also, it is not clear from your question if you do this, but, as VonC says: you don't push to master. You push your branch to the remote repo and then send a Pull/Merge Request.

It is less of a problem if you have some kind of staging environment (that is, new commits don't go directly to production). In this case, even if you miss something, it has second chance to be detected when someone clicks through the app on staging.

Upvotes: 2

VonC
VonC

Reputation: 1325155

I assume what happens is that when I pull my files will update with the latest version of the class and methods inside it

What you do is actually is:

git checkout yourBranch
git fetch
git rebase origin/master

That will replay yourBranch on top of the updated origin/master.

Then you compile, check if everything is running, run your unit tests, ....
And only then you push back your branch, and make a pull request (GitHub) or merge request (GitLab) in order to trigger a code review and a merge back to the remote master branch.

The idea remains: test locally if your code is still working, then push back and go through a code review (pull/merge request): that is where the communication naturally takes place, through code comments.

Upvotes: 2

Related Questions