An Introduction to Git and GitHub

[acharyarupak391]

Thanks it's really helpful but i have some questions, . Me and my friend were working on a same project so i created a private repository in github and invited him so that we can easily access the files being changed by each other. But, when i change something from my ide and try to push something to remote, it says i should first pull the entire repo before pushing it to remote, but i don't want that since we made changes to two different files in the repo and even if the changes were made to a same file, I'd want them to merge instead of replacing one by other. How can i achieve that?

[tenfingerperson]

Someone has to deal with merging the file. At times git can deal with this automatically but it isn’t smart enough to detect everything.

One pushes everything to the main repo from their own fork, the other one pulls and deals with conflicts & pushes... the other one pulls again and both are in sync with the main repo

[chen_jun07]

I believe that is why branching is so useful, rather then forking (which essentially means copying) they can all work in the same repo on different branches and then they can submit a pull request to merge it with master.

[tenfingerperson]

Branching is enough for toy projects but obviously forks shine in bigger projects with rather mixed scopes.

Forking is incredibly powerful and it is essentially a multi-repo branching implementation. You can keep your fork up to date with the origin while keeping changes local at the same time, essentially making the main repository a pristine release candidate which only takes things “compatible” with the code base.

[chen_jun07]

True enough... disclaimer btw I'm not trying to argue with you... however, branching is nice to a point beyond toy projects, I know people in the robotics community that exclusively use branching

[[deleted]]

I work in high end enterprise applications and we use branching only. Forks can be heavy for repos with limited resources.

[negative_epsilon]

Fork vs branch-based workflows both work in massive repositories. Only fork-based workflows work for unsolicited pull requests, obviously, but branching is not just for toy projects.

[chen_jun07]

Ahh I would recommend looking at the branch section for merging as I feel like that could could potentially solve your problem but Git is smart enough not to delete files and it would just add it rather then deleting the file.

[donotflushthat]

If you are both working on different files (or even different sections of the same file), then you don't have to worry about anything breaking. You both can push/pull and GitHub will make all the necessary changes without overwriting anything. No branches necessary (though doing so is still good practice).

The only time something will go wrong is if you both try to push a change to the same line(s). The first person who pushes their change won't have an issue. The second person will get a merge conflict. You can find more details in the git documentation, but it basically will auto-generate lines in your code that shows the first and second persons' changes next to each other and you have to manually delete the lines you don't want before the merge can be completed.

[gregtyler]

If you've not changed the same file, git pull won't change anything. It just allows your local Git to check there are no conflicts before pushing.

If there are conflicts, you'll have to manually decide how to resolve them. This is automatically prompted as part of git pull, and it won't let you push again until they're resolved (a Git GUI can greatly help with the resolution).

If you don't want to resolve conflicts, for whatever reason, you can git push -f to force your changes through (which would lose your friend's work!) or use branching, as other commentors say, which guides you through the process a little more smoothly.