GitHub questions - How to maintain a custom A3W

So, I set up Github and cloned the a3wasteland repository because I would like to implement some changes on the current version of a3wasteland. Previously I did this by just downloading the 0.9f release files and making changes offline. This time, I'd like to be able to do it properly but my understanding of the process is not very clear.

Here's a theoretical setup with a3wasteland containing just 3 files:
a3w-1-revive-9gh.sqf
a3w-2-revive-9gh.sqf
a3w-3-revive-9gh.sqf

Say I branch this and edit a script in one of the files:
a3w-1-revive-jumbo-9gh.sqf (jumbo edit)
a3w-2-revive-jumbo-9gh.sqf (jumbo edit)
a3w-3-revive-jumbo-9gh.sqf

In a month's time a new feature is added to revive:
a3w-1-revive-9gh.sqf (laser sharks added)
a3w-2-revive-9gh.sqf
a3w-3-revive-9gh.sqf (laser sharks added)

So some scripts are edited and some remain the same as 9gh. At this point, what is the best way to add laser sharks to my branched version and update to 9i while keeping my changes? Can I create a diff to show all changes and manually add the required ones or is there a different way to do it? Would the new changes be considered upstream or downstream? I don't really understand the terminology or methodolgy but I'm sure Github is used for these sorts of scenarios. I understand that the devs are busy so perhaps someone in the community can answer please?

The main method for combining branches is by using Git Merge. The recommended workflow to maintain an alternate version of the mission is the following:

• Fork the main probject on GitHub; this will give you your own repository to make changes on.
• Clone the repository on your own computer using a Git client of your choice (TortoiseGit, SmartGit, GitEye, GitHub Desktop, etc.)
• You will most likely have to spend some time learning how to use your Git client, especially for: pulling, fetching, committing, pushing, merging, and comparing (fixing conflicts).
• Using a Git client is not easy if you're new to source control, or if you came from a simpler VCS like SVN. It may involve a lot of trial and error; it took me several months to harness the power of Git, and I still learn stuff every day. Although, you just need basic knowledge to maintain a fork. The best bet for starters is to avoid the command line as much as possible, no matter what so-called Git experts tell you (unless you're trying to fix something you broke)
• As you make changes to the code, files will start getting marked as "changed" in your Git client. Once you're satisfied with your current changes and everything seems to work, it's time to "commit" everything, which will save your changes in your local Git database. There are many ways to commit changes, you can either put all your changes in a single commit, or make multiple commits for different files to better separate smaller changes.
• When your commits are done, you can "push" your repository; this will upload your commits onto your GitHub repo.
• To update your fork to the latest vanilla changes, you're gonna have to merge the vanilla repo into your own; this process is different from one Git client to another, but it generally involves the following:
  
  • register the Git address of our vanilla repo as a "remote" in your local repo
  • fetch the data of the vanilla remote into your repo
  • merge the vanilla branch of your choice into your own repo
  • if there are any conflicts, you will need to fix them before completing the merge; this will involve comparing vanilla files and your modified files one-by-one side-by-side to pick which conflicted lines do you want in the final version; when compares get too complicated, usually it's easier to merge lines manually and force the merge process to accept your version of the file
  
  When the whole thing is complete, you can finish the merge, and then you'll be able to push your stuff back onto GitHub.

This whole thing is really complicated from the start, but once you get used to it then it gets relatively easy (except when you have a huge amount of conflicts, it can take hours or even days to fix everything, but this is very rare).

Hopefully the length of this post didn't discourage you from using this method. Some people use other methods, for example merging all the changes manually side-by-side and then doing a single huge commit like lodac from TOPARMA, but I don't recommend this since in the end you'll end up wasting time on stuff that Git can do automatically for you.

Do not use the command line or msysGit's botched Git GUI, it'll forever make you hate Git. It's much easier to start with a real GUI. Personally, I use TortoiseGit because everything is integrated in Windows Explorer, but it's all up to you. Most other GUIs are all-in-one clients where Git operations are done in their own file browser. Most commercial Git clients have full-feature free versions for personal use.

