Jump to content
  • Advertisement
Sign in to follow this  
menyo

Source control with git hub/lab?

This topic is 1424 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So i installed github power shell and opened a account at gitlab. I even got my existing project into my gitlab repository. But there are still some question remaining, how do i actually use this to backup my working project or version control?

 

My assumptions and questions:

- I need to create a branch and work that branch, if that branch fails to work i can fall back on the master.

- If that branch works i can merge it to the master project.

- If i still want to fall back on a previous branch can i still access those after i merged?

 

Am I on the right track? Or can I actually find revert every change in any file committed and pushed? Imho the tutorial i have seen are vague about how this exactly works they show you how to start and stop there.

Share this post


Link to post
Share on other sites
Advertisement

Thanks, this already provides a good read. Maybe i should fiddle around a bit with a simple test project. Still a newbie question i cannot seem to wrap my head around:

 

When working on a new branch should i pull that branch into a new folder or is this somehow all managed by git by setting the checkout to a new branch? What are the inner mechanics here? When i checkout on a branch and create some files but then checkout to master these newly added files in the branch will disappear? 

Share this post


Link to post
Share on other sites

When working on a new branch should i pull that branch into a new folder or is this somehow all managed by git by setting the checkout to a new branch? What are the inner mechanics here? When i checkout on a branch and create some files but then checkout to master these newly added files in the branch will disappear? 

 

You should create a test and play around with it.  When you switch branches, the files will appear, disappear, and change to match that branch or changeset.  If you have some changes that you will loose git won't let you checkout a new branch until you commit them or stash them.  

 

1.  Make a new project and add a couple of files, create a master branch, and check them in.

2.  Then tag that as the initial release

  git tag -a 0.1 -m 'Initial 0.1'

3.  Then create a development branch off of master.

4.  Usually, you'll create another branch off the dev branch (the feature branch) and commit work to that.

5.  If you go back to the master branch all the new files you've added to the development branch will be gone.

6.  To release something, you can either create a release branch off of development or just checkout everything into development and merge all that into master.

7.  Then you do another tag for that release (on the master branch)

  git tag -a 1.0 -m 'Release 1.0'

 

That's the basics.  If you need a hot fix, for example, you create the hotfix branch off master, not development, fix and test, then merge that into master,switch back to development, merge the hotfix into development, fix any conflicts, and you are done.  It sounds complicated, but you'll get the hang of it.  

 

It would look something like this:

 

git checkout -b hotfix-1.0 master

 

// fix stuff

 

git commit -am 'hotfix complete'

git checkout master

git merge hotfix-1.0 --no-ff

git tag -a 1.1 -m 'Release 1.1'

git checkout development

git merge hotfix-1.0 --no-ff

git branch -d hotfix-1.0

 

Or something like that.  I did all that from my head because once you start doing this stuff all the time it is easy.

Edited by Glass_Knife

Share this post


Link to post
Share on other sites

You don't need to create branches just to write new code, branches have other uses.

 

You can just work on the master (at least for smaller and personal projects). Every time you push changes it will count as a new revision of the code, and you'll always be able to revert any or all files to any previous revision. Also, pushing changes after you reverted to an old revision won't delete the revisions you ignored while reverting, it will create a new revision, so you can always have access to any code you pushed to the repository, at any time. Just make sure you send code that compiles, runs and pass all test (if you have programmed tests), and add descriptive comments of what's commited in every push. Git even has a "local" repository step, where you can do multiple commits before pushing, so try to commit only related things. If you created a new view and also updated the log system, use one commit for each if it's possible, then push everything.

 

About branches, as I mentioned, they have other uses. Say you started with the game being only for Windows and it's still in dvelopment. Now you found a friend that would like to make a Linux port, even with the current version not being finished. So, he creates a branch (or you create it and then he "switches" to it) that will have the same code at that point. Now he can work in the same repository but he won't have to adapt he's code every time you push some changes. Now, when he finished the Linux port you may or may not make a merge, or merge only some revisions, this depends a lot on the project and what you want. I worked in a company where a game had a lot of branches for different platforms, but the ports where merged for older versions of the master game (the IOS version).

 

