I need to prepare for Distribution Version Control Systems for working with others on a project.  What is an easy and simple, smart, quick, and adequate approach?  Well documented and forums would be great too!

Thanks again,

Josheir

What version control system are you going to use? I assume Git, based on your previous questions about GitHub, but...

And what specifically are you looking to learn? Again, based on previous posts you already seem to have an understanding of the basic working model of Git, at least as presented by GitHub, so what is it you're interested in learning more about, exactly?

Well really I was interested in GitHub and than someone mentioned Git.  I thought GitHub was interesting because of the VStudio extensions and someone also mentioned it.  I'm not really interested in learning a lot of terminal code if I don't need too.

Specifically, which one should I learn.  Do I need to learn a terminal program?

I am wondering when I Push Commit and Sync how to make the project directories  and so forth intact so that when someone pulls they get the right directory structures for the project.  Also how to change the actual solution (.sln) file.

Also I am wondering if every change is a branch and how it appears, does it get very large and complicated.

I'm also interested when working together and if two people are working on the same files and we can't sit together because of the distance how we merge are different work efforts.  It seems to me it could get pretty complicated if there are changes on a few different files at once.  What for example if one person deleted some code and someone else used this same undeleted code in there changes.

Fifth I want to find a specific forum.

Also I don't understand the relationship between Git and GitHub.

And Finally, how do I push graphical images that are needed by the project into the right directories.

Thank you jpetrie,

Josheir

2 hours ago, Josheir said:

Also I don't understand the relationship between Git and GitHub.

"git" is a distributed version control system, a suite of software used to store and control revisions to source code.  It was originally a tool developed by Linus Torvalds to help him work with his Linux operating system kernel.

"GitHub" is a commercial web service that provides free hosting for remote git repositories and provides associated integrations with other web services that can be used in software development (eg. wikis, bug and work tracking, continuous integration and deployment).

Yes, merges between git branches (also known as pull requests, merge requests, or merge proposals) can become complicated when there are "merge conflicts."  It often requires someone to manually reconcile the conflicts.  Fortunately in practice it doesn't happen often, as can be witnessed in the Linux kernel development tree which has literally thousands of contributors.

OI git, every change is not a branch but a "commit", which is a collection of one or more files as changed tagged by a hash of the changes.  A branch is a particular labeled commit that can be moved as more commits get pushed to it (think of it as a label pointing to whichever commit is on the top of a stack).  One branch is traditionally labeled "master" but that's just a tradition, not a requirement.

You don't have to learn a the command line to use git, there are graphical shells you can use instead.  You may find as you gain more experience that you also gain more power using the command line, but I understand it may not be for everyone.

As to using git with Microsoft VIsual Studio, and your other questions, I can't help but I'm sure others here can.

2 hours ago, Josheir said:

Specifically, which one should I learn.

You will need to understand some basic Git concepts in order to use GitHub at all, because GitHub (as noted above) is just a website that provides hosting for Git repositories plus some extra stuff.

2 hours ago, Josheir said:

Do I need to learn a terminal program?

No. But if you don't acquire an understanding of Git's command-line interface, you may find it harder to track down examples and documentation for any specific operation in Git you want to perform: if you search for "how do I do <X> in git" you'll likely find examples that demonstrate the task using the command-line. If you are only going to use a GUI tool, you'll have to restrict yourself to documentation and support forums for that tool which, depending on the tool, may be sparse.

2 hours ago, Josheir said:

I am wondering when I Push Commit and Sync how to make the project directories  and so forth intact so that when someone pulls they get the right directory structures for the project.

What you commit (and push) is what other people will get when the pull. You don't have to do anything special to preserve directory structure. If you put foo.cpp in a Code/Files/Something/Whatever subdirectory of your Git repository, commit and push it, when somebody pulls it they will get Code/Files/Something/Whatever/foo.cpp.

2 hours ago, Josheir said:

Also how to change the actual solution (.sln) file.

The solution is just a file like any other. Make your changes to it (in VS, usually), and add, commit and push those changes.

2 hours ago, Josheir said:

Also I am wondering if every change is a branch and how it appears, does it get very large and complicated.

Every change is not a branch. Every change is a commit. Lots of commits will make your repository get bigger. Lots of branches might make your project get complicated. It's more a factor of how you choose to use branches than anything else. You are likely fine ignoring complex branching workflows for the time being.