Wow, thanks for all the information. I am not put off at all, this is exactly the sort of info I need and I'm sure it will help others. My previous attempts to modify the mission were very awkward.

I will approach with caution (and keep plenty of backups )

I will approach with caution (and keep plenty of backups )

Indeed, when doing major operations on your local repo (especially just before a merge or before attempting to fix broken commits), it's always good to take a copy of the folder before moving on, otherwise you may end up with broken code spaghetti if you mess up real bad

In general, if you have committed all your changes before attempting something risky, it's possible to go back if you mess up, but it ain't always easy, and you may have to use the command line for that.

Also, try to avoid force-pushing things to GitHub at all costs, otherwise it will mess up the repos of everyone else who have cloned your repo. Force-pushing is when you try to do a normal push and Git gives an error, but you decide to bypass the error by ticking the "Force" box. Git is one of the very few things in life for which you can truthfully say "Do not use the Force, padawan" 

The only valid reason to force-push is if you need to fix crap done by a previous force-push 

I have done some source control before , but GiT is just messing with me ...

I just want to do 1 simple thing , have my code on a repo, and compare and changes from the development_main A3W branch to check and do essential commits.

This is what I have done so far ..

I created a fork from the development main A3W stratis to my repo.
Then I cloned it to my desktop. ( using GitHub for Windows )
I then created my own CRE4MPIE branch and updated my changes to that, published and synced it back up to my repo.

So i have the Development_Main Stratis branch, and I have my custom CRE4MPIE branch.

https://github.com/CRE4MPIE/ArmA3_Wasteland.Stratis/tree/CRE4MPIE

Now all i want to really do here is compare the latest dev branch with my custom branch - is that so hard to do

My brain is fried - plox help!

CP out

you mean like this?
https://github.com/CRE4MPIE/ArmA3_Wasteland.Stratis/compare/CRE4MPIE

(green compare icon on top of your git page)

you mean like this?
https://github.com/CRE4MPIE/ArmA3_Wasteland.Stratis/compare/CRE4MPIE

(green compare icon on top of your git page)

would't that then try merge my changes into the development_main branch ?

not if you keep your fingers of the pull request button, it just shows the differences

You may want to look into IntelliJ using Git integration. I have only used it once and honestly still learning it myself.  That will do what you are looking for. Some other members in here may be able to help you set it up real quick as I had to get help myself. It will allow you to merge the vanilla updates with yours and you can pick and choose what is merged and not merged. It is a pretty slick app, but even with me being a computer guy it was a  B*tch to figure out and setup.

We use TortoiseGit (Thanks to the recommendation from AgentRev)

Fork off the main mission, clone it to you computer, copy over your files, then in the future you can fetch the changes and merge what you want.

Tortoise works well indeed (as long as you dont mix up origin and push url's (see my recent stratis repo incident)  )

We use TortoiseGit (Thanks to the recommendation from AgentRev)

Fork off the main mission, clone it to you computer, copy over your files, then in the future you can fetch the changes and merge what you want.

So you are saying you would clone the Vanilla to your PC. Overwrite that with what you have. Then fetch the vanilla once it updates and pick and choose what to merge and not merge?

So you are saying you would clone the Vanilla to your PC. Overwrite that with what you have. Then fetch the vanilla once it updates and pick and choose what to merge and not merge?

Pretty much.

This is my route for updates.

I have a remote setup within TortiseGit for AgentRev and several other forks.

When I see updates, I show Log on my repo, fetch updates from remote, then I merge into my repo, correct conflicts and verify everything works. Or if someone else has a fork with something I like, I may Cherrypick the commit.

I test it, verify it works. Commit it, Push it

I will have to give that a try. Thanks for the info.

Tortoise works well indeed (as long as you dont mix up origin and push url's (see my recent stratis repo incident)  )

i was wondering about all those GoT reverts lol ...