I don't have the exact definition of when to create branches, but the example may give you a better idea of it's use. Branches are not there to handle mergin conflicts either, if you pulled the code but before pushing changes other member submited new things, you can merge things (if git can't do it automatically) and continue the push.

Edited by DiegoSLTS

Share this post


Link to post
Share on other sites


You don't need to create branches just to write new code, branches have other uses.

Well, with git the idiomatic use is to create a branch for every change.  You can create feature branches for multiple changes, too, and branch that and merge the smaller changes into one large change, then merge that.  You can even do squash commits that effective make smaller branches disappear after the fact.  You can rebase branches more easily than rebasing sets of commits.  Branching and merging in git is cheap cheap cheap.  It isn't yer grandpa's CVS with its mucho expensive branch-and-tag operations.

 

You can, of course, have long-lived independent branches a la CVS, if you want.  That happens in the Linux kernel tree, where from time to time groups of changes get cherry-picked from other trees and pulled into Linus's tree, and become official.  If nothing else, git is powerful and flexible.

 

There is no "master" branch, in fact.  There's just a whole lot of branches everywhere and the meaning of each is an external semantic.

Share this post


Link to post
Share on other sites

Really? A new branch for every change? Never heard anyone doing that.

 

That's pretty much the basic rule when using git. You could even go as far as saying "master is for merging, not for developing". Just make it your goal that master is always in a decent state, builds and isn't a messy construction site.

 

Of course the usefulness of heavy branching varies. If you're working alone and have a habit of finishing on thing before you start working on something else, then branching is somewhat pointless. If you work on a team or keep working on multiple things at once, then you absolutely should get into the habit of using on branch per "thing" (if you say "feature", keep in mind that a bug fix for something that was already merged is a "feature" as well).

 

We're using Gerrit at work, which requires all changes that get pushed to be reviewed before they get merged to master (plus, a build is automatically started to verify the project still compiles... in the future, we might make unit tests still passing a requirement as well). Since every commit turns into a review, you will quickly learn to appreciate keeping every feature separate and tidying up your branch history with interactive rebases before pushing. Of course some people just dump several changes into one, creating an absurd number of changed files, making reviews seriously annoying (because you never know which changes actually belong together) and then complain if they need to fix something, because it's all just one big mess.

 

If you find working (and especially branching) with git unwieldy, I'd suggest GitExtensions. It lets you do most tasks without needing a command line and gives you a very good overview of your repository structure. Alternatively, SourceTree looks extremely similar.

Share this post


Link to post
Share on other sites
Branches are not a list of commits. Branches are pointers to a single commit. Commits point to their parent(s). There is also a reflog of commits where the branch pointer has been recently, in case you need to examine or return to a point in your sequence of branch operations for some reason.

Making a new branch doesn't change anything until you commit to it. Even then, the commit doesn't care what branch it's in, it cares about it's parent commit. The branch pointer just happens to move with it.

When you understand that branches are just pointers to nodes in a graph of commits, you also realize that you're free to do almost anything you want to. You can move branches anywhere (with the reset command) - backwards, forwards, even to a totally unrelated commit. When you move a branch, you're not moving the commits. You're changing your viewpoint (your "working tree" in git terminology - the files that you can view, edit and then commit), and you're changing the location where new commits will be attached.

When you checkout a remote branch, you aren't editing that branch. You're making a separate branch with the same name that you can edit locally. Even though they have the same name at first glance, they are *different branches*. Your local branch is "tracking" the remote branch. This is just a convenience to let git commands infer the relationship between the two without you having to manually type it in each time. You're ALWAYS automatically working in a separate branch from everyone else, and cannot affect anyone else, until you push.

When you push, your computer copies your commits to the other computer, then asks it "please move your branch pointer to the same commit I'm pointing at...". It might deny this request, usually because someone else pushed a different set of commits without your computer being aware of it. This is a special rule the server uses to prevent people from losing work. When this happens, you need to properly join the two commit sub-graphs together such that the new commit you ask the server to move to is a descendant of the commit it is currently pointing to. You can do this in two ways: You can use fetch-and-rebase or pull. I prefer fetch-and-rebase.

The particular style you use for committing and dealing with branches in git is referred to as your "git workflow". The workflow is just the agreement the particular team has for how they go about coordinating their git repos.


At work, our workflow is:

- Checkout the branch that your sub-team is currently working on.
- Do some work, commit as necessary.
- Test your changes to make sure they work. Where I work, everyone that is able to make changes is also able to build and run the game on their own machine, and is expected to test their stuff before pushing it.
- IF code reviews are currently mandated, make a new branch at your commit, push that branch, and get it reviewed. After it's reviewed and given the thumbs-up, switch back to the local tracking branch and push it. Delete your code-review branch.


On some projects, this workflow can't be used! On some projects, you won't be able to build and test the change on your own machine. You need to have a dedicated build machine compile and test your changes instead. In THAT case, you want to push to a branch with a unique name each time, tell the build machine about your branch (it might automatically do this), and then merge back into the common branch after it tells you everything is OK. Edited by Nypyren

Share this post


Link to post
Share on other sites

Thanks for all the good information. I still, and probably will for a while, work on my project alone. But I got very comfortable with git in a couple of hours reading and testing. This thread helped me a lot better then the tutorials i found out there. I will be adopting the git workflow by Vincent Driesen, although that might be overkill for my current project it will help me organize future project as well.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!