2 hours ago, Josheir said:

I'm also interested when working together and if two people are working on the same files and we can't sit together because of the distance how we merge are different work efforts.  It seems to me it could get pretty complicated if there are changes on a few different files at once.  What for example if one person deleted some code and someone else used this same undeleted code in there changes.

As above, you have to reconcile these "simultaneous" changes. Git is pretty good about doing this automatically, but it cannot get it right 100% of the time. How you do this, precisely, depends on the specific tools you've chosen to use. Generally it will involve some form of looking at the base version of the file (the common ancestor of both changes), your change and their change, and picking the parts of both changes that make sense.

2 hours ago, Josheir said:

Fifth I want to find a specific forum.

I don't know of any forums specific to Git. There are old-school mailing lists but they are probably not what you're looking for.

2 hours ago, Josheir said:

And Finally, how do I push graphical images that are needed by the project into the right directories.

 

Images are files just like code, just like the solution file. Put them where they are supposed to be, add them to the repository, commit the change, and push the change.

Just now, jpetrie said:

As above, you have to reconcile these "simultaneous" changes. Git is pretty good about doing this automatically, but it cannot get it right 100% of the time.

Now, jpetrie when I work on a program on my own and I decide to go a different direction and make drastic changes to most files except there are other programmers I'm assuming communication is key and keeping in touch and staying organized.  Maybe sometimes people need to wait for others to make corrections before they can add related code?  Maybe a higher level of programming than this usually expected.

 I have a fear that if there are major code changes then there could be a piece of code forgotten to be changed to reflect the new differences possibly from simultaneous changes.  Some stray piece of code related to some other change.  How are you all not making this sort of mistake? 

How are people communicating with their team... telephone and Skype?  And how many meetings a week/day?  For me, does it sound realistic that when new code is to be written on a small project that there is a discussion of how I want to meet the objectives so that there is no need for major changes later that could adversely effect the other programmers?

Just now, Bregma said:

Fortunately in practice it doesn't happen often, as can be witnessed in the Linux kernel development tree which has literally thousands of contributors.

This sounds amazing to me, and reassuring too!  How did they do it and what is there advice and techniques for this?  Any informative links out there?  What are their philosophies?  How did they communicate?  I assume there are programming practices for working with a team that big.  

I would expect there were a lot of files but still with thousands of contributors they were sometimes working simultaneously.  They were probably highly skilled with very few mistakes and were considerate of others with there advancements.  I imagine they all had similar understanding of their code structure and programmed for the future.

I can't wait to try this, it's very exciting; unbelievable too!

Josheir

So when I push and commit and sync am I saying that this code is ready and the other programmers need to pull my changes?  And the commit is the collection of all the changes I made?

Thank you,

Josheir

One thing that hasn't been discussed much yet is what to commit and how. I used UQDS for several years, and it has a lot of good ideas for high quality software in a small development team. Unfortunately, the authors wrote it down at the divmod website, which went down. A brief summary is still available

https://twistedmatrix.com/trac/wiki/UltimateQualityDevelopmentSystem

but it's very short. Let me try to expand on it a bit.

Basically, you don't just do random stuff in a project, you have aims. There are high level aims ("make a game" is one), and low-level aims ("add asteroids"), and they go down to aims that can be resolved in a single commit ("rename function makeAsteroid to createAsteroid"). The latter aren't much use, so you won't have them often.

An aim is represented by a ticket. The ticket is the central point to find what is happening, and what has been done. Lower level aims that do a part of a higher-level aim mention the other ticket. For example you could have a high level aim be a list of lower aim tickets. In a ticket you can also discuss, and list decisions, etc.

People can assign tickets to themselves to denote they work on it.

In the version control system, there is one branch that is "hot bleeding edge", the latest working version. In the webstie above they call it "trunk", in Git, it's usually called "master", although some git branching schemes make it complicated by naming it "develop". I would recommend using "master" in Git.

You NEVER commit in master directly. When you decide to handle a ticket, you make a new branch, from the current master revision. Give it a unique name, and append the ticket number at the end like "add-asteroids-21". That way you can easily find the ticket that it belongs to. (And it also means you cannot have a branch without a ticket, which is what UQDS aims for.)

