Git use eventflow

Question

I'm clearly using Git the wrong way, so I'd like someone to tell me what's the actual way of using it.

Basically, me and a co-worker are working on the same project. We pulled from the central repository and each one of us start working on different features.

At some point, we both have to modify the same file, so the conflict comes when one of use finish and push it to the central repository, the other needs to pull before push.

Here the issue is, whenever my co-worker push, I need to pull and merge files, this end up breaking the whole code. What is the right git event flow in this case?

Answer 1

As you Say when "change made on same file". Git have One Special Command like git Stash. When both of you working on same file and you need to pull the changes from Central repository.

You Can save your current state of Edited files temporarily by:

git stash

You’re back to your original working state.

Then Pull your coworker changes from central repository by

git pull.

Then its merged without conflicting.

git stash list

you can see the list of created stashes with unique id.

Now you can apply Stash by

git stash apply stash@{1}.

So your Stashed Changes are apply to the updated repository. You can continue to work from this Point.

Answer 2

I don't think there's a silver bullet here. If you edit the same file, conflicts might happen. It's not about your work flow, it's just how things work.

Now you might find it easier to deal with the situation by keeping your feature branches short lived (not diverging too much) and by continuously catching up (rebasing) with the master branch. That way, you will not have to resolve a large conflict at the end, but rather a small ones (easier to resolve) along the way.

Having said that, I think the key here is communication. Talk to your co-workers, very often you will be able to prevent the conflict just by knowing what others are working on and maybe waiting on their push before you start editing a possibly conflicting file.

Answer 3

You concern me a great deal when you say that a pull breaks "the whole code", but I can understand somewhat - you've got a merge conflict and you're not entirely sure the best approach on how to resolve it.

You've got a few options, but in all of these cases, communication with the other developer is paramount. You can fix bugs so that you're unbroken, but you run the risk of breaking them and repeating the cycle.

First, you've got the mantra right - if the remote has changes that you don't, Git will actively reject your pushes* until you become up to date with remote.

Next, determine what changes were made to the file that you were touching, and if they truly step on your toes. It could be that a method you were using was renamed, or rewritten in such a way that it altered your use case.

If there are such changes, talk it over with the other developer and see if those changes are needed for the next release, or can be put off until your code changes stabilizes and matures. Regardless of whose changes can be put off, commiting them under a separate branch and merging that branch after release/stablization is ideal.

If both of your changes are needed, now you have to merge. Again, talk with the other developer. You don't want to accidentally merge commits out of existence that either of you had worked on. A key tenet of ensuring that your merge went successfully is to run both of your test suites** on the resultant merge code; if your tests pass, then the merge went successfully.

A good merge tool (you'd have to look it up on Google, since "good" is highly contested) would be invaluable to have. My recommendation if you're a Mac user would be Kaleidoscope; it's pricey, but it's pretty good. If you're using IntelliJ IDEA, its merge tool can get the job done, but you'd also have to configure your project around the IDE.

The main takeaway here should be to talk with the other developer about what the changes are and why they're needed for this release/iteration/period.

• If the changes can be put off until later, put them on a feature branch and let merges into development/master continue as normal.
• If both changes are needed, merge them, but be sure to run tests to ensure there were no regressions.

^{*: You can force-push, but unless you know what you're doing and why, I do not recommend you do this at all.}

^{**: I assume that your tests are well-written and well-covered. Please don't forget this, as if there are branches that aren't covered that are critical, it will make future merges a nightmare.}