Jump to content

A Basic Modder's Guide to Git and Github


Recommended Posts

follow up question: how do I get at that command-line interface?

 

(My sum knowledge of all this is contained in Cam's original post, and that uses TortoiseGit, not the command line.)

Please don't start with CLI. You will loose time and eventually be frustrated. The GUI will give you very nice flexibility and extra features like diff's across branches/taks without being git cli master.

 

Take look at this: https://www.slant.co/topics/4985/~visual-git-guis and choose any GUI

 

My personal suggestion would be:

1. SmartGit - it's free, cross-platform, every git operation is also presented as commandline version, simple operations take one click, advanced operations are easy, every time that something was fuckedup, I manage to recover without using CLI

2. SourceTree - almost exactly as above, key difference is interface

3. GItKraken - if you like dark interface

 

If you really want CLI: https://gitforwindows.org

Edited by ALIENQuake
Link to comment

Cam (or anyone): how does one revert a set of pushed changes?

 

(It’s hypothetical, I don’t need to do it right now.)

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

 

Example: https://github.com/Gibberlings3/immutable/commits/master

Suppose that you want to revert this commit: 6189a9f

 

1. You need to preform "git reset" for the one commit before: "Minimal content in the readme" 915f587

2. Then, you need to "git push --force" to rewrite online history, you basically replacing the online version of the repo with modified local copy

3. Depends on the type of the "reset" operation (mixed, soft,hard), you can also reset all local changes to files - it's like restoring local full backup

 

What is the effect of such operation? When people will try to "pull" from you repo, they will get the error that mismatch history and they can't pull it anymore. So how software devs are dealing with such unwanted side effects? They never rewrite history: they simply revert commits and pushed new one where the changes are reverted. Rewriting history is used only when repo contain sensitive private data like passwords etc.

 

Consider the nature of you project, I won't be a big deal when you rewrite history once a while if you really wanted to do so.

Edited by ALIENQuake
Link to comment

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.
Link to comment

 

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.

 

Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones.

Edited by ALIENQuake
Link to comment

 

 

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.

 

Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones.

 

No, it's not. `revert` is the proper way to undo a pushed commit. It creates an inverted commit that undoes the targeted commit entirely.

 

The thing you are talking about, rewriting history, is arguably a bad way to work with pushed commits. It's fine for local stuff, knock yourself out, but once the commit is pushed, you should not rewrite it unless you have very good reason. Beyond `revert`, you "alter" a pushed commit by pushing a new commit that makes the desired changes.

Link to comment

 

 

 

As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

What? Like Mike says, that's what `revert` is for. No rewriting history at all.

 

Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones.

 

No, it's not. `revert` is the proper way to undo a pushed commit. It creates an inverted commit that undoes the targeted commit entirely.

 

The thing you are talking about, rewriting history, is arguably a bad way to work with pushed commits. It's fine for local stuff, knock yourself out, but once the commit is pushed, you should not rewrite it unless you have very good reason. Beyond `revert`, you "alter" a pushed commit by pushing a new commit that makes the desired changes.

 

wisp, The recommended way is ofc to create next commit where you simply revert changes. I'm just explaining how to remove/alter already pushed commits. Is not desired and should not be generally used but it's good to know why and how to eventually do it.

Link to comment

Another technical question on releases:

 

In my local repo, I created a 'legacy' folder that gathers

  • All the former files that have been modified (I am updating a very old mod, so I fix all bug reports I found AND I provide EE compatibility)
  • All the content that was unused and therefore not installed

If I push them in the remote repo, then create a pre-release for testing, this folder is included in the release, what I don't want. I really need to keep track of the latest version in the repo, but I don't wan't to release this stuff.

 

Is there an easy way to exclude the legacy folder from the release? I am not sure gitignore is the right thing to do it... :hm:

Edited by Gwendolyne
Link to comment

If you're creating releases via the Mod Packaging tool, it doesn't have any explicit support for excluding files or folders (and it won't ignore stuff you specify in .gitignore).

 

However, you could go in and modify it to exclude your specific folder. It already excludes some predetermined files depending on whether it is packaging Windows, OS X, or Linux versions (see the -x flags on lines 83, 95, and 106 here).

Link to comment

I used the release tab on github and tagged the release as pre-release for testing. I don't care if the testing release contains the legacy folder, but I would prefer no packaging it in the final release.

 

Edit: and I thought the Mod Packaging Tool was created to provide G3 formated release (exe).

Edited by Gwendolyne
Link to comment

You need to exclude the legacy files from version control. Tags (and github releases are tags) you create include all tracked files; they are essentially a snapshot of the project. Alternatively, do like Mike suggested and do not mind having the legacy files present in the tag, but exclude them when you create the archive you intend to distribute.

Edited by Wisp
Link to comment

Does someone know why under my commit messages appear something like <First Name Last Name> authored and <First Name Last Name> committed X days ago instead of just <GitHub nickname> committed X days ago? I'm not sure how I enabled that change...

Link to comment
On 11/10/2020 at 10:15 AM, AL|EN said:

@Luke

Blind shot: Assuming that you don't do anything than simple commit, check if .gitconfig user.name and user.email match the GitHub username and email.

Yes, I had to reset them in Terminal, thanks. I'm not sure what I messed with, probably something related to "git-fetch" in VSCode...

Separately, do you know how to remove commits (and their related content) from a repo (both local and remote)? I tried with "git reset --hard HEAD~5" but they keep reappearing as soon as I make a new commit...

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...