You work in such branches (you can have several at the same time, but keep it limited, or you're just confusing yourself).

In a branch, you add commits to solve whatever you have to solve. It pays to keep a single commit small and focused. Do one logical change in one commit, like rename a variable, or a function, add some function, connect a function to other code, remove some part, etc. Smaller commits are easier to review, they are less likely to have a conflict, and in the case you do get a conflict, it is simpler to resolve, since it is very clear what the commit aimed for.

Git loves small commits, and they are cheap, use it. Give each commit a proper message of what was done.

Once done, test the changes in the branch, does it solve the ticket? didn't you break other code parts from master?

If all seems fine, make a pull request. Basically saying "I am done with ticket 123, it's ready to be merged with master. Here are the changes I made, can you have a look?". I would recommend a project rule that says that the author of a branch may not merge his/her branch back to master. Someone else must check the code, and give comments for things that need fixing. If the 2nd person also approves, he/she can merge back to master, and close the ticket.

(The project rules should say who closes the ticket, and who deletes the review branch, to avoid problems there.)

It is perhaps too much at this time, but it may give a point of reference, one example how you could organize it. There are many other ways, find one that works for your project. In the project decide how you are going to work with branches, tickets, reviews, etc. Document them eg at the wiki, so there is a point of reference describing it (also useful if a new member arrives). It can be changed of course, by all means, if a team member doesn't like it, change the rules, but do have some rules agreed upon by everybody. It saves a lot of headache and confusion.

Rules may seem restrictive, but in my experience, they are not. They provide direction, so you don't have to think about it, and you can focus on the more challenging parts of being in a project, like finding good next steps, and implementing them.

"I'm assuming communication is key and keeping in touch and staying organized"  - Normally with a shared project you'd want to confer with others before making major changes, just like you'd talk to people who live in your house before you knock some walls down.

"Maybe sometimes people need to wait for others to make corrections before they can add related code?" - Yes, this is common, although obviously if you can work on unrelated code as far as possible, you won't find yourself waiting often.

"if there are major code changes then there could be a piece of code forgotten to be changed to reflect the new differences possibly from simultaneous changes.  Some stray piece of code related to some other change.  How are you all not making this sort of mistake? " - If you can talk to others and avoid working on related code, this problem doesn't exist. Obviously you can't do that all of the time. When 2 people try to commit changes to the same file, your source control program (e.g. Git) will prompt the 2nd person to try and merge the 1st set of changes into theirs before they proceed, and that programmer will make sure everything still works after they finish the merge. Additionally, all programmers can take small steps to make such conflicts less likely (e.g. make code more modular), and to make merges easier (e.g. use several small commits instead of one big one, sort #includes and other arbitrary lists alphabetically, use text-based file formats instead of binary formats wherever possible).

"How are people communicating with their team... telephone and Skype?" - However you like. Most programmers share an office with their colleagues. If you don't, then Skype is good, or any instant messenger or chat program - Facebook, Slack, Discord, etc.

"And how many meetings a week/day?" - It's common to have a "daily standup" meeting where everybody mentions what they're working on, so that the rest of the team will spot if there's any overlap. If you don't change tasks often, and your team is small, then you might not need to do this daily. You could just send a group message or email whenever you move to a new task.

"For me, does it sound realistic that when new code is to be written on a small project that there is a discussion of how I want to meet the objectives so that there is no need for major changes later that could adversely effect the other programmers?" - Yes, definitely. They can also give you feedback on the implementation and offer suggestions for improvement.

To comment on what Alberth said - I think a good branching strategy is very helpful, but I'd be reluctant to recommend that to beginners. Branching is a complex subject and even confuses experienced programmers, so I would suggest avoiding branches until you're more familiar with the standard pull/commit/push flow. Then, maybe experiment with making a small branch of your own and merging the end result back into the main branch. After that, you might be ready for git-flow or UQDS or similar.

5 hours ago, Kylotan said:

Branching is a complex subject and even confuses experienced programmers, so I would suggest avoiding branches until you're more familiar with the standard pull/commit/push flow.

Not sure how feasible that is with git.

Would you recommend rebase here then? (fetch origin/master, rebase local master onto the new origin/master). It's clean as far as I can see, but it breaks "branches X and origin/X" are pairs, and a lot of information about git use, I think.

Merging with --ff-only is not going to fly at least, and a push where you create multiple heads is going to be a nightmare as well. (Github disables multiple heads in master by default afaik, so one might not be able to do that at all, luckily). A normal merge would give you totally messed up changes afaik, at least non-usable for review, I think.